Exchange Server 2007: How To Allow Relaying

In Exchange Server 2003, unauthenticated hosts can be allowed to relay by adding their IP address(es) in SMTP Virtual Server properties | Access tab | Relay. This is commonly done for application servers, and devices that need to send mail - like copiers that can scan documents and send by email.


Figure 1: Controlling relay restrictions in Exchange Server 2003

In Exchange Server 2007, SMTP Virtual Servers have been replaced by Receive Connectors, and the SMTP stack is now native to Exchange (unlike Exchange Server 2003, you no longer need to install IIS' SMTP service/stack). Understandably, the way you allow relaying has changed as well.

Do you really need to allow relaying?
Before you setup unauthenticated relaying, it's important to understand the need for relaying. If your application server or devices like copiers need to send mail only to internal recipients - mail for which Exchange has an AcceptedDomain (or a Recipient Policy in Exchange Server 2003/2000) and therefore will receive inbound mail for - it is not considered relaying. The application server or device should be able to do this without any configuration on Exchange.

Recipient Policies and Exchange Server 2007

Exchange Server 2003 Recipient Policies tell Exchange which domains to receive inbound email for, and to generate email addresses. Exchange Server 2007 splits this functionality into AcceptedDomain - which, as the name suggests, tells Exchange which domain(s) to accept inbound email for - and EmailAddressPolicy which actually generates the email addresses. Unlike Exchange Server 2003/2000, there's no RUS to watch AD for new recipients or changes to existing ones. Recipients are provisioned in Exchange - using the console or the shell - and EmailAddressPolicy applied in real-time.

Just like previous versions, Exchange Server 2007 allows authenticated relaying by default. So if your application server or device can authenticate, that's the way to go.

The best way to allow unauthenticated relaying, or certainly the more secure and recommended one, is to create a new Receive Connector. I recommended this approach even on Exchange Server 2003/2000 - it's not a good idea to use your internet-exposed SMTP virtual server to allow unauthenticated relaying, even if restricted by IP addresses.

Scott Landry wrote about this recently on the Exchange team blog in "Allowing application servers to relay off Exchange Server 2007".

To create a new Receive Connector, you need another IP address on your Exchange server. (The other alternative is to create a new Receive Connector that listens on a different port instead of the default SMTP port (TCP port 25). Most app servers and devices don't like this, and many won't let you configure an alternate port for sending smtp mail. I would simply add another IP address to the server. As a sidenote, Exchange Server 2007's Receive Connectors also consider the RemoteIPRanges in addition to the IP address + port combination for binding. More about that in a future post.).

The easy way: With the new IP address added to the Exchange server - let's say it is 192.168.1.17, and your app server, device or copier that needs to relay is 192.168.1.100, fire up Exchange shell and use the following command:

New-ReceiveConnector -Name RelayConnector -usage Custom -Bindings '192.168.1.17:25' -fqdn server.domain.com -RemoteIPRanges 192.168.1.100 -server MYEXCHANGESERVER -permissiongroups ExchangeServers -AuthMechanism 'TLS, ExternalAuthoritative'

What this does - creates a new Receive Connector called RelayConnector for usage type: custom, binds it on port 25 on IP address 192.168.1.17, gives it the fqdn of server.domain.com, and allows the IP address 192.168.1.100 to connect to it. Additionally - and most importantly, it also assigns ExchangeServers permission group to it, and disables authentication - or rather, it assumes you completely trust the IP address 192.168.1.100 and have another means of authenticating it, such as IPSec.

This also bypasses all security for messages received from that IP address - doesn't apply any anti-spam filters, nor cares about message size limits, resolves P2 headers, and allows sending on behalf of users. Going back to Exchange Server 2003, this is somewhat similar to adding the sending host's address to Connection Filtering's Global Accept list.

A better, more secure way: If you want it to be more secure, you can create a Receive Connector with PermissionGroups set to AnonymousUsers:

New-ReceiveConnector -Name RelayConnector -usage Custom -Bindings '192.168.1.17:25' -fqdn server.domain.com -RemoteIPRanges 192.168.1.100 -server MYEXCHANGESERVER -permissiongroups AnonymousUsers

Notice, we've left out the AuthMechanism parameter in the above command.

Next, allow anonymous users to relay. This is done by allowing anonymous users the extended right ms-Exch-SMTP-Accept-Any-Recipient for this Connector:

Get-ReceiveConnector RelayConnector | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

For more information about transport permissions, refer to "Exchange Server 2007 Transport Permissions Model" in Exchange Server 2007 documentation. Granular permissions can be assigned to security principals on Receive (and Send) Connectors. For instance, if you want to have these messages bypass the anti-spam filters, you can also assign the ms-Exch-Bypass-Anti-Spam permission.

What's the difference? The difference between the 2 approaches can be seen when you send test messages, as shown in the following screenshot:


Figure 2:The difference between the 2 approaches can be seen in how messages are displayed in email clients

The first message at 9:22 AM is sent by the first Connector, where the message received without authentication actually shows up as sent by me - the P2 headers are resolved. (More about resolving anonymous senders in previous post: " A Late New Year's Resolution: Do Not Resolve Anonymous Senders"). Whereas the second message at 9:34 AM actually shows up with the sender's SMTP address.

The second message also went through the anti-spam filters - a quick check of the message headers reveals the antispam headers.


Figure 3: Messages received using the second method do not bypass anti-spam filters by default