Slashdot Mirror
SPF Design Frozen
Eric S. Smith writes "SPF, previously mentioned here, is a step closer to becoming a real, live RFC. We are encouraged to publish SPF records and thus to hasten the beginning of the end for annoying spam forgeries. SPF describes DNS TXT records that define the hosts authorized to send mail on behalf of users in your domain. Sites can then consult your SPF records and reject spam forged to look like it comes from you." (SPF stands for "Sender Permitted From.")
I've always wondered how a spam filter system based on authorization might work. Your mail server could automatically send out a verification request to the email address that sent the email, then if the email address exists, an authorization would be sent back to your mail server. All mails that weren't confirmed by a returned authorization could be automatically deleted. This way, you could only get mail from active email addresses. Could cut down on email spoofing because anyone spamming you would have to use a real email address which would allow you to complain to the domain owner. Of course, all mail servers in the world would have to be upgraded to this new protocall for it to work, or everything would be considered spam.
Does any of this make sense?
You're right, I wouldn't steal a car. But if it were possible, I sure as hell would download one!
This is a great idea. I'm all in favor of it. I would update my companies DNS to this new standard immediately. But, I envision these issues, correct me if I'm wrong:
1) Increased network traffic at all points - where one mail server gets the email, and the network of the domain being sent from or forged. Imagine how this might increase AOL's or hotmail's network traffic, while they gain nothing from it. Every mail server in the world could be trying to contact their dns servers to check if they allow the mail. I hope you like lag if you use AOL.
2) Spammers tend to use made up domains anyways. This is bad with this method for several reasons. The first being that you will have delayed email receiving times because your mail server will be trying to contact dns servers that don't exist. The timeout would have to be short for this to work.... then on the other hand, if the timeout is too short, and a busy mail server can't respond in time, the email is rejected, which is just as bad as a real email getting flagged as spam, aka a false positive.
While I agree in practice with this technology, I'd like to see how people can solve these issues before I would use it at my company.
Your points are both invalid.
1) Most mail servers already to a return DNS lookup on the IP of who the sender is. (The recived from lines in the headers) DNS takes so little bandwidth compared to normal activity (even compared to the payload of the email it is tiny, not consider all the web browsing, DNS is trivial)
2)DNS works by asking the root servers who owns a domain. The root servers respond either with the DNS for the domain, or with a no such domain. (Ever hear of Verisign's sitefinder? Verisign runs the root servers, and they started saying anything unowned belonged to them) Essentially no overhead is involved in this.
I know I'm going to put the SPF records in as soon as I get a chance, but these statistics aren't terribly optimistic so far:
http://www.infinitepenguins.net/SPF/register.php
This system serves to monitor the take-up of SPF. So far, 274 domains with SPF records are known.
As yet, only a count of registered domains is displayed; more analysis tools will appear once the number of domains increases.
Of these:
84 parse cleanly
0 parse with warnings
173 parse with errors
17 are yet to be checked by this system
Imagine how this might increase AOL's or hotmail's network traffic, while they gain nothing from it.
Well, they do gain, actually -- if the plan works, it will blot out quite a lot of spam. AOL and Hotmail spend an astronomical amount of money dealing with spam in the current situation (it doesn't help that lots of spammers forge AOL or hotmail return addresses... I'm sure those bounces crank out the bandwidth required). If they need to pay for more bandwidth and more servers to support SPF, I have to imagine that will be much cheaper than the manpower they have to support to fight the problem now.
Besides, how much extra bandwidth is really involved? Wouldn't it work like other DNS records, and be cached all over the place?
I don't know enough about the technology to properly address your second point... but I think because we're dealing with DNS servers here (instead of needing to contact the mail servers) this may actually work out. Sure, some people run mail servers from home, etc., but DNS is usually provided free by an ISP; there are also free DNS hosts.
Either way, I'm rooting for it. Spam is killing email.
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
Okay, I am not trolling here, I'm serious. This plan will be moderately successful at preventing joe-jobs on unwitting victims. If you control the DNS for a domain, you can say who is allowed to send mail for that domain. Therefore, if a spammer attempts uses your domain in the "From:" header then it will only be delivered to those hosts that are NOT checking the SPF records. That's an important distinction, because getting everybody on the planet to do something is very hard, so this will never completely wipe out the possibility of joe-jobs. And there are the possible negative effects here, for example employees not being able to send company email while on the road without hassle.
But that aside, how does it reduce spam? The spammers will always be able to find a domain to stick in the "From:" header. They can choose to use a domain that they do not control that has not yet added SPF to their DNS or they can choose to use a domain that they control. In either case it's trivial for them to get their mail from their system to yours, and that's all that they really care about anyway -- the "From:" header has always been meaningless to spammers anyway, it's not like they would be forfeiting the ability to receive replies or something.
Note that in the case of using a domain that they don't control, we're back to the issue of "until everyone on the planet does this, there will always be some domain somewhere that can be forged." And even should those run out, spammers can just register anything for $7 a year, or less for bulk registrations. (They already do this when they're playing hosting tricks, to bounce you around from one host to another.)
Now, you might say that at least with this implemented you could discover what those domains are that the spammer is registering for use with his spamming. That is true. But, we've had the concept of a blocklist for ages, that's nothing new. Everyone has ranges of IP addresses that they won't accept mail from, and some very kind organizations have even maintained lists of "bad IP addresses", so you might expect a similar thing to happen with domain names. But all you have to do is look at the current state of blocklists and you'll know this doesn't buy you much. We already have blocklists, and they're riddled with problems. You're back to playing whack-a-mole with the spammers. They make a spam run with example.com, you block example.com; they make another run with example.org, you block example.org. You're always one step behind, while the spam piles up in your inbox. You might make the point that this inconveniences them, but you have to realize how many domains there are out there that are available for forging. The SPF-protected domains will be the vast minority of all domains for the forseeable future.
So, in summary: This might be moderately effective at preventing joe-jobs. It will not make a significant change, however, until everyone on the face of the earth that's not a spammer both updates their DNS and updates their MTA software to check these records. The likelyhood of this happening any time soon is quite small. And even if this were to happen, the spammers would still be able to deliver piles and piles of garbage to your inbox though domains that they control. You're back to blocklisting, which we've had for quite some time now.
So, I ask seriously, what does this do to combat spam that is really all that significant? I applaud any developments on the antispam frontier, but let's not get too carried away with visions of this somehow "plugging the insecure SMTP hole", or anything remotely resembling it.
From a security standpoint, this is a dumb idea. Really dumb. It's stupid, open to a ton of attacks, and does diddly about spam. However, it's probably going to get some popularity for the following reasons:
* Folks hate spam, and will glom onto anything that claims to reduce it with the gullibility of a cancer victim being scammed by a faith healer.
* It's easy for IT folks to implement. The CIO can say that he "implemented an initiative to reduce the most frequent user complaint, saving the company N dollars". He doesn't give a damn about whether he actually *accomplishes* anything, just whether it looks good.
* SPF is a pet project of someone. Obviously not someone who's a security person, but someone.
* There's money in it for consultants. The firewall craze made many many people very much money. The promise of a *new* even less useful system that can be used to pry money from companies is quite appealing.
Things that *could* reasonably be done to combat spam:
* Limit email amplification.
* Require one of a number of pay or auth systems for email.
* Whitelisting
* Allowing clients to publish rules to mail servers (so that a client whitelist, for instance, would allow a server to avoid soaking up any bandwidth at all...this would be a useful set of IMAP extensions).
Frankly, unless a bunch of engineers get together and put out a *useful* RFC (i.e. not this crap) a la PNG, there's probably going to be an industry consortium that decides what to do. And standards committes have an awfully low rate of getting-it-right.
May we never see th
Some people here have complained that this might not work because everyone on the planet would need to use it and even then spammers could use their own domains.
Certainly it's true that nearly everyone will need to get on board for this to work. Fortunately, it should be an easy update on both the MTA and DNS ends.
The real advantage here, I think, is that it will make filtering and blacklisting much easier. Instead of trying to filter on 18 zillion weird rules and scads of IP addresses, some of which may have some valid users, you just need to filter on domain names.
For this to work, we will need one or more trustworthy registries of bad domain names. And it should probably be distributed, with a way to continually update it by automatically propagating the list of bad domains to all clients. There should be a way to get a domain into the blacklist very quickly if anyone receives spam from that domain.
Alternatively, a system could be in place to treat all new domains as bad by default. That has obvious problems though -- how would you get your domain trusted? Would it require a VeriSign like identification process? I would oppose that -- I think people should be able to buy domains and freely run email servers on them without paying some central "authority."
My biggest concern with this idea is that I run a domain where I give out POP email addresses to people. I'm still trying to figure out how that will affect me.
If they couldn't get consensus inside the IRTF's spam working group, what makes them think they can get it in the IETF community at large (I love the note to the RFC editor - HA)
I have mod points and I am not afraid to use them
That's it. That's really it, at least for publishing your permissions. So simple I already did it for my domains.
The registry was only actually completed today; the parser wasn't fully operational before that (it was just online for testing).
Unfortunately some of you caught the parser while it was buggy... it *should* be fine now.
It's also correct that some of the records were produced before the standard was finalised. All these bugs should now be out of the system (I'm going to regret saying that)...