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

PowerShell TTUC #13 – Scheduled Jobs

PowerShell Tips, Tricks and Useful Commands (TTUC) #13 – Scheduled Jobs PowerShell scripts can be run as a scheduled job using using Windows scheduler.  Create a batch file with the following syntax/commands:   Powershell.exe “c:scriptsmytestscript.ps1” Read more…

Microsoft

PowerShell TTUC #15 – File Name with Time Stamp

PoweShell TTUC (Tips, Tricks and Useful Commands) #16 – File Name with Time Stamp File can be created with date / time suffix using the following syntax / commands: New-item -type file -Name (“MyFile_$(Get-Date -f Read more…

Microsoft

F5 VPN Plug-in and NPuroamHost.dll Issue

By default, the F5 VPN plug-in (F5 Networks Firepass Host Plugin) doesn’t install from Internet Explorer 11 browser.  If you try the manual installation option, you will get only the NPuroamHost.dll file. Copying and pasting Read more…