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."
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.
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.
You forgot [at least] one:
5. You can just add an SPF record for your IP address and you're set.
And a falsehood:
SPF doesn't tag spam, and has nothing to do with it. It just makes it impossible to fake a sender address from a domain with proper SPF records.
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.
Q2: Doesn't having a patent on Sender ID complicate the process of getting it adopted as an IETF standard? A: No. It should not. There are dozens and dozens of patent rights that have been disclosed to the IETF that may cover IETF standards. See http://www.ietf.org/ipr.html for a complete list. We are not aware of any of these patents complicating the standards process especially where the patent owner has provided an assurance that it would make licenses available on a royalty-free basis with other reasonable and non-discriminatory terms and conditions as Microsoft has done here.
Nothing costs nothing
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.
"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.