In-Depth
Valid ID Required
Fighting spam requires authenticating e-mail addresses on the fly. Despite igniting a battle of its own, the Microsoft-backed Sender ID spec
is shaping up as the best option.
The open source community has made no secret of its disdain for it and an IETF working group that was trying to fashion it into a standard disbanded before completing its work. But industry watchers nonetheless expect the Microsoft-backed Sender ID will still emerge as the most effective immediate solution to the problem of authenticating e-mail and, ultimately, stopping spam.
Sender ID is a protocol jointly developed by Microsoft and Pobox.com that is intended to determine whether an e-mail is coming from the domain it claims to come from by validating the sender's Internet Protocol (IP) address, which is much more difficult to fake than an e-mail address. Proponents say implementing such e-mail authentication technology will help substantially slow down spam, as well as phishing and spoofing attacks, because most of these scams utilize forged e-mail.
But whenever Microsoft is involved in the standards process, controversy is almost sure to follow. With Sender ID, the controversy primarily revolves around two key issues: How much control Microsoft would exert over the burgeoning authentication technology, especially if it becomes a standard; and longer term, whether Sender ID's way of validating an e-mail's origin is effective enough for e-mail providers and enterprises to embrace.
The main alternatives to Sender ID are encryption-based schemes like Yahoo DomainKeys and Cisco's Identified Internet Mail, both of which use a cryptographic signature within the message to verify the sender's identity. Proponents of such schemes say they do a better job at validating the identity of the user, a stance virtually no one denies. The question is whether that added validity is worth the price in complexity and expense that it takes to implement an encryption-based scheme.
"While there are certain technical advantages to DomainKeys, organizations will go with Sender ID because it offers good enough protection and because it is easier to implement," concludes Jonathan Penn, a principal analyst for Forrester Research, in a recent brief.
The Birth of Sender ID
Sender ID was formed by the merger of two authentication technologies: Microsoft's Caller ID and Sender Policy Framework (SPF), created by Meng Weng Wong, founder of the e-mail service provider Pobox.com. When it became clear over the summer of 2004 that both—SPF with its already growing support from the industry and Caller ID with its support from Microsoft—would have a good chance of survival, they were merged to create Sender ID in hopes of creating a single industry standard.
The two were similar in their approach and implementation—both checked the validity of sending Message Transfer Agents (MTAs), which are the sending mail servers, against a registry of legitimate ones registered in the Domain Name System (DNS). Where there were differences, proponents say Sender ID took the best from each approach—or pieces from both. For example, Caller ID listed its e-mail servers in XML format, whereas SPF put the information in text format. Sender ID uses text, because, according to Wong, "XML was a bad idea, it made the records much longer." Caller ID contributed to Sender ID's capability to check the From address in the e-mail message. Sender ID also confirms a valid return path identity, a la its SPF forebear.
"Technically speaking, it was a wise choice to roll these protocols together," says Paul Judge, CTO of Atlanta, Ga.-based CipherTrust, which makes the e-mail security software, IronMail, that Judge says is used by 30 percent of the Fortune 100. Given the minor and complementary differences, he says he saw "no reason to have separate protocols," and is hopeful about Sender ID's prospects. IronMail began incorporating SPF in February 2004, but Judge was planning to include Sender ID technology by the end of 2004.
Stumbling Blocks
Others, however, aren't so keen on Sender ID. When it decided it would patent elements of Sender ID, Microsoft caught flack from industry groups, the open source community, and other Internet titans, most notably AOL.
The patents largely surrounded the way the software checks that an incoming e-mail address is indeed coming from a domain that has been cleared by the recipient, the so-called Purported Responsible Address (PRA) checks. Microsoft says the patents were necessary to protect the technology from being patented or misused by others. But the issue raised fears over how much control the software Goliath would ultimately exert over the ostensibly "free and open" technology.
The issue became so heated that AOL, one of Microsoft's key partners in its legal and public war on spam, announced in mid-September 2004 that it would not support Sender ID. About the same time, the IETF Mail Transfer Agent Authorization Records in DNS (MARID) working group, which was established to review potential standards for e-mail authentication, sent Sender ID back for more work, also citing concerns over Microsoft's intellectual property claims.
"The patent on Sender ID was a big issue," says Andy Newton, former co-chair of the MARID working group, which disbanded in late September in the wake of the controversy over Sender ID and the patent issues.
In late October 2004, Microsoft resubmitted a revised version of Sender ID for review to a "special purpose directorate" of the IETF and it has since been submitted to the Internet drafts depository for public review, Newton says. Craig Spiezle, director of industry relations and strategy for Microsoft's Safety Technology and Strategy Group, said that before its resubmission Microsoft was "deeply engaged with others in the industry to make changes to the spec that are consistent with the recommendations made by the MARID working group co-chairs."
Spiezle also underscored the importance of Microsoft's patented PRA checks as the "most accurate representation of where the mail came from," adding that the company planned to implement the PRA function into MSN and Hotmail before the end of 2004.
 |
| (Click image to view larger version.) |
But there is a more basic problem with Sender ID. It only authenticates the last hop of the e-mail—not any previous senders—making it difficult to determine the true validity of mail that might go through multiple hops (for specific steps to how Sender ID works, see "Sender ID at Work"). Craig Taylor, vice president of technology for IronPort Systems, which supports Sender ID, says the technology is "easy to deploy" and provides some needed validation for e-mail. It may not, however, authenticate "the bulk of mail," he says.
"It's still spoofable," agrees David Jevans, chairman of the Anti-Phishing Working Group, a group composed of more than 400 companies and 100 vendors collaborating to stop phishing scams. Jevans says that a smart crook could pretend to be "a relay … or an agent," and still dupe e-mail users.
Assessing the Crypto Option
Sender ID has captured a lot of support, because of its ease of use and its connection to SPF, which Newton believes is used by at least 1 million domains. But it faces serious competition, mainly from the encryption-based schemes.
DomainKeys is the most ballyhooed of the cryptographic authentication schemes. It requires domain owners to generate private and public key pairs that are used to sign and verify all outgoing messages. The public key is published in the Domain Name System, and the private key is available to all DomainKeys-compliant outbound e-mail servers. The e-mail system uses the stored private key to generate a digital signature, which is attached to the message as an e-mail header. The receiving e-mail server gets the public key from the DNS of the sender's claimed domain to verify the digital signature was indeed generated by the matching private key. If it's a match, this not only proves the e-mail was indeed sent by the sender's purported domain, it also validates that the contents of the message and its header were not altered along the way.
Sender ID also requires that domain owners register their domains in the DNS, but it doesn't do the digital signing. In Sender ID's world, domain owners register the IP addresses of their outbound MTAs. Before e-mail is passed to the recipient, Sender ID-compliant receiving e-mail servers then check the From field within the e-mail and compare it against the registered list of domain and e-mail addresses that are allowed to send mail to the recipient. If it passes muster, the message is sent along to its intended recipient; if not, the message can be flagged, sorted into a junk mail folder or automatically rejected and deleted (see "How DomainKeys Works").
 |
| (Click image to view larger version.) |
According to Terrell Karlsten, a spokesperson for Yahoo, emerging e-mail powerhouses SendMail and Google's Gmail are both implementing DomainKeys, and Yahoo itself plans to have its system in place by the end of 2004. The technology is seamless for users, and "not a burden to implement," Karlsten says.
Others aren't so sure. Newton says technologies like Sender ID and SPF, that don't require public and private key encryption, are naturally "more practical and easier to deploy."
Sender ID doesn't require any changes to sending servers for the most part, Penn says, only that domain owners list their outbound
e-mail servers in the DNS. DomainKeys requires that outbound servers be both listed and upgraded to support digital signing. DomainKeys also burns processing cycles in
generating those digital signatures for outbound messages.
"Sender ID is a good compromise," says Jevans of the Anti-Phishing Working Group. It will find ready support because it's "easy to implement on the sender side" and doesn't require huge modifications or expenditures.
The fact that it doesn't require encryption makes Sender ID a more "lightweight and effective method of authenticating e-mail" that will provide immediate benefits for organizations, says CipherTrust's Judge.
But encryption has its advantages. Jevans admits that while "Sender ID is worth doing, it doesn't really solve the problem," adding that ultimately better e-mail authentication will require digital signing. Even Wong, the architect of SPF, agrees that encryption-based solutions like DomainKeys present a "better long-term solution, if they work." That's because encryption-based authentication schemes are more difficult to spoof, and provide the benefit of authenticating message contents as well as origin.
No Time to Lose
One in three online U.S. households say 75 percent or more of their e-mail is spam, according to a survey released in June by Gartner. So the question is: Can the industry afford to wait for cryptographic authentication to work its way into the market?
Microsoft says no. In addition to CipherTrust and IronPort, Redmond has also lined up support for Sender ID from e-mail providers and security vendors such as Verisign, Tumbleweed, Symantec, Sendmail, Cloudmark and Barracuda Networks. With Microsoft's revised Sender ID narrowing the scope of some of its patents and offering backward compatibility for companies and ISPs that already support SPF, even AOL publicly announced its renewed support just as Microsoft resubmitted its proposal.
The iron is hot, and industry pundits say, the time is right.
"The use of e-mail validation technologies will eliminate, or at least make it a lot more difficult, for spammers to hide their identities," Penn of Forrester predicts in a June 2004 report. "Adoption of e-mail validation is already underway, will really take off in the second half of 2005 and will quickly become mainstream within the 12 months after that."
Playing Wait and See
But the industry as a whole has yet to whole-heartedly embrace Sender ID. Stephen Currie, director of product management for communications products at Earthlink, says his company supports Sender ID, but is also trying out other IP-based protocols as well as cryptographic solutions like Yahoo's DomainKeys.
"We feel the right thing to do right now is test all these things," says Currie, "and eventually, the cream will rise to the top."
Brad Nightengale, vice president of emerging products for Visa USA, echoes that Visa is considering the development of all the potential e-mail authentication techniques. The issue is an important one for Visa, whose financial industry members are among the major targets of e-mail scammers. Right now, he says, "no one seems to have a silver bullet."
Hani Durzy, a spokesperson for Ebay, says the company—another major foil for phishing fraudsters—supports both Sender ID and the original version of SPF.
Most enterprise users of e-mail—even banks, online retailers and other companies squarely in the sights of phishers and spoofers—seem to be playing wait and see. Previous e-mail scam targets, U.S. Bank and Wells Fargo Bank, were not willing to provide comment on their e-mail authentication efforts for this story. Amazon.com failed to respond to more than half a dozen phone calls.
"Enterprises are being very quiet," says Wong. "It's been a disappointment. People need to speak up and say what they want."
Judge of CipherTrust admits that given "all of the attention phishing gains, only a very small percentage of companies so far are deploying SPF records."
Most on-lookers agree there will eventually be a need for both Sender ID (or something like it) and an encryption-based method for authentication.
"The two solutions work in tandem," says Karlsten. "They're not mutually exclusive by any means. I can see companies implementing both."
Taylor of IronPort agrees that both can run simultaneously, but believes that "Sender ID has the opportunity to deploy faster … once people can get around the licensing and patent issues." Jevans of APWG predicts that with Microsoft's pull (and its ownership of Hotmail and MSN), within a year 20 percent to 30 percent of all e-mail messages in this country could be verified through Sender ID. In four or five years, he foresees signed verification being at least as pervasive.
As for the controversy surrounding Sender ID and the competition from potentially better technologies, Wong believes that will not stand in the way of Sender ID becoming a standard in a world that desperately needs to do something about all the spam.
"Hey it's not perfect," he quips, "but it's a start."