해당 자료를 기준으로 Self Study 진행
메일 흐름 및 전송 파이프라인 | Microsoft Docs
커넥터, Exchange, Exchange 송신 커넥터, Exchange 수신 커넥터 | Microsoft Docs
커넥터의 Exchange Server | Microsoft Docs
Mail flow and the transport pipeline
https://docs.microsoft.com/en-us/exchange/mail-flow/mail-flow
| In Exchange Server 2016, mail flow occurs through the transport pipeline. The transport pipeline is a collection of services, connections, components, and queues that work together to route all messages to the categorizer in the Transport service on an Exchange 2016 Mailbox server inside the organization. For information about how to configure mail flow in a new Exchange 2016 organization, see Configure mail flow and client access. Exchange Server 2016에서 전송 파이프 라인을 통해 메일 흐름이 발생합니다. 전송 파이프 라인은 조직 내부에있는 Exchange 2016 사서함 서버에서 경로로 함께 전송 서비스의 분류기에 모든 메시지를 작동 서비스, 연결, 구성 요소 및 큐의 모음입니다. 새 Exchange 2016 조직에서 메일 흐름을 구성하는 방법에 대한 자세한 내용은 메일 흐름 및 클라이언트 액세스 구성을 참조하십시오. |
일단 쭉 서비스를 하나씩 살펴보겠습니다.
Front End Transport service
|
| Front End Transport service on Mailbox servers: 이 서비스는 Exchange 2016 조직의 모든 인바운드 및 (선택적으로) 아웃 바운드 외부 SMTP 트래픽에 대한 상태 비 저장 프록시 역할을합니다. 프런트 엔드 전송 서비스는 메시지 콘텐츠를 검사하지 않으며 사서함 전송 서비스와 통신하지 않으며 메시지를 로컬에 대기시키지 않습니다. |
EX2010 에는 해당서비스가 없고, EX2013 에서는 CAS 에서 확인할 수 있습니다.
종속성에는 별다른 점은 없어보입니다.
Transport service:
|
| Transport service: 이 서비스는 Exchange Server 2010의 허브 전송 서버 역할과 거의 동일합니다. 전송 서비스는 조직의 모든 SMTP 메일 흐름을 처리하고 메시지 분류를 수행하며 메시지 콘텐츠 검사를 수행합니다. Exchange 2010과 달리 전송 서비스는 사서함 데이터베이스와 직접 통신하지 않습니다. 이 작업은 이제 사서함 전송 서비스에서 처리됩니다. 전송 서비스는 사서함 전송 서비스, 전송 서비스, 프런트 엔드 전송 서비스 및 Edge 전송 서버의 전송 서비스간에 메시지를 라우팅합니다. |
Transport Service를 통해서 EX2010 과 2013 의 Mail flow 의 프로세스가 변경되었다는 점을 확인할 수 있습니다.
위에서 언급된바와 같이 EX2010의 경우 Hub Transport 역할, EX2013의 경우 Mailbox 역할에서 해당 서비스를 확인할 수 있습니다.
EX2010 과 EX2013 에서 종속성의 차이를 확인할 수 있습니다.
EX2010
EX2013
Microsoft Filtering Management Service
해당 서비스를 검색하면 아래의 기사를 확인할 수 있습니다.
Microsoft Filtering Management Service won’t start on Exchange 2013
| Mailbox Transport service on Mailbox servers: This service consists of two separate services: Mailbox Transport Submission service:
Mailbox Transport Delivery service:
Mailbox Transport service doesn't communicate with the Front End Transport service, the Mailbox Transport service, or mailbox databases on other Mailbox servers. It also doesn't queue any messages locally. |
| Mailbox Transport service on Mailbox servers: 이 서비스는 두 가지 개별 서비스로 구성됩니다. Mailbox Transport Submission service::이 서비스는 Exchange 원격 프로 시저 호출 (RPC)을 사용하여 메시지를 검색하는 로컬 사서함 데이터베이스에 연결합니다. 이 서비스는 SMTP를 통해 로컬 사서함 서버 나 다른 사서함 서버의 전송 서비스로 메시지를 전송합니다. 사서함 전송 전송 서비스는 전송 서비스와 동일한 라우팅 토폴로지 정보에 액세스 할 수 있습니다. Mailbox Transport Delivery service: 이 서비스는 로컬 사서함 서버 나 다른 사서함 서버의 전송 서비스에서 SMTP 메시지를 받고 RPC를 사용하여 로컬 사서함 데이터베이스에 연결하여 메시지를 배달합니다. 사서함 전송 서비스는 프런트 엔드 전송 서비스, 사서함 전송 서비스 또는 다른 사서함 서버의 사서함 데이터베이스와 통신하지 않습니다. 또한 로컬에서 메시지를 대기열에 넣지 않습니다. |
Microsoft Exchange Mailbox Transport Submission
아래의 서비스 설명은 의미 있어보입니다.
Description: This service, running on the Mailbox servers, receives the Submit events, processes the messages by converting them from MAPI to MIME, and then hands them over to the Transport service on a Mailbox server.
Microsoft Exchange Mailbox Transport Delivery
Description: This service, running on the Mailbox servers, receives mail items from the Transport service on Mailbox servers, submits them to extension modules for processing, and then commits them into a mailbox database.
| Transport service on Edge Transport servers: This service is very similar to the Transport service on Mailbox servers. If you have an Edge Transport server installed in the perimeter network, all mail coming from the Internet or going to the Internet flows through the Transport service Edge Transport server. |
| Transport service on Edge Transport servers: 이 서비스는 사서함 서버의 전송 서비스와 매우 유사합니다. 주변 네트워크에 Edge 전송 서버가 설치되어 있으면 인터넷에서 전송되거나 인터넷으로 전송되는 모든 메일이 전송 서비스 Edge 전송 서버를 통해 전달됩니다. |
Edge 의 Trasport Service 는 EX2010 과 EX2013이 큰 차이가 없는 것으로 보입니다.
개념만 보면 이해가 어렵습니다.
아래는 Diagram 을 통해서 흐름을 이해하는 것이 좋을 것 같습니다.
| Note: Although the diagrams in this topic show the components on a single Exchange 2016 server, communication also occurs between those components on different Exchange 2016 servers. The only communication that always occurs on the local Exchange 2016 server is between the Mailbox Transport service and the local mailbox database. |
봐도 봐도 이해가 힘든 메일 흐름
Transport pipeline 을 조금씩 쪼개서 분석 해보겠습니다.
[1단계] 단순 흐름 분석
Inbound
FrontEnd Transport service -> Transport Service -> Mailbox Transport Service -> Mailbox Transport Delivery Service
Outbound
Mailbox Submission Service -> Mailbox Transport Service -> Transport Service
[2단계] 커넥터와 연계하여 흐름 분석
| A message from outside the organization enters the transport pipeline through the default Receive connector named "Default Frontend <Mailbox server name>" in the Front End Transport service. The message is sent to the Transport service on the local Mailbox server or on a different Mailbox server. The Transport service listens for messages on the default Receive connector named "Default <Mailbox server name>". The message is sent from the Transport service to the Mailbox Transport Delivery service on the local Mailbox server or on a different Mailbox server. The Mailbox Transport Delivery service uses RPC to deliver the message to the local mailbox database. |
Inbound
[External]
↓
[Front End Transport Service]
Receive Connector: Default Frontend <Servername>:25
↓
[Transport Service]
Receive Connector: Default <Servername> :2525
↓
[Mailbox Transport Service]
↓
[Mailbox Transport Delivery Service]
↓ RPC
[DB] (Mailbox)
Outbound
[DB] (Mailbox)
↓RPC
[Mailbox Transport submission]
↓
[Transport Service]
Default <Servername>:2525
↓
Send Connector
↓
(Outbound Proxy Frontend <Servername>) (Optional)
↓
[External]
언급이 안 된 Connector
1) Client Frontend <Servername> : 587
- 주로 POP3, IMAP
2) Client Proxy <Servername>: 465
- 주로 POP3, IMAP
[3단계] 커넥터와 연계하여 흐름 분석
기본 값으로 로그가 Enable 되어 있는 커넥터와 아닌 커넥터들이 있습니다.
기술자료를 통해서 반드시 확인하시기 바랍니다.
#수신 커넥터 로그 활성화
Get-ReceiveConnector|Set-ReceiveConnector -ProtocolLoggingLevel Verbose
#송신 커넥터 로그 활성화
Get-SendConnector|Set-SendConnector -ProtocolLoggingLevel Verbose
#암시적 송신 커넥터 로그 활성화
Get-TransportService|Set-TransportService -IntraOrgConnectorProtocolLoggingLevel Verbose
Get-FrontendTransportService|Set-FrontendTransportService -IntraOrgConnectorProtocolLoggingLevel Verbose
#사서함 배달 수신 커넥터 로그 활성화
Get-MailboxTransportService|Set-MailboxTransportService -MailboxDeliveryConnectorProtocolLoggingLevel Verbose
아래의 명령어로 로그의 위치를 각서버에서 변경할 수 있습니다.
#Transport Service
Set-TransportService -Identity "서버명" -ConnectivityLogPath "D:\ExchangeLogs\Hub\Connectivity" -MessageTrackingLogPath "D:\ExchangeLogs\MessageTracking" -IrmLogPath "D:\ExchangeLogs\IRMLogs" -ActiveUserStatisticsLogPath "D:\ExchangeLogs\Hub\ActiveUsersStats" -ServerStatisticsLogPath "D:\ExchangeLogs\Hub\ServerStats" -ReceiveProtocolLogPath "D:\ExchangeLogs\Hub\ProtocolLog\SmtpReceive" -RoutingTableLogPath "D:\ExchangeLogs\Hub\Routing" -SendProtocolLogPath "D:\ExchangeLogs\Hub\ProtocolLog\SmtpSend" -QueueLogPath "D:\ExchangeLogs\Hub\QueueViewer" -WlmLogPath "D:\ExchangeLogs\Hub\WLM" -PipelineTracingPath "D:\ExchangeLogs\Hub\PipelineTracing" -AgentLogPath "D:\ExchangeLogs\Hub\AgentLog"
#Frontend Transport Service
Set-FrontendTransportService -Identity "서버명" -ConnectivityLogPath "D:\ExchangeLogs\Frontend\Connectivity" -ReceiveProtocolLogPath "D:\ExchangeLogs\Frontend\ProtocolLog\SmtpReceive" -RoutingTableLogPath "D:\ExchangeLogs\Frontend\Routing" -SendProtocolLogPath "D:\ExchangeLogs\Frontend\ProtocolLog\SmtpSend" -AgentLogPath "D:\ExchangeLogs\Frontend\AgentLog"
#Mailbox Transport Service
Set-MailboxTransportService -Identity "서버명" -ConnectivityLogPath "D:\ExchangeLogs\Mailbox\Connectivity" -ReceiveProtocolLogPath "D:\ExchangeLogs\Mailbox\ProtocolLog\SmtpReceive" -RoutingTableLogPath "D:\ExchangeLogs\Mailbox\Routing" -SendProtocolLogPath "D:\ExchangeLogs\Mailbox\ProtocolLog\SmtpSend" -MailboxDeliveryThrottlingLogPath "D:\ExchangeLogs\Mailbox\ProtocolLog\Delivery" -MailboxDeliveryAgentLogPath "D:\ExchangeLogs\Mailbox\AgentLog\Delivery" -MailboxSubmissionAgentLogPath "D:\ExchangeLogs\Mailbox\AgentLog\Submission"
외부에서 메일 발송
헤더는 아래와 같이 기록되어 있습니다.
<메일 흐름1>
우선 아래의 로그 경로로 이동합니다.
Frontend - ProtocolLog - SmtpReceive
기술자료에 나와 있는데로 Default Frontend 에서 SMTP 통신한 로그가 확인됩니다.
또한 EX19MBX3으로 Inbound Message를 Proxy 했다는 기록도 유추해 볼 수 있습니다.
<메일 흐름2>
Frontend - ProtocolLog - SmtpSend 경로로 이동합니다.
암시적 송신 커넥터의 로깅ㅁ을 활성화 하면, 아래와 같이 Inbound Proxy Internal Send Connector 로그가 활성화됩니다.
또한 EX19MBX3(10.0.3.6)의 Default EX19MBX3 Connector와 SMTP 통신이 진행되는 것도 확인됩니다.
아래와 같이 SMTP 통신 기록을 확인할 수 있습니다.
지금까지 EX19MBX1에서 이루어진 Frontend Transport Service 로그를 확인해 보았습니다.
이제 EX19MBX3에서 이루어진 Transport Service 로그를 확인해 볼 차례입니다.
마찬가지로 Hub(Transport) - ProtocolLog - SmtpReceive 에서 해당 시간대의 로그를 확인합니다.
Default EX19MBX3 에서 아래와 같이 기록이 확인됩니다.
즉, Default Frontend EX19MBX1 -> Inbound Proxy Internal Send Connector ->Default EX19MBX3 순으로 동작이 이루어졌습니다. 흐름도를 보면 수신커넥터가 다음 커넥터에 전달하는 것처럼 보이지만, 세부적으로 나누면 별도의 송신커넥터가 따로 존재한다고 볼 수 있습니다.
그리고 하나의 세션은 Sequence-number 순으로 로그가 기록된다는 것을 기억하도록 합니다.
역시 동일하게 SMTP 통신이 진행됩니다.
그렇다면 Frontend <->Transport 간의 로그가 동일하게 같지 않을까? 생각하지만, 그렇지는 않습니다.
요청하는 측과 응답받는 측에서 몇가지 동작이 다르기 때문입니다.
2개의 로그를 Excel에 복사하여 비교해 보았습니다.
<메일 흐름3>
Hub - ProtocolLog - SmtpSend 위치에서 다음 로그가 어떻게 이어지는지 확인해 보겠습니다.
Context 항목에 보면 SmtpReceive 에 기록된 session id를 Proxying 한다는 기록이 확인됩니다.
IP가 10.0.3.4:2525 라는 것은 EX19MBX1 의 Default EX19MBX1 커넥터와 통신한다는 것을 의미합니다.
그래서 EX19MBX1의 SmtpReceive 로그로 이동 한 뒤,
EX19MBX1의 입장에서 상대측 10.0.3.6.:34894 를 조회하였을 때, 아래와 같이 기록이 확인되었습니다.
헤더상에서는 기록이 나오지 않았지만, 다시 EX19MBX3 -> EX19MBX1 SMTP 통신이 이루어 진것으로 확인됩니다.
암시적 송신 커넥터의 기술자료 상에서는 다음과 같이 확인됩니다.
Transport service -> Transport service 에 해당하는 것으로 보입니다. 이 부분은 흐름도상 어떠한 영역에 해당하는 지 확인 되는대로 차후에 업데이트 하겠습니다. (아직 이해 못함)
<메일 흐름4>
EX19MBX3 의 SMTP Receive 로그를 다음 세션 ID를 계속 살펴 보면, 10.0.3.6:475로 SMTP 통신이 이루어지는 것으로 확인됩니다.
475 포트는 Mailbox Transport Delivery service 의 암시적 수신커넥터에서 발생하는 로그입니다.
Implicit Receive connectors in the Mailbox Transport Delivery service on Mailbox servers
즉, 475 포트로 통신이 이루어졌다는 의미는 Transport Service -> Mailbox Transport Service로 진행되는 흐름을 의미합니다.
그렇다면 Mailbox - ProtocolLog - SmtpReceive - Delivery 로그를 확인합니다.
Connector-id는 Default Mailbox Delivery <ServerName> 으로 기록되는 것이 확인됩니다.
해당 로그에서 MDBGUID 기록되는 것이 확인됩니다.
아래와 같이 GUID가 일치하는지 확인
추가적으로 Connectivity Log도 확인해 보았습니다.
Connectivity Log에서도 다음과 같이 확인됩니다.
기술자료에서 Inbound 흐름만 보면 다음과 같습니다.
그리고 각각의 커넥터의 로그에서 1~5구간을 확인할 수 있었습니다.
다음 포스팅
2022.01.15 - [Exchange] - Exchange Server Study (2-2). Mail Flow - Connector - Outbound
'Exchange' 카테고리의 다른 글
| 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 |
| Exchange Server Study (1). Mailbox (0) | 2022.01.09 |
| [EOS시리즈2](6) Exchange Server 2013 Uninstall & 2019 Install (0) | 2022.01.07 |
| [EOS시리즈2](5) Exchange Server From 2013 to 2019 Mailbox Migration (0) | 2022.01.06 |