Slashdot Mirror
Sender-ID Back From The Dead
NW writes "Microsoft's Sender-ID standard has been left for the dead since the rejection earlier this fall by the IETF. According to a Reuters story, it has been revised and will be resubmitted to the IETF. Along the way, Microsoft managed to pick up AOL's endorsement of Sender-ID. My humble analysis appears here."
Sender ID rocks, if its implemented properly. Too bad spammers will just start registering domains and using them semi-legitimately.
Cemil.
Being that AOL's marketing strategy is based somewhat on spam (the cds you get in the mail, the "Sign up for AOL" icons that appear on your desktop), doesn't that kind of hurt the legitimacy of that endorsement? I dunno, if the guys offering me home loans and viagra said this was good technology, I might think twice.
If we have learned nothing from watching AOL feast on Netscape's corpse it's that there are LOTS of execs at AOL with radically different ideas about ways to do things, and they change their mind on a weekly basis. Exert a modest bit of pressure and they can be made to bend over like the fitty cent whores they are.
AOL is certainly not a highly respected corporation, especially in the tech-world. They've agreed to ally themselves with Microsoft for this particular issue, but until some other notable corporations or organizations (particlarly Yahoo!, Google, and Apache) accept sender-ID as a "standard," there's no way it will make any difference in the fight against spam.
An effective signature identifies a particular user amongst a base of thousands.
With AOL using this standard, Microsoft gets a huge chunk of marketshare for it.
Microsoft has one goal in all of this: To lock Open Source out of a standard, and then launch FUD campaigns about how Open Source refuses to support Sender-ID (because MS will charge an insane fee for licenses, but MS won't mention this) and thus helps spammers.
"You spoony bard!" -Tellah
Sender ID is flawed in that it fails to address the issue of the inherent insecurities in an unsecured content delivery system. Truly the only way to kill unsolicted drops is a system requiring authentication based on individual originators as opposed a location-based system that ignores the fundamental problem of having such an open-ended system.
Even if this is somehow accepted, it will make little diffence as its effectiveness will prove worthless in actual implementation. I project that this will become a moot point after the election, and even less so by the middle of the 2010's.
You can't make a standard anymore if you hold a patent and are unwilling to grant a free license. Submarine tactics are just too popular these days. Fool me once, shame on you. Fool me 20 times, shame on me. Nobody buys into this "don't worry, we're just defending ourselves" crap anymore. They all start out that way, but without a real license we can use, it's just an empty promise.
This is actually irrelevent. The problem is not with the technical details but the legalities. So long as there is a patented technology included without a universal right to use for any purpose, the proposal stinks and needs to be kicked in the head.
_O_
.|< The named which can be named is not the true named
Unfortunately for Microsoft many IT decision makers refuse to even weigh the merits of this idea before discounting it.
SenderID is not perfect, but if a more 'neutral' company like Sun, Apple, Google, etc introduced it, it would have at least been given a fair shot.
Instead of saying "SenderID is bad because of XXX and, by the way, M$FT Blows" they would be saying "SenderID is bad because of XXX but here's how it could be made better"
PRA appears to me to have been written because MUAs (as opposed to MTAs) do not consistently deal with envelope addresses, MAIL FROM, and the resulting Return-Path header. It adds complexity to the outgoing MUA to make sure that the PRA is the same as the envelope from. The incoming MUA will have to follow the PRA algorithm to figure out who's responsible for the mail, rather than just make the Return-Path accessible for spam filtering. The overall feeling is that the designers assumed people couldn't understand how to deal with the return path, so they replaced it with something more complicated and broken.
It's nonsense to think that something should be a standard if the implementors can't implement it. If the patent issues have been removed (say by dropping the absurd requirements, or by the patent office rejecting the patent), then great. But it's not reasonable to try to use a standards body to prevent alternative implementations. The whole purpose of a standards body is to define standard interfaces that everyone can implement. Since there are many important open source software implementations of these interfaces (in this case for MTAs), then the standards need to be implementable by open source software. If not, then the IETF should just send it right back; nothing important has changed. The problem is legal, not technical, and it requires a change in legal situation.
- David A. Wheeler (see my Secure Programming HOWTO)
And so Microsoft has a golden oportunity. They can help reduce costly spam incoming to their networks (corporate, hotmail, msn, etc.). They can help reduce one of the most popular vectors for malware that has a negative effect on adoption of their software. AND they can pull off a major warm-and-fuzzy PR move to counter the expanding cadre of IT types who have come to distrust, if not lothe them.
What do they do? Play licensing shennanigans.
Sketpicism is very much justified.
It maybe a good solution but isnt the whole point of email that its globally compatible with open standards. Yes that may have been the failings of smtp/standard email delivery with the massive increase in spam. But realistically having a patent based email system inhibits the majority of email on the internet.
I personally dont know of any ISPs that use exchange as thier ISPs platform. the only large scale internet exchange setup that I know of is hotmail...
So in microsoft and aol trying to adopt this system whats going to happen to email in the future?
Nobody should have patents on core protocols and mechanisms of the Internet. It's just likely to end up becoming a cash cow.
Someone at Microsoft already stated they liked the idea of email stamps, paying a nominal charge per email.
Sender-ID is not Microsoft's. Sender-ID is SPF with a patent encumbered (and useless) technology known as PRA. Here is my speculation. Microsoft has been trying to (and successfully has it appears) the SPF vehicle to use for their own purposes, which is to compete with Yahoo's Domain Keys. Props to Yahoo for at least a decent and aptly named technology. Microsoft's competetive *cough* copy cat *cough* technology is called "Email Postmarks". The continued association of electronic mail with real mail is disturbing -- as is Microsoft's use of "CallerID for E-mail". Man they really know how to label those projects so absolute fucking morons can understand... oh wait, thats right, thats most MS lusers... MS wants to shove this postmarks crap down your throat and Verislime wants to sell you certificates for this. The idea being that in order for mail from your server to be respected you'll need to buy a certificate. If you have one, then people won't reject your e-mail. What a novel idea! They are trying to do to SMTP what Verislime did to HTTPS.
How on earth I can reference anything insightful when slashdot signatures are limited to 120 characters?!
> What reason would Apache have to do anything with Sender-ID?
Perhaps because of SpamAssassin?
Quoting ASF:
Since SpamAssassin is not limited to only one MTA and its purpose is to filter spam, the Apache Software Foundation needs to ensure proper domain validation is performed.
This isn't that hard to do. sender-id, spf, etc, does nothing. We already know most semi-legitimate spammers are publishing SPF records on their throwaway domains which takes care of the other 10% of spam...
Fix this properly. Declare it within the law to assassinate anyone who sends a piece of spam. Then merely wait.