Email Relay is one of the more annoying features of email servers. However, there are times it can be pretty useful. It’s annoying because Spammers love to exploit it, and it’s useful because it can allow you to centralize a lot of email services. If you aren’t sure whether you need a relay at all, check out my post on that subject. Most of the time, it’s not necessary, but if it is, continue reading.
What is Email Relay?
Email relay is, quite simple, a feature that allows one email server to use another email server for sending mail. In a relay setup, one SMTP server is configured to relay all the mail it’s trying to send through another email server when the sending email address is not a part of the second server’s organization. In a relay situation, Server 1 will connect to Server 2 and attempt to send an email using SMTP. However, unlike a normal SMTP session where Server 1 sets the recipient as an email address that “belongs” to Server 2, Server 1 tries to send an email to a recipient in a completely different organization. A successful relay basically means that Server 1 can use Server 2, which accepts email for company1.com, to send email to Company2.com.
How is Anonymous Relay Useful?
Sometimes you have an application or device that has its own email capability built in that needs to be able to send email to external recipients. Sometimes that application doesn’t support email authentication. Without the ability to perform anonymous relay, that application or device would need to have wide open access to the Internet in order to send email. This is not always an optimal solution, especially if you already have a central email solution in place. It’s simply more secure to have that application or device relay mail through a central email solution.
How is Anonymous Relay a Problem?
Allowing relay on an email server can cause some major problems, though. The biggest problem is with spammers. Spammers have software that will go to as many public IP addresses as possible, looking for IPs that respond on port 25. If a server responds, the software will attempt to send an email to a recipient by creating a relay session. If the relay session succeeds, that server is tagged as an “Open Relay” and the software will attempt to use that server as a source for loads and loads of Spam. This often results in massive mail queues and the server that is being used to relay mail will often be blacklisted and legitimate mail from that server ends up getting blocked by email systems that use blacklists as a form of spam filtering. In other words, having an open relay can cripple your Email infrastructure in any number of ways.
Relaying with Exchange 2010
By default, Exchange 2010 does not allow anonymous relaying. In fact, the last Email server developed by Microsoft that allowed relay by default was Exchange 2003. However, it is possible to configure Exchange 2010 to work as a relay, but you have to be careful with it because you don’t want to turn your Exchange server into an open relay for spammers to use and abuse.
Relaying in Exchange 2010 (and 2007 if you haven’t made the jump to 2010) is accomplished through the use of a simple setting that exists on the Receive Connectors. It’s called Externally Secured Authentication. Unfortunately, MS didn’t do a very good job at explaining what that setting actually does. The setting exists on the Authentication tab of the Receive Connector properties screen in the Exchange Management Console. The image below shows this setting:
The Externally Secured Authentication setting on Receive Connectors basically removes all security blocks and allows complete and total access to that receive connector for any server with an IP address that matches the address range configured in the Network tab on the connector. This means that once that little box is checked, any computer that matches the connector’s IP range can use the Exchange Hub Transport Server as a Relay.
The Externally Secured Authentication setting shuts everything off because it assumes that you are using some other security technique to allow other mail servers to communicate with the connector. So if you have a Unix mail server that has to send mail to your Exchange server, you can secure the communication between the two servers using IPSec or some other technique to prevent snooping and unauthorized access. Exchange assumes that the connection between hosts is secure and therefore allows complete access to all servers that communicate through the connector.
Checking Exchange Connectors for Hidden Relay Permissions
There are some rare situations where an Exchange Receive Connector can be set to allow relay. This is necessary in some cases, but isn’t recommended. The only time this situation exists is if someone has purposefully set a connector with the permissions that allow it. This permission will *not* show up in the Exchange GUI. You can check each connector for relay permission by running the following command in Exchange PowerShell:
1 |
Shutting Down Open Relay in Exchange
If you have Exchange 2010 and discover that your server is an open relay, the cause is usually due to someone having configured Externally Secured Authentication on your Default Receive Connector. The Default Receive Connector in Exchange 2010 is set up to allow communication with all IP addresses. If the Externally Secured Authentication setting is checked on the Default Receive Connector, every IP address is therefore allowed to use your Hub Transport Server to send mail to any recipient. This is not a good thing. Simply removing the Externally Secured Authentication setting will remove anonymous relay in this instance.
If you have receive connectors with the hidden rights shown above, run this command to remove those permissions:
1 |
You are, of course, free to keep those permissions if you like, but using the Externally Secured option makes the connector more easily identifiable, and that is a better practice as a result.
Securing an Anonymous Relay Connector in Exchange
So let’s take a for-instance. Let say you have an application that has to send emails to people who aren’t in your organization. You really want to use a Relay connector to do this. Here’s how you set it up in the EMC:
1. Navigate to Server Configuration -> Hub Transport in the EMC.
2. Click New Receive Connector in the Right side pane.
3. When the Wizard pops up, enter a name for the connector (Relay Connector works fine) and click Next
4. The Local Network Settings screen doesn’t have anything you have to worry about for this, so you can click next to go on or change the settings there to meet your needs.
5. The Remote Network Settings section of the wizard is where we actually secure this relay connector. The image below shows the default screen:
By default, you can see that the entire IPv4 range shows up (I have IPv6 disabled on my email server, on yours it may show the whole IPv6 range here as well). Select all entries that show here and click the red X to remove them. Click Add and enter the IP address of the server you want to use anonymous relay for. Click Next, then New to finish the wizard and create the connector.
6. Once the wizard is done and the connector is created, you should see it in the EMC. Right click the new connector and go to the Permissions tab first. Select Anonymous and Exchange servers (You have to do this to allow Externally Secured Authentication to be a valid selection). You can also check whatever other groups you want as well.
7. Click the Authentication tab and select the Externally Secured Authentication box. Remove all other check marks and click Apply. Click apply and the connector will be set up properly to allow Relay.
8. Click the Network tab and make sure that only the servers you want to relay are listed under “Receive mail from remote servers that have these IP addresses.” If you still have the full IP range listed the server will be an Open Relay at this point.
Note that when you do this, all communications between the server that is sending mail to the Relay server will be in clear text. This means that anyone sniffing traffic between the two mail servers can read the emails with ease. This is usually not a big deal on an Internal network, but you’ll want to make sure there actually *is* an external encryption system going between the two servers to secure the transmission of data.
