Information Technology Management

For many years, I have had a server at one colocation site or another.  I host a number of my own sites, and a hand full of others which helps pay for the cost of hosting.  I was growing increasingly concerned that my 4 year old Dell 2950 server was going to die and leave me high and dry.  A few months ago, I saw that the colocation company I use was running a special – a much newer/faster dedicated server and 10x the bandwidth for about $100 per month less than I was paying to host my own old server.  Good deal, I thought, particularly since that is $100/month back into my pocket.

As part of turning up the dedicated server, I received a new block of IP addresses.  I migrated the sites and data to the new server without much of a problem.  The next day is when the fun began.

One of the sites I host is a non-profit organization that does a lot of communication with members (nearly 19,000) via email lists.  I got a message from my contact at that organization that he was seeing a lot of email bounces.  I took a look at the mail server logs, and sure enough, most destinations were rejecting mail from this new server because the IP addresses provided to me appeared in many DNS blacklists.

I found this pretty frustrating.  I wasn’t mad at my provider, I was mad at the maintainers of these lists for some reason.  My provider graciously offered new addresses or to reroute my former addresses to the new server.  I saw it as a challenge, though.

I saw a lot of rejections that looked like this:

** xxx@xxx R=lookuphost T=remote_smtp: SMTP error from remote mail server after initial connection: host smtp.secureserver.net [216.69.186.201]: 554-m1pismtp01-019.prod.mesa1.secureserver.net\n554 Your access to this mail system has been rejected due to the sending MTA’s poor reputation. If you believe that this failure is in error, please contact the intended recipient via alternate means.

This was far and away the most common rejection notice, and there was no detail on how or why my addresses were there.  I spent some time on Google and found that this message comes from the Cisco IronPort mail security product, even found a link that validated my IP’s reputation was poor in their eyes.  In my reading about Iron Port and Sender Base, I found that it’s tough to get off the list if you are listed in the common DNS RBL’s .  So, I put my IP address into MX Toolbox and got a long, ugly list of blacklists I was included in.  Starting from the top, I visited the site of every single one, and completed the removal request form, or sent an email to the list’s administrator pleading my case.  Within a week, my IP address was not on any of the DNS RBL’s tracked by MX Toolbox.   Unfortunately, I was still seeing a large percentage of outbound email being rejected, most of it still coming from the IronPort product.  I sent a message to support at senderbase.org, explaining the situation, and that I had gone to the effort of removing those addresses from the blacklists.  I was pleasantly surprised to get a message back within a few hours asking some questions.  I had to follow up twice, but within a week, I was showing “good” on senderbase.org’s reputation lookup tool, and was not seeing any more rejections from IronPort mail servers.

Next on my list to fix were emails being rejected by Barracuda spam firewalls because my IP’s were on the Barracuda Reputation Block List.  I had no idea how many organizations use the Barracuda anti-spam system.    In my logs, I saw this:

** xxx@xxx R=lookuphost T=remote_smtp: SMTP error from remote mail server after RCPT TO:<xxx@xxx>: host barracudamailsrv.udem.edu.mx [148.238.48.37]: 554 Service unavailable; Client host [www3.stelesys.com] blocked using Barracuda Reputation; http://bbl.barracudacentral.com/q.cgi?ip=69.61.23.66

Fortunately, Barracuda lets you know the source of the problem, unlike IronPort.  Barracuda lets you look up your IP, and if you are on their list, gives you the option to request it be removed.  As with many of the blacklists, removal appeared to be automated, indicating that since this was the first request to have that IP removed from the list, it would be removed.  I suspect that if I started spamming from that address, it would be harder to get off the list the next time around.

At this point, nearly all outbound mail is being delivered.  I noticed that a good number of Barracuda mail firewalls do not update frequently, and 3 weeks after being removed from the Barracuda list, there are still a small handful of mail servers rejecting mail from my server because the Barracuda application thinks I am still on the list.  I found a few organizations that apparently maintain their own private blacklists, and all but one included directions on how to request removal – Qwest communications being the exception.

There is still one list that is blocking me, though…  I found it by looking at my IP address using the search tool on this page.  My IP shows as being listed by mipspace.  After digging around on their site, I found a contact email for them.  As with every other blacklist admin previously, I pleaded my case.  I got an email back from the list administrator indicating that the whole /17 netblock for my colo was in the list because of rampant spamming.  Their suggestion was to request my ISP to SWIP the /28 netblock for my server to me.  I have yet to do that, since I am not seeing any rejections caused by obscure DNS RBL.

Learn from my story – if possible, research the IP addresses you are given first if you care about things like having email delivered.  I spent roughly 30 hours over the course of a month to clean up these IP addresses.

Improperly configured mail servers contribute greatly to the pervasive spam problem on the Internet, both for the addresses served by the mail server, and also those on the Internet at large. Improper configuration on a single mail server can result in:

• The mail server being used to relay spam
• Other mail server operators forced to choose between disabling certain anti-spam settings and accepting email from the improperly configured server.

The following is a list of best practices to implement proper controls on mail servers to allow effective and efficient anti-spam measures:

Relaying Internally

A common deployment scenario for mail servers has a mail exchanger accessible to the Internet which relays email to an internal mail server. All filtering should be performed at the mail exchanger to prevent an internal mail server from rejecting mail from bogus recipients, which results error messages being sent to 3rd party mail addresses.

The Internet-facing mail exchanger needs to be able to reject mail for invalid recipients. This may require some form of custom directory service integration between the internal mail server and the mail exchanger. The implementation of such an integration is entirely dependent on the technology used and the architecture implemented.

DNS Configuration

There are two key DNS considerations:

1. Ensure the forward and reverse DNS match for the mail server. A basic screen for spam is for a mail server without a reverse DNS entry. If all legitimate mail servers set forward and reverse DNS to match, further anti-spam control could be achieved.

2. Implement SPF records for the domain. This is a simple but key item that can drastically reduce the success of spam that is illicitly sent masquerading as a domain. This can help to prevent reputation and image damage created by spam sent without your ability to control it.

Use Valid Senders

Too often, organizations will send out automated email using an address that cannot accept email, because it is not a valid address. This is often done to ignore any bounces from invalid addresses and/or to not have to deal with the responses that come back from the message. DO NOT do this. These are tactics commonly used by spammers. Using such tactics will cause recipient mail servers to disable one of the single most effective anti-spam techniques – sender call-out verification.

The Basics

• Use a valid postmaster address
• Use dns blocklists
• Block dangerous file types
• Mail exchanger anti-virus is strongly recommended

These steps aren’t a panacea for spam, but establishing a baseline configuration for responsible mail servers will go a very long way to helping organizations effectively block spam without having to make choices between receiving mail from badly configured servers and using effective anti-spam techniques.