Comply! Comply! - Keep your mail servers off blacklists, avoid being flagged as spam

Alternate title : Making Sure your Email Services are up to Date with RFC Standards

Greetings from the Great White North! This is Leah Kubik, hailing from Canada. Welcome to our first blog posting! I say "our" not (as you may suppose) because I am suffering from the belief that there is actually more than one of me. This blog will be shared by Jason Brown, a fellow co-worker of mine, and myself. Jason and I will be posting alternately, in attempt to bring mind blowing Email hosting thoughts to you on a regular basis. If you would like to read more about who we are and what we do, please do check out our profile on this site.

So, without further ado, let's move on to the main topic for today.

These days, it seems like every week, large and small Email hosts are having to tighten the screws on their email servers just a little bit more in order to battle against spam and viruses. Generally speaking, having more servers out there tightening their security and policies is a good thing, but if you do not follow some basic precautions on your own mail server(s), valid email from your hosted email domains may start to be flagged as spam, returned, or you may even become blacklisted if your servers are not RFC compliant. Essentially, if your servers do not comply to the various standards surrounding how an SMTP server is supposed to function and be configured, an angry mob of clients awaits you (assuming they are not already beating down your door.)

Why must we be RFC compliant, you may ask? You must comply (insert robot voice here) because most spammers do not. Spammers function by using quick and dirty setups, and by taking advantage of scripts, trojan horses, and any other number of nasty tricks. Because of this, spammers will send email from servers that are often very outdated, or from scripts that simulate SMTP sessions. The spam and virus sources of the world are, for the most part, much more concerned about quantity than they are about quality. Thus, you can distinguish yourself and appear less and less likely to be a spam host to others, by focusing on quality. The easiest way others can identify spam is by determining that the sending end is doing something that a modern SMTP service is not supposed to do. Thus, by being standards compliant, you will be less likely to be mistaken for a spammer.

Here is my list of seven things that you can, and should, do:

1. DNS : Check http://dnsreport.com for domains that you host. Having your DNS correctly configured for each domain is vitally important! Many email servers will reject mail from your server entirely if your DNS is incorrectly configured. This tool will also check the mail server for the domain with a few basic tests for obvious issues.

2. SPF : Publish an SPF record in DNS. Many major mail services will automatically flag emails from domains that do not have an SPF record as spam or potential spam. You can find out more about how to do this at http://en.wikipedia.org/wiki/Sender_Policy_Framework and http://openspf.org .

3. If at first you don't succeed, try, try again : Make sure that your mail server will try to send again if it gets a failure the first time. Many mail servers use greylisting (http://en.wikipedia.org/wiki/Greylisting), and will not ever let a message through on the first try. If you configure your mail server to fail after one try (possibly to reduce server load) or your SMTP service does not properly handle retries, it is not RFC compliant. http://tools.ietf.org/html/rfc2821#section-4.5.4

4. Update : Ensure that your mail servers have updated and patched operating systems, as well as that the actual SMTP service or daemon that you use is updated or patched as well. Not only will this protect you from security holes, but older mail software is often not standards compliant and will cause problems.

5. Do not trust your users : Scan outgoing messages from your server for spam and virus issues. Block messages going outbound that score too high. Limit sending to huge recipient lists. Many people implicitly trust all of their users and do not check their outgoing messages. Unfortunately, accounts are easily compromised due to weak user passwords and viruses. It is all too easy for a mail user to unwittingly send spam and viruses. If you allow to much spam out from your own servers, no matter how valid they are, you will find yourself turning up on blacklists. Usually these blocks are temporary, unless you never do anything about the problem. If the blocks do not go away after making your changes, you will have to spend countless hours trying to contact the blacklist sites that have you listed and working with them to resolve these blocks. They will probably refuse to unblock you if you are continuing to allow spam out from your mail server.

6. Abuse and Postmaster email : Make sure that for each email domain you host, you have both an abuse@example.com address defined and a postmaster@example.com. These addresses must actually go somewhere useful (such as to your support system or IT staff) so that other administrators can contact you if they find a problem that has to do with your domain.

7. Open Source : Use an open source SMTP server. Often proprietary software is not RFC compliant, because no one can easily fix small problems. Also, with proprietary software, people often do not upgrade to newer versions as often as they should, because there is a cost associated with each service pack (in many cases.) In general, open source mail servers tend to be more secure, up to date, and standards compliant. If you must go with a proprietary solution, find out from the sales representative what testing the product has gone under to prove it's RFC compliance, and if they have a guide for configuring the server service so that it is compliant.

There are many more things that you can do, but these steps should help point you in the right direction. If you don't know what the proper setting is for something, you can always check and see if the RFC has a recommendation for it: http://tools.ietf.org/html/rfc2821

Happy improving! System administrators around the world thank you.