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."
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
The reason they, and the rest of the IETF rejected the original Sender ID proposal was because it seemed to go out on its own track with no regard for other schemes that do similar work. To have incorporated and accepted Sender ID at that time would have meant that other ideas like SPF would have been left by the wayside and Microsoft's vision of email would be dominant.
That whole thing was rejected, thankfully.
Now, Microsoft seems to have actually taken a look at the concerns surrounding their original proposal and formulated a new Sender ID scheme that is inclusive of other existing schemes such as SPF. AOL put a lot of effort in developing this kind of technology and now Microsoft's proposal finally includes them too.
What it sounds like from the Yahoo article is that Microsoft's Sender ID is at best a superset of all authentication schemes and at worst a compatible, though competing, technology. Neither of those are bad things. I think AOL realizes this for what it is, Microsoft actually trying to do something useful to help the ailing email system.
The Sender ID scheme seems to allow for further developments that may or may not be based on Microsoft technology but still be fully compatible nonetheless.
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.
SenderID is Microsoft's name for its patent-encumbered variation on SPF.
Too bad spammers will just start registering domains and using them semi-legitimately.
The real point of SPF and Sender ID is to make it hard for spammers to forge their "from" addresses, so that blacklists and whitelists can be more effective. Adoption or lack of adoption by spammers doesn't really have much impact on the success of SPF.
Find free books.
What are you talking about? Why is that relevant? Didn't you see "Microsoft" in the article summary? And, as if that wasn't a clear enough message what to think, it also said "AOL." Sender ID is bad bad bad. Not only won't it work, it represents the most insidious kind of fascism. An open source solution would obviously be better, and more liberating.
Slashdot.... Fuck yeah!
Matt Daemon.
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
From what I've seen, AOL has a large amount of respect in the Anti-Spam community.
Let me first expand on my original statement. Wall Street does not look highly upon AOL: they dramatically overpaid for Netscape, a division that is, for all intensive purposes, dead; they were involved in one of the most under-reported merger scams of the past decade (Time Warner, a long-profitable company was, many believe, duped); and their growth prospects are extremely limited. They've proved their inability to display original content, and the slow atrophy of their user-base has begun.
The user community, too, has a seemingly endless list of complains--those who remember their growth problems (myself included), the constant busy-signals, buggy and bloated software, high prices, and extremely poor technical support--they place the blame soley with AOL, regardless of who is at fault.
But you argue that the anti-spam community respects AOL? I would disagree. True, they've pursued legal action against several high-profile spammers, but I would normally expect far more from a company with legal abilities such as theirs. They've acted in their own interest, and not in the interest of their users (not surprising, of course, as their obligation is to the shareholder, and not the consumer).
AOL could have, and indeed should have done more; they, however, have remained largely apathetic.
An effective signature identifies a particular user amongst a base of thousands.
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"
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)
For many months now, I've published SPF records for all domains under my management. And every day, we get AOL trying to bounce messages allegedly from non-existant addresses within those domains... If AOL were really using SPF to reject spoofed mail as it arrives at their gateways as they've said they were going to, they'd have never accepted the spoofed messages, and I'd knock about 3% off my server load...
What utter tosh.
Just because you can't use SNTP AUTH because of a firewall don't try to dictate how everyone else should use SPF.
Perhaps we could call it Microsoft ID instead? Why fluff it up with a name, call it as it is. The government gives us social security numbers so they can know who we and track us.. why not let Microsoft have the same power?... um.. because!!
iSnack 2.0 - Download it now to your iToast 9.0
AOL is their own little world.
And... that is bad how?!?!
Do you really want them little tiny-tot AOLers coming at you?
It seems you've been leading two lives, Mr. Finch. In one life, you're a nice Slashdotter, with excellent Karma who even M2Ms reguarly. In another life, you're an AOL user. You use AIM, chat with 14 y.o. with teenage girls and help your landlord find his pr0n.
One of these lives has a future, one of them does not.
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.
From Netwizard's Blog:
The FTC and NIST are holding a joint summit on email authentication in two weeks in Washington, DC (during the same week as IETF's 61st conference). They hinted earlier this year that if the industry does not come up with a standard for authentication, the feds might impose one.
Could the FTC actually do this? I wasn't aware that they had any authority over internet standards. The internet isn't some corporation, or the sole property of any business, even if some companies wish it were.
Think about the consequences of that. Even if Microsoft follows through on its promise to make the license available "for free" to anybody, it means that if you buy a Microsoft mailer or a mailer from a sublicensee, you can just install it and run it. If you install an "open source" mailer, however, your legal department needs to execute a licensing agreement with Microsoft's legal department. The costs and delays resulting from that alone make the "open source" mailer uncompetitive, no matter how much better it may be than Microsoft's products.
That is why the official open source definition does not allow such patents: if software implements such a patented invention and requires a licensing agreement with Microsoft, that software simply is not "open source", even if it it is distributed under the text of an open source license--the existence of the patent and licensing requirement makes it not open source.
Sender ID is just SPF on steroids. E.g.: SPF points out the systems which can be used to send E-mail from a given domain while sender ID adds an additional algorithm (the PRA) which verifies if a given E-mail forwarded by mailing lists, .forward files, or relays (to name a few examples) is legitumate. Mailing list hosts may not have permission to send E-mails from your host, but they can specifically tell who they are and that they are just forwarding agents, thus making themselves responsible for the message and leaving you (the receiver) with an option to block E-mail coming from a particular forwarding domain (e.g.: the mailing list's domain) or from a particular sender domain.
In other words: the sender ID allows you to do almost everything you always did with your MTA but adds some authentication to the process. SPF alone would limit you to a single host or network, or force you to clearly specify which addresses could forward messages from your domain, which is not practical if you are using your ISP's domain to communicate with the Linux Kernel Mailing List, for example. Sender ID addresses this limitation.
Ok, my previous post is rather confusing, so I'll try to rewrite it.
When you send a message from the authenticated host A to host B there may be forwarding agents (such as mailing lists, relays, etc.) routing your message, the message is not always direcly sent from host A to host B. With SPF you would be limited to that. You would have to mention (for example) all mailing lists in whom you are subscribed, which is not practical if you are not controlling the domain from where you send your messages. Sender ID addresses this limitation with PRA, an algorithm that computes the last responsible token, which may or may not be the sender MTA, thus allowing messages to be routed the same way they always have been.
For more information about the PRA algorithm, check this PDF. I am sorry for my last post. Should use the preview button more often. Please do NOT mod my last post up.
If you connect to me I do a bunch of dnsBL checks. If you pass those then I'll do an SPF lookup. If, in your case, you don't have an SPF record then the mail goes though (to spam assassin). If you fail an SPF check because you're "spoofing" a from address for a domain which has valid SPF lookups then you get rejected.
Your cases where your MTA has no SPF has no effect, the mail gets passed through because you did not fail. I'm not blocking on a "must pass", that would be insane. So why is blocking like this bad in your eyes? You seem to think that people only tag, wrong. People reject on *fails*. A domain which does not have an SPF record is not a fail.
I want to first say that I am one of hte last people to jump to the defense of AOL.
:)
That's hardly an insightful comment.
18 million users means you care a heck a lot more about the impact of spam than pretty much any other network in the world.
And if you write your own little hacked up mail tool (like I have, to send legitimate, solicited email, not spam, heck, not even advertising) and start hitting AOL with bad SMTP envelopes, you're going to find them sending back 550's with a url.
I wish I could remember the url, but it dictates their "friendly mailer" policy. You don't follow this policy, you don't get to send AOL's users email.
To get them to let you send email again, you must call them and have a little chat with an email administrator. It's not a nice chat. It's a "don't fuck up again" chat. Thankfully, my boss made that call for me.
I've managed to trip up several large e-mail hosts like Yahoo and Hotmail, but AOL's is by far, the most draconian. Personally, I applaud it. I'd be overjoyed to get an email account with those kinds of practices, that I don't have to administer myself. I just can't stand the rest of the service. Perhaps my intentions were good, but I'm the exception to the rule as far as people who write these kinds of mailers go. I imagine that phone call rarely gets exercised.
This is how it was about a year and a half ago. I don't know how it is today.
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.
DomainKeys is a much better proposal, using DNS to publish public keys and then signing a hash of the message with the servers private key before sending. The client then looks up the public key via DNS and can verify the senders domain.
It was covered on Slashdot a little while ago, under the heading that GMail has started to use DomainKeys. Link.
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.
"Friendly mailer"? That's a laugh.
AOL (and their properties) is the single worst email provider on the planet. They routinely drop email and often bounce legitimate email. They may claim they prevent 10 million quadrillion spams or something, but I'd guess that a good percentage (though not a majority or anything) are legitmate emails falling victim to their "policies".
They use their large size to bully people around, like they did to you. If some small ISP was bouncing your mails for the same reason, would you have begged to get off their bounce list? AOL blocks mail from large swaths of IP space because they "might" be sending spam. Heck, I have RoadRunner (which is an AOL property), and I can't even send mail to other RoadRunner users because as a RoadRunner user I'm probably sending spam!
I've had AOL bounce emails because I PGP signed them, which IMO is the best form of "sender-ID" there is (and anyone serious about getting rid of spam would support this, but very few actually do, probably because it would mean taking responsibility for the problem). But according to AOL, it's probably spam, so it got bounced! (in this case, it was a user setting to bounce mail with attachments, but shame on AOL for not realizing what a PGP signature was and allowing/endorsing it)
AOL's policies are not conducive to a good Internet neighbor. AOL and their arrogant policies have always been bad for the Internet. Anything that AOL endorses automatically raises my suspicion. Nevermind the fact that as the OP stated, AOL popularized the idea of spam with their mass mailings and selling of email addresses (way back in the day before they realized what a bad idea that was).
If you really want your personal email account to be like AOL, just setup a procmail filter that deletes/bounces half your mail.
"Save the whales, feed the hungry, free the mallocs" -- author unknown
Vendors are always issuing press releases that they're "submitting" or "resubmitting" something to IETF. As far as IETF is concerned, this means exactly nothing. Anybody can submit an internet-draft on any topic related to Internet protocols, and it has exactly the same effect as if Microsoft does so. Just because you submit a draft doesn't mean that anybody is going to look at it. In this case, there isn't even an open working group to consider the topic. So the significance of Microsoft resubmitting a SenderID draft to IETF is minimal at best.