Earning Trust for Your Email Server
I host my own email server, this in itself is a very odd thing to do in this day and age. If you want email to come from your domain, Google offers this for free and provides the same interface as Gmail. If you insist on running your own mail server, then setting it up to use your ISP as a smarthost is the easy way to go (very easy with Ubuntu), of course I didn’t take that path.
As an aside, setting up a mail server that uses fetchmail to gather email from the various accounts you have, and using a smarthost configuration to send email does give you most of the benefits of running your own mail server with very few headaches. The reason to do this might be that you don’t want to trust Google (or someone else) to hold all your email, and/or you don’t want the individual PCs in your house to be the storage for your email (hard to migrate to a new machine, recover from disaster). This is how I started down the path of running my own true email server. [I keep thinking that someone should create an easy to install NAS add-on that provides exactly this type of email server]
Ok, maybe you don’t want to run your own email server but you’re interested in knowing what is involved… Having a static IP address is handy, mostly to save you from DNS issues. While you can manage to have a domain name tied to a dynamic IP, many blacklists include the IP ranges used by ISP for dynamic addresses. Of course you need a domain name, and a DNS server too. You might also want to consider a secondary MX record, in case your connection goes down. You’ll also want to check that your ISP isn’t blocking port 25 outgoing, and having a valid reverse DNS is important too.
So you’ve followed the Ubuntu documentation and setup a mail server, great. Assuming your IP address is “clean” (ie: not on a blacklist), then you can probably send email just fine. Until you start hitting problems where spam filters have taken a dislike to your system – in my case it was Rogers (email provided by Yahoo) that treating my outgoing as spam. One solution is to have the recipient add your email address to their address book so they do still get to see your email. It may still get tagged as [Bulk] but it won’t get lost. This isn’t a great solution for someone new you want to contact, or a friend who isn’t terribly technical.
It turns out there are some additional measures you can take on the email server side to add more trust. There are three I’ve implemented:
All of them rely on the same basic ‘trick’ of adding a TXT record to your DNS information that serves to validate the email. This works for the simple reason that spammers tend to use botnets made up of machines without valid DNS records. SPF simply is a declaration that the IP address sending the email is allowed to send email for the specified domain. DKIM is an updated version of DomainKeys, but both can be used concurrently and some systems only know one. Both DKIM and DomainKeys have the email server sign the email with a secret (private) key, and the DNS record has a public key that will validate the signature.
After implementing all three, it turns out Yahoo was still tagging my email as spam. Very frustrating. One solution I did consider was to avoid the problem entirely and selectively smarthost email going to rogers.com (and yahoo.com, etc). In the end, it turns out that Yahoo maintains their own blacklist of sorts and you can request to be removed. To check this, you need access to a yahoo email account that you can send test messages to. By examining the header you will see X-YahooFilteredBulk if your IP is on their blacklist, this appears to be independent of the status of your SPF/DKIM/DomainKeys authentication that should show as a pass. The solution is to fill in the Yahoo form, and be persistent. Much of the form will not apply but you do need to fill it in with something reasonable (and valid). After a couple of exchanges over several days I was rewarded with this reply:
While we cannot fully exempt your mail server from our SpamGuard
technology, we have however, made appropriate changes to this IP address
in our database. This should help with delivering mail to the
appropriate Yahoo! folders.
Now email sent to yahoo.com is not tagged as spam or [Bulk] – I did a little victory dance once this happened.
The remainder of this post goes into some of the details of getting the three (SPF, DKIM, DomainKeys) implemented.
Sender Policy Framework (SPF)
This is very simple as it only needs the addition of a TXT record to your DNS entry. The SPF project website provides additional information, a wizard to help create the record in the correct format and a testing tool.
You can also test is manually using nslookup:
lowtek.ca text = "v=spf1 a mx ~all"
Optionally you can configure your email server to use SPF to reject mail from unauthorized sources.
Domain Keys Identified Mail (DKIM)
The Ubuntu documentation on this is pretty straight forward. The example /etc/dkim-filter.conf file provided has more changes that is strictly required. You only need to set the values for: Domain, KeyFile, and Selector – the remainder of the file you can leave as is.
Creating the key will look something like this:
$ openssl genrsa -out private.key 1024
Generating RSA private key, 1024 bit long modulus
e is 65537 (0x10001)
$ openssl rsa -in private.key -out public.key -pubout -outform PEM
writing RSA key
I did get tripped up copying my public key into my DNS record. The public key will look like:
$ cat public.key
-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----
Clearly you need to remove the BEGIN/END lines, but the TXT record format must be on a single line. Thus you need to further edit the key to be a single long string of characters.
There are some testing tools available at sendmail.org. You can also manually test using nslookup to validate the data in your DNS entry:
$nslookup -query=txt mail._domainkey.lowtek.ca
Gmail does have DKIM validation, so a simple test is to send email to a gmail account and view the header. Look for the Authentication-Results header entry.
Again the Ubuntu documentation is a good guide. This is very similar to the DKIM setup so it went smoothly for me. The only difference is that it uses two TXT records instead of a single record.
I did come across a nice testing site for all of these technologies.