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.
From what I've seen, AOL has a large amount of respect in the Anti-Spam community.
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.
I'm not sure how someone who uses the phrase "for all intensive purposes" could be moderated insightful. It's "for all intents and purposes."
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.
Yay, one of my favourite grammar mistakes. for all intensive purposes. Not flaming (posting AC to avoid karma backlash though), trying to be informative.
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.
No I'm not. If you don't have control over the firewall or DNS then you don't have the ability to produce an SPF entry anyway.
I am assuming that if you have the technical ability to have an SPF entry then you also have the ability to setup SMTP AUTH, a VPN to your server or any other way to support remote working.
People seem to be assuming that if you don't have an SPF/Sender ID record your mail gets rejected. That's not the case in most setups, and hell, at the end of the day it's my mail server I'll configure it how I like :)
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.
Sender-ID may do that: SPF addresses the authenticity of the MAIL FROM SMTP command rather than the headers.
And if my server checks the SPF record of the domain in your 'MAIL FROM' against your IP before allowing your SMTP transaction to proceed, how exactly will you be able to fake a message from a SPF-enabled domain? Either the envelope-from is valid or your mail is dropped before you even sent it (provided the SPF-record of the domain is in order). If you set your From: header to be different from your envelope-from, that could be checked at a later time (e.g. procmail or some spam-filter). But the purpose of SPF is to make it impossible to forge the 'MAIL FROM', and if 'MAIL FROM' is correct I can always bother your admin (or the admin of your upstream) if you do something nasty.
"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.
From what I can tell, it looks like MS want their idea to be the standard, yet they also want their idea to be one that you have to pay for a license to use.
Basically having what everyone uses and getting paid for it. Plus if, as it seems, the license is incompatible with F/OSS MTAs then suddenly any non-commercial offering has a damn hard time competing with "what everyone else uses".
It's like MP3 or ISO-MPEG4. Both are, I believe, published standards. Both also require a license to use. Which is why some Linux distros have issues with supporting MP3 out of the box (trivial to fix, but still requires post-installation steps), or that XViD (at last check) would only distribute source and not binaries from their official site.
Tiggs
"120 chars should be enough for everyone..."
Their current license prohibits redistribution of any source code implementing SenderID, regardless of license. BSD vs. GPL this is not.