Apache Rejects Sender ID

hexene writes "In an open letter to the IETF MARID Working Group, the Apache Software Foundation has rejected the patent-encumbered Sender ID specification. This means no Sender ID support for SpamAssassin, Apache JAMES, etc. They state that the current license is generally incompatible with open source, and contrary to the practice of open Internet standards."

Comments

Hoody Hoo!

[CountBrass]

Well done Apache! Surely this must be a big stake in the heart of MS email domination plans ?

Re:Hoody Hoo!

[Tracy Reed]

No, it does not hinder SPF. Sender ID is SPF+MS's hacks. You are still free to use SPF by itself.

Re:Hoody Hoo!

[Abcd1234]

Yup, you're absolutely right! Despite what the ASF said, they're rejecting SenderID because it's *Microsoft*! Yeah! Sure, they *claimed* it was because it was patent encumbered, but you have efficiently seen through their veil of deception.

Don't be a tool. The ASF doesn't gives a damn who created the freakin' standard. The fact is, it's patent encumbered. Period. And, as a result, they refuse to implement it. This shouldn't be at all surprising. Frankly, I think it's down right ridiculous that the IETF is willing to consider a standard that's patent encumbered. But, hey, who wants a free, open Internet?

Good start...

[keiferb]

Hopefully this is just the start of a string of rejections. If lots of big names in the OSS community and some of the e-mail superpowers (yahoo, gmail, etc...) jump on the bandwagon, maybe it'll get pushed aside.

Wishful thinking? Probably, but a boy can dream...

Patent encumbered indeed!

[Anonymous Coward]

Is this why the sender ID article on Wikipedia is only a stub?

Please, click "edit this page" and help if you know anything!

Stick with JAMES

[Anonymous Coward]

I use JAMES for my mail transport, and have found it to be fantastic. A single XML file can configure all the services you need (SMTP, POP3, IMAP), with or without TLS. If you want TLS, you just add an entry for it.

Also, it's really easy to write custom programs for mail processing, called "Matchers" or "Mailets" (many already exist), for things like SPAM detection, custom mail delivery, etc. I highly recommend it over sendmail/qmail.

Re:Good for them, but not far enough.

[athakur999]

In the scenario you mentioned, it forces the spammer to use machines that's within the ISP's control. If the spam bearing your domain is originating from some random computer in China, there's not a whole lot you can do. But if the spam has to originate from one of your customer's computers and has to be sent via one of your SMTP servers, then you can look at the logs on your SMTP server, figure out the infected customer, and take appropriate action.

Encumbered Standards

[Secrity]

I find it pretty amazing that the IETF accepts encumbered "standards". Protocols should either be industry standards or propietary. It could become interesting if an RFC calls for the use of an encumbered standard and half of the Internet chooses to ignore the standard.

Sendmail what is your move now??

[bryam]

"Sendmail releases open source milter for Sender ID
August 30, 2004
Today, Sendmail, Inc. is releasing an open source implementation of the IETF's Sender ID specification for testing on the Internet. This implementation utilizes the milter interface to plug directly into the sendmail MTA.

Sender ID is a standards-track proposal that merges Meng Wong's SPF and Microsoft's Caller ID for email. Authorizations records are published in DNS in an SPF-compatible format, and then used to validate user-visible message headers using the Caller ID "Purported Responsible Address". This sid-milter release implements the marid-protocol and marid-core draft standards, leaving the marid-submitter SMTP Extension to be implemented directly by the sendmail MTA.

Downloadable source code for sid-milter can be found at: sendmail.net/sid-milter"

Re:MSFT doesn't care about Apache.

[trifster]

Your logic doesn't flow. If that were the case then everyone would have stopped using sendmail and switched to exchange so everyone can send meeting appointments and tasks in addition to email. no, apache is on the right track. open standards (truely open) and protocols will win over closed source solutions. the reason is simple...the desires of the many will trump those of the few or only. so the majority will move on to the open technologies.

RMS summed it up well

[Skiron]

RMS E-Mail to IETF MARID WG ML

All listen to the man!

Good articles on this

[Anonymous Coward]

A few good articles on sender-ID controversy:

http://www.eweek.com/print_article/0,1761,a=134028 ,00.asp
http://www.circleid.com/article/730_0_1_0_C/
http://www.eweek.com/article2/0,1759,1639880,00.as p
http://www.newsforge.com/article.pl?sid=04/09/01/1 555212
http://trends.newsforge.com/14/04/08/26/1326244.sh tml?tid=137

Also, here are the opinions of Eben Moglen of FSF and Larry Rosen of OSI:
http://www.imc.org/ietf-mxcomp/mail-archive/msg036 78.html

What this means for the standard

[cerberusti]

In less than a week, IETF Last Call for this standard will be over. As of the moment, there is no consensus on the Microsoft patent issue. This will almost certainly prevent the standard from moving forward. The IETF is too divided on this issue for the standard to progress as it is.

Also, a clarification of how the IETF handles patent claims seems to be in order.

Patents are allowed in IETF standards under any terms that the working group feels are acceptable. In most cases, since the goal is to produce a standard which is useful to the largest group possible, patented methods are only used if the patent holder is willing to grant a very permissive license.

For example: The latest working group I was part of was SEND (SEcure Neighbor Discovery), a part of IPv6. SEND makes use of Cryptographically Generated Addresses, which are patented by Erricson. Erricson agreed to license the patent on the terms below:

In addition, for the CGA submission, if said submission is included in the IETF SEND standard and Ericsson has patents that are essential to the implementation of such included submission in said standard, Ericsson shall not assert any such patent against any company or legal entity using said patents in the IETF SEND standard. The Ericsson non-assertion is conditional upon such company or legal entity not asserting any patents within the IETF SEND standard against Ericsson. For all other purposes Ericsson's general patent license statement as referred to above, shall apply.

This is a fairly normal license for the IETF and was found to be acceptable. In almost every case where a patent is relevant to one of our standards, a licence statement such as this one is provided.

The Microsoft license is different, and has sparked quite a bit of discussion. Since this standard has a very large intended audience and there is significant concern over the terms of the license, unless Microsoft changes the terms of their license, this will stop the standard from progressing as is. Either the standard will be restructured to avoid using the methods claimed in the Microsoft patent, or the working group will terminate without a standard.

A lot of people are irritated about this.