Sender ID: Back From the Grave

I love Halloween, partly because I have young children who get caught up in the excitement of picking out costumes and going trick-or-treating and partly because Halloween a great excuse to eat a lot of candy. This week's column is relevant to Halloween because I'm writing about something that has clawed its way out of the grave: Microsoft's Sender ID.

If you've been following Sender ID's development, you probably know that about a month ago the Internet Engineering Task Force (IETF) disbanded the MTA Authorization Records in DNS (MARID) working group, which was charged with hammering out an IETF standard for using DNS records as a mail-authentication tool. That move seemed to spell the end of Sender ID's life as an IETF standard; the conventional wisdom was that without IETF approval, Sender ID adoption and deployment would be too limited to be of any use.

Now it looks as though Sender ID has been resurrected. Microsoft took the original proposal and changed two aspects of it that had troubled the MARID working group.

The first change involves backward-compatibility and interoperability with the Sender Policy Framework (SPF) standard, which is more widely deployed than Sender ID. This change apparently means that Sender ID-compliant implementations will honor valid SPF records. I say apparently because, as of this writing, Microsoft hasn't released the details of what backward-compatibility means in this context. Microsoft has likely extended Sender ID to perform both Purported Responsible Address (PRA--see http://www.winnetmag.com/article/articleid/43917/43917.html ) checks and envelope FROM address checks.

The second change isn't technical; it's legal. Microsoft applied for a patent for some of the key technologies Sender ID uses, and the company had planned to require licenses to use the standard. Microsoft now says that you won't need a license to publish Sender ID records or to perform SPF-style envelope FROM checks. You need a license only if you're checking the PRA, but whether that condition refers to everyone or only to ISPs and large enterprises (the two types of organizations specifically called out in the Sender ID FAQ) isn't clear.

The big news is that AOL has endorsed these changes, meaning that the company is throwing its support behind Sender ID. In fact, AOL has committed to testing Sender ID by year's end and to sharing the test results. I'm looking forward to seeing the results because AOL generates and receives mind-boggling amounts of SMTP traffic every day.

This saga has one more twist. As Yakov Shafranovich points out in his blog (http://www.shaftek.org/blog/archives/000160.html ): "The \[Federal Trade Commission--FTC\] and \[National Institute of Standards and Technology--NIST\] are holding a joint summit on email authentication in 2 weeks in Washington, DC (during the same week as IETF's 61st conference). They hinted earlier this year that if the industry does not come up with a standard for authentication, the feds might impose one. If Microsoft comes to the FTC with AOL in tow, this may tip the balance in favor of Sender ID as the 'ultimate' industry standard."

This interpretation seems reasonable because in other industries (including the telemarketing industry) the FTC has stepped in to introduce regulations after giving those industries a chance to self-regulate. Will Microsoft and AOL successfully position Sender ID as a spam-control measure that's good enough to forestall FTC action? I wouldn't bet against it. But anything can happen during Halloween.

Comments

Plain text