The battle over email authentication is mired in the minutiae of technical standards which only the geeks of the Internet Engineering Task Force (IETF) could love. Yet, far from many of the esoteric Internet standards battles that are blessedly irrelevant to most of our day-to-day working lives, the fight over email authentication is something that promises to make your life measurably better, or worse, in the very near future.
Fear not, gentle reader. You will be spared from sifting through IETF groups charters and technical specifications. For, in a quiet corner of a Thai restaurant in San Jose, Calif., I recently had a chance to debrief John Levine, chairman of the IETF's Anti-Spam Research Group, and author of numerous books including Internet for Dummies.
Wielding only peanut sauce and Thai iced tea, I was able to coerce John into giving me the Dummies-style insider's view of the email authentication wars. He explained why the leading proposal, Microsoft's Sender ID, self-destructed, and why today's most promising authentication proposal promises to lose your email and bring your company's servers to a crashing halt.
What sparked the demise of Microsoft's flagship authentication idea?
According to Levine, it boiled down to Microsoft's overreaching claims in patent applications for the technology surrounding Sender ID. During much of the MARID talks, Microsoft had downplayed the scope of its intended patent claims. But when they were forced to show the relevant patent applications, they turned out to be vastly broader in their claims than they had previously led the standards community to believe.
''The sweep of Microsoft's patent claims were truly breathtaking, which is really saying something for Microsoft,'' says Levine.
While there were many conceptual and technical problems with the proposal, some of which I have written about previously, it was the unwillingness of the community to entrust the future of email to a technology licensed from Microsoft that spelled the doom of Sender ID.
So with Sender ID off the table, all eyes are turning back to SPF, the original version of the DNS-based sender authentication scheme offered by Pobox.com founder Meng Wong. Earlier this year, Wong reached an agreement with Microsoft to fold his SPF, or Sender-Permitted ''From'', proposal into the Sender ID concept. But after the combined effort was rejected, Wong announced that he would press forward with the original SPF idea.
For John Levine, the renewed focus on SPF is a little like bounding out of the fire and landing squarely back in the frying pan.
''The bottom line,'' he says, ''is that SPF was designed without serious attention to either the technical risks or the security risks it creates.''
At its core, SPF calls for adding more text records to a domain's DNS entries, which define what IP addresses should be permitted to send email for that domain. These statements embedded in the DNS records would need to be queried from the sender's DNS infrastructure, and then parsed by the receiving server, in order to know whether to accept or reject each piece of email.
This approach raises several areas of concern, according to Levine.
First, there has been no large-scale experience in using SPF to reject email. We do know, however, that a non-trivial number of early SPF adopters have found it difficult to correctly describe even relatively simple networks in SPF syntax. Once you factor in more complex arrangements, such as multi-homed inbound/outbound systems, outsourced email and mailing list hosting environments, remote offices with their own email infrastructures, etc., we still don't know the extent to which SPF will break email.
Second, SPF has yet to be put to serious security scrutiny. In his own experiments, Levine has developed legitimate SPF implementations that are so complex that any mail server attempting to decipher them will become mired in a quicksand of ''nested'' queries. Nested SPF records are ''legal'' under the SPF spec, and indeed would provide a way for representing some complex network configurations.
Levine experimented by creating a complex series of nested SPF records that are not all that different from a conceivable configuration for a moderately large and widely distributed email infrastructure. His results? Upwards of one hour to look up the SPF records for just a single email. If a legitimate set up could do this, an evil-doer could cause mail servers to launch Denial-of-Service attacks on themselves simply by seeding bogus data in nested records and sending your mail server on a wild goose chase that would bring down your inbound mail.
''Any system that causes your server to execute arbitrarily complex instructions controlled by potentially hostile people is pretty dumb,'' says Levine.
Meanwhile, as corporations try to decide whether to give SPF a try, the fastest growth in SPF adoption is among the ranks of, you guessed it, spammers! According to a report by email technology firm CipherTrust, the average spam email they examined is three times more likely to pass an SPF check as compared, with 34 percent more spam using SPF records than non-spam.
And just when you thought it was safe, the government has decided to get into the fight.
In November, the U.S. Federal Trade Commission is sponsoring a conference to discuss what role, if any, there might be for the federal government in advancing the email authentication debate.
Stay tuned, sports fans... This story just keeps getting better!
Ray Everett-Church is a principal with ePrivacy Group, a privacy and anti-spam consultancy. He is a founder of CAUCE, an anti-spam advocacy group, and he is co-author of ''Internet Privacy for Dummies.''