Limits of SPF and DKIM sender authentication techniques

Since identity theft is one of the preferred methods of spammers, one of the solutions proposed in recent years has been the implementation of systems to authenticate the sender’s identity, such as SPF(Sender Policy Framework), SenderId, DomainKeys and DKIM.

Faced with the many techniques used by spammers, the most logical solution is to develop a cost-effective system that can quickly identify whether an e-mail is spam or not, without excessive consumption of resources. Strategies that rely on e-mail content analysis do not fully meet this need, as analysis requires time and power, especially when the system is dealing with an extremely large number of e-mails per day. Authentication systems therefore seem to offer a practical solution to this problem.

SPF allows domain owners to specify their legitimate mail server in their DNS records. Only servers present in the registration are allowed to send e-mails from the domain. The receiving MTA performs a DNS lookup on the supposed domain of origin of the message and checks whether the sending server is present in the record. The whole thing is designed to make identity theft impossible, and to guarantee the authenticity of the sender.

First problem: SPF doesn’t really check the authenticity of the sender. Rather, it is a check on the authenticity of the sending server. Any server authorized to send messages from a domain can send messages from that domain (it’s redundant, but expressive enough). It says nothing about the identity of the user or the content of the message. The system therefore contains a fundamental logical flaw. A spammer who manages to take control of a machine can easily register his own mail servers in the system’s DNS records. Come to think of it, they won’t even need to add their own mail servers: all they have to do is use the machine’s mail server, since they already have control over it.

Second problem: what’s to stop spammers from using systems that perfectly respect SPF? At present, absolutely nothing. In fact, from the outset, spammers have complied with authentication mechanisms (see the article “Spammers hijack sender id” by T. Claburn in the September 2004 issue of Information Week). Acquiring a domain and installing SPF is extremely easy.

Third concern, which explains why major ISPs are reluctant: when they transfer mail from one server to another, there’s a risk that the mail will be refused on arrival, since it no longer comes from the original sender’s IP address. And what about organizations that have multiple mail servers, sometimes located in different countries, and need to manage a large number of IP addresses? An error in the listing of these IPs will result in messages passing through them being considered as spam.

The final problem is that SPF (like Sender and Domain Keys) is neither universally applied nor in a dominant position. This makes it difficult for legitimate users to configure their server for SPF, SenderId, DomainKeys and DKIMMany large mail servers don’t yet use this type of authentication, but if they don’t implement it (or implement it badly), they run the risk of losing their mail. Here’s the problem: legitimate users who don’t use SPF may have their mail refused, while spammers who do will have their messages accepted.