Exchange 2013 Mail Flow (Part 3)

If you would like to read the other parts in this article series please go to:

Front End Transport service Routing

As explained in the previous articles of this series, this service runs on all Client Access servers and acts as a stateless proxy for all inbound and outbound external SMTP traffic.

For outgoing messages, the Transport service on Mailbox servers uses Send connectors to communicate with the Front End Transport service. Specifically, outgoing messages are proxied through the Front End Transport service when the FrontEndProxyEnabled parameter on an applicable Send connector is set to $True in the Exchange Management Shell, or the Proxy through client access server option is selected in the Exchange Administration Center:

Image
Figure 3.1:
Exchange 2013 Send Connector Proxy Enabled

For incoming messages, the Front End Transport service looks for a single healthy Transport service on a Mailbox server to receive the message. Failure to do so results in the e-mail service being perceived as unavailable by the external senders as this service does not queue messages.

The Front End Transport service resolves message recipients to mailbox databases (unless the recipient is a distribution group, for example) by querying AD. Then, for each mailbox database, it looks up the delivery group (which can be a Routable DAG, a Mailbox delivery group or an AD site) and the associated routing information.

Based 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 AD 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 AD site. Because message bifurcation doesn’t occur in Front-End Transport, only one Mailbox server is selected;
  • If the message has no mailbox recipients, select a random Mailbox server in the local AD site.

Mailbox Transport service Routing

For incoming messages, the Mailbox Transport Delivery service receives SMTP messages from the Transport service and connects to the local mailbox database using Remote Procedure Call [RPC] to deliver the message. For outgoing messages, the 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. The Mailbox Transport service is stateless, and does not queue any messages locally.

When a user sends an e-mail, the Mailbox Transport Submission service resolves the message recipients to mailbox databases (unless the recipient is a distribution group, for example) by querying AD. Then, for each mailbox database, it looks up the delivery group (which can be a Routable DAG, a Mailbox delivery group or an AD site) and the associated routing information.

Based on the number and type of recipients, the Mailbox Transport Submission 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 AD 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 AD site;
  • If the message has no mailbox recipients, select a Mailbox server in the local delivery group.

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 as it can only deliver the message if the recipient resides in an active copy of a local mailbox database. If not, then the Mailbox Transport Delivery service can’t deliver the message and must provide a non-delivery response to the Transport service. This might happen if, for example, the active copy of the mailbox database recently moved to another server and the Transport service incorrectly transmitted a message to a Mailbox server that now holds an inactive copy of the mailbox database. In this case, the non-delivery response that the Mailbox Transport Delivery service returns to the Transport service is one of the following:

  • Retry delivery;
  • Generate an NDR;
  • Reroute the message.

Tracking Message Flow

Similar to Exchange 2010, we can use Delivery Reports to track messages sent to or from users in an Exchange 2013 organization (sent using Outlook or Outlook Web App only and not POP or IMAP!) and check their delivery status.

However, to better understand the flow of messages in Exchange 2013, we need to turn to our good old friends Message Tracking Logs. There is only one difference in this new version of Exchange: because we no longer have a dedicated Hub Transport Server role, the Get-TransportServer cmdlet is getting replaced by two new cmdlets:

  • the Get-TransportService cmdlet which returns transport configuration information for the Transport service on Mailbox servers or for Edge Transport servers;
  • the Get-MailboxTransportService cmdlet which returns transport configuration information for the Mailbox Transport service on Mailbox servers

So, let’s look at the flow of an e-mail sent from the internal user Nuno (whose mailbox is on server MBX1) to the internal user Mota (whose mailbox is on server MBX2). Using the Exchange Management Shell, we run the following cmdlet to get information regarding this particular e-mail (in this case it doesn’t matter which of the above cmdlets we run as all we need are the names of the Mailbox servers possibly involved in the mail flow, which both cmdlets return):

Get-TransportService | Get-MessageTrackingLog –ResultSize Unlimited –Start “11/11/2012” –Sender [email protected] -Recipients [email protected] –MessageSubject “Testing Mail Flow” | Sort TimeStamp | Select ClientHostname, ServerHostname, ConnectorId, Source, EventId

Analyzing the output of this search, we obtain the following which we can map into the following diagram:

Image
Figure 3.2: Exchange 2013 Transport Pipeline

1. The Mailbox Transport Submission service uses the Store Driver to connect to the mailbox database using RPC and retrieves the e-mail:

ClientHostname          : MBX1.letsexchange.com

ServerHostname          : MBX1

ConnectorId             :

Source                  : STOREDRIVER

EventId                 : RECEIVE

2. After resolving the message recipient to its mailbox database, the Mailbox Transport Submission service looks up the delivery group, a Mailbox delivery group in this case. So the Store Driver passes the e-mail to the Hub Selector for this to be sent over SMTP to the appropriate server.

In this case the e-mail is not passed to the Transport service. You can test this by stopping the Microsoft Exchange Transport service on your source mailbox server and you will see the e-mail will still be sent.

ClientHostname          : MBX1

ServerHostname          : MBX2.letsexchange.com

ConnectorId             :

Source                  : STOREDRIVER

EventId                 : SUBMIT

3. The Transport service on the MBX2 mailbox server receives the e-mail sent over SMTP from the Mailbox Transport Submission service of server MBX1 using its default receive connector. Content inspection is performed, transport rules are applied and anti-spam/anti-malware inspection is performed (if enabled). As the e-mail is not rejected by any of these, it is put in the Submission queue.

ClientHostname          : MBX1.letsexchange.com

ServerHostname          : MBX2

ConnectorId             : MBX2\Default MBX2

Source                  : SMTP

EventId                 : RECEIVE

4. The Categorizer picks up the e-mail from the Submission Queue, processes it and puts into a delivery queue based on the destination of the message (in this case, a mailbox database):

ClientHostname          : MBX2

ServerHostname          :

ConnectorId             :

Source                  : AGENT

EventId                 : AGENTINFO

5. The e-mail is sent over SMTP from the Transport service to the Mailbox Transport Delivery service:

ClientHostname          : MBX2

ServerHostname          : MBX2.letsexchange.com

ConnectorId             : Intra-Organization SMTP Send Connector

Source                  : SMTP

EventId                 : SEND

6. The e-mail is received over SMTP by the Mailbox Transport Delivery service from the Transport service:

ClientHostname          : MBX2.letsexchange.com

ServerHostname          : MBX2

ConnectorId             : MBX2\Default Mailbox Delivery MBX2

Source                  : SMTP

EventId                 : RECEIVE

7. The Mailbox Transport Delivery service uses the Store Driver to connect to the mailbox database using RPC and writes the e-mail to the mailbox database:

ClientHostname          : MBX2

ServerHostname          : MBX2

ConnectorId             :

Source                  : STOREDRIVER

EventId                 : DELIVER

Simplifying the diagram in Figure 3.2 for this example, we end up with:

Image
Figure 3.3: Mail Flow Trace

Queues

As we saw several times now, out of the three services involved in Mail Flow, only the Transport service provides local queuing. The Front End Transport service and the Mailbox Transport service, do not provide local queuing.

This is different from earlier versions of Exchange as we do have queues in the Exchange 2007/2010 Edge servers. I do not know the reason behind this decision but if you use a Client Access server as the e-mail gateway to your organization, be very careful! If there are no mailbox servers available to receive e-mails (either the one where the recipient’s mailbox resides or any other), a failure notification will be issued to the sender’s server immediately… Although most servers will keep trying to deliver the e-mail to your organization for 24, 48 or even 72h, this might lead to message failures especially with applications or other devices other than mail servers.

Therefore, if you have a custom Receive Connector for applications, printers, or other devices, with Exchange 2013 you might want to create it on your Mailbox servers and not on the Client Access servers for this exact reason.

Conclusion

In this article series we explored Mail Flow and the changes introduced to the Transport Pipeline by the new architecture of Exchange 2013.

In a future article, we will look at the High Availability improvements to the Transport Pipeline introduced in Exchange 2013.

If you would like to read the other parts in this article series please go to:

About The Author

6 thoughts on “Exchange 2013 Mail Flow (Part 3)”

  1. Great post. But as internal email flow goes through a receive connector, why doesn’t that Receive connectors max size limit apply? This occurs in my environment. The org level is set higher so I believe the most restrictive is supposed to take affect which in our case would be that Default Receive Connector, but the messages that are above that threshold still make it to it’s destination.

    1. Hi Scotch,

      Thank you! 🙂

      Please note that recipient limits between authenticated senders and recipients (typically, internal message senders and recipients) are exempt from the organizational message size restrictions! This means that your org limit will not apply for emails exchange between internal users.

      Nor will those on Receive Connectors (assuming users are sending emails using Outlook/OWA). If you want to limit the size of emails for your internal users, either set limits at the mailbox level, or at the Transport level (check by running: Get-TransportConfig | Select MaxSendSize, MaxReceiveSize).
      Hope this helps.

      Regards,
      Nuno

  2. Hi Nuno, this is a very good article. I just want to know what could be the possible reason when a user sends an email to an external recipient, but the recipient didn’t receive it. Also, there’s no NDR

    1. Hi Drei,
      Thank you! 🙂 It could be that an intermediate (or even the destination) server is simply dropping the emails without sending an NDR. It’s impossible to tell what the problem is without doing a message trace from the recipient’s side…

  3. Hi Nuno,
    Thanks for a very comprehensive article!
    Unfortunately, I wasn’t able to find the answer I was looking for. I’m trying to set up a custom receive connector that enforces mutual auth TLS from one particular external vendor partner. I can create a FrontendTransport Receive Connector and scope it for the IP the partner is sending from, but I cannot receive test messages, UNLESS the default FrontendTransport Receive Connector is also enabled. I have configured Authentication, Permission Groups, and scoping as appropriate for the external partner on the FrontendTransport Receive Connector. Since it doesn’t work in testing if the default FrontendTransport Receive Connector is disabled, it makes me wonder if the custom FrontendTransport Receive Connector also requires a custom HubTransport Connector to be configured with Authentication, Permission Groups, and Scoping settings that exactly match those of the FrontendTransport Receive Connector.
    Can you confirm if that’s the case?

  4. Hi Nuno,
    Great post. Any plans for an follow up post where Office 365 is included in an hybrid configuration with Exchange?

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top