Sender ID Declines, Domain Keys Shines

Microsoft's Sender ID proposal to identify legitimate e-mail was voted down by an Internet standards body and rejected by America Online. That gives a huge boost to a competing proposal -- Domain Keys.
Microsoft isn't getting everything it wants these days, and this month provides yet another example. In the space of a few days, its "Sender ID" proposal to identify legitimate e-mail was voted down by an Internet standards body and rejected by the world's largest Internet service provider (ISP), America Online (AOL).

That reversal of fortune gives a backhanded boost to "Domain Keys," a competing and arguably superior proposal supported by Yahoo.com and other Web players.

Since both protocols are billed as fighting the evils of identity theft, phishing, and spam — a cleanup that only ne'er-do-wells would oppose — it's fair to ask whether the public humiliation for Sender ID may actually have the good outcome of hastening the adoption of Domain Keys as a single, unified standard.

Much Ado About E-Mailing

I analyzed Domain Keys, Sender ID, and a third proposal, SPF, in this space on April 26, 2004. All three protocols grapple with the fact that anyone can make any e-mail message appear to be coming from any address they like. The three specs go their separate ways from there:

SPF. Sender Policy Framework is a simple principle that's been promoted for many months by Meng Wong, the CTO of the Pobox.com e-mail service. Owners of domain names, such as Example.com, would announce in the World Wide Web's registry a list of Internet Protocol (IP) addresses that are authorized to handle mail related to their domains. E-mail messages could not contain a "bounce" address that didn't correspond to one of the IP addresses on the list. This would prevent spammers from sending out e-mails, some of which would bounce back to whomever they picked as their victim (a harassment technique known as a "Joe job").

Sender ID. Microsoft's proposal began life as "Caller ID for E-Mail." The name was later changed to "Sender ID" when Microsoft accepted the SPF concept into its own proposal. In addition to checking that a message's "bounce" address is legit, e-mail recipients who checked for Sender ID compliance would verify that the domain name in the "from" address of each message was plausible. Recipients could reject messages that claimed to be from "Someone@Example.com" if they came from IP addresses that Example.com hadn't declared.

Domain Keys. Rather than verifying merely the "bounce" address and the "from" address, the Domain Keys proposal would also guarantee that the contents of the message hadn't been altered by anyone along the way. To accomplish this, each outgoing e-mail server would "sign" each message using a digital certificate. recipients could reject messages that didn't sync with a domain's centrally stored value in the World Wide Web registry.

The above summaries, of course, are oversimplifications of three quite technical proposals. But it's enough background to let us forge ahead on the main question: If you want e-mail to be reliable once again, and you're willing to implement a small change on your servers to help end spam, is Domain Keys the horse you should bet on?

One Small Step For a Server, A Giant Leap For Antispam

Miles Libbey, the antispam product manager for Yahoo Mail, naturally feels that Domain Keys' time has come. He ticked off several advantages Domain Keys has over both Sender ID and the original SPF proposal:

Real Authentication. "The original sender of the e-mail is authenticated," Libbey says of Domain Keys, "rather than the last server that touched the e-mail." Under the Sender ID proposal, the IP address of a sending e-mail server is checked. In the Domain Keys scheme, both the IP address of the sender and the digital signature of the sender's message must match.

Mail Forwarding Still Works. Unlike Sender ID, which Libbey says has tricky implementation issues for messages that are forwarded from one server to another, Domain Keys doesn't interfere with forwarding at all. "They don't have a good solution for forwarding," he asserts. "E-mail is a store-and-forward system," Libbey notes, and long-established practices must continue to work if any e-mail authentication spec is to gain acceptance.

It's The Reputation, Stupid. Merely checking that an e-mail comes from a known IP address won't eliminate spam or phishing. Spammers can easily buy cheap, disposable domain names (such as Citibank-Example.com) and send spam that really comes from that domain. Many consumers would still be fooled into revealing their passwords to phishing sites with such confusing names. Authenticating the source of e-mail messages must be combined with a reputation rating system that totes up positive scores for legitimate senders and negative ones for spammers. Yahoo has for more than two years operated such a rating service — SpamGuard — which Libbey says gives Yahoo a powerful tool to identify "good" senders and filter out "bad" senders.

Taking Hits Over The Performance Hit

One criticism that's been leveled against the Domain Keys proposal is that the digital signing of outgoing e-mail messages requires more CPU time than simply sending messages raw and unsigned, as it were. Domain Keys doesn't require the encryption of an entire message, but it does require the signing of a snapshot or "hash" of the message. This would inevitably consume some fraction of a CPU-second.

Fortunately for us, this question was thoroughly tested by Sendmail Professional Services, the company behind Sendmail, software that ranks among the world's most widely used e-mail server back ends.

In a benchmark report released last July, Sendmail's testers established that the signing of average-sized messages would reduce a server's potential e-mail handling only 7.8 to 15.2 percent. The adoption of Domain Keys could easily give back more processing power than that by merely denting the volume of spam that a company's servers have to analyze every day.

Domain Keys "will prove to be far more efficient than current methods of filtering and evaluating all messages," Sendmail said in its findings. It should be noted that Sendmail executives have, in the past, also endorsed the concept of Sender ID. Sendmail is expected to support a number of different protocols so mail administrators can implement the ones they prefer.

Who Wants To Play?

Microsoft's Sender ID proposal hasn't been dealt a death blow, but it's at least limping from the highly public Sept. 11 vote against it by a working group of the IETF (Internet Engineering Task Force) standards body. A co-chair of the group, Andrew Newton, said a patent application Microsoft has submitted regarding Sender ID was an issue. The Redmond company says it will license the intellectual property for free to anyone who pledges, among other things, not to sue Microsoft over patent claims.

Five days later, AOL let its views be known. The ISP said it wouldn't support Sender ID, partially because the current Microsoft proposal seems to have altered the nature of SPF from its original design. AOL has already posted SPF information for its own domains and says it will start rating SPF compliance as part of its spam-filtering formula, possibly as soon as the end of this year.

In response to questions about its recent political setbacks, a Microsoft spokesperson said in an e-mail that the company "is pleased to offer its necessary Sender ID patent rights on a royalty-free basis but only to those who are also willing to make their Sender ID patents available on a reciprocal royalty-free basis."

The spokesperson, who declined to be identified by name, added: "Microsoft has disclosed the existence of those pending patent claims and has provided its assurance that if such claims are granted Microsoft will make licenses available on reasonable and non-discriminatory terms."

Asked whether the company might revise its Sender ID proposal, perhaps to incorporate support for Domain Keys, the spokesperson replied: "Microsoft continues to believe complementary technologies such as signing solutions (of which Domain Keys is one) and computational proofs will be important to address other technical aspects of spam that these IP-based authentication mechanisms do not address."

An AOL spokesperson did not respond by press time to telephone calls seeking comment.

Conclusion

SPF temporarily represents a silver lining in the Internet cloud. Adding to your servers a small SPF-compliant text file would require very little time and might slightly improve your e-mail delivery success rate. Microsoft's own Hotmail and MSN e-mail services — as a first step toward a full-blown e-mail authentication scheme — will start giving brownie points to SPF-compliant e-mail this October or soon thereafter.

It's too early to tell whether Sender ID or Domain Keys will emerge as the winner to handle e-mail properties that SPF doesn't.

But it's not too soon to say that Domain Keys is a stronger proposal to clean up the e-mail mess than Microsoft's more limited and patent-entangled Sender ID.






0 Comments (click to add your comment)
Comment and Contribute

 


(Maximum characters: 1200). You have characters left.