Sending a simple email is getting harder and harder these days. Spam has created a huge issue. I'm not talking about the issue of spam itself, I'm talking about the issue of poorly designed anti-spam. Anti-spam should have the least number of false positives associated with it. Think about it, which hurts your business more each user looking at a couple spams in their inbox from time to time or one user missing an important email from your biggest customer?
Although it's impossible to ensure every email hits your user's inbox, there are some standards that are widely recognized that every mail admin should be aware of and fully understand. Here are a few.
1. SPF
SPF, or Sender Policy Framework (defined in RFC 4408), is one of my favorites. In my post "Testing SMTP" I describe how to create a SMTP session and send an email. You'll notice in there that NOWHERE does it mention authenticating yourself. This is a huge design flaw in SMTP, but hey, RFC 821 was written in 1982, a lot has changed in almost 30 years of email.
SPF is a means of authenticating what servers are authorized to send claiming to be from your domain in the "MAIL FROM:" argument of the SMTP session. There are many ways of doing this, from the PTR records, the IP, mail servers listed inthe MX and more. I'd recommend checking out RFC 4408 and www.OpenSPF.org for more information, and then using the SPF lookup to test your new SPF record.
Implementing SPF for your domain will have several positives.
A. When spammers try to spoof your users, they will have dramatically fewer bounce messages. Backscatter is a huge issue, and can be mitigated by using SPF.
B. You'll often receive positive weight to your email when SPF passes in SpamAssassin and other heuristic filters.
C. You'll be doing your part to help stop spam. I wish SPF was a required record. That when you registered a domain you were required to create SPF instantly. Unfortunately this is not the case yet, but in the meantime you're helping others determine legitimate email from bogus email, and therefore adding one small vote for good email practices.
2. PTR records
PTR records allow you to query for a "name" of an IP. They are the exact opposite of type A records which turn a name into an IP.
Because or this inverse relationship to A records, PTR records are commonly called "reverse DNS entries". This is a foolish name for them since the DNS query works exactly the same as "forward lookups", and infers that all DNS does is facilitate A record lookups, but that's a rant for another time :-).
You ALWAYS want to be sure that your mail server's IP has a PTR record, and that it's a common format. Not something like 4.3.2.1.HostingProvider.com or another "generic" looking record, but something like "smtp-out.YourDomain.com".
Also, "Forward Confirmed Reverse DNS" checks will take the hostname supplied in the PTR record lookup and see if that hostname has an A record which resolves back to the connecting IP. FCrDNS is a silly little way of blocking spam, but it's fairly commonly used, and should be respected when possible. You can use the PTR Lookup to check what your PTR records are.
FYI, notice nowhere in there did I mention the sending domain name. That's because rDNS has nothing to do with the sending domain. It is simply the PTR record for the IP address, and sometimes the A record that points to that IP ( FCrDNS ). For information on "legitimizing" the traffic from a particular sender's domain, see SPF records above.
3. RBL
Realtime Blackhole Lists were one of the first ways of stopping spam. Before botnets became huge spam producers there were "open relays" and of course servers that were owned/operated by spammers. Since there are only so many new compromised servers available each day, and only so many IPs that spammers can buy/lease at a time, it was relatively trivial to keep lists of what IPs delivered spam to your mail server and then share these lists among other users of the RBL. Although somewhat dated, RBLs have a huge following and are remarkably efficient since they can be run even before the "HELO" in the transmission.
MX toolbox offers a very comprehensive lookup of over 100 publicly available RBLs, but there are others too. Barracuda, IronPort, and every little admin that has a pet antispam project running on their mail server have their own. Once you're compromised it can be like dealing with extortionists to get off of some of these lists. Most will simply expire after a period of hours, days or sometimes weeks. Depending on the size of the issue "waiting it out" may not be an option, so you should contact the RBLs for delisting as soon as you're aware of an issue.
It's important to stay on top of your traffic to ensure you're not compromised, and use an outbound spam/virus scanner, preferably a relay, to be sure that if you're caught off guard you're not spewing junk mail across the globe.
Unfortunately, the spammers are making our lives harder. Nonetheless, it's our job as admins to stay ahead of the technology curve and make sure that we're implementing all of the best practices possible to keep our skills cutting edge and our users happy. Setting up and keeping an eye on SPF/PTR records and RBLs is one key factor of staying ahead of the curve.
