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.")
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.
And then it occured to me that spammers would probably find some devious way to use this feature to generate lists of valid email addresses. Rather than sending a zillion emails based on a dictionary attack, they could send a zillion emails to known good addresses.
Unless all the email servers in the world worked on the new protocol all the servers with the validation functionality would be MORE vunerable to spam and not less.
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
Are you suggesting this in concert with SPF? If not, then spammers would just forge the mail as being from a valid address.
What you describe sounds sort of like a challenge-response system (http://tmda.net), but more automated. The trouble with that is the same trouble with VRFY. That is, it can be used to determine whether an address is valid or not for future spam attacks. That's called RCPT harvesting.
My brother runs thille.com using sendmail and he didn't disable VRFY. Nearly all the accounts on there got harvested and we started getting tons of spam. I run thille.org (on qmail) and haven't had that trouble.
Since robert@thille.com forwards to my mail server, I just setup TMDA on the address it forwards to.
I've also had trouble with being 'joe-jobbed', where someone sent spam, and forged the 'From:' (and probably the envelope as well) as from me. I got lots of bounces, but luckily no hate mail. SPF would help with that.
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
SPF is all well and good if you intend to have all of your users send mail through your short list of approved hosts. Some places can swing this. Good for them.
I have run a vanity domain for myself and a handful of friends from high school since the mid 90s. They use their vanity accounts to get mail, since it forwards to wherever they happen to be now. I want them to be able to send mail as those accounts, but SPF won't let that happen.
The SPF-approved answer is "have them relay through you with something like authenticated SMTP". Yeah, right. I'm not about to open up a bunch of extra crap on my mail server for a handful of people who run around and do stuff all over the world at times.
With SPF, I either cut a huge hole for my entire domain for every network one of my friends happens to inhabit, or I screw all of them by limiting it to my own personal network. There's no middle ground, and it puts me in a bad spot.
I'd much rather say user A is allowed to send mail from network A, user B from network B, and so on. That would let my friends send mail from a few designated places without any trouble. For the true globetrotters, I'd just disable all network restrictions on their address at the expense of possible spoofing.
Everyone seems to be hung up on things like SPF because it uses DNS, so they don't have to write a new protocol, servers, or clients. That makes it very tempting, and that's why this article is here.
> Come on, sell me on this
Assuming SPF is successful, there would be less need for manually-created "residential" IP lists that ban you. It would all be automatically handled by your DNS provider. (However, this put an anti-spam burden on DynDNS etc)
So this is the way out for you.