OmniTraining

Recently people have been led to believe that the solution to spam is just around the corner. In the top running, we have SPF, Sender-ID, and Domain Keys, but will any of them actually help? The answer is: only slightly. In this article we’ll explain why and cover how each of these technologies work.

All of the solutions are very similar, and they tend to restrict email in a way that nobody in the history of email has experienced. The first and most important point to understand is that email is used in very strange ways. The proposed spam fighting solutions limit just a few servers to being the originators of email from a domain, but people frequently send email in such a way that violates this. They’re using email legitimately, too.

Configuring your email client of choice normally involves a few steps, namely identifying the incoming POP or IMAP server and the outgoing SMTP server. This is usually a straightforward process, and so is the next step. To add a second account, perhaps so that you can check mail from your university or work account, only the incoming information is generally provided. End result? People are sending mail from user@domain2 via their SMTP server for user@domain1. Often times people do this on purpose to get around filtering issues that crop up because of misguided administrators. This is the simplest example, but rest assured there are more, for example forwarding messages from one account to another (a .forward for us Unix people). Many businesses also rely on email tricks when conducting B2B transactions.

The second most important point, and we hope the most valuable take-away from this article, is that you should never, ever straight-out reject email based on these criterion. It is perfectly acceptable to use these tools to aid in the decision process, but if your mail server finds an invalid SPF and simply rejects the email, you’re in for a world of hurt. The concept of a decision process means that your spam or virus filtering should be the one checking these DNS records, not your mail server software itself. Most spam filtering applications use weights, and each piece of evidence will count toward a final score used to determine if an email is spam. If your mail server is configured to run these checks, generally it will completely reject the email based on the information it receives.

Speaking about the act of “using” these protocols can be a bit confusing. You can use (or misuse) them in three different ways. These are all just DNS records that are published for your domain, so the first concept of use is simply publishing a record that gives other people some information. The published information is a list of IP addresses that are authorized to be a mail server for your domain. When another server receives email with a “From:” header that claims to be your domain, they can check with your published information to make sure they are receiving it from an authorized server. The act of checking, or “turning on checks” is the second way to use these protocols. Hopefully, as we discussed earlier, the receiver will not simply discard the message if it’s coming from an “unauthorized” source. The third method is to both publish your own, and also check all incoming mail for these records.

Our first contender, SPF, or Sender Policy Framework, was the first kid on the block. SPF is simply a TXT DNS resource record that can be queried by remote sites to see who you authorize mail to be sent from. This doesn’t work, because of the reasons cited above.

The MARID working group of the IETF was tasked with finding a solution. They failed, but produced some interesting analyses in the process. The second on our list of buzzwords is Microsoft’s Sender-ID. Sender-ID is the same as SPF, with a few minor enhancements. It’s functionally equivalent, for our purposes. Microsoft joined the MARID working group late, and tried pushing their protocol on everyone, stating that it was the best solution. Everyone who runs Microsoft servers and didn’t care about patent issues tended to agree, but the majority of the world did not. Neither SPF nor Sender-ID will ever be widely used. Interestingly, many sites started using SPF, but for the most part have backed down.

Domain Keys is the final contender. It too is a DNS record that provides information about a domain’s policy regarding where email should originate. There is a commonly used tactic in the computing world to fake progress: wrap it with crypto. Domain Keys is providing the same information as SPF and Sender-ID, but it’s cryptographically signed so you know 100% that it’s correct. Google publishes Domain Keys, but they use it properly: as a tool to help, knowing full well that it isn't the final solution.

To be fair, Domain Keys can also be used to verify a specific email’s integrity, but we’re really trying to deal with the spam issue here. The consensus, regardless of the author’s obvious bias in the same direction, is really: “domain verification breaks too much.” Especially when used improperly, i.e. dropping all email that gets shipped through an unauthorized server. Domain Keys aren’t as bad as other cryptographic nightmares, like DNSSEC, because they don’t require a central certificate. What this really means is that people can implement this without having to rely on a third party’s stamp of approval and subsequent collection of funds.

The moral is that these solutions are all the same. It’s called domain verification, and it simply won’t work. Email has been around since the dawn of the Internet, and its model has always been to allow everyone access. Quite literally, your email is a file that everyone on the Internet is allowed to append things to. The whole system is going to have to be redone, and a complete solution will have to involve a trusted third party. Perhaps everyone will register their person, and all email sent “From:” them will be validated, making the domain a moot point. Spammers would be immediately identified with that type of system.