How to Test for Open Mail Relays

Carrie Roberts // *Guest Blog

It is important to ensure that your external mail servers are properly configured to not support open relaying of mail. An open mail relay can be abused by spammers, eating up your resources and landing you on a blacklist. It is not too common to find completely open mail relays these days because they get abused, thus inspiring them to be fixed.

But what is common is to find is what I call a “Partially Open Mail Relay”. This occurs when the mail relay can be used to do one of the following:

• Send email from an external source address to an internal destination address.
• Send email from an internal source address to an internal destination address.

This is quite useful for an attacker developing an email phishing campaign against internal users. Imagine an email to all employees appearing to come from the CSO. Exploiting the partially open mail relay makes the email appear genuine so that employees have no visual indication that this is not truly from the CSO. If the employee’s email client is telling them it came from the CSO and the source email address confirms this, they are more likely to trust that it actually did. None of the usual “this is a phish” clues, such as the use of a look-a-like domain name are present.

Unfortunately, vulnerability scanners do not do a good job of detecting this vulnerability, if they even detect it at all. So to be sure, you need to test it yourself, and this is how you can do it.

Use a telnet or netcat client to connect to the mail server port. There is a gotcha here to watch out for. The mail server port is typically port 25 and many home Internet Service Providers block this port. This means that when you try to connect, it will time out. Two examples of failing to connect for this reason are shown below. The first is an attempt with the telnet client and the second is an attempt to connect with the netcat client.

You can check if your port 25 is open for communication on windows with the following PowerShell command.

powershell (New-Object System.Net.Webclient).DownloadString('http://open.zorinaq.com:25')

If you get a response other than “Yep, port 25 is open” you may have filtering going on and you’ll need to do this testing from a different network location.

Now that we know we can communicate on port 25 we can use the following commands to test for open mail relays. In the example below, the blue text shows what you should enter on the command-line and green text shows the command output or server response.

The commands above are just an example and as it turns out, a bad one for testing open mail relays. This is because example.com is actually a special case configured into some mail servers for testing. It will pretend to accept the message for delivery but it actually doesn’t.  So when you want to test on open mail relay, use a different domain than example.com. The first thing you should check is if mail can be relayed from an external email address to an external email address as shown below.

Test: External Source Address, External Destination Address

• MAIL FROM: <[email protected]>
• RCPT TO: <[email protected]>

Next, check to see if you can relay mail using an external source email address and an internal destination address.

Test: External Source Address, Internal Destination Address

• MAIL FROM: <[email protected]>
• RCPT TO: <[email protected]>

Last, check to see if you can relay mail using an internal source email address and an internal destination address.

Test: Internal Source Address, Internal Destination Address

• MAIL FROM: <[email protected]>
• RCPT TO: <[email protected]>

You should repeat this last test to ensure you have used both an existing internal source address and a non-existing internal source address. This is because some mail servers may be configured to require authentication for an existing user but it may be possible to bypass this protection by using a non-existent internal source address such as [email protected] in our example.

Check this on all your mail servers, as each may be configured differently. This is how you can use the Linux dig command to list the mail servers for your domain. Or for Windows, try nslookup.

dig @8.8.8.8 blackhillsinfosec.com -t MX 

There is also a Metasploit module that can test for mail relaying here.

And finally, here are some suggestions for how to remediate any issues you find. The simple answer is to configure your mail server to not relay mail, but business requirements may require mail relaying from trusted third parties. In this case, consider implementing one of the following controls, with the first being the preferred solution:

• Require authentication with user accounts and encryption through STARTTLS.
• Configure the email gateway to only allow the IP addresses of the email gateways themselves and authorized IP addresses to send.