Exchange 2013: Recipient Filtering Agent (More Lessons in Proxy)

  • [アーティクル]

With the arrival of Exchange 2013 came some design changes and, with those changes, inevitably something was bound to catch us off-guard. To help explain this better, enter the proxy from the CAS Frontend to the Mailbox backend.

All SMTP connections (we’re focusing on SMTP for this post) utilize the proxy of the Frontend Transport to make an SMTP connection. Even on multi-role servers, the incoming request on 25 utilizes the proxy to 2525 for Transport.

Here is a screenshot over-view of Transport from a previous EHLO blog:

The introduction of protocol proxy isn’t limited to SMTP but we’re focusing on SMTP, as it’s relevant to this post.

With the introduction of protocol proxy, there was an introduction of an issue with Transport Agents. Namely, Transport Agents that were installed on a Frontend server (CAS) were actually installed on a backend server. To get around this issue, one had to use local PowerShell and add the Exchange PowerShell Snap-in. However, what wasn’t consider is the following:

An Exchange Administrator installs the Transport Agents via PowerShell on the backend server and enables the Recipient Filtering Agent. [This introduces our problem.]

User A, external of the organization, composes a message to User B and an invalid recipient, User C, who are internal of the organization. The invalid recipient source isn’t as important as the fact that the invalid recipient exists in the header. When the external mail server connects to the on-premises Frontend, the typical SMTP traffic occurs:

  1. EHLO <domain>

  2. Server responds with “Hello <domain>”

  3. MAIL FROM: UserA@domain.com

  4. Server responds with “Sender O.K.”

  5. RCPT TO: UserB@domain2.com

  6. RCPT TO: UserC@domain2.com

  7. DATA command is sent

At this point in the session, the proxy connection is sent to the mailbox server that hosts UserB. The server, seeing that UserB exists responds with Recipient o.k. but, due to tar-pit, this doesn’t quite reach the Frontend, yet. When the Mailbox server receives UserC, it responds with 5.1.1 but this is during the data stream. This causes an NDR to be generated for all recipients of the message. This also means that the valid recipient never receives the email.

This is an issue with Exchange 2013 and the fully supported scenario is to only activate the recipient filtering agent on the Frontend server. The Frontend will respond correctly with the “250 2.1.5 Recipient OK” and “5.1.1 Invalid Recipient”, while the correct recipient receives the email and an NDR is generated for the invalid recipient.

Comments

  • Anonymous
    January 01, 2003
    thanks
  • Anonymous
    January 01, 2003
    You're welcome, "Me".
  • Anonymous
    August 07, 2014
    Thanks
  • Anonymous
    July 03, 2015
    Does this mean that it won't work in a single server scenario?