반응형

해당 자료를 기준으로 Self Study 진행

메일 흐름 및 전송 파이프라인 | Microsoft Docs

커넥터, Exchange, Exchange 송신 커넥터, Exchange 수신 커넥터 | Microsoft Docs

수신 커넥터 | Microsoft Docs

커넥터의 Exchange Server | Microsoft Docs

프로토콜 로깅 구성 | 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
  • All inbound SMTP Traffic
  • (optionally) outbound SMTP traffic
  • Stateless proxy
  • Queue X, inspection X
Front End Transport service on Mailbox servers: 이 서비스는 Exchange 2016 조직의 모든 인바운드 및 (선택적으로) 아웃 바운드 외부 SMTP 트래픽에 대한 상태 비 저장 프록시 역할을합니다. 프런트 엔드 전송 서비스는 메시지 콘텐츠를 검사하지 않으며 사서함 전송 서비스와 통신하지 않으며 메시지를 로컬에 대기시키지 않습니다.

EX2010 에는 해당서비스가 없고, EX2013 에서는 CAS 에서 확인할 있습니다.

 

종속성에는 별다른 점은 없어보입니다.

 

Transport service:
  • This service is virtually identical to the Hub Transport server role in Exchange Server 2010.
  • Handling all SMTP mail flow
(the organization, performs message categorization, and performs message content inspection.)
  • Unlike Exchange 2010, the Transport service never communicates directly with mailbox databases.
  • Routing messages among the Mailbox Transport service, the Transport service, the Front End Transport service, and (depending on your configuration) the Transport service on Edge Transport servers.
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

Description: Manages the queuing and dispatching of scan requests.

 

해당 서비스를 검색하면 아래의 기사를 확인할 있습니다.

Microsoft Filtering Management Service won’t start on Exchange 2013

https://blogs.technet.microsoft.com/exchangechallengeaccepted/2016/02/18/microsoft-filtering-management-service-wont-start-on-exchange-2013/

 

Mailbox Transport service on Mailbox servers: This service consists of two separate services:
Mailbox Transport Submission service:
  • connect to the local mailbox database using RPC.
  • submit the messages over SMTP to the Transport service on the local Mailbox server or on other Mailbox servers.
  • has access to the same routing topology information as the Transport service.


Mailbox Transport Delivery service:
  • receive SMTP messages from the Transport service on the local Mailbox server or on other Mailbox servers 
  • connect to the local mailbox database using RPC to deliver the messages.


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 통신이 이루어 진것으로 확인됩니다.

 

암시적 송신 커넥터의 기술자료 상에서는 다음과 같이 확인됩니다.

Implicit Send connectors

 

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

반응형

+ Recent posts