In this first article of our Exchange Architecture Series, we will explore the new Transport Architecture of Exchange 2013. I’ll try not to repeat a lot of information that is stored on other Sources unless I believe that there is a lot of value to having it in my posting.

The Transport Pipeline
The transport pipeline is a new concept introduced in Exchange 2013 to describe the collection of services, connections, components, and queues that work together to route all messages to the categorizer in the Transport service on a Mailbox server inside the organization.

The transport pipeline comprises of three primary services that have been deployed either on a Mailbox Server role or on a Client Access Server role. (Note that in Exchange 2013,  the Hub Transport and Front End Server roles have been removed)

• Front End Transport service (CAS role): This service runs on all Client Access servers and acts as a stateless proxy for all inbound and outbound external SMTP traffic for the Exchange 2013 organization. The Front End Transport service can filter and route messages based on policy rules, but cannot inspect message content. This service communicates with the Transport service on a Mailbox server, and doesn’t queue any messages locally.
• Transport service (Mailbox role): This service runs on all Mailbox servers and replaces the Hub Transport server role in previous versions of Exchange. The Transport service manages all SMTP mail flow for the organization, (includes message categorization and content inspection). This service routes messages between i) the Front End Transport service; ii)the Transport service on other servers; and iii) the Mailbox Transport service.
• Mailbox Transport service (Mailbox role): This service runs on all Mailbox servers and consists of two separate services:
  i) Mailbox Transport Submission service: connects to the local mailbox database using RPC to retrieve messages, and submits the messages over SMTP to the Transport service on the local Mailbox server, or on other Mailbox servers. Accesses the same routing topology information as the Transport Service and also does not queue any messages locally.
  ii) Mailbox Transport Delivery service: receives SMTP messages from the Transport service on the local Mailbox server or on other Mailbox servers, and connects to the local mailbox database using an Exchange remote procedure call (RPC) to deliver the message.

The transport pipeline is illustrated below (source)

Inbound Mailflow Steps:
It’s easier to describe this architecture by tracing how an email from an external sender gets to your mailbox. The steps are as follows:

1. An email message arrives over the internet via SMTP and gets processed by the SMTP Receive connector within the Front End Transportservice running on an Internet-facing CAS Server†.
2. The Front End Transport service inspects the message header and performs some routing logic. In this case, the message is routed to a Mailbox Server in the same site and transmitted via the SMTP Send component of the Front End Transport service.
3. The SMTP Receive connector of the Transport service on the target Mailbox Server receives the message and performs message content inspection; applies transport rules; and performs anti-spam and anti-malware inspection if they are enabled.
4. Every message that is isn’t rejected by the Transport service must then be categorized. It is first placed in the submission queue.
5. The categorizer picks up one message at a time for categorization, performing the following steps:

• Recipient resolution (includes top-level addressing, expansion, and bifurcation)
• Routing resolution
• Content conversion
• Applying relevant mailflow rules

6. Messages are then placed in a delivery queue that’s based on the destination of the message. (Exchange 2013 has a more granular queuing model that is based on destination mailbox database, DAG, Active Directory site, Active Directory forest or external domain)
7. The message is finally transmitted via the SMTP Send connector to a routing destination, which in this case is the Mailbox Transport Delivery service running on the same server††.
8. The Mailbox Transport Delivery service receives the message and submits it to the Store Driver, which instructs the Mailbox Deliver Agents to submit the messages to the individual mailboxes.

†There are multiple ways by which messages can enter the Transport service on a Mailbox server, including

• Through a Receive connector.
• From the Pickup directory or the Replay directory.
• From the Mailbox Transport service.
• Through agent submission.

††There are also multiple routing destinations that a mailbox transport service can route emails, including

• Another Mailbox Server that’s part of the same DAG
• The Transport service running on another Mailbox Server that’s in a different DAG, Active Directory site, or Active Directory forest
• The Front End Transport service on a CAS server for delivery to the Internet

Conclusion:
In this post, we got to see how a message is treated as it enters an Exchange organization and eventually gets delivered to a user’s mailbox. In the next post, we will explore how Exchange 2013 routes messages.