Debian Project Rejects Sender-ID

NW writes "Following on the heels of Apache Foundation taking a stance against Sender-ID, the Debian Project announced today their rejection of Sender-ID as well."

Comments

Solution : Go for SPF, the unencumbered version

[Anonymous Coward]

A list of SPF-enabled registrars and DNS providers is at http://www.spf.idimo.com/

Re:Statements but little analysis

[Anonymous Coward]

it's patent-encumbered, which means that reverse-engineering won't help: regardless of the implementation, they would still need to abide to whatever ms is telling them.

not possible for section 7 of the gpl

[Anonymous Coward]

7. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.

Re:not possible for section 7 of the gpl

[Alsee]

FAQs say specifically that all GPL software can include royalty-free implementation

No it does not. It explicitly states the OPPOSITE.

FAQ 15
Question: Is Microsoft's Royalty Free Sender ID Patenty License compatible with the GPL?
Answer: Unlike some other open source licenses, the GPL includes a provision that appears to prohibit the distribution of code that is subject to [THIS PATENT LICENSE].

If you are thinking of the last sentence in Q15 where they say you can distribute a Sender ID implementation with Linux and other GPL software, that is the same as saying you can distribute a boxed copy of Microsoft Windows with a box of Linux. Obviously Linux is prohibited from containing Microsoft Windows.

Microsoft is prohibiting any GPL or similarly licensed software from including a Sender ID implementation. Microsoft wants to turn an open standard into an exclusionary "standard".

It should be possible to publish any GPL software under dual license (GPL and non-GPL) the latter supporting Sender-ID.

You have no clue what you are talking about. It's certainly possible to dual-licence code you write which does not contain any one else's code. However if you write code including Sender ID and GPL it you cannot legally distribute it. If you take a GPL project and add a Sender ID code to it you cannot distribute it under any licence at all.

Sender-ID... plugin itself could be LPGL

No. Microsoft's patent license also excludes LGPL distributions.

how is Microsoft's standard a poison pill?

Because Microsoft made a specific effort to design it to exclude GPL, LGPL, and similar license implementations. If Microsoft successfully has their exclusionary patent terms included in the standard then GPL and similarly licensed software would be prohibited from implementing it. Sender ID compliant severes would then be rejecting any mail coming from GPL and similarly licensed mail servers for failing authentication.

A mail server that cannot send mail is effectively exterminated.

-

And for those of you wondering what it is...

[the pickle]

Description of the Sender ID Framework from Microsoft.

It would be so much nicer if people writing/editing these stories would link to stuff that isn't blindingly obvious to everyone.

p

No basic DNS changes

[WoodstockJeff]

The changes to DNS involve adding a TXT record to the domain which lists the hosts authorized to forward mail for the domain. Nothing proprietary there, and anyone with control over their DNS can do it.

Of course, if you have a DNS provider who won't let you make such changes, you probably need a different DNS provider!

Re:Sun, RedHat, IBM's response?

[Zocalo]

I was expecting your link to go the Newsforge story that leads to this article, but apparently not. Apparently Earthlink is refusing to adopt Sender-ID in its current state as well, and most interestingly it is doing so on the advice of its legal counsel. Given that the project leads of Exim and Postfix, but interestingly not Sendmail, have also adopted a similar stance I think Sender-ID is pretty much dead in the water at this point.

I have to admit, I'm in two minds about this. On the one hand it's long overdue for Microsoft to be seriously given the finger by a collective group that it is unlikely to be able to bully or "embrace and extend" around. On the other, Sender-ID does seem to be the most sophisticated of the sender validation technologies proposed to the MARID group at the IETF, it would be a shame to lose it to corporate greed if Microsoft doesn't resolve the patent issues soon.

Re:I don't get it...

[WoodstockJeff]

Sender ID adds checking of the header FROM field to SPF. SPF just checks the domains mentioned in the SMTP protocol exchange (HELO/EHLO, MAIL FROM), while Sender/Caller ID check the optional FROM header found in the DATA portion.

Re:Sender ID - hell, how about reverse dns?

[Homology]

If AOL and hotmail alone required valid everse DNS the rest of the world would follow suit in short order.

Not very likely, for this would break large part of the e-mail infrastructure. There are many virtual hosters whose reverse DNS does not match the domain they are hosting. Or in my case with static IP home DNS that does resolves to something, but my domain name. And I suppose we can say bye, bye to many backup MX servers as well.

What AOL sensibly require is :

• If the sender's domain is the only domain sending mail from a specific IP address, we recommend that the reverse DNS entry (PTR Record) match the domain name (A Record), but we do not require it.
• AOL does require that all connecting Mail Transfer Agents have established reverse DNS, regardless of whether it matches the domain.
• Reverse DNS must be in the form of a fully-qualified domain name - reverse DNS containing in-addr.arpa are not acceptable, as these are merely placeholders for a valid PTR record. Reverse DNS consisting only of IP addresses are also not acceptable, as they do not correctly establish the relationship between domain and IP address.
• /ul

MS's stance goes clear to the top on this

[optimus2861]

Browsing the mailing list, I came across this message from Matt Sergeant of MessageLabs, about a conversation he had with Craig Spietzle of MS. Notable excerpt:

I pressed him: "Will you fix the license?". I never really got a confirmed yes or no, but my feeling was "no" when we ended the conversation. I suggested that they give their IP to the IETF (such as I believe there is precedence of - I know that IBM has committed patents to the public domain before in a similar act of openness), to which I was told that Craig believed this was a reasonable idea, but that Bill Gates himself had vetoed that idea because of the current focus on patent gathering and IPR issues at Microsoft.

(emphasis added)

Re: Critical mass needed.

[farnz]

Sendmail's licence is a hybrid between the GPL and the BSD licences. I think it lets you get away from the patent issue though (ask a lawyer to be certain).

Re:Will it work?

[pe1chl]

The sendmail support is from Sendmail, Inc. not from the open-source sendmail at sendmail.org

Re:Statements but little analysis

[pavon]

Here is the deal with Sender ID. Caller ID is patented (Sender ID = SPF + Caller ID), and thus everyone who uses in must get a patent from MS. If something is patented, you must license it to use it. It doesn't matter if you got the ideas from copying, white-room reverse engineering, or if you independently discovered the idea - the patent holder still has a monopoly on the use of the ideas and you must license them. As far as I know ASP and SMB are not patent encumbered. MS didn't have a policy of patenting their software until several years ago (about the same time as the Halloween papers were written, IIRC).

MS has licensed the Caller ID patent(s?) under what, on the surface, appears to be a very fair and open royalty free license. You don't have to pay any fees to MS to get a license to include Caller ID in your software. You can distribute the software to anyone you want, and your users are also free to redistribute this software. You can even distribute the source. For more information, read this article. However there is one issue that makes it incompatible with open source software - the patent license is non-transferable and non-sublicenseable.

What that means is that each developer who creates or modifies Caller ID code must sign and mail their own license from MS. The OSI definition of Open Source Software, and FSF definition of Free Software both state that the user must be free to modify and redistribute the software. This puts FLOSS licenses at odds with the Caller-ID license. If your software license meet the terms of the Caller-ID license then the software isn't FLOSS, and if you use a FLOSS license, then you are not meeting the terms of the Caller-ID license. The best lawyers on the subject agree that it is impossible to make these two agree. They also do a good job of explaining why redistribute of modified works is critical to FLOSS software, and why we should refuse to use a license that would be compatible.

So thats where things stand. It would be possible to write a non-FLOSS plugin for FLOSS software, but it is impossible to write a FLOSS implementation. Debian has a long history of not accepting non-free software into their main branch. But even among those that are more tolerant of combining proprietary software with FLOSS, there are many who disagree with proprietary standards and are thus opposed to the Caller ID license.

Re:Restrictive Patents

[miquels]

Actually, Sender-ID is a standard for MTAs (Message Transfer Agents) and here open-source sofware /does/ dominate the market. The four large names are Sendmail, Qmail, Postfix, and Exim.

For more info see the IETF sender-id mailinglist at http://www.imc.org/ietf-mxcomp/mail-archive/thread s.html

Re:Sender ID - hell, how about reverse dns?

[slittle]

There are many virtual hosters whose reverse DNS does not match the domain they are hosting. Or in my case with static IP home DNS that does resolves to something, but my domain name. And I suppose we can say bye, bye to many backup MX servers as well.

I don't think he means that the delivery DNS match the envelope sender, only that the delivering IP have valid and matching forward and reverse DNS records. This would not affect virtual hosts, MXs, send-only or receive-only relays, or SMTP HELO.

Or in my case with static IP home DNS that does resolves to something, but [not?] my domain name

Too bad. Get an account with a decent provider that will give you a proper reverse DNS, or accept the fact that you are a second class netizen and relay your mail through your ISP.

Preferably the former, as it may force more ISPs to offer the service.