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...
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.
MSFT does need to care about open source and other mail servers. They are a small fish in a big sea when it comes to mail systems.
Evolution or ID?
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'm glad that a major OSS project has seen through the FUD and is speaking out on behalf of the community. I seem to have lost my faith in humanity, but events like this start to restore it.
Ads? What ads?
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.
"People that quote themselves in their signatures bother me" - athakur999
If you do not like spam, please stop spamming slashdot.
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.
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.
OK I'll bite. I fail to see how SPF only helps the big ISPs. Any little guy (running a domain) can publish his own SPF record. Any little guy (running a mail server) can check against existing SPF records. Checking against an SPF record will weed out (or at least certainly reduce) SPAM with forged source addresses (or make it harder to forge an acceptable address). Trackable SPAM is a definite improvement over the current state of affairs.
Obviously you have a beef with SPF. I seem to have missed it. So where's the beef?
You are horribly wrong, and I will bite. I had my email address 'spoofed' by the W32.Netsky worm a while back, and it was sent from a machine that is not of the domain of my address. An SPF enabled mail server would reject emails with spoofed headers, and so my friends (victims) will not see the infected email with *my* email address. On the other hand, non-SPF enabled mail servers will accept it, and my friends sees it, and accuses me of sending them a 'virus'.
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.
Please direct all bug reports to
industry standard?
isn't a bit early to be calling it a standard?
especially if apache is rejecting it.
for a minute there, i lost myself...
Not only that, but as the world's predominant web server, Apache has a fair bit of clout with the IETF.
M$
Correct. It's not a standard at all but a proposal. Hopefully SenderID never becomes a standard. Wong should be slapped shitless for ever agreeing to couple SPF with CallerID. What a stupid move to make.
i doubt your claim of technically superior. if i remember DomainKeys work on the headers, which means you have to send the whole mail first (thus anihilating any sort of bandwidth reducing abilities, which spf does not suffer from)
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.
SPF doesn't tell admins a damn thing they didn't know before. Admins do not pay attention to header addresses when determining the source of spam, they look at the IP addresses, which are not truly being forged (not in the same sense, anyway).
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 break legitimate uses of SMTP to see it adopted, without seeming to even reale the leverage it hands big ISPs.
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.
There are 56 Million domain names in existence (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.
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?
Lawrence Rosen had this to say:
In other words, Microsoft's license is not compatible with Open Source. Open source projects are not allowed to re-distribute the license to end users, unless they obtain a special license from Microsoft. If Apache did this, then you downloaded the Apache product and gave a copy to a friend, you would be infringing on Microsoft's patent because you don't have permission from Microsoft to sublicense their patent. Clearly this creates a completely unworkable situation with respect to Open Source software. Only authorized sites (authorized by Microsoft) would be allowed to distribute software which includes this IP. But, you are correct -- the license is 'royalty-free'. Just understand what strings are attached, and under which circumstances you may end up in jail, or paying huge fines...This puts way too much power in the hands of a single company, given that email is a piece of core internet infrastructure. This isn't even proven technology yet, but for some reason there is this rush to get this through the IETF.
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.
Sendmail has to make money so supporting Sender ID is a good thing for them. They are packaging it as a seperate download so as to not encumber their main product with Sender ID's problems. This is how real vendors should deal with real problems.
The majority of spam is now sent by zombied Windows PCs. Windows insecurity is now a large part of the spam problem.
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?
>> My ultraviolent Linux switch video.
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.
11*43+456^2
I have my own domain and I pay a 3rd party, EasyDNS, to handle my DNS. They support SPF... I just type some info into a textbox in the web-based management console and it works! If your DNS provider doesn't support SPF then they probably aren't very tech savvy... and that isn't an attribute I'd like in a DNS provider.
This is all about stopping forgery of the From: for domains that have registered their Sender-ID or SPF records. Spammers can still register a domain with authorization for any or all mail servers that they want, and continue sending out spam from zombied systems to their blackened and smoking hearts' content. They can continue to send spam for any other domains that allow forgery, like for alumni accounts or other drop box domains.
Sender-ID is only designed to stop phish-ing emails. So if you get an email from citibank.com, you can be reasonably sure it came from somebody at citibank.com, and not some guy's home pc, as long as citibank.com set up their records appropriately. That's all.
BTW, the reason the IETF is considering Sender-ID over SPF, is because it is highly probable that Microsoft can sue SPF out of existence.
This isn't meant to stop spam. This has nothing to do with stopping spam.
Everyone is entitled to his own opinions, but not his own facts.
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.