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."
I don't see any reason to use SPF either. It only benefits big ISPs, by keeping spammers from mentioning them in their return addresses. Even then it only works until the spammers hijack the machine of some dumb sap who's a legitimate customer of such an ISP, and send under his name. It does you and me no good at all, either way.
The whole exercise has been a waste of time and attention for all involved, and the sooner it's forgotten, the better.
We will not be implementing support for Sender ID until such time as the issues with the license are fixed and acceptable to the Apache James and Apache SpamAssassin Project Management Committees.
It's obvious that Apache's concerns are of the utmost importance to both MSFT and those conducting the discussions. If they were SO concerned this would have been taken care of long ago. MSFT figures that either Apache will kowtow after users get pissed that they cannot send to those behind an MS mail solution or that they will end up having to break down themselves later. It's a lot bigger of a gamble for Apache to ignore MSFT than it is for MSFT to ignore Apache.
As an alternative resolution, we would find it acceptable if the pending patents were granted to a non-profit organization such as ISOC and licensed under sufficiently open
terms.
This, OTOH, is a valid option and should be exercised but I highly doubt it will be for obvious reasons.
"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"
RMS E-Mail to IETF MARID WG ML
All listen to the man!
According to this article SenderID in the agreed upon form is nothing new. Indeed it seems that MS has embeaced and extended someone else's IP and put their own claim to it.
Therefore, Apache maybe abandoning something that it needs not to abandon.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
I think this is the first time I've seen a situation where Microsoft is unable to dictate to others on "how things are going to be". The question I have now is "what will Microsoft do next?". Are they willing to be directed by an Open Source project, or will they go their own route to stave off the perception that Microsoft isn't as omnipotent as they want everyone to believe?
Fascinating. Absolutely fascinating.
Ruby on Rails Screencast
In fact, the ASF just rather recently set up SPF filtering on their own internal mail servers.
Who said Freedom was Fair?
I hope Apache wins the day here. However, the entire reason for the RAND proposal in the first place was to allow commerical interest to capture open Internet standards. I don't think they will be easily deflected.
sPh
i have a small email server at home that i use for website signups & imdb movie queries, i have a domain name pointing at it but the reverse dns of my IP gives me not my domain name but my ISP's name of my machine as i dont control the dns for that, so how can i use these email certification systems ? i have complete and correct mail headers and am willing to verify who iam but iam a bit pissed at being denied the use of smtp, whats next ? SSH or [insert port here]
so how will these email schemes protect me ? or is this a case of screw the honest geek on a cable modem and render being in control of my own email useless, forcing me to use "approved server$" from [insert large corp name and another fee here]
After reading the statement on the ASF web sit, I reluctantly had to agree with the Apache Software Foundation on the issue of Sender ID. The "free license" offered to those that support SenderID in open-source software packages has too many pitfalls, too many places where it could encumber open source projects. The SpamBouncer will therefore not support SenderID either until there are fundamental changes in the license.
This is a shame. Meng Weng Wong's original idea for SPF was quite good, and I was planning to support it.
Catherine
I think we are missing the real danger here. There was never all that much difference between SPF and Microsoft's Caller ID. The differences were in the details of how they were put into the DNS, the use of XML vs text formats, and maybe some issues about exactly which mail headers were checked. But the basic idea was almost identical.
This means that Microsoft's forthcoming Caller ID patents probably cover SPF. That's the real problem here.
We can't just tell Microsoft to get stuffed and then go ahead and use SPF. There's too much risk that Microsoft will surface with a patent in three or four years that covers a technology which is by then widely used on the net.
I think this decision kills SPF and everything along those lines. Some may cheer and some may be upset, but that is the reality we face. Going forward with SPF under these circumstances is far too risky. Microsoft has warned us about the patent applications and we can't ignore them.
At this point, MSFT is basically beyond the control of the United States.
I'm not talking about life and death. The Constitution was made to cover life-and-death, and keep those kinds of decisions in balance. We're talking about optimizing life. And within the confines of that issue, MSFT is un-touchable.
Like I've said before, if the revolution ever does break out, MSFT will be the first ones up against the wall. There will be a bunch of hippies up against the wall with MSFT, as well, simply because we know they don't have any guns.
Christ, we'd have a clean nation again. I don't know what we would do with ourselves. Probably, like, making space stations or something. Conquer space. I dunno...
Nobody can fork the standard. The patent "grant" is for compliant implementations only. So its microsofts document, microsoft controlled and thats the end of it.
SPF also has another deeply fundamental flaw - it requires the ISP to be vaguely competent. That alone is fatal for many of ISPs.