SPF, DKIM, DMARC and GPG, first line defense against phishing and SPAM
At the university we used to ‘fake mail’ each other now and again with messages from ‘root’ or from the administration. Usually the content was so outrageous that nobody fell for it. It was not very hard to do, since the SMTP-protocol (which is almost the same protocol used nowadays) allowed for the sending party to state who they are.
So you could enter simply:
From: root <root@localhost>
and the recipient would see that Root (the systems ‘boss’) had sent him a message.
That was all fun and games, since the Internet did not have many commercial and/or malicious parties that tried to peddle their wares by stuffing your inbox with SPAM.
Spam
Whilst the name Spam is derived from a popular comedy show from the 20th century, there is nothing funny about the spamming practice.
It is the practice of sending out advertisements to every known, calculated or guessed email address that a malicious advertiser can get its hands on.
At the moment of writing it is around 80% to 85% of all email pushed around the globe. Imagine the cost-factor that has to be borne by all the users of the Internet, just so they can get their 15% to 20% of wanted email.
And on top of that, while Spam is the herbivore by just ‘grazing’ people that actually think some of the messages are worthwile advertisements, some of the Spam has evolved to a rather more sinister carnivore: Phishing.
Phishing
Phishing is the practice of trying to ‘angle’ or ‘fish’ for usernames, passwords, creditcards or any other information that gives the sender ill-gotten advantages or wealth. This can be done by constructing emails that make the recipient believe he or she is dealing with the ‘real thing’ and claiming that for some reason or other the requested information is absolutely necessary.
And because URL’s have become more complex over time, it is nowadays a normal practice to include clickable links in an email; only very few recipients type a link or copy/paste the visible part into their address bar of the browser.
Drawing a line
The main reason that these practices flourish so well is, as always, the user’s tendency to do as little as possible and whenever convenient to let technology sort it out. But in the case of e-mail that is stating the case too simple.
At fault there is also the protocol itself; it never was designed to have a verification mechanism, it was designed to be reliable and robust. And it is reliable and robust.
But SMTP is just a transport protocol, just like TCP, and so security and authentication need to rely upon other mechanisms.
Well, there are. And they are relatively easy to implement (but require some thought when used in complex configurations).
The first three are all implemented by adding DNS records, the last one is rather person specific. Two of the methods use cryptography to ‘sign’ messages.
Introducing Sender Policy Framework (SPF), DomainKeys Identified Mail (DKIM), Domain-based Message Authentication, Reporting and Conformance (DMARC) and Gnu Privacy Guard (GPG)/OpenPGP.
In essence they provide the following:
SPF – tells the recipient that the machine that sent the mail is allowed to do so on behalf of the domain.
DKIM – tells the recipient that the mail was sent by an application that is allowed to do so on behalf of the domain. DKIM also cryptographically ‘signs’ the message contents.
DMARC – tells the recipient what to do with messages that do not pass DKIM/SPF tests and where to report any abuse.
OpenPGP/GPG – tells the recipient that the message was authorized by the person that holds the private key. Usually the named sender.
Implementing these methods makes your domain(s) less attractive for spammers and phishers, because the big recipients (and software like SpamAssassin, but also Microsoft Exchange, Courier, Postfix etc.) already have the checking in place.
This means that anyone trying to pass for a sender from your domain will most likely get tagged or rejected. In combination with DMARC a legal/justicial effort is possible.
How to implement these steps?
As there are lots of different sites that explain it all in detail there will not be a detailed ‘howto’ here, but more of a ‘plan of approach’
The first thing to do is to get your SPF records in working order.
The biggest ‘snag’ here is that you forget to include mailservers from your own provider. So, prepare by figuring out which servers or providers are allowed to send email.
If your provider has an SPF record you can use the ‘include:<providersdomain>’ to include that SPF record. This saves you making changes whenever they change.
This include is also very convenient if you have lots of domains but do all the sending from a single special domain.
Next, do not forget all webservers or other automated systems that send out email on your domain’s behalf.
If you have your own ip-range and wish to grant all of the numbers the right to send on your behalf, use the ip4 or ip6 fields.
But for most people the SPF wizards from either Microsoft’s SPF wizard or EasyDNS’ Ajax SPF Wizard will be enough.
Be careful when implementing and go step-by-step using tools like Port25’s Sender Authentication or Kitterman’s SPF validation tool to verify that all works well.
This step is easy and rather painless to implement. It should take less time than reading this article, so please go ahead and do it. This week.
The next step is to implement DKIM.
This step depends on your MTA (Mail Transfer Agents) and some parts need to be redone for each and every application that sends email directly.
The best method of course is to have all applications use one MTA setup so you only have to do this once.
It involves generating a public/private keypair and publishing the public part in DNS, whilst supplying the MTA with the private pair.
Large mailproviders like GMail have wizards that will completely walk you through that process.
But if you like to do it on your own you can use Port25’s DKIM Wizard to get you started.
Again, this step is rather easy to implement, but it may mean that you now really need to consolidate and reorganize all these PHP Mailers, Perl mailers and whatnot’s to use a single provided MTA.
The good thing is also that it becomes harder to be messy with email software in your company. Again, please fix this asap. This month.
Now for DMARC.
This is, just as SPF, just deciding what should happen and then placing a DNS record. It is in fact the easiest of all steps, but it must not be implemented before the previous two are completely in working order.
In the worst scenario, nobody would receive any of your email anymore until the previous two items have been fixed.
So, do not start implementing this before the previous two are rock-solid.
Basically, you have to decide what should happen with email that did not pass the SPF/DKIM tests. I would recommend starting out in ‘monitor’ mode, which means that you only get reporting on failed tests.
This will give you an insight in any servers or applications you may have forgotten to include (or you may have forgotten the existence of) in the previous steps.
You can use again a wizard like Unlock the inbox’s DMARC wizard or you can use DMARC.org’s explanation to build your own record.
Do this as soon as possible after the two previous steps have been concluded. Really. It will give you an insight into who is using your good (domain)name to peddle hokum on the Net.
Finally OpenPGP/GnuPG
Because this is quite mailclient dependent and there are also commercial offerings only a link to GnuPG is presented here.
Just as with DKIM, it uses a private/public keypair, but this time it is personal. If you are working for a large company it may be prudent to see which software is available to integrate with your user management and if your MTA can not use a keypair automatically.
The importance of this is rather that even if someone is able to use your MTA as a relay for phishing, the mail is not signed personally by you. This can give a recipient a clue that he or she should not click on this ‘very very important link’ at all.
Basically these four steps should help you draw a line against spammers and phishers using your domain.
There are other initiatives which you would be encouraged to participate in, most notably Project Honeypot, which uses your website to snare email address harvesters so they can be blacklisted.
Other measures you can take are on the receiving side but that is for another article.