decoration decoration
Stories

GROKLAW
When you want to know more...
decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books
Your contributions keep Groklaw going.
To donate to Groklaw 2.0:

Groklaw Gear

Click here to send an email to the editor of this weblog.


To read comments to this article, go here
FTC Email Authentication Summit and Sender ID
Tuesday, November 09 2004 @ 03:16 AM EST

It looks like Sender ID is being pushed in a big way tomorrow at the FTC hearings on email authentication. There will be phone lines open, first come, first serve for the public who are unable to attend in person. The hearing itself is also open to the public on a walk-in basis. Here's more info from the FTC's website:

Phone lines will be available on a first come, first serve basis to members of the public who are unable to attend the summit in person.

Call-in Information

Date: 11/9/2004
Start Time: 8:30:00 AM
Phone Number: 800-720-5850
Chairperson: Bruce Jennings
Confirmation No. :27530905

Date: 11/10/2004
Start Time: 8:30:00 AM
Phone Number: 800-720-5850
Chairperson: Bruce Jennings
Confirmation No.: 27531336

There will be an email address monitored during the summit for members of the public who wish to email questions to panelists. Information about the email address will be available on the day of the summit.

And here is the list of companies and individuals who have hopped on the Sender ID bandwagon. Some of them may not realize that there is an issue about the GPL. Amazon, for example, runs its business on GNU/Linux systems.

You can read some of the comments submitted by the public on this page. They are all PDFs. Here's a bit from one:

Relying upon any single vendor or a national mandated approach will faiL. The degree of global acceptance and adoption required to eliminate the 'spam' and viral infection problems is 99.99999%. No solution that only works on one type of operating system/platform version will adequately solve the problem. Solutions should easily work on all types of client and server computers running e-mail client and server software: Unix, Microsoft Windows, Macintosh, Linux, PDAs, web-enabled phones, etc. The optimal solutions would likely come from the Free and Open Software community since they already write the software powering 70% of internet servers.

And another:

The Microsoft proposal, with its 'poison pill' against the GPL, is a good example of a VERY bad idea that must be rejected. All such attempts to 'monetize' the internet's email system by any party must be avoided. If the U.S.A chooses to attempt to force such a system, the likelyhood is that some non-trivial percentage of the world (including those inside the USA) will NOT adopt the system, thus either making it impossible for folks on one side to send email to folks on the other, OR there will be email gateways - which will end up gatewaying spam (and completely voiding all possible benefits of the system!).

From EFF:

Any Internet standard, including any for email server authentication will have to be compatible with open source software licenses and cannot be burdened by intellectual property claims such as patents. According to a study done by Oan Bernstein(http://cr. to/surveys/smtpsoftware6.txt), open source software accounts for the majority of Simple Mail Transfer Protocol (SMTP) servers on the Internet.

According to Yakov Shafranovich, a co-founder and software architect with Solid Matrix Technologies, Inc., and former co-chair of the Anti-Spam Research Group (ASRG) of the Internet Research Task Force (lRTF): lt is well known that free and open source software collectively called 'FOSS' runs majority of the Internet architecture: Linux, Apache BINO, sendmail, OpenSSL and others have significant if not most of the market share in their respective categories. On the other hand majority of the desktop market is dominated by commercial software, a major part of which is either made or sold by Microsoft. This is even more expressed in the email market than other categories: the biggest four software packages used for email servers today are qmail, send mail postfix and exim, all of which are FOSS (although some dispute that regarding qmail). (http://ww.circleid.com/article/732 - C/

Here's a snip from David Wheeler's letter:

* NIST should urge lawmakers to make spam illegal, so that technological measures will have legal standing. Authentication has little anti-spam value without it.

* NIST should insist that any anti-spam technical standard must be implementable by all suppliers of email infrastructure, both proprietary and open source software. . . .

Businesses must be able to accept emails from strangers; it's how they get new business. Home users must usually accept emails from long-lost people they knew from years ago. It's not practical to only accept email from previously known email addresses. Thus, a spammer can create a new address for every message, each of which can be authenticated. And as noted in the Register, spammers now take over user's machines, and thus they can send email as that user (and could authenicate themselves, too).

This doesn't mean that authentication is useless. Authentication is useful in its own right, especially for countering phishing attacks, and for eliminating false "bounce" messages from forged email. And authentication, when combined with other anti-spam technology, could have a very slight impact on spam in the short term. But unless there are laws forbidding spam, that permit civil suits and recovery of damages against spammers, then the technological measures will not be very effective.

Microsoft is encumbering its proposal with what it calls its "Royalty Free Sender ID Patent License." Novices might see no problems with this, but this is simply not a reasonable proposal. As the careful analysis of Mark Shewmaker (http://ww.imc.org/ietf-mxcomp/mail-archive/msg03514.html) and others shows, this license is extremely discriminatory: it is essentially incompatible with open source software (OSS).

Since vast amount of the mail infrastructure is implemented with ass, this is unreasonable and extremely discriminatory. For example, the Apache Software Foundation (ASF) announced that it couldn't support Sender-ID, at: http://ww.apache.org/foundation/docs/sender-id-position.htm I This is important since ASF releases the widely-used SpamAssassin (as well as the Apache web server).

Any authentication system MUST be implementable by all major systems. This means that it must be implementable by all open-source and proprietary systems. Mere public specification is not enough; systems must be IMPLEMENTABLE to be useful, and that includes terms that permit widespread implementation by all relevant parties.

And finally, Microsoft:

Technology alone, however, will not solve this problem. A holistic approach that also includes industry collaboration, legislation, enforcement, and education is necessary to shift the burden from the user to the spammer, resulting in an increase in the reliability of e-mail and of the Internet. This approach also requires that any proposed authentication standard be supported on a global basis, because spam transcends and traverses national borders. Collectively, these measures will help to substantially reduce the amount of junk e-mail delivered to users' mailboxes and optimize users' overall online experience.

See, that's just the problem. The Internet runs on FOSS and increasing numbers of individuals, businesses and government agencies prefer to use Linux, and by choosing a license that excludes all those folks, Sender ID, by Microsoft's own logic, won't work.

Of course, Microsoft has thought of that and they have a plan:

Sender ID also requires modest changes to the e-mail software used by sending servers in certain situations -- mainly to those servers that perform e-mail forwarding. As more and more organizations adopt e-mail authentication techniques, pressure will mount on those who are not participating, because their e-mail will be subjected to greater scrutiny and will be at a greater risk of being blocked by spam filters. Thus, over time, upgrades to existing software will become necessary.

Devilish indeed. But I urge you to read the section on Intellectual Property, beginning on page 8. Their version of what happened with the Internet Engineering Task Force (IETF) is something to behold. It begins like this:

Open Standard. Any authentication system requires cooperation between senders and recipients of e-mail. For that reason, we believe that specifications for these systems must be publicly available and widely implemented -- which is why our Sender ID specifications have been published as Internet Drafts at the Internet Engineering Task Force ("IETF"). A technical interoperability specification is an open standard when it has been ratified in an open, consensus-based process. . . . The Sender ID Framework satisfies these conditions because its specifications are published by the IETF, and because the essential intellectual property rights disclosed to the IETF have been made available on reasonable and non-discriminatory terms that are also free of royalties and other fees.

That is clearly false, as the license attaches terms that preclude its use with any GPL software. They do mention that the IETF working group "has not reached consensus on the proposal and has suspended its work for now -- a decision which is being appealed -- but the disclosure of intellectual property rights to IETF and its publication of Sender ID Framework specifications endures and thereby satisfies the conditions for an open standard." They say the test isn't whether a solution is an open standard isn't whether it has been ratified "through an open-consensus based process", but whether the solution "can be widely adopted. . ." Not a word that I can see in their letter about the GPL conflict. This kind of doubletalk is beyond my heart's comprehension. And here's a scary sentence about the Sender ID license:

"The terms of this license can be accepted by anyone at any time, now or in the future, and will extend to all of Microsoft's essential patent rights needed to implement Sender ID -- not just the essential patent rights that could issue from these patent applications. . . . although this license does not cover other patent rights that might be owned or controlled by parties other than Microsoft and that may be needed to make, use or sell implementations of Sender ID . . . "

By the way, this is what Microsoft's words look like if you copy and paste them, so I had to hand type them:

'l:'chnoiogy ",1011_ 11owt'-v.;r, vì1 not ~wivi.~ this prob1em. A holi~tit appiwJdi that "i1so incl1tdes industry coJiaboratio):, kgislaiiüt1, üHfürçem~l1t, and education is necess::ry to shift the burden i1'om ~he user to the sp;,nw:wr, n::sii1Üng În an increase in lhi; rdiahilit:" of e--rnai¡ and of the TntemeLThis appwadi "iko requ:res that any propo~1ed mdientieition :"Ümdardbe supported on a global basis, hteaw3i; spam tn.mseends and traver~:;es national bün.:kn:" Cü!kctivdy" i.hese measures wH1 help to sl,bsLmUally redlice

Now, Groklaw is nonpolitical, and I'm not one to be telling the FTC or any government agency what to do, but you could be a child and see that Microsoft's definition of open standards is ludicrous. Ludicrous and dangerous. It looks to me like Sender ID is just another way to set up conditions to hold back Microsoft's principal competition. They intend that non-Sender ID email will over time become so annoying that we all finally acquiesce and sign their poison pill license. What is the difference between that strategy and Microsoft's tried-and-true anticompetitive trick of arranging it technically so that competitors' applications don't work well in a Windows environment?

And while we are on the subject of anticompetitive moves, you'll find this article instructive, I think. It gives more detail about the Novell-Microsoft litigation, particularly why Microsoft wasn't willing to settle that claim without litigation, and also reveals that Microsoft just settled with another organization:

In a separate settlement announced yesterday, Microsoft said it will join the Computer & Communications Industry Association (CCIA), the trade group that has fiercely opposed it for years and was its main challenger in European courts. At the same time, the group agreed to withdraw its complaint against the company in Europe.

"We and other companies in our industry do have the capacity now to sit down face to face and resolve the kinds of thorny antitrust issues that in the past were left to the government to resolve," said Microsoft General Counsel Brad Smith.

The CCIA's complaint, according to Microsoft, was "a principal obstacle to our ability to negotiate a settlement" with European Union regulators in March. Some money is being paid to CCIA for their legal expenses. Ed Black, president and chief executive of CCIA, says "we're going to continue our effort in open-source and copyright and patent areas." Microsoft, in the article, tries to portray RealNetworks as standing alone now against them. A spokesman for RealNetworks is quoted as saying, "Microsoft's payments to Novell and CCIA do not change the anticompetitive conduct condemned by the European Commission."


  View Printable Version


Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details )