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."
Why is that the spammers actually supporting this ? Does this give them more targeted email addresses ?
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.
Question: Is the IETF allowed to adopt patent-encumbered standards? I mean, wouldn't that grant some sort of monopoly license in effect for MS, seeing as if you want to adopt a standard, you need to pay somebody? Shouldn't standards be free, and people can make money off the implementation of said standards? I don't know how these things work, nor am I a lawyer of any capacity.
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.
This worries me more than it makes me excited. I have several email addresses that I send mail from home through ISP. I don't believe they are going to put those domains in thier DNS list.
In the case I guess the only option will to be use webmail for any addresses not provided by my ISP. That's a pain...
"Luke, I am your node.parent();"
MS will not take this without fighting back. I suspect they will hint that they may have issues with SPF as well, maybe in a years time or so.
Fucking S/W patents. If these had been available 20 years ago the NET would never have been born.
These people are just selfish. They build their bisinesses on the NET backbone, given to them for free and then do everything possible to destroy the vehicle that built it.
Human nature?
SPF Breaks Forwarding.
Yes I know about SRS. (sender rewriting scheme)
SRS is a LAME workaround for the fact that SPF breaks forwarding.
They caved and send they'd implement Sender-ID.
1 44 2237&tid=111&tid=109
It makes Apache and FSFlook good as they
proved resistance isn't futile.
http://it.slashdot.org/article.pl?sid=04/02/24/
When Microsoft ships their method on all their mail servers and mail clients, will it matter that it is not a sanctioned standard?
Where law ends, tyranny begins -- William Pitt
combatting spam. It's about being able to verify that the envelope sender is actually authorized to send mail for the domain in the envelope. That is all.
HAND.
I already sent a mail to the company that hosts the DNS A records for my domains (also my DNS registrar) asking when I'll be able to add an SPF record.
The one feature of Sender-ID that I'd like to see in SPF is checking the header-sender as well as the SMTP-sender. Of course this is expensive, requiring reception of the message body, but it's worth it.
It occurred to me recently that I could write a separate milter to implement just this one check. It would compare the SMTP-sender against the header-sender, and if they don't match then it would add a header to the message saying "possibly forged". A later step in the delivery process, such as bogofilter, would see this header and weigh it appropriately.
I'm interested in comments on this idea.
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!
Patents are always a monopoly.
That said, the answer seems to be no. The IETF can adopt a patent-encumbered method as a standard.
As you can see here, there appear to be quite a number of patents which may or may not relate to IETF standards. And you can see that in these cases, it appears that the IETF demands that the patent is licensed on "fair, reasonable and non-discriminatory terms".. whatever that means.
I'm now seeing 30-40 bounceback emails a day originally sent from people spoofing my vanity domain - I haven't given any accounts out, of course. Makes me wonder how many of their emails got through to their victims, as these are just some of the failures. The most annoying part for me is that I see them come in batches - with very different originating IPs and to different mail servers for each message - so I don't know if it's a pack of zombies and my domain is one of the ones in rotation, picked out of someone's address book, or if someone is doing a deliberate joe-job on me.
This ought to be considered actionable as a DOS attack - if companies start filtering out my domain name, I can't apply for jobs with them, for example. And if my upstream ever gets tired of explaining to idiots to read their headers instead of thinking it's me, then I'll have to hunt for another provider. Even without those reasons, it still takes me time every day to clean out my admin box so I can get my real mail. In fact, because I'm the only person at my vanity domain, and it's part of my online identity, it also ought to be considered slander for someone to pretend to be from my domain, because they're effectively claiming I'm sending these ads, etc.
I hope SPF becomes generally accepted, and soon. I'm afraid it won't, though, because there are millions of people running old copies of MS Exchange, etc., and they probably won't want to pay to upgrade or take the performance hit to authenticate messages this way. Still, if I go ahead and stick the DNS entries in, it might at least prevent some of the damage.
Get off my launchpad!
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.
Unfortunately, that's what's covered by Microsoft's patent.
Really.
Microsoft want to patent going through a header to see who the message claims to have been sent by - the "Purported Responsible Address" - aka the PRA.
Take a look at the algorithm they are trying to patent and ask yourself how many times you've done this yourself when trying to figure out where mail came from.
It's like trying to patent an algorithm to find the author of a book: 1) look for a name on the cover 2) look for a name on the spine 3) look for a name in the copyright declaration 4) if you've found it, there you go! 5) if you haven't, too bad.
How can they expect to be taken seriously?
That's not what you'll be thinking when a Joe Jobber effectively slashdots your server: you'll say No to a few people at first before your server melts down.
Besides, this would require a fair amount of stateful information on your mail server- what do you think you should do, store a message digest of each message you send? If so, how long do you store it? When do you get rid of it- first time it's asked for? What if no one ever asks for it (probable, given the adoption lag)? What if the mail is delayed several hours for various reasons? It's a rather complicating feature.
The World Wide Web is dying. Soon, we shall have only the Internet.
If your system asks the sending *server*, this is redundant, as you already know the sending server sent it, by definition.
If your system asks the domain that the mail is supposedly from, then you may as well be using SPF, as it saves on network traffic and gets you the same answer.
And in follow up to the parent's post, I want to ask:
So... what, if they did publish the patent, they could decide to include it in a standard? Seeing the patent doesn't prevent the patent owner from taking advantage of it, does it? (In fact, seeing the patent makes it easier to be sued for infringement.) Or am I missing something here?
404555974007725459910684486621289147856453481154 in hex is "You sank my Battleship?"
[GPG key in journal]
Who would control or gives out the signatures? What or who would be available to get a these signatures and how would a spammer not get one. There are certificate based methods already in place that many people already use, problem is it costs money and configuration that people are not going to spend. Free/open versions of PGP already exist and are in use but again, no restrictions to prevent the bad people from using it. Your idea would help verify who sent a message but not limit who you could get them from.
Bad boys rape our young girls but Violet gives willingly.
3. On the issue of ignoring patent claims, the working group has at least rough consensus that the patent claims should not be ignored. Additionally, there is at least rough consensus that the participants of the working group cannot accurately describe the specific claims of the patent application. This stems from the fact that the patent application is not publicly available. Given this, it is the opinion of the co-chairs that MARID should not undertake work on alternate algorithms reasonably thought to be covered by the patent application. We do feel that future changes regarding the patent claim or its associated license could significantly change the consensus of the working group, and at such a time it would be appropriate to consider new work of this type.
Look closely. The wording to pay close attention to is "This stems from the fact that the patent application is not publicly available. Given this, it is the opinion of the co-chairs that MARID should not undertake work on alternate algorithms reasonably thought to be covered by the patent application.".
In other words, we don't know what the patent is, so we shouldn't waste time doing any work an anything that might infringe it. That's significantly different to saying that the original patent-encumbered work won't be accepted, in fact the wording has been very carefuly picked to remain non-committal on that point.
Next, look at an extract from point 4 of the summary: ...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.
4.
In other words, not only the should the committee not waste its time until all the patent claims are made public, but neither should anybody else try submitting new things until the committee knows what's happening with the current proposals.
I read the summary as a glorified "we can't know what to do as not all claims have been made public, so we'll just put everything off until the claims are fully known". Neither backing for, nor rejection of Sender-ID. And certainly nothing whatsoever about falling back purely onto SPF.
Cheers,
Ian
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.
Yakov Shafranovich, the former co-chair of the Anti Spam Research Group (ASRG), has written an excellent dissection of the history of Sender ID, published on the CircleID website. Part 1 Part 2
Opera Watch - An Opera browser blog.
#1. No, it would not look up your ISP's SPF record. It would look up the SPF record of the domain you claimed to be sending from. If that SPF record included the mail servers from your ISP, it would be fine.
#2. What happens when the SPF record does not exist or does not match is entirely up to the implementation.
Example: SpamAssassin
I can set the rule to add 20 (or any other number) if the SPF doesn't match.
I can set the rule to add 1 (or any other number) if there is not SPF.
It all depends upon which system you use to check the SPF and what the capabilities of that system are.
That's great to hear that you did even that much. I have no doubts that companies could implement SPF even with MS Exchange, but it will take work. And if you think back to how long it took your company to decide to set up that XWall, it will probably seem obvious that many companies, especially small ones, won't bother.
I'm really worried that MS will just include Sender-ID as part of their next server releases, or worse yet offer service packs for prior versions, and when/if companies upgrade or patch, they'll think Sender-ID is what they want because they got it "free." Since you said you're too lazy to see if XWall supports SPF, if a service pack for your exchange version came out, and enabled Sender-ID, would you just run with it? That's what I'm talking about.
These arguments others have about most email servers not being MS-related are feeble, in my opinion, because they do seem to be the largest player in the corporate email market, and that's where the important email goes. Spoofers (at least the ones I've been seeing bounced mails from) connect directly to destination mail servers, they don't use their ISPs as MTAs. So what ISPs might run is not relevant to them.
Get off my launchpad!
Yes, it's an issue. When I first set up my mail server about six years ago, the default configuration was to bounce unknown local addresses back to the sender. As I was only getting a few pieces of unwanted email a week that wasn't a big deal.
... but unfortunately about ten thousand spams a week were being bounced back to their senders by the server and my ISP figured that I was spamming!. Oops.
Then three weeks ago my ISP shuts off my SMTP access, no warning, no explanation. Now, as it happens my server runs all incoming mail through three or four RBLs, also uses SpamAssassin, has a Bayesian filter system and I use Thunderbird. So after all that filtering I really didn't see much spam in my Inbox
The higher the technology, the sharper that two-edged sword.
Doesn't matter what you're running (i.e. old versions of Exchange). For the old-Exchange-org, for their outgoing mail all they have to do is put the TXT records in their DNS. Doesn't matter what their mailer is. For incoming (to use SPF to check incoming mail) all they have to do is have a front-end mail relay in front of their exchange server which deals with the filtering before passing mail onto Exchange -- which they should do anyway, only a nutter exposes an old version of Exchange directly on the internet.
Oolite: Elite-like game. For Mac, Linux and Windows
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.
Forwarding is wrong. Always has been. Re-mailing is what should be done in the majority of cases. Mailing lists won't have any problem because the mailing list itself can be the return address, thus not invoking an SPF lookup on the poster herself. Private forwarding is the big issue (e.g. like bigfoot.com) and in these cases SRS and backtracking can be used.
Now do you a constructive suggestion of an alternative to SPF that both supports the kind of forwarding you want to do, and still informs those who participate that no mail server but mine (or which I say) are valid for sending mail addressed as from my domains?
now we need to go OSS in diesel cars
That's probably because you shouldn't be bouncing mail like that. If the local address is unknown or the message triggers a spam filter, the mailserver should respond with a 500-series SMTP error (probably 550). Note: this only works on machines receiving SMTP connections directly from the world. If you know there's another machine between you and the world (eg. external server receives mail, queues it and then passes it along to a second machine that runs the spam filters and delivers the mail to mailboxes), SMTP errors cause other problems.
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.
It's not over for Microsoft's efforts...though it's very close to being over. The important section that points this out -- with highlighted text -- is below;
They aren't saying that the Microsoft patent (or any patent) is bad...they are saying that it can't be publically reviewed or is not clear enough to make a decision.
This does give Microsoft some wiggle room if they want to 'clarify' what they mean...and in the course of that, possibly elminate the problems they originally introduced.
Microsoft has a choice to either correct the mistakes (by 'clarifying' them) or what they contributed with patent encumberences will not be accepted.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
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.
I understand that SenderID and other proposals basically want to make sure that the user is a real user, but:
Doesn't this put a strain on the REAL system?
Let's say that a SPAM system uses my email address to send out 50000+ emails to the world. That means that my system will get hit with 50000+ requests to validate whether the server sending is really in a Mail Group.
So on top of all of the ACTUAL work my system is doing, it now has to support all the SPAM systems that want to use my email address on their system.
This works great for the AOL, Microsoft, etc, but what about the single server mail systems like mine. I support my own email server on my DSL.
What about all the email sent as spam that refers to linux.org or openoffice.org that already handle alot of ACTUAL mail through the domains.
Now it has to put up with all the SPAM messages requests to see if their real as well.
Why not setup the SPAM filters at the Mail Reciept layer, and return a 5nn message saying SPAM is not excepted at this domain.
They get paid per the actual receieved email. If everyone is killing their delivery before it is received then they don't get paid.
Am I missing something here?
Scott Carr
First off, the co-chairs message is so murky and confusing that about a half dozen of us have asked for clarifications about what the heck they are saying.
Far from ruling against MS, it appears to me that the co-chairs have give the green light to advance the patent encumbered PRA algorithm and they are saying that the IETF working group will not consider any replacement for the PRA since it might infringe on MS's patent.
Within a matter of seconds after Chuck first posted this story, I told him I thought he had gotten it totally wrong. Chuck agreed that the jig many not be up, reworded the very end of the story (RTFA) and sent email to the co-chairs. To the best of my knowledge, the co-chairs have not responded to any of us who have asked for clarification.
SPF support for most open source mail servers can be found at libspf2.
domainkeys
It allows the edge mail servers to sign an email, and it does not break email like SPF does.
Whatever happened to the idea that the Internet was a community of peers? I mean, my web browser doesn't care if the web site is registered with DNS or not. I can go to 125.10.233.5 as easily as I can go to linux.com. Likewise, my mail client doesn't care about DNS records. That used to be an optional part of the whole.
:(
Looks like the days when every machine was a peer on the Internet is gone in favor of the day when every machine must register with a superpeer (like DNS) to be considered a valid endpoint.
Kinda sucks, if you ask me, to fight spam by ruining the best part of the Internet, ESPECIALLY WHEN THERE ARE BETTER ALTERNATIVES OUT THERE! Look at IM2000 or any similar idea. These would work just as well without requiring me to lose my status as valid endpoint and without me being forced to register with a superpeer, like DNS.
-Tom
1. Will it solve spam? Well, it was announced with the statement "Spam as a technical problem is solved by SPF." but -- despite the lack of a full public retraction of that statement, we're now told it was never intended to solve spam. Fine...but let's note that if it didn't claim to have something do with spam, few people, if any, would care about it.
2. Will it solve forgeries? No. There are still a myriad of ways forgeries can be constructed -- and many of those will pass SPF checks, because they utilize the outbound mail servers as unforged mail. (And while you might think that the people running those mail servers would detect and correct this...you'd be wrong. They've built up multi-year track records demonstrating that they either don't know or don't care -- so it's unlikely they'll wake up tomorrow feeling differently.)
3. Will it stop bounces from forgeries? Maybe. But it's important to note that it doesn't stop them by actually FIXING the broken mail systems which are generating them. This is a brittle approach to solving the problem which has as its only merit that it may be easier than tackling the core issue. But experience strongly suggests that it would be much better for the long-term health of the Internet's mail system to roll up our sleeves and actually deal with the bounce-vs-reject issue than find a way to sweep it under the carpet.
4. Will it stop joe-jobs? Maybe -- if enough people use it, if spammers don't game it (and they're already working on it) and if it doesn't impose its own consequences. (Consider what will happen to your DNS servers if some spammer decides to joe-job your domain and N mail servers out there -- instead of just rejecting the traffic and being done with it -- all try to verify your SPF records simultaneously.)
5. Does it solve an important problem? No. Forgery isn't a serious problem -- spam is.
6. Does it solve the problem thoroughly? No. Really solving mail forgery requires secure DNS, public-key encryption of message content, secure end-user systems, secure mail clients, and other components. These all exist, but until they're ubiquitous, any sense that the mail forgery problem is "solved" is illusory.
Despite all this, there are a few good ideas in SPF, and in DomainKeys, and in some of the other proposals which are out there. But those ideas need to be weighed in light of the environment in which we find ourselves, and take into account:
- Millions of hijacked systems
- Cheap "throwaway" domains
- "Bulletproof" hosting
- Rapidly-updating DNS (which just got worse)
- non-SMTP methods of sending spam
- poorly-maintained mail gateways
- Scalability (SMTP, DNS, etc.) concerns
among other things. For example, a much better (and far simpler) proposal that could be implemented immediately with minimal impact is: here. Of course, this doesn't solve everything either, nor does it claim to: but what it does tackle, it handles very well. Backers of SPF/DomainKeys/etc. would be well-advised to take a long look at it.Now Microsoft says they have applied for a patent on reading the headers on an email to determine -- what? Who sent the mail! Could the writers of the RFC 822 have ever imagined that the headers on an email might be used for something so non-obvious -- so brilliant -- as determining the email address, including the domain name, of the person/entity that sent the email?
And Microsoft doesn't even have to be granted this amazing patent to throw the MARID working group into a tailspin. They only have to mention that they've applied for it...