반응형

아래의 자료들을 참고하여 작성하였습니다.

 

Mail routing in Exchange Server | Microsoft Docs

Mail Flow and Transport Deep Dive 2017 - YouTube

 

우선 Routing에서 반복적으로 언급되는 단어를 확인이 필요합니다.

resolve, resolution 이라는 단어가 메일 흐름에서 반복되어서 언급됩니다.

Resolve 라는 단어가 기본적으로는 해결하다 라는 뜻으로 사전에 나와 있지만, 메일 흐름에서는 확인하다로 보시면 됩니다.

Categorization, Categorize 도 계속 언급됩니다.

 

Destination 은 사전상에서는 목적지, 도착지로 나와있지만, Docs 페이지에서는 대상이라고 번역하고 있습니다. 

The primary task of the Transport service that exists on Mailbox servers in your Exchange organization is to route messages received from users and external sources to their ultimate destinations. Routing decisions are made during message categorization. The categorizer is a component of the Transport service that processes all incoming messages and determines what to do with the message based on information about their destinations.

Exchange 조직의 사서함 서버에 있는 전송 서비스의 기본 작업은 사용자 및 외부 원본에서 받은 메시지를 최종 목적지로 라우팅하는 것입니다. 라우팅 결정은 메시지를 분류하는 동안 이루어집니다.  Categorizer는 들어오는 모든 메시지를 처리하고 대상에 대한 정보를 기반으로 메시지로 할 작업을 결정하는 전송 서비스의 구성 요소입니다.

Mail flow 상의 Categorizer 에 대한 설명으로 확인됩니다.

 

Routing in Exchange 2016 and Exchange 2019 is virtually unchanged from Exchange 2013. These are the notable changes to routing compared to Exchange 2010:

  • Linked connectors are no longer available. A linked connector was a Receive connector that was linked to a Send connector. All messages received by the Receive connector were automatically forwarded to the Send connector.

Linked connector는 2010에서 사용된 개념으로 지금 시점에서는 중요하지 않을 것 같습니다.

아래의 흐름에서 1번->2번, 3번->4번 의 흐름처럼 전부 SMTP Receive 에서 SMTP Send로 전달하는 흐름을 설명하는 것으로 이해하였습니다.

 

 

1. Routing components

When a message is received by the Transport service on a Mailbox server, the message must be categorized. The first phase of message categorization is recipient resolution. After the recipient has been resolved, the ultimate destination can be determined. The next phase, routing, determines how to best reach that destination. Routing in Exchange is generalized for increased flexibility and decreased complexity by using the concepts of routing destinations and delivery groups.


사서함 서버의 전송 서비스에서 메시지를 받는 경우 메시지를 분류해야 합니다. 메시지 분류의 첫 단계는 받는 사람 확인입니다. 받는 사람을 확인하고 나면 최종 대상을 결정할 수 있습니다. 다음 단계인 라우팅에서는 가장 효율적으로 해당 대상에 도달하는 방법을 결정합니다. Exchange 라우팅은 라우팅 대상 및 배달 그룹의 개념을 사용하여 유연성을 높이고 복잡성을 줄이기 위해 일반화됩니다.

Routing destinations  과 Delivery groups 개념이해가 중요한 것 같습니다.

요약 하면 Categorizer는 다음과 같은 순서로 동작합니다.

  1. 받는 사람 확인
  2. 최종 대상 결정
  3. 효율적으로 도달하는 방법 결정

 

아래의 흐름을 설명하는 것으로 보입니다.

 

1-1. Routing destinations (라우팅 대상 or 라우팅 목적지)

The ultimate destination for a message is called a routing destination. Regardless of the complexity of an Exchange organization, there are surprisingly few routing destinations.


구글 번역
메시지의 최종 목적지를 라우팅 목적지 라고 합니다 . Exchange 조직의 복잡성에 관계없이 라우팅 대상은 놀라울 정도로 적습니다.


Docs 번역
메시지의 최종 대상을 라우팅 대상 이라고 합니다. 조직의 복잡도에 Exchange 라우팅 대상은 매우 적습니다.
  • 이 부분은 구글 번역이 조금 더 자연스러운 것 같습니다.

 

Routing destinations 은 3가지만 존재합니다.

They are:


  • A mailbox database: This is the routing destination for any recipient with a mailbox in the Exchange organization. In Exchange 2013 or later, public folders are a type of mailbox, so routing messages to public folder recipients is the same as routing messages to mailbox recipients.
  • A connector: A Send connector is used as a routing destination for SMTP messages based on the configuration of the Send connector (address spaces, scoped or not, etc.). Similarly, a Delivery Agent connector or Foreign connector is used as a routing destination for non-SMTP messages.
  • A distribution group expansion server: This is the routing destination when a distribution group has a designated expansion server (a server that's responsible for expanding the membership list of the group). A distribution group expansion server is an Exchange 2013 or later Mailbox server or an Exchange 2010 Hub Transport server.


Note that these routing destinations existed in previous versions of Exchange, but they weren't called routing destinations.
다음과 같습니다.


  • 사서함 데이터베이스: Exchange 조직에 사서함이 있는 받는 사람의 라우팅 대상입니다. Exchange 2013 이상에서 공용 폴더는 사서함 유형이므로 공용 폴더 수신자에게 메시지를 라우팅하는 것은 메시지를 사서함 수신자에게 라우팅하는 것과 같습니다.
  • 커넥터: 송신 커넥터는 송신 커넥터의 구성(주소 공간, 범위 지정 여부 등)에 따라 SMTP 메시지의 라우팅 대상으로 사용됩니다. 마찬가지로 배달 에이전트 커넥터 또는 외부 커넥터는 비 SMTP 메시지의 라우팅 대상으로 사용됩니다.
  • 메일 그룹 확장 서버: 메일 그룹에 지정된 확장 서버(그룹의 구성원 목록 확장을 담당하는 서버)가 있는 경우 라우팅 대상입니다. 메일 그룹 확장 서버는 Exchange 2013 이상 사서함 서버 또는 Exchange 2010 허브 전송 서버입니다.


이러한 라우팅 대상은 이전 버전의 Exchange에 있었지만 라우팅 대상이라고 하지 않았습니다.

 

A mailbox database

  • 수신자가 Exchange 조직내의 사서함이면 DB가 목적지입니다. 이 부분은 Inbound 흐름에서 확인할 수 있었습니다.

A connector

  • Outbound, Inbound 흐름은 Send -> Receive 구조입니다. 커넥터에 대한 설명인 것으로 보입니다.

A distribution group expansion server

  • 메일 그룹의 구성원이 서버의 개념인지 Recipient 의 개념인지 확인이 필요할 것 같습니다. 이 부분은 조금 더 공부가 필요할 것 같습니다.

2. Delivery groups

A collection of one or more transport servers is responsible for delivering mail to each routing destination. This collection of transport servers is called a delivery group. The term transport servers is used because the servers could be a mixture of Exchange 2013 or later Mailbox servers (the Transport service) or Exchange 2010 Hub Transport servers. The relationship between routing destinations and delivery groups is explained in the following table:


하나 이상의 전송 서버 모음은 각 라우팅 대상으로 메일을 배달합니다. 이 전송 서버 모음을 배달 그룹 이라고 합니다 . 전송 서버 라는 용어 는 서버가 Exchange 2013 이상 사서함 서버(전송 서비스) 또는 Exchange 2010 허브 전송 서버가 혼합되어 있을 수 있기 때문에 사용됩니다. 라우팅 대상과 배달 그룹 간의 관계는 다음 표에 설명되어 있습니다.

 

Transport Server 라는 용어는 Exchange Server 2010 에 해당하고, Exchange Server 2013 이후 버전에서는 Transport Service라는 용어로 변경되었습니다. 이 부분은 2010 과 2013의 메일 처리 방식이 달라졌기 때문인 것으로 보입니다.

 

Get-TransportServer 명령어도 없어질 것이라는 경고창도 동일한 맥락입니다.

Exchange Server 2010이 없다는 전제하에 delivery group = the collection of transport services  로 볼 수 있습니다.

아래와 같이 모든 Transport Service의 집합체라고 볼 수 있습니다.

 

기술자료상에서 Exchange Server 2010 을 제거한 뒤, 표를 확인해 보면 다음과 같습니다.

라우팅 대상과 배달 그룹 간의 관계는 다음 표에 설명되어 있습니다.

Routing destination Delivery group
Exchange 2013 or later mailbox databases Exchange 2013 or later Mailbox servers.
Connectors Exchange 2013 or later Mailbox servers
Distribution group expansion servers Exchange 2013 or later Mailbox servers

 

How the message is routed depends on the relationship between the source delivery group and the destination delivery group:
  • If the source and destination delivery group are the same, no routing decisions are required. The routing destination is the next hop for the message.
  • If the source delivery group is outside the destination delivery group, routing decisions are required. The message is relayed along the least-cost routing path to the destination delivery group. Depending on the size and complexity of the Exchange environment, the message might be relayed through many transport servers to reach the destination delivery group for delivery to the routing destination.

The different types of delivery groups that exist in Exchange 2016 are summarized in the following table.

메시지가 라우팅되는 방식은 원본 배달 그룹과 대상 배달 그룹 간의 관계에 따라 다릅니다.
  • 원본 및 대상 배달 그룹이 동일한 경우 라우팅 결정이 필요하지 않습니다. 라우팅 대상은 메시지의 다음 홉입니다.
  • 원본 배달 그룹이 대상 배달 그룹 외부에 있는 경우 라우팅 결정이 필요합니다. 메시지는 최소 비용 라우팅 경로를 따라 대상 배달 그룹으로 릴레이됩니다. Exchange 환경의 크기와 복잡성에 따라 메시지는 여러 전송 서버를 통해 릴레이되어 라우팅 대상으로 배달될 대상 배달 그룹에 도달할 수 있습니다.

다음 표에는 Exchange 2016에 있는 다양한 유형의 배달 그룹이 요약되어 있습니다.

 

아래의 내용들은 현재 단계에서는 다루기 어려운 내용들입니다.  우선 이부분은 Skip 하겠습니다.

 

3. Queues

From the perspective of the sending transport server, each message delivery queue represents the destination for a particular message. When the Transport service selects the destination for a message, the destination is stamped on the recipient as the NextHopSolutionKey attribute. If a single message is sent to more than one recipient, each recipient has the NextHopSolutionKey attribute. The receiving transport server also performs message categorization and queues the message for delivery. After a message is queued, you can examine the delivery type for a particular queue to determine whether a message will be relayed again when it reaches the next hop destination. Every unique value of the NextHopSolutionKey attribute corresponds to a separate message delivery queue.


보내는 전송 서버의 관점에서 각 메시지 배달 큐는 특정 메시지의 대상을 나타냅니다. 전송 서비스가 메시지의 대상을 선택하면 대상이 받는 사람에게 NextHopSolutionKey 특성으로 스탬프 처리됩니다. 단일 메시지가 둘 이상의 수신자에게 전송되는 경우 각 수신자는 NextHopSolutionKey 특성을 갖습니다. 또한 받는 전송 서버는 메시지 분류를 수행하고 배달을 위해 메시지를 큐에 넣습니다. 메시지가 대기열에 들어간 후 특정 대기열의 배달 유형을 검사하여 메시지가 다음 홉 대상에 도달할 때 다시 릴레이할지 여부를 결정할 수 있습니다. NextHopSolutionKey 의 모든 고유 값 속성은 별도의 메시지 배달 대기열에 해당합니다.

 

NextHopSolutionKey는 아래의 3가지 값을 의미하는 것으로 보이며, 이 부분에 대해서는 큐 포스팅을 별도로 작성하겠습니다.

 

4. Routing messages

기술 자료에서 너무 어려운 설명이 많이 나와 있어서 아래의 문구만 보고 넘어가겠습니다.

If multiple routing paths are possible, the routing path with the lowest aggregate cost is used.
여러 라우팅 경로가 가능한 경우 총 비용이 가장 낮은 라우팅 경로가 사용됩니다.


If more than one routing path has the same aggregate cost, the number of hops in each path is evaluated and the routing path with the least number of hops is used.
둘 이상의 라우팅 경로에 동일한 총 비용이 있는 경우 각 경로의 홉 수가 평가되고 홉 수가 가장 적은 라우팅 경로가 사용됩니다.

-> 최소 비용, 최소 경로로 설정된다고만 알고 넘어가도록 하겠습니다.

 

5. Routing messages between Active Directory sites

아래의 자료를 참고해주시기 바랍니다. 이 파트도 넘어가겠습니다.

Route mail between Active Directory sites: Exchange 2013 Help | Microsoft Docs

 

 

6. Routing in the Front End Transport service on Mailbox servers

여기서 부터는 중요하니 기술자료를 자세히 확인하겠습니다.

The Front End Transport service acts as a stateless proxy for all inbound and (optionally) outbound external SMTP traffic for the Exchange organization. For outgoing messages, the Transport service communicates with the Front End Transport service only when it's specifically configured to do so. For more information, see Configure Send connectors to proxy outbound mail.


프런트 엔드 전송 서비스는 Exchange 조직에 대한 모든 인바운드 및 (선택 사항) 아웃바운드 외부 SMTP 트래픽에 대한 상태 비저장 프록시 역할을 합니다. 보내는 메시지의 경우 전송 서비스는 특별히 구성된 경우에만 프런트 엔드 전송 서비스와 통신합니다. 자세한 내용은 아웃바운드 메일을 프록시하도록 송신 커넥터 구성 을 참조하세요 .
  • 이전 Front End Transport 서비스에 대한 설명이 반복됩니다. 비저장 (Stateless)는 결국 큐가 없다는 의미로 해서삭해도 될 것 같습니다.

 

For incoming messages, the Front End Transport service must quickly find a single, healthy Transport service to receive the message transmission, regardless of the number or type of recipients. Failure to do so results in the email service being perceived as unavailable by the sending server. Like the Transport service, the Front End Transport service loads routing tables based on information from Active Directory, and uses delivery groups to determine how to route messages. However, the routing tables used by the Front End Transport service have the following unique characteristics:
  • The Front End Transport service is never considered a member of a delivery group, even when the Mailbox server and the Client access server are installed on the same physical server (which is always the case in Exchange 2016 or later). This forces the Front End Transport service to communicate only with the Transport service.
  • The routing tables don't contain any Send connector routes.
  • The routing tables contain a special list of Mailbox servers in the local Active Directory site for fast fail-over purposes.


들어오는 메시지의 경우 프런트 엔드 전송 서비스는 받는 사람의 수나 유형에 관계없이 메시지 전송을 수신할 하나의 정상적인 전송 서비스를 빠르게 찾아야 합니다. 그렇게 하지 않으면 이메일 서비스가 보내는 서버에서 사용할 수 없는 것으로 인식됩니다. 전송 서비스와 마찬가지로 프런트 엔드 전송 서비스는 Active Directory의 정보를 기반으로 라우팅 테이블을 로드하고 배달 그룹을 사용하여 메시지를 라우팅하는 방법을 결정합니다. 그러나 프런트 엔드 전송 서비스에서 사용하는 라우팅 테이블에는 다음과 같은 고유한 특성이 있습니다.
  • 사서함 서버와 클라이언트 액세스 서버가 동일한 물리적 서버에 설치된 경우에도 프런트 엔드 전송 서비스는 배달 그룹의 구성원으로 간주되지 않습니다(Exchange 2016 이상에서는 항상 해당됨). 이렇게 하면 프런트 엔드 전송 서비스가 전송 서비스와만 통신하도록 합니다.
  • 라우팅 테이블에는 송신 커넥터 경로가 포함되어 있지 않습니다.
  • 라우팅 테이블에는 빠른 장애 조치를 위해 로컬 Active Directory 사이트에 있는 특별한 사서함 서버 목록이 포함되어 있습니다.
  • Delivery Group 은 Transport Service 의 묶음이며, Frontend Transport Service는 포함되지 않는다.

또한 이것은 Frontend Transport Service 가 Transport Service 와만 통신하도록 하는 것이다. 로 이해하였습니다.

 

Routing in the Front End Transport service resolves message recipients to mailbox databases. The list of Mailbox servers used by the Front End Transport service is based on the mailbox databases of the message recipients. Note that it's possible that none of the recipients have mailboxes, for example, if the recipient is a distribution group or a mail user. For each mailbox database, the Front End Transport service looks up the delivery group and the associated routing information. The delivery groups used by the Front End Transport service are:

  • Routable DAG
  • Mailbox delivery group
  • AD site
프런트 엔드 전송 서비스의 라우팅은 메시지 받는 사람을 사서함 데이터베이스로 확인합니다. 프런트 엔드 전송 서비스에서 사용하는 사서함 서버 목록은 메시지 받는 사람의 사서함 데이터베이스를 기반으로 합니다. 예를 들어 받는 사람이 메일 그룹이나 메일 사용자인 경우 받는 사람 중 아무에게도 사서함이 없을 수 있습니다. 각 사서함 데이터베이스에 대해 프런트 엔드 전송 서비스는 배달 그룹 및 연결된 라우팅 정보를 조회합니다. 프런트 엔드 전송 서비스에서 사용하는 배달 그룹은 다음과 같습니다.
  • 라우팅 가능한 DAG
  • 사서함 배달 그룹
  • AD Site

이전에 Accept Domain을 다룰때도 조금은 이해되지 않는 부분 중 한 가지는 Frontend는 어디서 사서함을 조회해서 전달 할까 였습니다. 아래의 3가지 영역에서 확인하여 전달하는 것으로 해석됩니다.

- Routable DAG, Mailbox Delivery Group(Transport Service 들의 묶음), AD Site

 

Depending on the number and type of recipients, the Front End Transport service performs one of the following actions:
  • For messages with a single mailbox recipient, select a Mailbox server in the target delivery group, and give preference to the Mailbox server based on the proximity of the Active Directory site. Routing the message to the recipient might involve routing the message through a hub site.
  • For messages with multiple mailbox recipients, use the first 20 recipients to select a Mailbox server in the closest delivery group, based on the proximity of the Active Directory site. Note that message bifurcation doesn't occur in Front End Transport, so only one Mailbox server is ultimately selected, regardless of number of recipients in a message.
  • If the message has no mailbox recipients, select a random Mailbox server in the local Active Directory site.


받는 사람의 수와 유형에 따라 프런트 엔드 전송 서비스는 다음 작업 중 하나를 수행합니다.

  • 단일 사서함 받는 사람이 있는 메시지의 경우 대상 배달 그룹에서 사서함 서버를 선택하고 Active Directory 사이트의 근접성을 기반으로 사서함 서버를 우선적으로 지정합니다. 메시지를 받는 사람에게 라우팅하려면 허브 사이트를 통해 메시지를 라우팅해야 합니다.
  • 여러 사서함 받는 사람이 있는 메시지의 경우, 처음 20명의 받는 사람을 사용하여 Active Directory 사이트의 근접성을 기반으로 가장 가까운 배달 그룹의 사서함 서버를 선택합니다. 메시지 분기는 프런트 엔드 전송에서 발생하지 않으므로 메시지의 받는 사람 수에 관계없이 궁극적으로 하나의 사서함 서버만 선택됩니다.
  • 받는 사람의 사서함이 없으면, 로컬 Active Directory 사이트에서 임의의 사서함 서버를 선택합니다.
  • Frontend Transport Service의 라우팅 원리중 가장 중요한 항목 같습니다.

하나의 메시지에서 받는 사서함이 1개인 경우, 여러 개인 경우, 없는 경우를 나눠서 설명해주고 있습니다.

 

7. Routing in the Mailbox Transport service on Mailbox servers

The Mailbox Transport service consists of two separate services: the Mailbox Transport Submission service and Mailbox Transport Delivery service. The Mailbox Transport Delivery service receives SMTP messages from the Transport service, and connects to the local mailbox database by using RPC to deliver the message. The Mailbox Transport Submission service connects to the local mailbox database by using RPC to retrieve messages, and submits the messages over SMTP to the Transport service. The Mailbox Transport service is stateless, and doesn't use message delivery queues.


Mailbox Transport service는 Mailbox Transport Submission service와 Mailbox Transport Delivery service의 두 가지 개별 서비스로 구성됩니다. Mailbox Transport Delivery service는 Transport service에서 SMTP 메시지를 수신하고 RPC를 사용하여 로컬 사서함 데이터베이스에 연결하여 메시지를 배달합니다. Mailbox Transport Submission service는 RPC를 사용하여 메시지를 검색하여 로컬 사서함 데이터베이스에 연결하고 SMTP를 통해 전송 서비스에 메시지를 전송합니다. Mailbox Transport service는 상태 비저장이며 메시지 배달 큐를 사용하지 않습니다.
  • Mailbox Transport Service 에 대한 다시 기본적인 설명을 해주고 있습니다. Mailbox Transport Service도 Frontend Transport Service와 동일하게 큐는 사용하지 않는다고 나와 있습니다.
Like the Transport service, the Mailbox Transport service loads routing tables based on information from Active Directory, and uses delivery groups to determine how to route messages. However, there are routing aspects that are unique to the Mailbox Transport service:

  • Because the Transport service and the Mailbox Transport service exist on the same Mailbox server, the Mailbox Transport service always belongs to the same delivery group as the Mailbox server. This delivery group is referred to as the local delivery group.
  • The Mailbox Transport Submission service doesn't automatically send messages to the Transport service on the local Mailbox server or on other Mailbox servers in its own local delivery group. The Mailbox Transport Submission service has access to the same routing topology information as the Transport service, so the Mailbox Transport submission service can send messages to the Transport service on Mailbox servers outside the delivery group. The Mailbox servers in the local delivery group are used as fallback options, and for delivery to non-mailbox recipients.
  • The Mailbox Transport service only communicates with the Transport service on Mailbox servers.
  • The Mailbox Transport service only communicates with local mailbox databases. The Mailbox Transport service never communicates with mailbox databases on other Mailbox servers.

Transport service와 마찬가지로 사서함 전송 서비스는 Active Directory의 정보를 기반으로 라우팅 테이블을 로드하고 배달 그룹을 사용하여 메시지를 라우팅하는 방법을 결정합니다. 그러나 사서함 전송 서비스에 고유한 라우팅 측면이 있습니다.
  • Transport service와 Mailbox Transport service는 동일한 사서함 서버에 있으므로 Mailbox Transport service는 항상 사서함 서버와 동일한 배달 그룹에 속합니다. 이 배달 그룹을 로컬 배달 그룹 이라고 합니다 .
  • Mailbox Transport Submission service는 로컬 사서함 서버 또는 자체 로컬 배달 그룹의 다른 사서함 서버에 있는 전송 서비스로 메시지를 자동으로 보내지 않습니다. Mailbox Transport Submission service는 Transport service와 동일한 라우팅 토폴로지 정보에 액세스할 수 있으므로, Mailbox Transport Submission service는 배달 그룹 외부의 사서함 서버에 있는 전송 서비스로 메시지를 보낼 수 있습니다. 로컬 배달 그룹의 사서함 서버는 대체 옵션으로 사용되며,  non-mailbox recipients에게 배달하는 데 사용됩니다.
  • Mailbox Transport service는 사서함 서버의 Transport service와만 통신합니다.
  • Mailbox Transport service는 로컬 사서함 데이터베이스와만 통신합니다. Mailbox Transport service는 다른 사서함 서버의 사서함 데이터베이스와 통신하지 않습니다.
  • Delivery Group의 개념은 지금 단계에서는 이해하기 어렵습니다. 이부분은 패스 하겠습니다.
  • Mailbox Transport Service는 해당 사서함 서버의 DB와 통신이 이루어지고 다른 사서함서버의 DB와는 통신하지 않는다는 부분이 설명되어 있습니다.
When the Mailbox Transport Delivery service receives a message from the Transport service, it accepts or rejects the message for delivery to a local mailbox database. The Mailbox Transport Delivery service can deliver the message if the recipient resides in an active copy of a local mailbox database. But, if the recipient doesn't reside in an active copy of a local mailbox database, the Mailbox Transport Delivery service can't deliver the message, and must provide a non-delivery response to the Transport service. For example, if the active copy of the mailbox database recently moved to another server, the Transport service might erroneously transmit a message to a Mailbox server that now holds an inactive copy of the mailbox database. The non-delivery responses that the Mailbox Transport Delivery service returns to the Transport service include:
  • Retry delivery
  • Generate an NDR (also known as a non-delivery report, delivery status notification, DSN, or bounce message)
  • Reroute the message
Mailbox Transport Delivery service가 Transport service로 부터 메시지를 받으면, 로컬 사서함 데이터베이스로 배달하기 위해 메시지를 수락하거나 거부합니다. 받는 사람이 로컬 사서함 데이터베이스의 활성 복사본에 있는 경우 Mailbox Transport Delivery service에서 메시지를 배달할 수 있습니다. 그러나 받는 사람이 로컬 사서함 데이터베이스의 활성 복사본에 없는 경우 Mailbox Transport Delivery service는 메시지를 배달할 수 없으며 Transport service에 배달 못 함 응답을 제공해야 합니다.  예를 들어 사서함 데이터베이스의 활성 복사본이 최근에 다른 서버로 이동된 경우 전송 서비스는 현재 사서함 데이터베이스의 비활성 복사본을 보유하고 있는 사서함 서버로 메시지를 잘못 전송할 수 있습니다. 사서함 전송 배달 서비스가 전송 서비스에 반환하는 배달 못 함 응답은 다음과 같습니다.
  • 배달 재시도
  • NDR(배달 못 함 보고서, 배달 상태 알림, DSN 또는 반송 메시지라고도 함) 생성
  • 메시지 경로 변경
  • Mailbox Transport Delivery Service를 통해서 메시지가 수신되거나, 수신되지 않을 경우에 대한 NDR 응답 시나리오에 대해서 설명되어 있습니다.

 

8. Routing in the Transport service on Edge Transport servers

  • Edge 서버에 대해서는 이번 포스팅에서는 다루지 않겠습니다.
반응형
저작자표시 비영리 변경금지

'Exchange' 카테고리의 다른 글

Exchange Server Study (2-7). Recipient resolution in Exchange Server  (0) 2022.03.05
Exchange Server Study (2-6). Connector selection in external message routing  (0) 2022.02.18
Exchange Server Study (2-4). Accepted Domain  (2) 2022.01.23
Exchange Server Study (2-3). Mail Flow - Message Tracking  (0) 2022.01.18
Exchange Server Study (2-2). Mail Flow - Connector - Outbound  (0) 2022.01.15

+ Recent posts

티스토리툴바