I recently wrote an article that dismissed the use of fake MX records as an email security measure, on the basis that it did more harm than good for preventing spam.

I was reminded this week of an incident in which a customer was confused as to how spam was making it into their email systems.  Actually this has happened on more than one occasion with the same ultimate outcome.

The confusion mostly comes from the client thinking that because there were no MX records in public DNS zones that pointed to their email servers that the spammers and hackers shouldn’t be able to find them.

The fatal flaw in that thinking is that spammers and hackers don’t just use MX records to find places to send email or attack mail servers.  When they really want to find email servers, say to try and locate some open relays that they can exploit, they will use port scans instead.

A “port” in networking terminology is a communications end point that is specific to a process or service running on a computer.  In the case of SMTP, the protocol that email users, the port is TCP 25.

In other words, if you’re running an email server on your network then chances are you firewall has TCP port 25 open and allowing traffic through from the internet to your server.  In many cases the traffic might be filtered first by an intermediary server, but with a lot of environments running their email security software directly on the email server itself, often the SMTP traffic goes straight to that server.

In my customer’s case they had multiple servers in the environment, with a security product running on the internet-facing email server.  When they had merged companies they had ended up with multiple internet connections and firewalls, and kept those running.  They consolidated all of their email to the primary site, removing the MX records that were pointing to the second firewall and then promptly forgot all about it.

Later they redeployed a second email server at the secondary site as it outgrew the first one, re-using the IP address of the server that had originally been there.  Spam became a problem for them a few weeks later.

Their first mistake was only removing the MX records and leaving the firewall port open.  The second mistake was also common to a lot of environments that I see.  The server was configured to allow relaying to anyone.  The thinking at the time was that the server was accessible to internal devices only, so allowing to relay anything was easier than limiting relay to specific IP addresses.

Because they had reused the original mail server IP for that site, it now sat exposed to the internet, configured as an open relay.

The lessons for email administrators are clear:

• Understand that MX records are not the only way that attackers seek out email servers
• Don’t configure your servers as open relays, even when you think they are internal only
• Always be aware of what firewall rules are configured for your email server IP addresses