UPDATED: May 2017
Allow internal SMTP email relay, bypass the junk filters, and make it all work right the first time.
Update: This guidance is still valid up to and including Exchange 2016, but the steps below refer to Exchange 2010. Newer versions use the same types of permissions, but most operations must be done through Exchange PowerShell.
A common scenario for server admins is allowing internal servers to safely relay anonymous emails for alerts, logs, or internal application notifications through Exchange, and ensure the messages are delivered correctly to users.
Beginning with Exchange 2007 Microsoft made changes which made this a better and more controlled process than previous versions, but also made two confusing and distinct ways to configure: the "Externally secured" method and the "anonymous" method.
Both have their pluses and minuses, but our recommendation is always the latter, as it makes identifying emails that were submitted anonymously (and therefore potentially untrusted) more obvious. Why? Messages submitted in this fashion will advise Outlook not to resolve the sender address to a Display Name. Rather, it only shows the exact (and often completely random) sender from the host SMTP session's envelope. Equally importantly, using this method the end-to-end anti-junk mail configuration will work correctly across both Exchange and Outlook's various filters.
Microsoft's provides this Technet article which covers how to configure both methods on the Exchange server, but unfortunately gives no context or explanation as to why an admin would choose one or the other. We've written this article based on our experience and testing, to provide the missing details.
Configuration Guidance for Anonymous Method:
We will follow the steps in the article section Grant the relay permission to anonymous connection
- In EMC at the Organization/Hub Transport node under the Anti-Spam tab, ensure that the IP Allow List and Content Filter are enabled. These features together actually do the work to make the messages quasi-trusted and stamp the "SCL -1" rating. Failing to enable both will result in messages not correctly bypassing filters.
If you don't see these options you might have to run the script to enable Anti-spam features on your server.
- You may use either the EMS or the EMC (Under Server Configuration/Hub Transport node) to create a new Receive Connector and define the appropriate remote networks or hosts that will be able to use this new connection.
Note: Be sure you don't leave this new connector accepting connections from all IPs, as this is a security risk for mailicious staff or malware that may get lose on your network. All conenctions to Exchange should be secured or from known systems only.
- Next, assign the appropriate AD Permission of Ms-Exch-SMTP-Accept-Any-Recipient via the Exchange Management Shell. At this point, DO NOT follow the rest of the steps under Configure the Receive connector as externally secured, as this method will not be used.
- Under Server Configuration/Hub Transport switch to the Anti-spam tab. and open the IP Allow List
- Duplicate the list of hosts that you had enabled to send through your new Receive Connector here. This ensures that both server and client-side anti-spam are bypassed, and the X-SCL -1 header is stamped for Outlook's later use.
Email will now be accepted and relayed through your new connector and will always go directly to the Inbox of users in Outlook/OWA.
Why Not Externally Secured?
While this method is easier to configure - just click the checkbox in the EMC - it has two negatives. The first is the previously mentioned display name resolving in Outlook (via the AD Permission "ResolveP2") With this permission Exchange will consider submitted emails to be authenticated (which they're not), and subsequently resolves the SMTP address to a display name if possible. This is a bad practice in our opinion, as it tricks the end-user into believing this is trusted sender.
The second, and more frustrating problem, is that Exchange will not stamp SCL headers into the message, so the Outlook client-side filtering will be applied (if enabled). As more-often than not server alerts and backup log messages will look very spammy, they will promptly get turfed into the Junk Email folder. As Outlook thinks it is being helpful deciding on its own, rather than looking at what Exchange rated the message, when in fact it's just creating unhappy users and admins.
Further Reading
What happens when you make your new Receive Connector Externally Secured?
This will be granting several rights including the ability to send on behalf of users in the organization, the ability to ResolveP2 (that is, make it so that the messages appear to be sent from within the organization rather than anonymously), bypass anti-spam, and bypass size limits. The default "Externally Secured" permissions are as follows:
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authoritative-Domain}
MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Anti-Spam}
MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Message-Size-Limit}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Exch50}
MS Exchange\Externally Secured Servers {ms-Exch-Accept-Headers-Routing}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Submit}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Recipient}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authentication-Flag}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Sender}This is telling Exchange to ignore internal security checks because these servers are trusted, which goes against the ethos of an anonymous relay point.
What happens when you add the Relay Permission instead?
This option grants the minimum amount of required privileges to the Receive Connector for accepting messages from and to anyone, and must be done consciously through the Exchange Shell, rather than clicking a checkbox.
Accepted Domains, Safe Senders List and You
http://blogs.technet.com/b/exchange/archive/2011/07/08/accepted-domains-safe-senders-list-and-you.aspx
Exchange anti-spam myths revealed
http://blogs.technet.com/b/exchange/archive/2009/11/13/exchange-anti-spam-myths-revealed.aspx
The saga of the "Junk Email" Folder - putting the puzzle together
http://www.exchangeinbox.com/article.aspx?i=155
Need your Exchange Server to work day and night, and not worry?
Planning an Office 365 Migration?
Contact us today.
![language_01[1].png](https://images.squarespace-cdn.com/content/v1/4f8f1911e4b05c061cb7c910/1376420720926-7UJVMDZL0AYL773S6DD4/language_01%5B1%5D.png)