Slashdot Mirror
IETF Decides On SPF / Sender-ID issue
Zocalo writes "The MARID working group at the IETF responsible for deciding on which extensions to SMTP will be used to try and prevent spoofing of the sender has made their decision. At issue was whether Microsoft's patent encumbered Sender-ID would be eligable for inclusion in an Internet standard. An initial analysis of the text of their decision, available here with a brief analysis, would suggest not. Unless Microsoft is going to make any dramatic concessions out of desperation, that pretty much clears the way for Meng Wong's Classic SPF to become the standard and hopefully make Joe-Jobs at thing of the past."
I love it when the world has a moment of clarity and decides that Microsoft has enough damn patents and we're not going to let them run everything. Adopt the open standard that everyone can use. It makes more sense.
Microsoft shouldn't be surprised that their patent-encumbered method didn't fly. Remember the whole "burn all GIFs" campaign, when a patent made gif files possibly illegal to use? Now - imagine that mess with your email, and Microsoft holding the reins. Argh.
We've been through the whole embrace-and-extend loop with MS before, and it's nice to see the IETF understand the problems that a patent encumbered standard would produce.
Weaselmancer
rediculous.
That's not what the MARID chairs decided at all!
Depends... last I heard, sendmail was still (by far) the number one mail server on the internet. Now, if everyone else other than Microsoft went with a better, open standard and started flaggin email from Exchange as SPAM... that might put some pressure on MS to go with more open standards.
Extending HELO to include the return-path is what's needed. I wish Meng would stop jerking about with PRA and accreditation and just deliver the basic working system he promised.
Yes the ITEF can use patented standards.
On the other hand if the majority of Email servers are F/OSS, and F/OS doesn't adopt it because of the patent, it doesn't make sense to support it anyway. You suddenly appear to be in MSFT's pocket.
Being in MSFT's pocket nowadays isn't considered a good thing.
i thought once I was found, but it was only a dream.
Yes, but this does change the method finding the origionator of spam and other annoying messages. It allows an ISP to lock down a compromised system after it sends a very large volume of emails through their gateway, it allows black holes to target ip's used by spammers more efficiently, and it allows email gateways to throw away virus emails which came directly from infected system which are obviously not authorized to send for the myriad of spoofed addresses they have classically used. It is just a tool in the fight against spam and viruses, but it is a fairly powerfull first step in patching SMTP into a more trustworthy system.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
SPF Breaks Forwarding.
Yes, that's true. But what we think of as "forwarding" is really "forging". After all, if I send you an email why should you be able to re-send it to somebody pretending to be me? That's forging my name on it. If you want to forward an email, you can damn well put your name in the From: field. After all, it's from you isn't it? I certainly didn't forward it to the person. Why should the headers say I did?
The fact that we've come to rely on easy forgery for some email applications is no reason to not fix the problem. Mailing lists of course have a similar problem, but there is no reason why email from an email list shouldn't have the email list itself as the sender. It's just convention to do otherwise.
There is absolutely zero value proposition for anyone to let MS own, encumber, or otherwise threaten, by act or by fear of an act, the email standard.
They need to be kept 1000 feet away from any standards setting. Microsoft should only encounter the email standard when they send an email. Anything else is an absurdly bad idea.
If you had to bet, could you honestly bet they wouldn't exploit their license to shut out open source, or (more likely) GPL, now or (more likely) later?
I'd bet your well-cushioned ass they would.
It is hardly a conspiracy theory, when you can open any business section and read about their new patent portfolio manager or the SCO lawsuit. They play dirty, they do it in exactly this way, and everybody knows it.
Letting them taint the standard is bad for other vendors. It's bad for service providers. It's bad for users (read: most of the world's population, individuals and businesses). It's even bad for Microsoft itself.
It is absolutely absurd to have a standards war over email. But now we have to consider it.
Standards bodies may do the right thing. That's great. But what I fear now is that Microsoft will say "OK, you don't want to play our game? That's fine. Have it your way. Just don't bother sending any emails to @microsoft.com or @hotmail.com (and everywhere else we can buy or control) without a patented Caller/Sender ID record."
When they do this, we have to stand in a big line facing them, stare back, grin, and say "your loss."
Get ready...
Want to Know How to Cheat the GPL? Read On!
Such a good thought that I was thinking and spreading this idea for a time. But I had to realize I can't succeed. Why ? Because while our IT friends use GPG, nobody else does it willingly. They all say it would make their life more difficult. Most of them out there don't even know what signing is, let alone GPG. My answer to that is as always: right, complaining is easier :P
The problem all around spam is most of the users are just users. Don't understand, don't care, don't want to care. They just spread other people's viruses, spam, etc. without knowing or if knowing don't believeing they do much trouble by using crappy buggy and vulnerable sw.
If I could afford the luxury to devnull all e-mails I receive that are not signed, I would never ever get spam, that's for sure. The problem is one can't easily talk others into GPG.
They would much more easily turn into over-patented Microsoft solutions however crappy or overpatented they would be.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
Forwarding exploits a hole in SMTP.
Yes I know a lot of people use forwarding (resending a mail with the same from address as it had originally)
Forwarding is a LAME workaround for the fact that SMTP has no proper email redirection built-in.
Microsoft's patent covers checking the header-senders in a particular order. If you've been following the patent discussion you should know that there are plenty of other programs that check in other orders. If you're worried about the patent (I'm not), then just don't use Microsoft's particular order.
I'm not sure about how using a .forward file (or a procmail forwarding rule) is forging. I like to forward a copy of my mails to a web account when I'm on vacation just to make sure I can read them whether or not I have a (trusted machine with a) ssh client available (read: internet cafes). I guess it's time to change that procmail script then.
You are correct, and that's why the SPF/SenderID solutions are off target. SenderID is a bandaid designed to block zombie Windows machines while allowing 'legitimate email advertisers' (*choke*) to continue to spam. Since these solutions are designed for a specific problem, they don't get at the real source of spam.
The whole problem is that there is currently no way for a mail server to determine with certainty that the sending host is who it says it is. SPF/SenderID just tell the server that the sending host is the right one to be sending from the domain it's claiming. As far as I can see, that doesn't fight the real problem, which is forged headers.
The real answer is to fix SMTP so that forged headers don't work. That's all. Don't try to do too much or focus on a specific area of spam.
Once we know which machines are sending spam, we can take countermeasures. The countermeasures (blacklists, complaints to abuse@their.isp, quarantine, etc.) all fall into place once we know with certainty who is spamming.
sigs, as if you care.
1) Embrace (Done)
2) Extend (Pending)
3) ??? (Pending)
4) Profit (Pending)
Thanks for helping MS with Step 1. Wait for changes + patent threats in 3-5 years.
Oh, you mean like DHCP and BootP?
Yeah, that's been a REAL disaster. Encumbered by patents, not cross platform, very secretive...
Christ- I hate MS as much as the next guy, but chill out.
Please help metamoderate.
The next logical step is to require authentic SSL keys, I think. This gives the addition of an encryption, and moves authentication/authorization back to where it belongs... not in the DNS records. The extra effect is that in order to get a key to run a server like that, they have to publish more of their identity, and the companies selling keys say they check all the information provided.
The other alternative has been possible for a long time, and that's to use a web of trust built on a keyserver and require all email to be signed. This has never really gotten off the ground, though.
The best solution I could think of in a completely open fashion is to require someone to be able to recieve regular mail in order to send email. Then you have a physical address tied to the email address. Which no one is going to like, even me, because of the privacy issue. The honest truth is we can't have anonimity and not have spam. Because we have anonimity on slashdot, there are a lot of wierd things posted, but it just get's modded down. The air-tight solution is to do away with anonimity for professional messaging services, and have an "Untrusted Inbox" for everything that could be anonymous. So, if you want to be a trusted sender of email, you have to register your physical mailing address, you are sent a key, you are now responsible for every email that goes through that address, or any email address you vouch for (in case you have multiple). In the contract to be added to the list, you have to agree that you will pay something crazy like 50$/unsolicited mail that you send through the system. They sign the contract, and send it back. If you spam, you either commited two felonies (forgery and tampering with the mail) in the US, or a bill and/or a summons to court will make you liable for a pretty large sum. Of course you would have a privacy policy in the contract saying that the address is confidential between you and the user. That should make it at least palatable for professional use.
None of these methods will protect you from a virus/worm stealing your email information and sending from you. The best thing you can do for this is to have a secure operating environment, which is never gauranteed. You can at least suspend the user's email though.
Karma Clown
I agree, but there's one thing that confuses me. Elsewhere in this discussion thare are claims that Microsoft has patented the PRA algorithm, Purported Responsible Address. This reads the mail headers to figure out where the mail claims to come from. Yet the IETF decision reads:
With regard to items 3 and 4 above, it is also the opinion of the co-chairs that any attempt by the MARID working group to define any new scopes other than "mailfrom" and "pra" for the SPF syntax will at this time result in failure to find consensus within the working group.
This suggests that PRA actually is an effort which the Working Group will pursue. How can they do so if Microsoft has patented PRA with unknown terms?
I read Microsoft's Intellectual Property Disclosure. It says that the covered material is:
Both Sender ID: Authenticating E-mail <draft-ietf-marid-core-03.txt>
and Purported Responsible Address in E-mail Messages
in combination.
This does not make clear the exact scope of the PRA patent. It could just cover the one specific sequence of steps in the PRA document. Or it could cover the very idea of scanning the email to find the PRA. Or something in between.
Usually patents are written in a hierarchical manner. First you have the broadest possible claim covering the general idea of what you want to do. Then you have a series of dependent claims which expand on the earlier one(s) by providing more details about how it will work. This gives you the greatest possible coverage while allowing the patent to survive and be useful even if some of the broadest claims are invalidated.
I don't see how the IETF WG can proceed with PRA type algorithms when Microsoft has advised them that PRA is covered by a pending patent. And given that they are doing so, it certainly does not seem like they are rejecting Microsoft's approach.
Trouble is that this is a greed train run amok for people like Verisgn. $3000 fees per server (or whatever the marker will bear), etc.
You have other choices too:
(1) Encourage your hosting company to offer smtps, or switch hosting companies (they're pretty cheap these days). As SPF becomes more popular, I think hosting companies will be more aggressive about enabling secure smtp.
(2) Don't bother publishing SPF records. You won't get the protection that SPF affords, but everything will still work.
(3) Hire an SMTPS provider separate from your current hosting company.
It's your DNS server which gets hit (a very lightweight hit--one UDP request, and a reply, which is static and requires no processing), not your mail server. In most cases, depending on the recipients' configurations, your DNS server is getting hit by the receiving mail server anyway (reverse lookup), so this is not a significant increase in traffic.