Relaying: The easy way, and the secure way

The best way to allow unauthenticated relaying, or certainly the more secure and recommended one, is to create or use a Receive Connector dedicated for this purpose. 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 anonymous relaying, even if restricted to specified IP addresses.

Relaying: The easy way, and the secure way

The best way to allow unauthenticated relaying, or certainly the more secure and recommended one, is to create or use a Receive Connector dedicated for this purpose. 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 anonymous relaying, even if restricted to specified 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.
Receive Connector Bindings in Exchange 2010/2007

Server processes communicating using TCP/IP listen on a particular port number on a given network interface or IP address. This combination of IP address + port number is known as a socket or binding. Two processes can’t use the same socket at the same time— each needs to have a unique binding. In Exchange 2003, SMTP Virtual Servers bind to a socket, specified by a unique combination of IP address + port number.

In Exchange 2010/2007, Receive Connectors also consider the RemoteIPRanges — the IP addresses or subnets that are allowed to connect to a Receive Connector, in addition to the IP address + port combination, as a unique binding. In other words, you can create more than one Receive Connectors using the same IP address + port combination, but different RemoteIPRanges. This allows you to enforce different settings for different SMTP hosts that connect to the same IP address + port. .

Allow relaying: 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
  • Specifies the usage type Custom
  • Binds the Receive Connector to port 25 on IP address 192.168.1.17
  • Gives it the FQDN of server.domain.com
  • Allows only the host with the IP address 192.168.1.100 to connect to it (specified by the RemoteIPRanges parameter)
  • Additionally, and most importantly, it assigns the ExchangeServers permission group to it, and disables authentication. When you select ExternalAuthoritative for authentication, you’re telling Exchange that you completely trust the IP address(es) or subnets specified in the RemoteIPRanges parameter (192.168.1.100) and you have another authentication mechanism outside of Exchange, such as IPSec, to authenticate.

This also bypasses all security for messages received from that IP address. Because Exchange treats all hosts specified in RemoteIPRanges as trusted, it doesn’t apply anti-spam filters, doesn’t enforce 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 to allow relaying

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. However, we’re still restricting it to a particular IP address— 192.168.1.100. The big difference from the previous approach is we’re not treating the host as trusted.

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 AUTHORITYANONYMOUS LOGON” -ExtendedRights “ms-Exch-SMTP-Accept-Any-Recipient”


Leave a Reply

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

Related Posts

Microsoft

Azure Password Reset – The Password you’ve selected does not meet your Active Directory password policy

This is a common error message when you try to reset a password from Azure management port or Self service portal.  The error message is very clear here – “The Password you’ve selected does not Read more…

Microsoft

Azure – Your account is temporarily locked to prevent unauthorized use

Here is the another common error message when dealing with directory and password synchronization.  Error Message: Your account is temporarily locked to prevent unauthorized use. Try again later. Contact Customer Support if the problem persists Read more…

Microsoft

Verify Service Status Remotely Using Local Account – PowerShell Script

I have modified one of my previously published script – Stop, Start, Disable Service Remotely–PowerShell Script (http://portal.sivarajan.com/2011/05/stop-start-disable-service.html) to use Local account (instead of a domain account) to verify the status of the service.   Input Read more…