Apache Rejects Sender ID 351
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."
Hoody Hoo! (Score:5, Insightful)
Re:Hoody Hoo! (Score:2)
SPF has some good traction, but as far as I'm concerned, this is the death knell for SenderID.
Re:Hoody Hoo! (Score:5, Funny)
You know, you guys could have seen this one coming.
Re:Hoody Hoo! (Score:2, Funny)
you're new here, aren't you?
Re:Hoody Hoo! (Score:5, Insightful)
Re:Hoody Hoo! (Score:3, Interesting)
Re:cool (Score:3, Informative)
grep -c helps avoid unnecessary use of wc -l
Re:Hoody Hoo! (Score:4, Insightful)
Re:Hoody Hoo! (Score:5, Insightful)
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?
Re:Hoody Hoo! (Score:3, Insightful)
So? Arent there plenty of boards where people
1) Love MS or 2) Hate open source?
The internet is a big place. You could always hang out at gotdotnet or any of the thousands of MS sponsored blogs if you want to be filled with pro MS propaganda.
Re:Hoody Hoo! (Score:2)
Re:Hoody Hoo! (Score:2, Insightful)
Re:Hoody Hoo! (Score:4, Funny)
Some propagandas are more equal than others.
Re:Hoody Hoo! (Score:3, Insightful)
You don't suppose that's got anything to do with the behavior of some proprietary vendors, specifically Microsoft?
You'll note that there are numerous other major players in IT who don't get the same kind of attention. Nobody is without criticism, of course. But how much bashing does, for example, Cisco get around here despite their market position in networking gear?
Microsoft reaps what it has sown.
Re:Hoody Hoo! (Score:4, Insightful)
This is a common claim directed at Microsoft critics. There is a belief that Microsoft gets attacked because of their position. And I'm sure there is a certain degree of truth to it. However, I often see this as a dismissal to ALL Microsoft criticism - or even criticisms that individuals simply don't agree with. And that, frankly, is bunk.
I'm at a disadvantage here. I didn't read either the linked article nor the
I also occasionally disagree with some of the criticisms towards Microsoft that are voiced on Slashdot. However, that doesn't mean that all the criticisms are wrong. Nor does it mean that Microsoft is even unjustly targeted. Microsoft should be criticized for actions that deserve criticism. And there is no short supply of such actions from Microsoft.
Good start... (Score:5, Insightful)
Wishful thinking? Probably, but a boy can dream...
Good for them, but not far enough. (Score:5, Interesting)
The whole exercise has been a waste of time and attention for all involved, and the sooner it's forgotten, the better.
Re:Good for them, but not far enough. (Score:5, Insightful)
Re:Good for them, but not far enough. (Score:3, Interesting)
I was really interested in SPF for a while, but I'm tired of this shit. Like the grandparent says, it's all a big waste of time. I'm going to delete those TXT records right now...
Re:Good for them, but not far enough. (Score:5, Informative)
SPF has a great deal of value. The only problem I see with it is the envelope rewriting schemem (SRS, I think it's called) which is cumbersome. I'm expecting a) someone will fork the SPF standard, since the original introducers got in bed with MSFT and b) they'll want to introduce a transfer-of-authority protocol into SMTP rather than trying to cram everything into the FROM part of the envelope.
After that, SPF is really all you need to stop forged spam.
What a lot of people (including the grandparent) don't get is that SPF isn't designed to stop spam. SPF is designed to stop two things: forgeries and bounces of forgeries. Stopping those two, however, then makes stopping spam a much more manageable problem.
If you're looking for the panacea spam solution, you're doomed. If you're looking for the right tools to eliminate almost all of the problem, SPF should be among your first few (along with a good, flexible, multi-technology server-based filtering tool like SpamAssassin; an extremely well maintained and liberal blacklist like Spamhaus; and an easy-to-use end-user spam filter like Thunderbird's).
Forking the SPF standard (Score:3, Interesting)
SPF also has another deeply fundamental flaw - it requires the ISP to be vaguely competent. That alone is fatal for many of ISPs.
Re:Good for them, but not far enough. (Score:3, Interesting)
Records already published by 70000+ domains, including some very important ones like aol.com.
A way to guess a default record for any domain not yet publishing, that works for most existing mail servers.
Code already under development and in beta testing for all major MTAs.
Algorithm already implemented in upcoming SpamAssassin filter, which is currently in release testing
It's an inferior attempt at authentication.
Yeah, yeah, yeah... it has crypto, s
Re:Good for them, but not far enough. (Score:2)
Re:Good for them, but not far enough. (Score:3, Insightful)
SPF is only useful to end users who can be fooled by forged text headers. It was created to help stop phishing and provide some kind of reputation protection. It's ridiculous that people who should know better co-opted it as a "spam solution" and are willing to bre
Re:Good for them, but not far enough. (Score:3, Informative)
Caller ID, on the other hand, was designed to look at things like the From: header. That was designed to stop phishing more than SPF was.
Sender ID isn't one or the other, but the combination of those and some
I wish this would happen (Score:2)
It seems like ISPs are incredibly hesitant to behave this way. Maybe spam is different than other abusive network traffic, but I still haven't seen any ISPs do anything about their users' worm-infected machines attempting to propogate the infection to every other machine on the network. When I say, 'maybe spam is different,' I mean that maybe it is more of a pinch point for them and they'll ta
Re:Good for them, but not far enough. (Score:3, Insightful)
Obviously you have a beef with SPF. I seem to have missed it.
Re:Good for them, but not far enough. (Score:2)
In theory, you're right. In practice, that isn't necessarily the way it is. Many small-time domain owners have no actual control over their DNS records, and therefore no way to implement SPF. My own situation[1] is that if I wanted to use SPF, I'd have to set up my own DNS. (At least, this is my understanding from peo
Re:Good for them, but not far enough. (Score:5, Insightful)
SPF will not only stop spammers, but will stop (or at least prevent) people and worms from spoofing the from address *sent from _everywhere_* to claim to be from a user@domain they do not own. I do not want spammers or anyone to claim to be from my domain (or my legit email address even), and have angry letters accusing me of letters I did not send.
If you have your machine hacked, or running a mail relay by accident, you should have secured those equipments, and if you had anything important on it (eg. financial records), you probably have much bigger concerns, like identity theft.
Yes, I know, we are supposed to check the email headers, but most home users are completely ignorant of those features.
Re:Good for them, but not far enough. (Score:2)
Re:Good for them, but not far enough. (Score:2)
Re:Good for them, but not far enough. (Score:2)
I understand that, thus my approval of SPF. My general, all-purpose no-frills mini-rant is about the number of networks where every host (read that, potential spambot) on the network is allowed to send smtp outgoing. It's not a dig on SPF, rather a dig on networks where every windowsboxen on the network can kick spam out because of management or sysadmin incompe
Re:Good for them, but not far enough. (Score:2)
That's the point -- it's NOT coming out of your network. It's coming from someone else's network entirely beyond your control.
SPF lets you list which source networks *are* in your control, and if a message comes from somewhe
Re:Good for them, but not far enough. (Score:2)
Re:Good for them, but not far enough. (Score:3, Interesting)
The former is much harder to know, for a zillion reasons (subnets controlled by downstream entities, legit residential mailservers, etc.).
Re:Good for them, but not far enough. (Score:2)
Um, no. In that case, spam prevention would be way, way easier. Spam from spammer@yahoo.com would have to actually come from Yahoo. That would make my f*ing day.
Re:Good for them, but not far enough. (Score:2)
Nope, sorry. It benefits anyone that owns a domain that is used for mail, more so infact than it does the big operators of email services. A friend of mine is currently being Joe Jobbed on her personal domain; adding an SPF entry made a significant impact on the number of bounce messages she is getting. SPF will not really do much to stop spam; the spammers can always use disposable domains or the domain of
Re:Good for them, but not far enough. (Score:2)
Inexpensive techniques (spammer's cost) will become much less effective. Profits from spamming are likely decrease.
Virus code will be prevented from easily spoofing fake addresses, likely resulting in easier identification and cleansing (or disconnection) of infected machines.
Virus propagation speeds by email will likely be reduced when a good portion of their messages are not delivered or filtered to a junk folder.
Reduction in widespread virus infections may dimini
In case you don't follow M$'s every move like me.. (Score:5, Informative)
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.
Re:In case you don't follow M$'s every move like m (Score:3, Insightful)
isn't a bit early to be calling it a standard?
especially if apache is rejecting it.
Re:In case you don't follow M$'s every move like m (Score:3, Insightful)
Be original (Score:2, Insightful)
Patent encumbered indeed! (Score:5, Informative)
Please, click "edit this page" and help if you know anything!
MSFT doesn't care about Apache. (Score:3, Interesting)
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.
Re:MSFT doesn't care about Apache. (Score:4, Insightful)
Re:MSFT doesn't care about Apache. (Score:2)
Maybe they can get a few other big mail services (say Yahoo) and ISPs (say AOL) to get on board. Someone makes a plugin/module for Apache to implement SenderID (if its possible, I suspect it would be), that would open up new servers using it.
It will be a sell job and thats what a big company like MS is good at.
Re:MSFT doesn't care about Apache. (Score:4, Insightful)
And getting a few of the big players onboard with MS isn't going to do jack. The top dozen big ISPs are a drop in the bucket in the email system world-wide. Sure they are the biggest ISPs but that doesn't mean their userbase makes up the majority on the 'Net.
Re: (Score:2)
Re:MSFT doesn't care about Apache. (Score:5, Insightful)
Re:MSFT doesn't care about Apache. (Score:2)
The few ARE the ones who control this. If you get a few software makers (MS, Apache, Apple) and some service companies (Yahoo, AOL, Google) to accept a standard, then its going to be the standard regardless of what anyone else outside of say the dozen companies want.
I don't get a vote in which email verification gets to be the standard. How am I not the many?
Re:MSFT doesn't care about Apache. (Score:5, Funny)
Good point!!! Because Apache has Billions of dollars invested in their product. Whereas Windows is mainly just a free download.
Re:MSFT doesn't care about Apache. (Score:2, Insightful)
Look at it another way? (Score:5, Insightful)
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.)
Re:MSFT doesn't care about Apache. (Score:3, Insightful)
There are 56 Million domain names in existence [netcraft.com] (22 million of them active). 70% of these domain names are hosted with Opensource software and hence use Opensource mailservers (for the most part).
MS needs buy-in from the Opensource community or their market share will continue to slip.
Oh really? (Score:4, Insightful)
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.
Re:Oh really? (Score:2, Informative)
Re:Oh really? (Score:3, Insightful)
Some do and some don't just like everybody else. Of course, some people would argue that a strong social conscience has more to do with things like poverty, war and the like than it does with the GPL.
Re:Oh really? (Score:2)
Re:Parent is not insightful (Score:2)
So it is insightful. And you're wrong. Wrong wrong wrong. Muahahahaha.
Stick with JAMES (Score:5, Informative)
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:Stick with JAMES (Score:5, Informative)
Re:Stick with JAMES (Score:3, Informative)
"IMAP development had been stalled, but has recently attracted new activity. IMAP support is scheduled for inclusion in James v3. In the meantime, there is experimental code in the repository. If you are interested in working on or trying the IMAP prototype code, join the james-dev mailing list and let us know."
Question [slightly OT] (Score:2)
Can James integrate with SpamAssassin or something similar? Multiple domains? Forwarding?
It'd be great to find out. I'd much prefer a Java-based solution because I'd be able to put my own skills to good
We've seen this before... (Score:2, Redundant)
Yahoo!'s DomainKeys is free and technically superior, and it's not mutually exclusive with SenderID. That means it will end up all the mail-related software except Microsoft stuff. Now who's the standard?
Re:We've seen this before... (Score:3, Insightful)
I had so much hope (Score:5, Insightful)
With the rejection by Apache, hopefully the rest of the FOSS will follow and then the industry at large.
Re:I had so much hope (Score:2)
My hope is that logic will eventually win (which does not see to be the popular outcome unfortunately). The MS stuff will vanish as support for it will dwindle. Also - remember what mail servers run most of the net - sendmails...
get a free ipod! [freeipods.com] This really works... [iamit.org] 3 more invites left!
What a suprise! (Score:5, Insightful)
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.
Go Apache foundation! (Score:2, Insightful)
Re:Go Apache foundation! (Score:2)
And how is Microsoft proposing a standard considered FUD?
Encumbered Standards (Score:5, Insightful)
Re:Encumbered Standards (Score:2)
A standard is required to be available for use. If it isn't, it can't be a standard, because that's a part of what standard means. Groups that ignore this are not standards committees, no matter what they claim, and should properly be ignored except at such times
Sendmail what is your move now?? (Score:5, Interesting)
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 summed it up well (Score:5, Interesting)
All listen to the man!
Please mod parent back up (Score:5, Insightful)
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.
Re:RMS summed it up well (Score:4, Funny)
He is spot on about what M$ are up to with this issue.
Good articles on this (Score:5, Informative)
http://www.eweek.com/print_article/0,1761,a=13402
http://www.circleid.com/article/730_0_1_0_C/ [circleid.com]
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
Sender-ID may not be MS's IP (Score:4, Interesting)
Therefore, Apache maybe abandoning something that it needs not to abandon.
Re:Sender-ID may not be MS's IP (Score:2)
Media issues (Score:5, Insightful)
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.
More about power and negotiating than technology (Score:5, Interesting)
Fascinating. Absolutely fascinating.
Just the logical outcome of the RAND debate (Score:5, Interesting)
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
what about home email servers ? (Score:4, Interesting)
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]
Re:what about home email servers ? (Score:3, Informative)
With that said, all isn't lost - you simply need to set up a legit domain to host your SPF records / etc. It won't be incredibly trivial, but then it isn't supposed to be - otherwise, some spammer could simply do it also, and we're back t
Why does this matter? (Score:5, Insightful)
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.
Re:Sender-ID was never about stopping spam (Score:3, Insightful)
is about forgery. Forged spam is a use case, but there never was an illusion that this would stop spam--a spammer can simply buy a $9 domain, enter a record, and send the mail. The spammer just can't send it as user@protected.example.net
any more.
But the "Microsoft can sue SPF out of existence" piece is not correct (sorry, dude!). SPF protects part of the envelope:
the bounce address coded in the RFC 2821 MAIL-FROM;
Caller-ID/Sender-ID protect
SenderID and Patent Issues (Score:4, Interesting)
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 [spambouncer.org] 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.
nothing worse then a hypocrite (Score:5, Informative)
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.
Microsoft Patents (Score:5, Interesting)
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.
We Need An Open Source Solution To A Closed Source (Score:4, Insightful)
The majority of spam is now sent by zombied Windows PCs. Windows insecurity is now a large part of the spam problem. [eweek.com]
It sure looks like Microsoft sold PC users the problem, and now they want to sell us the solution. Should we really encourage OS insecurity by paying for the fix to a problem that never should have been?
SPF is teh win (Score:3, Insightful)
Everyone's just gonna dump Sender-ID and implement classic SPF records. This whole marid/sender-id thing is ridiculuous, and smart reasonable people know that classic SPF is unencumbered, extremely simple, and does the job just fine. This popular opinion is evidenced by how quick and widespread the adoption of classic SPF has been to date. I suspect eventually we'll see dns servers implementing a custom record type for SPF to replace the current TXT records, but other than that, you don't really need anything else.
Classic SPF = no forgeries. As it's use becomes more widespread, eventually there will come a breaking point in time where "everyone" knows that when they set up an email server and make theri MX record, they better make an SPF record while they're at it too - and most people will reject email that hasn't passed SPF checks.
It doesn't directly stop spam, but it makes spam accountable, which is a large step in the right direction.
Why does the IETF need to be told this? (Score:3, Insightful)
Finally, as developers of open source e-mail technologies, we are concerned that no company should be permitted IP rights over core Internet infrastructure. We believe the IETF needs to revamp its IPR policies to ensure that the core Internet infrastructure remain unencumbered.
Amen to that. But why did the IETF open the door to patent-encumbered, proprietary material in Internet standards in the first place? Sounds to me as though the current IETF needs to be largely replaced.
What is this? Crazy Town? (Score:4, Funny)
Apache... criticizing a bad open source license... Whaaaaaa?
For those with no idea what I'm talking about:
http://www.undeadly.org/cgi?action=article&sid=20
http://yro.slashdot.org/yro/04/02/18/215242.shtml [slashdot.org]
http://www.apache.org/licenses/GPL-compatibility [apache.org]
On a different note, it's rather funny... In another few years, the OpenBSD guys will be maintaining their own forks of every open source project out there.
Courier MTA rejects Sender ID too (Score:5, Informative)
--
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
Re:First Post! (Score:3, Insightful)
Re:First Post! (Score:5, Funny)
Serves you right for registering 'asdf.com'
Re:I don't see the problem.. (Score:5, Insightful)
Re:I don't see the problem.. (Score:3, Insightful)
Lawrence Rosen had this to say:
In other words, Microsoft's license is not co
Re:I don't see the problem.. (Score:2)
Even that isn't a strong enough requirement for many purposes, but it would allow the proposed specifications to be used if one were quite careful with the licenses that one chose. (E.g., that requirement isn't strong enough to allow GPL code to be written that was "standard conforming" by anyone except the patent holder. [Don't hold your breath.]) But it wo
What this means for the standard (Score:5, Informative)
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.