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."
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
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"
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)
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.
Could someone please point me to a brief explanation of what Sender ID gives you that SPF doesn't. I thought they both just allowed you to verify that the "From" header line is consistent with the IP that the mail originates from.
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
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.
I don't get any say over the policies, so none of your "solutions" work. If you want to use SPF to block, that's fine, I'm just pointing out there are cases where legitimate email can only originate at non-SPF Ok'd MTAs. I wouldn't block using SPF, I'd tag, except tagging doesn't stop the costs of spam.
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
Come back when you know how SMTP works. I can set any domain in the from address when I connect to your SMTP server. You have three options: use the SPF records of that domain to block or tag the email, or do nothing.
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.
Yeah, the "moderators" should of noticed that. If they had, probably they all of the sudden would have changed their minds about moderating. I have a deep-seeded hatred for such errors, they make me loose my mind. However, moderators do have free reign.
However, attacking the intended payload due to presentation issues (inability use a pat phrase correctly) is a classic Logical Fallacy. Some people spend so little time with authoratitive written material that the correct forms may never have been seen, and only the spoken version encountered.
FP.
Also FatPhil on SoylentNews, id 863
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.
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?
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 :)
... just in time for halloween! :D
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.
Can anyone explain to a non-sys admin how sender-id will work, or a link to a noddy explanation
Nothing costs nothing
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!!
+4 Insightful?
I'd have thought this might make 'Funny' by the admittedly lenient comedic standards of this forum, but... insightful!?
Oh lordy!
http://www.imc.org/ietf-mxcomp/mail-archive/msg051 35.html
It appears that my predictions are coming true. Meng, MS and the IETF shut down the MARID WG so that they could more easily push the patent encumbered SenderID through. They no longer have to deal with a WG last call.
Expect more steps to happen after IETF-61 when the individual drafts will be "reviewed".
SPF support for most open source mail servers can be found at libspf2.
I have a question about this:
what about people like me who use my domain address for sending mail? I send my mail via horde at the domain, via Yahoo! Mail interface, via Opera M2 with my email (not return) address set to my domain address and even sometimes at mail2web.
Yahoo would use Yahoo SMTP servers, Opera would use my ISPs and only Horde would use the real mail.domain.com IMAP server. If they unblocked ISP STMP servers for this sort of thing... wouldn't that just defeat the purpose? Because they're used for more than just @isp email addresses.
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.
> Come back when you know how SMTP works. I can set any domain in the from address when I connect to your SMTP server. You have three options: use the SPF records of that domain to block or tag the email, or do nothing.
So, you can block mail that comes from a 'not authorized to send' smtp server, you can tag it (for exampel for usage by a spam filter later on) or do nothing..
In none of those cases you tag spam, in 2 of those cases you deal with the forged sender issue, and in the 3rd you do nothing.
What again was your argument?
> 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.
And yet you used the phrase "should of."
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.
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.
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.
Not to mention "they all of the sudden" and "loose my mind" (why, was it too tight?)
PRA is a side issue, it derives from the message header and so cannot be trusted since it could be faked.
Can I suggest this approach to handle relayed mail:
It doesn't matter if a message from A to B goes via C.
When you accept messages from 'C' and the header says its relayed mail, it is either:
1. A known blacklisted spammer relay.
2. An unknown relay in which case content filtering is used.
3. A relay that implements SPF itself and so messages from it can be treated as already having passed the SPF check.
Determining 3 isn't as difficult as you might guess. You can promote a relay server from 2 to 3 if you never receive spam with a faked origin, from it.
Since the whole point of SPF is to reduce the number of content checks, reducing the filtering load and improving the reliability, this is a reasonable strategy.
There's a dozen other companties that support microsoft.
You can see a list here
Funny thing to see AOL is not in that list.
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..."
SPF/etc doesn't really do anything specific as far as spammers go (that is, it doesn't treat spammers as some special case, and spammers by themselves aren't going to be disproportionally encumbered by this technology), and it doesn't preventing anyone from simply forging addresses (that is, using an address in the From line that doesn't map back to the spammer.) What it does do is prevent someone from using a From address whose domain belongs to someone else without that owner's permission.
The intent is to deal with "Joe Jobs", by ensuring that a domain name owner has the final say over any emails sent out whose From envelope address contains that domain name.
Now, some people are associating this with spam, on the grounds that some spammers send out emails with unauthorized email addresses as the From line. This, I suspect, is being done purely because it's easier than registering a domain. However, registering domain names isn't difficult or particularly expensive, so that spam is simply going to start coming from new domains rather than disappear.
To give you some idea of how ineffectual this is in terms of stopping spam, I registered a new domain for myself last week. Within fifteen minutes of me going to register.com, entering the credit card number, and accepting everything, the domain was live. That is, there was a DNS server under my control pointing at it, and my work DNS (completely unrelated to the DNS server I attached the domain to) was resolving the name correctly. If I were a spammer, I would have been able to start sending out spam under a non-blacklisted domain within fifteen minutes of me registering the domain.
The real major (positive) impact this will have is on certain types of virus. There are many viruses that work on the basis of sending out emails that look like they come from trusted friends (by searching, for example, an address book and sending emails from the owner of the address book, or sending them from addresses in the address book.) SPF has the potential to make that close to impossible.
The downside, of course, is that the technology isn't completely transparent. Roaming (where you use multiple ISPs but want to use one email address) becomes difficult if your choice of email address is from an ISP that uses SPF, and which doesn't have a suitable relay server available for you to send outgoing email via - and suitable can just mean that your email software doesn't support whichever of the myriad of authenticated SMTP systems your ISP uses.
You are not alone. This is not normal. None of this is normal.
Old tribal wisdom says that when you discover you are riding a dead horse, the best strategy is to dismount. Businesses, however, often try other strategies. These include...
1. Buying a stronger whip.
2. Changing riders.
3. Saying things like "This is the way we always have ridden this horse"
4. Appointing a committee to study the horse.
5. Arranging to visit other sites to see how they ride dead horses.
6. Increasing the standards to ride dead horses.
7. Appointing a tiger team to revive the dead horse.
8. Creating a training session to increase our riding ability.
9. Comparing the state of dead horses in today's environment.
10. Change the requirements declaring that "This horse is not dead".
11. Hire contractors to ride the dead horse.
12. Harnessing several dead horses together for increased speed.
13. Declaring that "No horse is too dead to beat."
14. Providing additional funding to increase the horse's performance.
15. Do a CA Study to see if contractors can ride it cheaper.
16. Purchase a product to make dead horses run faster.
17. Declare the horse is now "better, faster and cheaper."
18. Form a quality circle to find uses for dead horses.
19. Revisit the performance requirements for horses.
20. Say this horse was procured with cost as an independent variable.
21. Promote the dead horse to a supervisory position.