Sender ID: Not Dead Yet?

Via Ed Brill... reports of Sender ID's death are premature.

Well, when we last encountered the saga of Sender ID, I mentioned that the open source community had become uncomfortable with Microsoft's patent licensing terms, and given that Microsoft's patent claims had not been validated (as the patent is still pending) the implication was that Microsoft wanted vendors building Sender ID compatible mail servers to pre-emptively sign off on rights that Microsoft hasn't even proven they really own. But it was more than that, because not only was the patent still pending... it was not even published. It was therefore impossible to even know what parts of the proposed IETF standard that Microsoft believed would fall under their licensing.

Now eWeek reports that the patent claims have been published, and they appear to cover things for which prior art clearly does exist. Signing off on a licensing agreement for claims that should legitimately be invalidated would not serve the interests of the IETF, the mail server vendors, or the Internet mail community at large. And guess what technology appears to be the prior art? Why, SPF, which was the proposed standard all by itself before Microsoft offered to merge in their own Caller ID technology to create the joint Sender ID standard.

Meanwhile, AOL is dumping Sender ID (or more specifically, the Caller ID subset of Sender ID) in favor of SPF, so while IBM may be saying that "cooler heads will prevail" it seems to me that a "compromise" that leaves part of the industry adopting just half of the Sender ID standard will be a bad thing. I'm not one of those people who believes, by the way, that "compromise" is an inherently bad word. To the contrary as a matter of fact, but this would be one of those cases where compromise is bad.

Compromise on a pick-and-choose-your-authentication-code version of the Sender ID standard will leave us in a position where two vendors claiming to support Sender ID will really be supporting different technologies, and customers will find it difficult to know the difference. In a multi-vendor, multi-server email environment, that is unacceptable. In fact, it does precisely what Microsoft wants: it promotes lock-in for vendors who can claim to support the "full standard", and especially for Microsoft. The folks in Redmond will engage their vaunted PR machine to overwhelm the truth, and pretty soon everyone will be believing that the "real" Sender ID sprang forth fully formed from Microsoft, and only Microsoft servers can be trusted to do it right. The IETF should not allow this.

Let's be clear about this: for all intents and purposes, Sender ID = SPF + Caller ID. SPF is public domain, and SPF came first. Microsoft claims patent rights over Caller ID. Microsoft is willing to license those rights to anyone for use in an SMTP mail server, but on the condition that they don't challenge the patent rights. This kills all potential for innovation by anyone other than Microsoft in extending the patented techniques into any other applications, except by people who aren't in the mail server business. Furthermore, with broad industry sign-off on the patent, who would challenge it? Nobody would, even though the claims over the portions that overlap with SPF are invalid. The IETF should not compromise in any way, shape or form that lends support to a false claim.