Slashdot Mirror
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."
Well done Apache! Surely this must be a big stake in the heart of MS email domination plans ?
Bad analogies are like waxing a monkey with a rainbow.
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...
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.
Microsoft Sender ID Framework
... and it goes on and on
The Sender ID Framework is an industry standard created to counter e-mail domain spoofing and to provide greater protection against phishing schemes. This combined specification is the result of Microsoft's Caller ID for E-Mail proposal, Meng Wong's Sender Policy Framework (SPF), and a third specification called the Submitter Optimization. These three draft technical specifications were recently submitted to the Internet Engineering Task Force (IETF) and other industry organizations for review and comment.
Is this why the sender ID article on Wikipedia is only a stub?
Please, click "edit this page" and help if you know anything!
This means no Sender ID support for SpamAssassin, Apache JAMES, etc.
Funny, I thought Apache supported these things called modules that allowed you to extend Apache.
Just because it doesn't come from the Apache Foundation doesn't mean it wont happen.
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.
With the rejection by Apache, hopefully the rest of the FOSS will follow and then the industry at large.
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
Finally, as developers of open source e-mail technologies, we are concerned that no company should be permitted IP rights over core Internet infrastructure.
Is any really surprised that MS is trying to build it's patent arsenal around such things? And of course they want to do it quickly because it's much easier to get something underhanded accepted quickly. (PATRIOT Act anyone?)
We are also concerned by the rush to adopt this standard in spite of technical concerns, lack of experience in the field, and a lack of consensus in the IETF MARID WG.
I think again Open Source groups show their strength by not allowing such tactics to take place without notice. It also shows that many major groups are very aware of how the game is being played.
Really, I know what I'm doing...Ohhhh, look at the shiny buttons!
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 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"
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 E-Mail to IETF MARID WG ML
All listen to the man!
It's a lot bigger of a gamble for Apache to ignore MSFT than it is for MSFT to ignore Apache.
Good point!!! Because Apache has Billions of dollars invested in their product. Whereas Windows is mainly just a free download.
Serves you right for registering 'asdf.com'
AC comments get piped to
A few good articles on sender-ID controversy:
8 ,00.asp s p 1 555212 h tml?tid=137
6 78.html
http://www.eweek.com/print_article/0,1761,a=13402
http://www.circleid.com/article/730_0_1_0_C/
http://www.eweek.com/article2/0,1759,1639880,00.a
http://www.newsforge.com/article.pl?sid=04/09/01/
http://trends.newsforge.com/14/04/08/26/1326244.s
Also, here are the opinions of Eben Moglen of FSF and Larry Rosen of OSI:
http://www.imc.org/ietf-mxcomp/mail-archive/msg03
What about us users who are behind the MS mail solutions? I have addresses on both sides of the coin and to think the Microsoft won't let me get mail because someone didn't use their patented technology is crazy....
I know they are trying to ram it through committee, but have they really thought about this? It's crazy. They already put most of my mail in the "Bulk" folder with hotmail, even if it is sent from a friend. And technology is slow to adapt, yet they've already made the announcement that they will not take mail without Sender ID after October 1st (I believe). Who here still uses HTML tags like We were supposed to drop that years ago. It still renders though.
We all hate spam but a "magic bullet" will only kill e-mail altogether IMHO. I've missed out on money actually because something gets marked as spam but I needed it for "business". Let me setup my own spam filters or let me weed through it.
Either way, I resent corporations like Microsoft and even Yahoo getting into the mix and removing me from the situation.
It's easy, don't give out your address. Don't click on links in e-mail that are so long they look like encryption keys. Don't allow images to load (easy with Thunderbird + Sygate Personal Firewall in XP and most webmail). Don't sign up for a freeipod (I want to post my referral link, so bad too.)
Get your Unix fortune now!
Firm positions like this must be applauded and upheld, but once again we also need other professionals to help get the voice out about the truth. We shall not be fanatical, but I humbly believe it is clear Microsoft is not being transparent in this and that does not bode well for the Internet as we've come to know it.
The revolution will not be televised.
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
You obivously haven't got a clue what we're all talking about or SenderID in general. Microsoft requires a license for SenderID and all covered implementations to issue at their discretion. Apache Software Foundation also didn't say it wasn't going to support IETF standards. It said it opposed Microsoft's SenderID *proposal* which IS NOT A STANDARD. Contradicting one's self is not nearly as bad as talking out one's ass, wouldn't you say?
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]
Sender-ID, and in fact any other technology that tries to "fight spam" by restricting some particular technique that spammers are using, is going to be a purely short-term solution... and not much of a solution at all.
Spam is a social problem, and the behaviour that needs to be attacked is the broadcast unsolicited messaging process itself. Any bulk or broadcast communication that the recipient is not in control of (they didn't directly solicit it, or it's not relevant mail from someone they have an ongoing and clear relationship with) has to be explicitly illegal.
Mandate Sender-ID or SPF, and spammers will sign up and continue to spam. Mandate tagging, and spammers will tag and spam *and* people who aren't spammers will be unsure and tag as well... and their mail will be filtered out.
This is already happening, in both cases.
So, it doesn't matter whether anyone implements this technology or not, it's irrelevant to the problem people are hoping it will solve.
RMS's comments to the MARID list are very pertinent and to accuse him of "politics" is to make the mistake (deliberate or otherwise) of relativism. Open source/free software is not a subjective political opinion. The effects of adopting a petent-encumbered standard go far beyond mere politics. They affect the quality and cost of what issues.
RMS is entirely accurate when he says that Microsoft's is probably aiming to control anti-spam tools by controlling who can develop to the standards.
You may or may not support Microsoft's right to attempt to control a market. What you should not do is ignore the impact such control would have.
Open source and free software has proven to be a significant balancing force in the push for better and cheaper IT. Microsoft have done an excellent job in lowering the cost of certain kinds of software, mainly the user front-ends. Open source and free software have handled the back-ends - the servers - better than anything produced by any company, anywhere.
Spam is not a front-end issue. Locking anti-spam standards into a Microsoft-dominated front-end will make much money for some people but will ultimately end in a monopoly control of email, almost certainly built to the usual Microsoft standards: pretty, charming, and totally insecure.
The IETF is composed of individuals, each with their agendas. Many IETF members work from principle, but many others are paid for their work, and paid by companies with serious commercial interests in the outcome.
It's easy to mock RMS: he is sincere and outspoken. But it is misplaced. RMS is a prophet in the true sense of the word: he has had a vision of the way software should be made, and he has defined a way for this to happen.
Naturally some commercial interests detest him. But it's wrong: cheaper software means opportunity for everyone, especially commercial software firms. The world has an endless appetite for pretty, seductive front-ends.
They just should not be doing anything really, vitally important.
And that includes filtering spam.
Sig for sale or rent. One previous user. Inquire within.
[source:http://www.anti-spamtools.org/SenderIDEmai lPolicyTool/Default.aspx]
No SPF Record has been found for the domain microsoft.com. However, MX and/or A records currently exist for this domain.
The domain's MX and A records contain the following information:
Addresses Listed in A Records
207.46.130.108
207.46.250.119
Mail Servers Listed in MX Records
maila.microsoft.com 131.107.3.124
131.107.3.125
mailb.microsoft.com 131.107.3.122
131.107.3.123
mailc.microsoft.com 131.107.3.121
131.107.3.126
I think the industry term is "eat your own dog food". thanks for the recommendation MS, let me know when you start using your own bloody system.
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.
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.
I'm a signature virus. Please copy me to your signature so I can replicate.
On the 27th of last month, the author of the Courier mail system, Sam Varshavchik, announced that Sender ID would not be supported by his MTA software due to the Microsoft patent problems, but that SPF would be. The following is a copy of that eMail.
:-)
--
The purpose of this message is to clarify my plans for any deployment of the Sender-ID specification in Courier (http://www.courier-mta.org).
Microsoft has made certain patent claims on the Sender-ID specification. Microsoft has issued the IPR disclosures and royalty free license required by the IETF. It appears that IETF's contemporary policies do not prevent the sponsor/advocates from including patented IP material into standards-track specifications, without even requiring the sponsor to actually enumerate and identify their intellectual property; a mere claim of the existence of some nebulous IP rights is sufficient, which can be revealed at any point in the future, at the sponsor's discretion.
The current development version of Courier implements the original SPF-classic specification, that predates Sender-ID. This will be rolled into a forthcoming release. I'm quite pleased with the results so far -- there are a lot of classic SPF records in existence, as witnessed by my mail logs
It will not be possible for me to implement Sender ID in Courier. Courier is licensed under the GPL. The FSF already flatly stated that Microsoft's IP license is not GPL compatible. I reviewed the most recent version of Microsoft's proposed IP license, and I've reached the same conclusion. For this reason Sender ID cannot be implemented in Courier; Courier's implementation will be limited to the unencumbered SPF-classic.
--
Sam Varshavchik
http://www.courier-mta.org