Page II: For almost two years, I've argued for a non-proprietary, interoperable, freely deployable anti-spam standard, even as every spam-fighting solution I've seen has failed to pass muster. Until now.
Even if the motives appear altruistic, that's not to say that there aren't business benefits for Yahoo or Microsoft should authentication technologies like DomainKeys, CallerID, or SPF be adopted en masse. Such standards could lead to some much needed relief to the systems that transmit and store e-mail. As a side note, judging by the e-mail storage limit war that has erupted between Google, Yahoo, and Lycos, I'm not so sure that the storage problem is as bad as many say it is.
Regardless of the business benefits, Yahoo is still to be commended for meeting its social obligation by taking this giant step. Dan Rosensweig, Yahoo's chief operating officer, told me, "As spam is an industry-wide issue, we believe it is important to collaborate with the broader Internet community on promising e-mail authentication technologies. We are encouraged by all of the progress being made to protect people from spam and e-mail forgery, and will continue to actively participate in these important discussions."
Not to be upstaged by Yahoo's well-timed-to-the-MARID-meeting announcement, Microsoft will, by the time this story is published, or very shortly thereafter, submit to the IETF the specification for its CallerID technology. According to Sean Sundwall, spokesperson for Microsoft's Anti-Spam Technology and Strategy Group (a group that employs 60 people for the spam problem alone), "Microsoft's submission of the CallerID specification to the IETF will happen within days." However, there remains a bit of controversy around the already published licensing terms for CallerID.
Not surprisingly, any royalty-free licensing terms from Microsoft, especially regarding a technology that could become a permanent fixture in one of the Internet's two biggest killer applications, gets special scrutiny. The first CallerID licence raised industry-wide concerns about the perpetuity of the royalty-free terms. Microsoft's revision to the licensing agreement may have fixed that problem, but raised new concerns about sub-licensing -- a common wrinkle in the licensing of standard specifications. Though everyone's guard appears to be up (because it's Microsoft) and the current licence is considered a barrier to mass adoption, most people I spoke with (both in and out of Microsoft) regarding CallerID's licensing terms view the hang-ups as ambiguities that Microsoft will eventually resolve.
"The idea has not been to create a business model," according to George Webb, Microsoft's general manager of its Anti-Spam group. "The intent of our licensing terms is to prevent folks from creating [functionally different derivatives] of CallerID and then having those versions being something that others profit off of."
"We've had a lot of feedback and concerns," Webb told me. "I'm aware of the sub-licensing and perpetuity issues. There will be a new IP declaration that goes with the RFC and there will be modified terms as well. The intent is to have this as broadly adopted as quickly as possible and to hand this over to a standards body and our submission this week will be a proof point of that."
Issues other than licensing also will determine the breadth and speed of adoption. The more complex a specification is, the harder it is to deploy, the longer it will take before a reasonable number of systems begin to interoperate over that spec, and ultimately, the longer it will be before any of the technologies' effects on spam can be felt. In terms of the three specifications, the first complexity issue that MTA developers are apparently looking at is how much work must be done on both the sending and receiving ends of the pipe. In this regard, CallerID and SPF may hold more promise than does DomainKeys for accelerated penetration.
Although all three specifications rely on the DNS, DomainKeys alone requires changes on both the sending and receiving systems, while neither CallerID nor SPF require changes to the send-side of an MTA. In order to get started, only the receive-side of the MTA must be modified to compare certain information found in inbound e-mails to information that's stored in the DNS. In fact, the similarities between SPF and CallerID are compelling enough that the two are viewed as competing specifications on a path to merge once their differences can be resolved.
One of those differences is Microsoft's employment of XML to store information about sending systems in the DNS. According to John Levine, co-chairman of the Anti-Spam Research Group (a working group within the research arm of the IETF known as the Internet Research Task Force or IRTF), "Merging the two shouldn't be that hard. Microsoft would just have to drop XML from the CallerID specification, and we'd be done. XML is the main complaint and an XML parser is a large chunk to add to a lot of programs," said Levine. "XML is a good way to do a lot of complex data, but we don't want complexity."
Microsoft's Sundwall says that Microsoft is trying to ease the pain associated with XML by creating wizards that make it so easy to generate the XML string that's entered into the DNS that even his grandmother could do it. Said Levine, however, "Creating the string is the easy part. Parsing it is hard. Not only must a routine on a receiving system be able to parse correct XML, but it must also be able to deal with arbitrarily coded or hostile data." Complexity leads to vulnerabilities, Levine added. "The more complicated the format, the harder it is to see and deal with [in the parser] all the ways that it might be broken." Because of the complexities associated with CallerID, Levine says, "If the MARID group decided to do the easiest thing first, then that would be SPF."
One major criticism of CallerID and SPF that DomainKeys overcomes in some situations is a forwarding problem. While CallerID and SPF are hailed as solutions that require no changes to the send-side of an MTA, there's a downside to this advantage. When users set their inboxes to auto-forward their mail to another inbox, the information from the original sender (which could have been a spammer) needed to complete the authentication process is lost.
4%
1%
