Exchange Server Study (2-7). Recipient resolution in Exchange Server

이번 포스팅은 아래의 자료를 공부하도록 하겠습니다.

Recipient resolution in Exchange Server | Microsoft Docs

 

이 포스팅에서도 몇가지 단어 정의가 필요합니다.

envelope 의 단어 뜻 자체는 봉투입니다.

 

Email 시스템에서 사용되는 Envelope 단어에 대한 이해가 필요합니다.

아래의 자료에서 해당 내용을 쉽게 설명하고 있습니다.

An email message is very similar to a physical letter that you would send in the mail. There is an envelope, with To/From information, and there is the actual letter on the inside, with it's own To/From information. The envelope to/from information is the real information that is used for message delivery, for both email servers and post offices. When an envelope comes into a post office, they inspect the To address on the envelope, and send it to the correct destination. The post office workers have no knowledge of the letter inside the envelope. The letting inside could have completely different To/From information than the envelope says. The Envelope could say the message is to Bob, but the letter inside may say it's for Alice. Or in real world: The envelope could say the message is to SomeCompanyName, and when secretary open envelope, letter inside say, it's is for Mr. Brown which work in SomeCompanyName. 이메일 메시지는 우편으로 보내는 실제 편지와 매우 유사합니다. To/From 정보 가 있는 봉투 가 있고 내부에 자체 To/From 정보가 있는 실제 편지가 있습니다. 봉투 수신/ 발신 정보 는 이메일 서버와 우체국 모두에서 메시지 전달에 사용되는 실제 정보입니다. 봉투 가 우체국에 오면 봉투의 받는 사람 주소 를 확인 하고 정확한 목적지로 보냅니다. 우체국 직원은 봉투 안의 편지에 대해 알지 못합니다. 내부를 보내는 것은 봉투가 말하는 것과 완전히 다른 To/From 정보를 가질 수 있습니다. 봉투는 메시지가 Bob에게 보낸 것이라고 말할 수 있지만 안에 있는 편지는 Alice를 위한 것이라고 말할 수 있습니다. 또는 현실 세계에서: 봉투는 메시지가 SomeCompanyName 이라고 말할 수 있고 비서가 봉투를 열면 내부 편지 는 SomeCompanyName 에서 일하는 Mr. Brown 을 위한 것이라고 말할 수 있습니다. [출처] What is email envelope and email header - MyBlueLinux.COM

Envelope 과 관련된 부분은 아래의 그림으로 설명하도록 하겠습니다.

 

Recipient resolution is when the Exchange server expands and resolves all recipients in a message. Recipient resolution is responsible for these actions: Recipient resolution  은 Exchange 서버가 메시지의 모든 받는 사람을 확장하고 확인하는 경우입니다. Recipient resolution 은 다음 작업을 담당합니다. Matching the recipient to the corresponding Active Directory object. 받는 사람을 해당 Active Directory 개체와 일치시킵니다. Expanding distribution groups into a list of individual recipients. 메일 그룹을 개별 받는 사람 목록으로 확장합니다. Applying message limits and any alternative recipients to each recipient. 각 수신자에게 메시지 제한 및 대체 수신자를 적용합니다. Recipient resolution is done by the categorizer in the Transport service on Mailbox servers. Recipient resolution 은 사서함 서버의 전송 서비스에 있는 categorizer에서 수행됩니다. Each message is processed by the categorizer after the message is put in the Submission queue, but before the message is put in a delivery queue. 각 메시지는 메시지가 전송 큐에 추가된 후 배달 큐에 보내기 전에 categorizer에서 처리됩니다. The component of the categorizer that's responsible for recipient resolution is frequently called the resolver. recipient resolution 을 수행하는 categorizer 구성 요소를 보통 resolver 이라고도 합니다.

 

Message TrackingLog에서 Source-context에서 확인할 수 있습니다.

 

1. Top-level resolution (최상위 확인)

Top-level resolution is the first stage of recipient resolution that associates each recipient in an incoming message to a matching recipient object in Active Directory.

최상위 확인 은 들어오는 메시지의 각 받는 사람을 Active Directory의 일치하는 받는 사람 개체에 연결하는 받는 사람 확인 의 첫 번째 단계입니다.

 

The categorizer creates a list that contains the sender and the initial, unexpanded recipient email addresses from the message, and uses that list to query Active Directory.

분류기에서는 메시지에서 보낸 사람 및 메시지의 미확인 초기 받는 사람 전자 메일 주소가 포함된 목록을 만들고 해당 목록을 사용하여 Active Directory를 쿼리합니다.

 

아래의 진행과정을 설명해 주고 있으며

 

그리고 아래의 아이콘 위치에

 

아래의 Envelope 를 대입해서 이해하시면 됩니다.

 

When a match is found in the email address properties for mail-enabled Active Directory objects, the categorizer caches the properties of the objects, and enforces any sender message restrictions.

메일 사용이 가능한 Active Directory 개체의 전자 메일 주소 속성에서 일치가 발견되면 분류기에서 개체의 속성을 캐시하고 보낸 사람 메시지 제한을 적용합니다.

 

1.1 Recipient email addresses (수신자 이메일 주소)

Top-level resolution begins with a message and the initial, unexpanded list of recipients from the message envelope.

최상위 확인은 메시지와 메시지 봉투의 확장되지 않은 초기 수신자 목록으로 시작됩니다 .

 

The message envelope contains the SMTP commands that are used to transmit messages between messaging servers:

메시지 봉투에는 메시징 서버 간에 메시지를 전송하는 데 사용되는 SMTP 명령이 포함되어 있습니다.

 

• The sender's email address is contained in the MAIL FROM command.
• 보낸 사람 전자 메일 주소는 MAIL FROM 명령에 포함되어 있습니다

 

• Each recipient's email address is contained in a separate RCPT TO command.
• 각 받는 사람의 전자 메일 주소는 별도의 RCPT TO 명령에 포함되어 있습니다.

 

The envelope sender and envelope recipients are typically created from the sender and recipients in the To:, From:, Cc:, and Bcc: header fields in the message header.

봉투 보낸 사람과 봉투 받는 사람은 일반적으로 메시지 머리글의 To:, From:, Cc:,  Bcc: 머리글 필드에 있는 보낸 사람과 받는 사람에서 만들어집니다.

 

However, these header fields are easily forged and may not match the actual sender or recipient email addresses that were used to transmit the message.

그러나 이러한 헤더 필드는 쉽게 위조되며 메시지를 전송하는 데 사용된 실제 보낸 사람 또는 받는 사람 전자 메일 주소와 일치하지 않을 수 있습니다.

• 실제 해더의 영역은 System이 어떻게 구성되어 있느냐에 따라서 수정이 가능합니다.

 

1.2. Encapsulated email addresses (캡슐화된 전자 메일 주소)

Standard SMTP email addresses follow the specifications in RFC 5321 and RFC 5322 (for example chris@contoso.com).

표준 SMTP 전자 메일 주소는 RFC 5321 및 RFC 5322의 사양을 따릅니다(예: chris@contoso.com).

RFC 5321 - Simple Mail Transfer Protocol (ietf.org)

RFC 5322 - Internet Message Format (ietf.org)

 

However, an email address can also be a non-SMTP address that's encapsulated in an SMTP address.

그러나 전자 메일 주소는 SMTP 주소에 캡슐화된 비 SMTP 주소일 수도 있습니다.

 

Exchange supports the Internet Mail Connector Encapsulated Address (IMCEA) encapsulation method that replaces characters that would be invalid in an SMTP email address with valid characters.

Exchange는 SMTP 전자 메일 주소에서 유효하지 않은 문자를 유효한 문자로 바꾸는 IMCEA(Internet Mail Connector Encapsulated Address) 캡슐화 방법을 지원합니다.

 

아래의 내용은 쭉 읽고 지나갑니다.

IMCEA addresses use the syntax IMCEA<Type>-<address>@<domain>: <Type> identifies the type of non-SMTP address (for example EX, X400, or FAX). Although SMTP and X500 are theoretically valid values for <Type>, Exchange recipient resolution rejects any IMCEA-encoded addresses that use either of these types. <address> is the encoded version of original address: Alphanumeric characters, the equal sign (=) and the hyphen (-) aren't replaced. Forward slashes (/) are replaced by underscores (_). Other US-ASCII characters are replaced by a plus sign (+) and the two digits of the ASCII value in hexadecimal (for example, the space character has the encoded value +20). <domain> is SMTP domain that's used to encapsulate the non-SMTP address (for example, contoso.com). IMCEA addresses are returned to their original values (unencapsulated) only when the domain matches the default accepted domain in the Exchange organization. For more information about the default accepted domain, see Default domain. The maximum length for an SMTP email address in Exchange is 571 characters. This limit includes: 315 characters for the name part of the address 255 characters for the domain name The at sign (@) character that separates the name from the domain name Exchange doesn't support IMCEA-encoded messages where the name part of the address exceeds 315 characters, even if the complete email address is less than 571 characters. IMCEA 주소는 구문을 사용합니다 IMCEA<Type>-<address>@<domain>. <Type> 비 SMTP EX주소 유형(예: , X400 또는 )을 식별합니다 FAX. 이론 SMTP 적으로<Type>는 X500 및 에 대한 유효한 값이지만 Exchange 받는 사람 확인에서는 이러한 형식 중 하나를 사용하는 IMCEA로 인코딩된 주소를 거부합니다. <address> 은 인코딩된 원본 주소 버전입니다. 영문자, 등호(=) 및 하이픈(-)은 대체되지 않습니다. 슬래시(/)는 밑선(_)으로 대체됩니다. 다른 US-ASCII 문자는 더하기 기호(+)로 대체하고 16진수로 된 ASCII 값의 두 자리입니다(예: +20공백 문자에 인코딩된 값이 있습니다). <domain> 은 비 SMTP 주소(예: 비 SMTP 주소)를 캡슐화하는 데 사용되는 SMTP contoso.com. IMCEA 주소는 도메인이 Exchange 도메인과 일치하는 경우 원래 값(캡슐화되지 않은)으로 Exchange 반환됩니다. 기본 허용 도메인에 대한 자세한 내용은 기본 도메인을 참조하세요. Exchange에서 SMTP 전자 메일 주소의 최대 길이는 571자입니다. 이 제한에는 다음이 포함됩니다. 주소의 이름 부분: 315자 도메인 이름: 255자 도메인 이름과 이름을 구분하는 @ 문자 Exchange 전체 전자 메일 주소가 571자 미만이어도 주소의 이름 부분이 315자보다 큰 IMCEA 인코딩 메시지를 지원하지 않습니다.

 

IMCEA 주소는 퇴사자 발생 시나리오등 LegacyExchangeDN이 변경되거나 제거되는 경우에 접할 수 있습니다.

IMCEAEX non-delivery report when you send email messages to an internal user - Exchange | Microsoft Docs

 

예를 들면 아래와 같이 사서함이 재생될 경우 개체 값들은 변경될 것입니다.

 

Outlook 상에서 해당 사용자와 주고 받았던 메일을 회신을 시도합니다.

 

아래와 같이 NDR 이 발송됩니다.

 

실제 운영서버에서 아래의 명령어로 로그를 조회하면 쉽게 확인할 수 있습니다.

Get-TransportService | Get-MessageTrackinglog -EventID FAIL -Start (Get-Date).AddDays(-2) -ResultSize Unlimited | Where {$_.Recipients -match "^IMCEAEX*"}

1.3. Address resolution (주소 확인)

For each message, the sender's email address and all recipient addresses are added to a list that's used to query Active Directory. Any encapsulated addresses are unencapsulated before they're added to the list. The Active Directory query is performed on up to 20 email addresses at a time. If the query encounters transient errors, the message is returned to the Submission queue and deferred for the time that's specified by the ResolverRetryInterval key in the %ExchangeInstallPath%Bin\EdgeTransport.exe.config XML application configuration file that's associated with the Transport service. The default value is 30 minutes. The Active Directory recipient objects that are used by Exchange are described in the following table. For more information about Exchange recipient types, see Recipients. 각 메시지에 대해 보낸 사람의 전자 메일 주소와 모든 받는 사람 주소가 Active Directory를 쿼리하는 데 사용되는 목록에 추가됩니다. 캡슐화된 주소는 목록에 추가되기 전에 캡슐화되지 않습니다. Active Directory 쿼리는 한 번에 최대 20개의 전자 메일 주소에 대해 수행됩니다. 쿼리에서 일시적인 오류가 발생하면 메시지가 전송 큐로 반환되어 Transport Service와 연결된 XML 응용 프로그램 구성 파일의 ResolverRetryInterval %ExchangeInstallPath%Bin\EdgeTransport.exe.config 키로 지정된 시간 동안 지연됩니다. 기본값은 30분입니다. 다음 표에서는 Exchange Active Directory 받는 사람 개체에 대해 설명되어 있습니다. Exchange 받는 사람 유형에 대한 자세한 내용은 받는 사람를 참조하십시오.

• 이전에 다루었던 내용이 반복되며, EdgeTransport.exe 프로세스의 연관성이 언급되어 있습니다.

The Active Directory query classifies an object with missing or malformed critical properties as an invalid object (for example, a dynamic distribution group object without an email address). Messages sent to recipients that are classified as invalid objects generate a non-delivery report (also known as an NDR or bounce message). For each email address, the categorizer does a single initial query for all possible recipient properties (for example, the recipient identifiers, recipient type, message limits, email addresses, and alternative recipients). The applicable recipient properties are cached for later use. Recipient resolution classifies recipients based on similarities in how the recipients are resolved, and the similarity of the applicable recipient properties. The LDAP filter that's used for address resolution depends on the recipient's email address: For the EX email address type, the LDAP filter is based on the recipient's legacyExchangeDN attribute (higher priority) or the recipient's proxyAddresses attribute (lower priority). For all other email addresses types, the recipient proxyAddresses attribute is used as the LDAP filter. If the email address doesn't match the recipient's primary SMTP address, the categorizer rewrites the email address in the message to match the primary SMTP address. The original email address is saved in the ORCPT= entry in the RCPT TO command in the message envelope. Active Directory 쿼리는 중요 속성이 없거나 형식에 문제가 있는 개체를 잘못된 개체(예: 전자 메일 주소가 없는 동적 메일 그룹 개체)로 분류합니다. 잘못된 개체로 분류된 받는 사람에게 보낸 메시지는 배달 못 함 보고서(NDR 또는 반송 메시지라고도 함)를 생성합니다. 각 전자 메일 주소에 대해 Categorizer는 가능한 모든 받는 사람 속성(예: 받는 사람 식별자, 받는 사람 유형, 메시지 제한, 전자 메일 주소 및 대체 받는 사람)에 대해 단일 초기 쿼리를 수행합니다. 해당 받는 사람 속성은 나중에 사용할 수 있도록 캐시됩니다. 받는 사람 확인은 받는 사람이 확인되는 방식의 유사성과 적용 가능한 받는 사람 속성의 유사성을 기준으로 받는 사람을 분류합니다. 주소 확인에 사용되는 LDAP 필터는 수신자의 이메일 주소에 따라 다릅니다. Exchange 이메일 주소 유형의 경우 LDAP 필터는 받는 사람의 legacyExchangeDN 속성(높은 우선 순위) 또는 받는 사람의 proxyAddresses 속성(낮은 우선 순위)을 기반으로 합니다. 다른 모든 이메일 주소 유형의 경우 수신자 proxyAddresses 속성이 LDAP 필터로 사용됩니다. 전자 메일 주소가 받는 사람의 기본 SMTP 주소와 일치하지 않으면 Categorizer는 기본 SMTP 주소와 일치하도록 메시지의 전자 메일 주소를 다시 작성합니다. 원래 이메일 주소는 메시지 봉투의 RCPT TO 명령에 있는 ORCPT= 항목에 저장됩니다.

• 주소 확인에 사용되는 쿼리 흐름에 대해서 설명하고 있습니다. 현재 단계에서는 다루기 어려우므로 해당 파트는 기회가 되면 별도로 포스팅하겠습니다.

 

1.4. Sender message restrictions (보낸 사람 메시지 제한)

The size of a message can change because of content conversion, encoding, and agent processing. When a message enters the Exchange organization, the original size of the message is recorded in the X-MS-Exchange-Organization-OriginalSize: header field in the message header. The lower value of the current message size or the original message size is used to enforce sender message size limits. If the original message size header field doesn't exist, it's created using the current size of the message. If the message is too large, it's returned to the sender in an NDR, and additional message processing is stopped. The sender recipient limit is only enforced in the Transport service on the first Mailbox server that processes the message. The original, unexpanded message envelope recipient count is compared to the sender recipient limit. The message sender and all recipients are marked as resolved by stamping an extended property in the message. This extended property allows the message to bypass top-level resolution if the message goes through recipient resolution again (for example, because the Exchange Transport service restarted. 메시지의 크기는 콘텐츠 변환, 인코딩 및 에이전트 처리로 인해 변경될 수 있습니다. 메시지가 Exchange 조직에 들어오면 메시지의 원래 크기가 메시지 헤더의 X-MS-Exchange-Organization-OriginalSize: 헤더 필드에 기록됩니다. 현재 메시지 크기 또는 원래 메시지 크기 중 더 낮은 값을 사용하여 보낸 사람 메시지 크기 제한을 적용합니다. 원래 메시지 크기 헤더 필드가 존재하지 않으면 메시지의 현재 크기를 사용하여 생성됩니다. 메시지가 너무 크면 NDR로 보낸 사람에게 반환되고 추가 메시지 처리가 중지됩니다. 보낸 사람 받는 사람 제한은 메시지를 처리하는 첫 번째 사서함 서버의 전송 서비스에서만 적용됩니다. 확장되지 않은 원래 메시지 봉투 받는 사람 수는 보낸 사람 받는 사람 제한과 비교됩니다. 메시지 보낸 사람과 모든 받는 사람은 메시지에 확장 속성을 표시하여 해결된 것으로 표시됩니다. 이 확장 속성을 사용하면 메시지가 받는 사람 확인을 다시 거치는 경우(예: Exchange Transport Service가 다시 시작된 경우) 최상위 확인을 무시할 수 있습니다.

• 테스트 메일을 계속 발송해봐도 해당 헤더값이 기록되는 경우는 찾지 못했습니다. 찾으면 추가로 작성하겠습니다.

 

2. Expansion

Expansion occurs after top-level resolution. Expansion completely expands nested levels of recipients into individual recipients. Expansion may require multiple trips through the expansion process to expand all recipients. Not all recipients have to be expanded. However, all recipients go through the expansion process to enforce recipient message restrictions for all kinds of recipients. 최상위 확인 후에 확장됩니다. 확장을 통해 중첩된 받는 사람 수준이 개별 받는 사람으로 확장됩니다. 확장을 사용하려면 모든 받는 사람을 확장하기 위해 확장 프로세스를 여러 번 진행해야 할 수 있습니다. 모든 받는 사람을 확장할 수 있는 것은 아니어도 됩니다. 그러나 모든 받는 사람은 확장 프로세스를 통해 모든 종류의 받는 사람에 대해 받는 사람 메시지 제한을 적용합니다.

 

 

외부에서 메일 그룹으로 발송

 

아래와 같이 그룹 구성원으로 수신됨 확인

 

Message Header 로 흐름 확인

<onprem-1@contoso.kr>

Received: from EX19MBX2.contoso.kr (10.0.3.5) by EX19MBX3.contoso.kr  (10.0.3.6) with Microsoft SMTP Server (version=TLS1_2,  cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.15 via Mailbox  Transport; Fri, 4 Mar 2022 15:22:30 +0900 Received: from EX19MBX1.contoso.kr (10.0.3.4) by EX19MBX2.contoso.kr  (10.0.3.5) with Microsoft SMTP Server (version=TLS1_2,  cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.15; Fri, 4 Mar 2022  15:22:28 +0900 Received: from ubt.chosangho.com (10.0.1.243) by EX19MBX1.contoso.kr  (10.0.3.4) with Microsoft SMTP Server (version=TLS1_2,  cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.15 via Frontend  Transport; Fri, 4 Mar 2022 15:22:28 +0900

Received: from EX19MBX2.contoso.kr (10.0.3.5) by EX19MBX2.contoso.kr  (10.0.3.5) with Microsoft SMTP Server (version=TLS1_2,  cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.15 via Mailbox  Transport; Fri, 4 Mar 2022 15:22:30 +0900 Received: from EX19MBX1.contoso.kr (10.0.3.4) by EX19MBX2.contoso.kr  (10.0.3.5) with Microsoft SMTP Server (version=TLS1_2,  cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.15; Fri, 4 Mar 2022  15:22:28 +0900 Received: from ubt.chosangho.com (10.0.1.243) by EX19MBX1.contoso.kr  (10.0.3.4) with Microsoft SMTP Server (version=TLS1_2,  cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.15 via Frontend  Transport; Fri, 4 Mar 2022 15:22:28 +0900

 

Message Trackinglog 분석

1. Default EX19MBX2가 기록된 구간부터는 Transport Service가 동작했다는 것을 알 수 있습니다.

2. Source-context에 DC가 확인되고 Test_Group1 -> Member로 등록된 주소로 Expand가 이루어진 것을 확인할 수 있습니다.

 

3. Resolver 라는 것은 위에서 언급했듯이 recipient resolution(받는 사람 확인)을 진행했다는 것으로 해석됩니다. 이후 onprem-1, onprem-2로 각각 메일이 Transfer 된 것으로 확인됩니다.

4. test_group1@contoso.kr 은 실제 사서함이 없고, 전달할 대상이 없기 때문에 DROP 처리한 것으로 추정됩니다.

 

5. Source가 Storedriver 로 기록되어 있다는 것으로 보아 Mailbox Transport sservice 구간인 것을 확인할 수 있습니다. 최종 사용자에게 메일이 전달된 것을 확인할 수 있습니다.

 

위의 흐름에 대해서 아래와 같이 정리되어 있습니다.

Distribution groups and dynamic distribution groups: Distribution groups are expanded based on the memberOf Active Directory property. Dynamic distribution groups are expanded by using the Active Directory query definition. If the ExpansionServer parameter is set on the group in the Exchange Management Shell, the group is routed to the specified server for expansion. 메일 그룹 및 동적 메일 그룹 : 메일 그룹은 AD 의 memberOf 속성을 기반으로 확장 됩니다. 동적 메일 그룹은 Active Directory 쿼리 정의를 사용하여 확장됩니다. Exchange 관리 셸의 그룹에 ExpansionServer 매개 변수가 설정된 경우 그룹은 확장을 위해 지정된 서버로 라우팅됩니다.

 

2.1 Recipient loop detection (받는 사람 루프 검색)

As groups, alternative recipients, and contacts chains are expanded, the categorizer checks for recipient loops. A recipient loop is a configuration problem that causes message delivery to the same recipients in an endless circle. The different types of recipient loops are described in this list: Harmless recipient loop: These are the two scenarios when harmless recipient can loops occur: When two groups contain one another as members. When mailboxes or mail-enabled public folders are set to deliver and forward to one another (the message is delivered to the original recipient and forwarded). When the categorizer detects a harmless recipient loop, the message is delivered to the recipient, but no additional attempts are made to deliver the message to the same recipient. 그룹, 대체 받는 사람 및 연락처 체인이 확장될 때 분류기에서 받는 사람 루프를 검사합니다. 받는 사람 루프는 동일한 받는 사람에게 메시지가 무한 원으로 배달될 수 있는 구성 문제입니다. 이 목록에는 다양한 유형의 받는 사람 루프가 설명되어 있습니다. 무해한 받는 사람 루프: 무해한 받는 사람이 루프가 발생할 수 있는 두 가지 시나리오입니다. 두 그룹이 구성원으로 포함된 경우 사서함 또는 메일 사용이 가능한 공용 폴더가 배달 및 전달으로 설정된 경우(메시지가 원래 받는 사람에게 배달 및 전달) 분류기가 무해한 받는 사람 루프를 감지하면 메시지가 받는 사람에게 배달되지만 동일한 받는 사람에게 메시지를 배달하기 위한 추가 시도는 없습니다.

예를 들면 아래와 같이 test_group1@contoso.kr 에 발송한다고 가정합니다.

 

Test_group1에는 test_group2가 구성원이고 test_group2에는 test_group1이 포함되어 있습니다. 이렇게되면 서로가 구성원이기 때문에 루프가 발생합니다.

 

 

Onprem-1@contoso.kr 의 헤더를 보면 일반적인 수신 흐름과 다르지 않습니다.

 

Message TrackingLog를 보면, Test_group2를 EXPAND 처리 -> Test_Group1이 구성원 확인 -> DUPLICATEEXPAND 처리 흐름을 확인할 수 있습니다.

 

Broken recipient loop: When mailboxes or mail-enabled public folders are set to forward to one another (the messages are only forwarded). A broken recipient loop can't result in successful message delivery. When the categorizer detects a broken recipient loop, expansion activity for the current recipient stops, and an NDR is generated. 손상된 받는 사람 루프: 사서함 또는 메일 사용 가능 공용 폴더가 다른 폴더로 전달로 설정된 경우(메시지만 전달) 중단된 받는 사람 루프가 발생하면 메시지가 배달되지 않습니다. 분류기가 중단된 받는 사람 루프를 감지하면 현재 받는 사람에 대한 확장 활동이 중지되고 NDR이 생성됩니다.

아래와 같은 시나리오를 설명하고 있습니다.

 

Onprem-1 계정에서 아래와 같이 Forwarding이 설정을 하면,

 

아래와 같은 흐름이 형성됩니다.

 

Onprem-2 계정에서 동일하게 설정합니다.

 

그러면 아래와 같이 서로가 계속 포워딩하는 형태로 동작하게 됩니다.

 

테스트를 위해서 아래와 같이 외부에서 발송을 먼저 진행하였습니다.

 

아래와 같이 보낸 사람에게 NDR이 발송됩니다.

 

원본 헤더를 보면 2개의 구간만 확인됩니다. 즉 Transport Service에서 계속 루프가 발생된 것으로 확인됩니다.

 

Message Trackinglog 를 확인해 보겠습니다.

Onprem-1 -> Onprem-2 -> Onprem-1 ..과 같이 Redirect 가 이루어지고 Loop가 감지되어 Fail 및 Drop 처리된 것을 확인할 수 있습니다.

 

이와 같은 루프는 다양한 시나리오가 존재할 수 있습니다.

 

Recipient loop detection doesn't prevent duplicate message delivery. For example, consider this scenario: Distribution Group A has Distribution Group B and Distribution Group C as members. Distribution Group C is also a member of Distribution Group B. In this scenario, Distribution Group C will experience duplicate message delivery. 받는 사람 루프 검색은 중복된 메시지 배달을 방지하지 않습니다. 예를 들어 다음 시나리오를 고려합니다. 메일 그룹 A에는 메일 그룹 B와 메일 그룹 C가 구성원으로 있습니다. 메일 그룹 C도 메일 그룹 B의 구성원인 경우. 이 시나리오에서 메일 그룹 C는 중복 메시지 배달을 경험합니다.

 

테스트를 위해서 아래와 같이 메일 그룹을 설정합니다.

 

아래와 같이 발송을 진행하여 onprem-3@contoso.kr에 중복메시지가 도달하는지 확인합니다.

 

그러나 중복메일이 수신되지는 않았습니다.

Message Trackinglog  상에서도 DuplicateExpand 기록이 확인됩니다.

 

나중에 중복메시지가 수신될 수 있는 시나리오에 대해서 조금 더 테스트 해보고 업데이트 하겠습니다.

 

이번 포스팅에서는 다루지 않은 영역들은 나중에 업데이트 하겠습니다.