Get-MessageTrackingLog가 CAS 서버를 지나 사서함 서버에 도착하는 것으로 표시하지만 ExplicitlyDiscarded 및 HAdiscard로 표시되는 인바운드 이메일이 있습니다.
RunspaceId : f73e23f6-64e7-43b4-98bd-9871aabc5396
Timestamp : 9/28/2015 8:53:10 AM
ClientIp :
ClientHostname :
ServerIp :
ServerHostname : MAIL5
SourceContext : ExplicitlyDiscarded
ConnectorId :
Source : SMTP
EventId : HADISCARD
InternalMessageId : 47266115095789
MessageId : <C6DDD5D4A02A3742BFD356033E939FB6029F09FAEF@VPRDMBX02.outsidedomain.local>
Recipients : {[email protected]}
RecipientStatus : {}
TotalBytes : 15273
RecipientCount : 3
RelatedRecipientAddress :
Reference :
MessageSubject : Your mailbox is almost full.
Sender : [email protected]
ReturnPath : [email protected]
Directionality : Incoming
TenantId :
OriginalClientIp :
MessageInfo :
MessageLatency :
MessageLatencyType : None
EventData : {[DeliveryPriority, None], [PrioritizationReason, ShadowRedundancy], [ExternalOrgIdNotSetReason, ]}
이메일을 사서함으로 전달한 후 기본 메일 서버에서 섀도우 복사본을 삭제하는 것이 정상적인 현상이라는 것 외에는 온라인에서 아무것도 찾을 수 없는 것 같습니다. 그러나 이 경우에는 사서함 자체에 대한 최종 실제 DELIVER가 없습니다. 위 내용은 추적 로그의 마지막 부분으로, 일반적으로 사서함에 "DELIVER(배달)"라고 표시되지만 그 정도까지는 도달하지 못했습니다.
이메일이 사서함 자체에 전달되기 전에 메일이 삭제된 이유에 대해 여기에서 무슨 일이 일어났는지 확인하는 방법에 대한 아이디어가 있습니까?
답변1
이메일의 메시지 ID를 확인하세요. 다른 이메일과 메시지 ID가 동일하여 명시적으로 거부되었을 수 있습니다.
답변2
메시지가 삭제된 시점에 이벤트 뷰어의 응용 프로그램 로그를 확인하여 무슨 일이 일어났는지 확인했습니까?
로그 이름: 애플리케이션
출처: MSExchangeTransport
작업 범주: SmtpReceive
수준: 경고
또한 조직 외부로부터 사서함이 거의 가득 찼다는 경고를 받는 이유는 무엇입니까? 메시지를 삭제하는 Exchange 스팸 필터일 수 있습니다.
또한 DAG를 실행하는 경우 수동 서버가 아닌 활성 데이터베이스 서버에서 배달을 선택했는지 확인하세요. 패시브 서버에서는 RECEIVE 및 SEND가 표시되지만 DELIVER는 표시되지 않습니다.
답변3
수신자는 조직의 내부 구성원으로부터 수신을 허용하도록 구성될 수 있습니다.