I Come to Bury Sender ID, Not to Praise It

R. A. Hettinga rah at shipwright.com
Fri Aug 27 05:56:33 PDT 2004


<http://www.eweek.com/print_article/0,1761,a=134105,00.asp>

EWeek




I Come to Bury Sender ID, Not to Praise It


August 26, 2004
 By   Larry Seltzer


 It must have seemed like a good idea at the time: The effort to create an
effective standard for SMTP authentication relied, and still relies, on
quick adoption by the largest companies in the e-mail business, and
Microsoft is a significant company in both the e-mail software and service
business. Why not bring them into the process and make them a central part
of the solution?

 But it was not to be. With just hours to go on their deadline under the
IETF standard process, Microsoft finally released their revised license for
their intellectual property rights claims in Sender ID. Microsoft has
offered a royalty-free license to all implementers of their property and,
it would appear, more than satisfied the needs of the IETF.

But open-source advocates in the working group have emphatically rejected
the proposed license. Those who would create a distribution of it must
obtain one of these royalty-free licenses directly from and fax a signed
license form to Microsoft. So if you have a license and wish to publish
your source code for others to implement, you can't include the
intellectual property rights with the distribution.

This only applies to people creating new distributions of the software, not
people who simply want to use software that implements Sender ID, even GPL
software, or who want to create Sender ID records in DNS.
 Fed up with spam? Read eWEEK.com's special report "Canning Spam."

The reasons for the license are defensive. The only people who can't get a
license are those who are suing Microsoft over the intellectual property
claims in it. As one participant said, any company with a sizable R&D staff
will need to make such defensive moves, and the IETF has happily worked
with standards that involved IPR licenses before, many more restrictive and
burdensome than this.

But Sender ID is different. It is intended for a software market that has
had a large presence of open source software. There is some dispute in the
working group over whether the license is or is not compatible with most
open-source licenses, especially the GPL, but there is a consensus that it
is at least problematic for those licenses and a poke in the eye of those
who use them. And lawyers from the Free Software Foundation have stated
that the license is not GPL-compatible.

I tried to warn them, and I know I wasn't alone. Microsoft gave the
impression that stopping spam, phishing and other abuses of e-mail was
important to them, but it obviously wasn't important enough. For Sender ID
to be successful it needs to be adopted widely, and the only way that was
going to happen was if it was unencumbered by burdensome licenses. And it
had to be obviously free in everyone's sense of the word so that everyone
could feel free implementing it and getting to the important business of
fixing the broken e-mail system on the Internet. Microsoft just couldn't
bring themselves to do it. Instead they actually advise people, if they are
unsure of how the license affects them, to hire a lawyer.

Next page: We can do better anyway.

There's another point that's bothering people, which is the exact scope of
their IPR claims. Microsoft has said they have patent claims related to
Sender ID, but haven't said exactly what they are. Microsoft set up an
e-mail address (stdsreq at microsoft.com) to which people could send questions
on the matter. I asked them, "Can you tell me what patents Microsoft holds
that pertain to an implementation of Sender ID?" and haven't heard back. It
appears that the claims have to do with the retrieval of the PRA (purported
responsible address) from the message. It's just not worth scuttling Sender
ID over that.

And it could have turned out well. The merger of SPF and Microsoft's Caller
ID may have been a bit ugly and scientifically worthy of South Park's Dr.
Mephisto, but it would have improved on the current situation a great deal.
And it would have been good to show that Microsoft can be cooperative even
with their most unrelenting and unreasonable enemies when an important
issue is at stake.

In a way it's just as well, since the technical luster had come off Sender
ID in the last couple of months, such as in the concern addressed here over
the clogging up of DNS records. No approach that addressed all the major
problems with e-mail fraud would lack some flaws, but even if there was a
consensus on Sender ID it was not an overwhelming one. And with the
licensing debacle the consensus has swung overwhelmingly against Sender ID
and Microsoft in particular.

Perhaps Microsoft thought that Sender ID was such a killer standard that
they could push people around, but it's not. They've only boxed themselves
out of the process. The rest of the SID standards process will now be a
waste of time thanks to Microsoft, and the other participants will
afterwards pick up the pieces and get the job done with another spec. Rest
assured that enough alternatives were proposed that something can be found
that will suffice and that will have none of the license issues.

I feel sorry for the Microsoft participants in the process, principally
Harry Katz of the Exchange Edge team, who I'm sure only wanted the whole
thing to work and were restrained by persons senior to them, probably
Microsoft's vaunted legal team who did such a good job for them in the
past. Of course, we all know what Shakespeare said about lawyers.

Security Center Editor Larry Seltzer has worked in and written about the
computer industry since 1983.

-- 
-----------------
R. A. Hettinga <mailto: rah at ibuc.com>
The Internet Bearer Underwriting Corporation <http://www.ibuc.com/>
44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'





More information about the cypherpunks-legacy mailing list