Three Ways To Authenticate E-Mail And Stop Spam

Don't stop at filtering software. Sender authentication provides another defense against spam--but you'll have to choose from three methods.
Phishing Defense
Sender ID, a backward-compatible extension to SPF, is a sender-authentication scheme backed by Microsoft and used by Hotmail and MSN. These services display Sender ID results in their Web mail interfaces. Sender ID, formally named Caller ID, makes use of the same DNS text resource records that SPF requires. But Sender ID is better than SPF at preventing phishing attacks because it checks the "from" address users see in their E-mail clients, instead of the one presented at the SMTP layer. And, like SPF, it won't cost you anything to get started.

The biggest concern with Sender ID revolves around Microsoft's Royalty-Free Sender ID Patent License Agreement. Organizations such as the Apache Software Foundation, AOL, the Free Software Foundation, and Open Source Initiative have expressed discontent with the licensing language; this appears to have slowed Sender ID's momentum. These groups believe that no one company should be given intellectual property rights over such a core Internet specification. Microsoft and open source providers seem stalled over "nontransferable, non-sublicenseable" terms and language that requires competitors to contact Microsoft when rebranding or redistributing Sender ID.

Spam Spotters
What to expect from E-mail authentication options

  Pros Cons
Sender Policy Framework Easy to deploy, widely supported Less effective for phishing
Sender ID Easy to deploy, effective for phishing Surrounded by licensing controversy
Domain Keys Identified Mail Validates message, not just server path; works with forwarded messages Complex configuration, affects server performance
Key Exchange
Yahoo's Domain Keys was merged with a similar spec that Cisco developed, called Internet Identified Mail, and is now referred to as Domain Keys Identified Mail. The companies revealed the joint effort in mid-2005, submitting updated documentation to the Internet Engineering Task Force backed by at least a dozen major companies. The DKIM sender-authentication approach is to sign outbound messages with a private key. Receiving E-mail servers can validate that the E-mail originated from a known source using publicly available keys in DNS, and they also can validate the integrity of the message--a capability SPF and Sender ID lack.

Setting up a DKIM-aware E-mail infrastructure is more involved than implementing SPF and Sender ID. Because outbound E-mail must be digitally signed, your outbound server E-mail software must be modified to let it compute and modify the message. As with SPF and Sender ID, if you want to validate Domain Keys Identified Mail messages, receiving E-mail systems also must be modified.

To enable signing of outbound E-mail messages, DKIM-aware outbound E-mail software must be installed--your current software may support it with some modifications. It also requires generation of a public-private key pair.

The main disadvantage of DKIM is that it requires both outbound and inbound DKIM-aware E-mail servers. Domain Keys Identified Mail also will add overhead to E-mail processing, requires more DNS lookups, and reduces the amount of E-mail your servers can manage because of the significant processing resources needed to validate signatures.

SPF is winning the early battle as the leading industry standard among the three sender-authentication methods. The specification's ease of deployment will let everyone publish SPF records quickly, and its record checking is supported by just about every E-mail server vendor.

No matter which authentication method you choose, E-mail users and the Internet community at large will come out ahead. Anything that trips up spammers is progress.

Editor's Choice
Brian T. Horowitz, Contributing Reporter
Samuel Greengard, Contributing Reporter
Nathan Eddy, Freelance Writer
Brandon Taylor, Digital Editorial Program Manager
Jessica Davis, Senior Editor
Cynthia Harvey, Freelance Journalist, InformationWeek
Sara Peters, Editor-in-Chief, InformationWeek / Network Computing