Table of Contents
- Personal
- What the Exchange 2010 SBR Transport Agent does
- What the Exchange 2013/2016 SBR Transport Agent does
- To Do / Not Tested
- SBR for Exchange 2010
- SBR for Exchange 2013
- SBR for Exchange 2016
- Comments
Personal
You may have found this page while searching for Exchange 2010/2013/2016 sender based routing, because you need this feature.
I'm not a programmer, usually I just do some VB/KiX/Dos batch/PowerShell scripting needed for logon scripts, AD and Exchange, so I had to invest some time in this little piece of code which is my first real coding project including compiling, creating a dll and stuff. I'm still on a steep learning curve...
As it is now it works as I want and it's externally configurable. I'd like to share it with you As Is, no guarantees whatsoever. Code is not *that* bad, a trained programmer would to many things different, there is no error checking for wrong input from the config files for example. So it's not foolproof, but as long as you know what you are doing... :-)
If you like it, use it, enhance it, found a logic flaw or bug in the code or just want to give me some advice what I could improve, I would be glad to hear from you at Contact.
What the Exchange 2010 SBR Transport Agent does
Mail Flow
While reading this article about ABP (Address Book Policies) changes in Exchange 2013 CU1, I realized that this agent can be a solution to the problem with fully resolved Exchange objects when one hosted organizations user sends emails to another hosted organizations user on the same Exchange 2010 system and shouldn't reveal all his information.
While the problem is solved in Exchange 2013 CU1 that ships with an agent that can be activated, there are no plans to backport this feature to Exchange 2010.
I therefore implemented a "GroupID" in the config files, so that the agent can check which internal domains are grouped based on this ID and for which email delivery can be normal (Exchange-internal). That means, if a recipient domain does not belong to the same ID as the sender domain, it should send the mail out of the system. When it returns from outside, the recipient is not able to fully resolve the senders AD object.
To prevent mail loops the agent only processes mails that originate from a client like Outlook, OWA, ActiveSync etc. (X-MS-Exchange-Organization-AuthAs header value = "Internal"). When it would process mails from outside (X-MS-Exchange-Organization-AuthAs header value = "Anonymous") for the defined domains, it would generate a loop.
Flowchart
• It looks at every mail that comes across the HT Server
• If the X-MS-Exchange-Organization-AuthAs header value is on the ignore list (typically Anonymous, inbound from outside), it quits
• If the sender domain or sender email address is not configured for re-routing, it quits
• If the sender domain or sender email address is configured for re-routing, it checks every recipient:
• Recipient domain is defined internal & GroupID is equal > No routing override
• Recipient domain is defined internal & GroupID is not equal > Routing override
• Recipient domain is not defined internal > It must be external > Routing override
Security Considerations
Maybe you noticed that this method sends an email out of the organization, and it comes back into it with an internal sender domain. For a while I had assumed Exchange would detect this domain spoofing automatically and deny the mail until I learned this is by default/by design/ootb not the case.
So we are not intentionally weaken security, the "feature" is already there for us to use. You could close this vulnerability by running this cmdlet Get-ReceiveConnector foo | Remove-ADPermission -user "NT AUTHORITY\Anonymous Logon" -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-Domain-Sender for your Receive Connector foo, but then this agent's logic wouldn't work anymore for the fully resolvable Exchange object problem.
What the Exchange 2013/2016 SBR Transport Agent does
Mail Flow
Flowchart
• It looks at every mail that comes across the MBX Server
• If the X-MS-Exchange-Organization-AuthAs header value is on the ignore list (typically Anonymous, inbound from outside), it quits
• If the sender domain or sender email address is not configured for re-routing, it quits
• If the sender domain or sender email address is configured for re-routing, it checks every recipient
• Recipient domain is defined internal > No routing override
• Recipient domain is not defined internal > Routing override
Security Considerations
You can close the domain spoofing "vulnerability" (emails with internal domain coming from Internet are received/allowed by default) by running this cmdlet Get-ReceiveConnector foo | Remove-ADPermission -user "NT AUTHORITY\Anonymous Logon" -ExtendedRights ms-Exch-SMTP-Accept-Authoritative-Domain-Sender for your default (Internet) Receive Connector.
Unlike in the Exchange 2010 solution above, we have an onboard agent here that handles the fully resolvable Exchange object problem for members of different ABPs which does not rely on sending a mail out of the organization.
Notes / To Do / Not Tested
2015/10/26: Exchange 2016 RTM is out. Precompiled the binaries and tested on my lab installation. Works.