Slashdot Log In
Does SPF Really Help Curtail Forged Email Headers?
Posted by
Cliff
on Fri Jun 22, 2007 05:30 PM
from the keeping-your-domain-out-of-spam-headers dept.
from the keeping-your-domain-out-of-spam-headers dept.
Intelopment asks: "My Domain name has recently been used a lot in the 'Reply' field by some inconsiderate spammer, and my ISP has suggested that I consider using the Open SPF service as a way to stop spammers from using my domain name for in their mail headers field. From what I can tell, it requires the receiving mail server to actually participate in the SPF service, which is where I have my doubts. Does anyone have any experience with this service? Does it work? Are many ISPs using Open SFP?"
Related Stories
[+]
Gmail, SPF, and Broken Email Forwarding? 300 comments
alek writes "I recently stopped getting Email from a friend ... which turns out to be related to his use of SPF records and my forwarding to gmail. This 'lost Email problem' may get worse with
Google implementing Domain Keys." Alek is looking for a non-complicated solution to this non-trivial problem; read on below for more details.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Some do (Score:3, Informative)
Re: (Score:2, Informative)
SPF breaks forwarding [woodhou.se]. It is a badly brain-damaged scheme.
A few years back it was alleged that more spam than valid e-mail was being sent using SPF. [theregister.co.uk]
SPF is bad, mkay? It should have been taken out behind the barn and put out of our misery a long time ago. Don't use it, and don't encourage it.
DomainKeys is a much smarter scheme. Use and encourage it instead.
Re: (Score:2)
Re: (Score:2)
2) Chapstick doesn't prevent spam either. Why didn't you mention that?
Re: (Score:2)
On the contrary, forwarding is Very Very useful. I have somewhere around a dozen different accounts on email servers that I don't control that forward to a couple accounts that I DO control. With so many accounts, fetchmail isn't viable (especially with "expiring" passwords to deal with) and some forwarding accounts don't even allow logins fr various reasons.
The SPF "solution" is SRS (Sender Rewriting Scheme).
Unfortunately, SRS ALSO sucks. Instead of a huge long post h
Re: (Score:2)
Re: (Score:3, Informative)
Now i run an ISP with a large number of custome
It does help, but... (Score:5, Informative)
Add SPF to your domain, and whatever subset of ISPs / mailservers that use it probably won't bug you. The only downside of using SPF is that you may have to change your DNS records if you want to use a new mailserver, but most people that I know only use one or two servers for outgoing mail for any one domain.
One DNS line to potentially stop a joejob against you - it's a no-brainer, even if you "have [your] dobuts". Go to the SPF Setup Wizard [openspf.org], fill in your servers and copy the IN TXT line.
See if it works, and proceed from there. If it doesn't, go back to the ISP and complain.
Re: (Score:2)
The main problem for me is that my outgoing mail currently goes through a server operated by my cable provider. I wonder, though, if I can get around this by setting From: to be from a different domain I have and Reply-To: to the the domain with the SPF records.
Re:It does help, but... (Score:4, Informative)
Why is this a problem? Does your cable provider not provide an SPF record? If they do, one of the variations on the SPF record ("include:") for your domain is basically a pointer to theirs.
Parent
Re: (Score:2)
Yeah I just found that in the wizard. The only problem is that the spam can still be sent from my cable providers domain, but reading the other replies it looks like this is really going to put a dent in my problem.
Re: (Score:2)
Not really. Very few site implement SPF in a way that would reject forged mail. Look, if they are not smart enough to reject outright and instead scan later and bounce (which is the cause of the collateral damage to begin with), what makes you think that YOU implementing SPF is going to help? It won't. Not one bit.
The easiest way to deal with backscatter bounce spam is to reject it. Scan for the common bounce messages,
doesn't really help (Score:2)
Now, that's all fine and good if you're willing to "include:" their SPF records... but unfortunately this steadfastly anonymous western Canadian cable ISP also happens to be one of the most prolific botnet havens in the world, so you're not really cutting down the number of people that can claim to be you by a useful amount.
Your best bet i
Re: (Score:2)
Re:It does help, but... (Score:4, Informative)
Go to the SPF wizard page, tell it what your mailservers are (even if they aren't your domain MX records) and it will tell you what to use. If your outgoing mail is set up as someguy@mycableprovider.com then you'll have to worry about them getting the records right, but if you're sending form someguy@mydomain.com you just have to worry about telling SPF which servers you send mail through.
Parent
Re: (Score:2)
Yes. I have been through the wizard and I got my SPF records set up. I will start looking for ways to integrate it with qmail now.
Some ISPs do, some don't.. but what's it cost you? (Score:5, Informative)
http://www.postmaster.aol.com/spf/ [aol.com]
Several ISPs don't.. For example, yahoo is busy pushing the competing standard of domainkeys.
Many open source spam scanners use it, ie: SpamAssassin.
However, even if not everyone supports SPF, at least some folks do, and that means if and when your domain does get forged by a spammer, there will be fewer folks receiving it, fewer mailservers accepting it and fewer bounces/complaints heading your way.
And of course, SPF is more-or-less cost free.. All you have to do is add a TXT record to your DNS, which probably won't cost you anything unless your DNS is hosted on some oddly billed 3rd party service.
I'd say the ROI on it is pretty good.
Many folks will immediately bash SPF as a poor spam control technology. Well, they're right, but that's not the point, and it's not what SPF is for, and it's not what your trying to get out of SPF.
SPF isn't a "cure-all" for spam that some folks think it is and others bash it for not being, but SPF IS a reasonable start at controlling forgery, and it's quite effective at it.
Re:Some ISPs do, some don't.. but what's it cost y (Score:3, Interesting)
It may not have a huge effect, but as a domain owner, I have had my domain 'used' a few times as the return address. It hasn't happened since I set up
Re: (Score:2)
The point is, if you exclusively use Gmail for SMTP, you should change the record to -all for better protection.
Re: (Score:2)
SPF is cost-free as long as the SPF records remain accurate for your domain. The problem is that things change, servers get moved, new websites get created, and if the SPF records aren't updated to reflect those changes, then some emails are going to go missing. A problem like that could go undetected for months, and that bears a cost.
The fact is, in larger companies the left hand doesn't alway know what the right hand is doing, while in smaller companies IT can get farmed out to multiple providers who ca
Re: (Score:2)
Yes, it's possible that all the other DNS records could get updated and just that one be ignored but it's pretty unlikely.
Having had occasion to mistype an IP in an SPF record once or twice I can assure you that it does not go undetected for month
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
"We'll provide you 50MB of webhosting for $10/month.. Oh, you wanna add another 60 bytes to your zonefile for another DNS entry.. sure thing, that'll be another $2.50/month".
SPF 30 (Score:5, Funny)
- RG>
Re: (Score:2)
drastically reduced mail server bounces (Score:5, Interesting)
I cannot be certain whether this is due to the spammer observing my implementation of SPF and no longer using my domain as a return address, or whether the spammer still uses my domain but mail servers have stopped sending me the bouncebacks.
Either way I+internet won, spammer lost.
Yes, it does work. (Score:2, Informative)
Not worth the complaints (Score:3, Interesting)
It Improves Your Fun (Score:3, Interesting)
The best part of using SPF, for me, is responding to automated mailers that send me messages saying "Your message to us failed an SPF check!" I always have great fun explaining that failing an SPF check means that they would have a better chance of reaching the person who actually sent the message by picking a random address on a random other domain.
It worked for me! (Score:4, Interesting)
I had lots of problems with my e-mail address being forged by spammers.
When I put in an SPF record, it stopped immediatly.
Re: (Score:2)
I added SPF records for my domains in the hopes that I could get maybe a 20% reduction in bounces, and I got a 100% reduction. I know that 100% of ISPs aren't checking SPF records, so I can only assume that spammers have made a point to check for SPF and not use my domains in their headers.
Re: (Score:2)
Re: (Score:2)
Please do - it costs nothing to publish, and .... (Score:4, Informative)
On the incoming side, a lot of ISPs are using it - and a great number of corporations are using it, even if they don't realize it. Spam Filter boxes like those from Barracuda (Can't recommend these guys enough), or software like SpamAssassin, can easily check SPF records. I think Barracuda's do by default, but I could be wrong - it's been a few years since we installed our Barracuda.
Granted, it's only one part of a good anti-spam system. I use SPF, DomainKeys/DKIM, SpamAssassin, and a nifty little feature of Sendmail called "greet_pause" (check it out if you use Sendmail for inbound email). It's cut down on my junk mail by an ungodly amount.
Re:Please do - it costs nothing to publish, and .. (Score:3, Interesting)
Recommend? Those bastards, their asshat defaults, and their RTFM-impaired users are responsible for some 40% of the shite in my mailbox right now (though that is unusually high, I grant you). It is NOT acceptable to bounce "back" to an innocent victim. It is NOT acceptable to advertise the piece of shit responsible in the subject header either - though I like to imagine competent sysadmins the world over vowing not to buy the product as a direct result.
If everyon
Re: (Score:2)
For what it's worth one of the updates recently disables bouncebacks triggered by SPF check. They heard that complaint from a lot of folks and finally got around to fixing it.
Re: (Score:2)
Re: (Score:2)
If they do, then the first part should be enough to show that they don't have prior business relationship with you (and are aware of this fact) and the second part shows that they are sending commercial email to you. I am not a lawyer, but it sounds like they are q
How I implemented SPF in an Exchange environment (Score:2, Interesting)
It allows me to set up a whitelist of the legitimate email addresses in my domain, and if an email tries t
Why not just try it? (Score:2)
I have it, apparently nobody notices (Score:2)
I routinely get bounce headers (for invalid destination addresses) from places where they are receiving mail which has been forged under one of the domain names I own (I happen to own over 20 domains and only about 2 or 3 of them would ever send any mail). All of the domains that I would send mail from have three IP addresses listed in the SPF records in the DNS: the fixed IP address that I get DSL supplied from Cavalier Telephone (for mail sent by my computer); the IP address of Cavalier Telephone's mail
it helps (Score:3, Informative)
For outgoing mail service:
-It becomes immediately apparent when "surprise" mail servers pop up. This can be a web server that's sending outgoing mail directly, or someone sending mail through their ISP's mail servers when they should be connecting and authenticating to your servers, etc. Tracking down mail problems in these situations can be very frustrating.
-It helps prevent forged messages claiming to be from your domain. Not all recipients support this, but even after the fact it's helpful to be able to have an answer for what can be done about it that doesn't get any blame on you.
For incoming service:
-Even a moderately strict SPF policy can help prevent bounce-spam from being sent via your servers.
-It helps protect your users from scams.
It's not a perfect solution, but it puts your network in a better defined state. And that helps keep things running smoothly.
Log data... (Score:3, Interesting)
So, someone is checking.
Consider Gmail for your Domain (Score:3, Insightful)
https://www.google.com/a/cpanel/domain/new [google.com]
I had these sorts of "Joe Jobs" against my domain for 2 years. The last straw was when I actually had a client upset at me over spam sent on my behalf from a different server. I explored a lot of different ways of stopping it, and ultimately arrived at moving my MX records to Google servers as part of the above Google Apps for your Domain. It uses SPF, and presumably Google's other tools they use to protect core Gmail users. The Joe Job emails stopped (I'd repeatedly get emails about send failures sent to me in regards to the Joe Jobs prior, and the occasional complaint). Not 1 more complaint or send failure notification.
strong authentication an important building block (Score:5, Informative)
As far as its effectiveness goes, in one analysis where we sampled a set of messages in which the purported sender's domain was that of a major ISP, we found that if the SPF authentication check returned 'softfail', the probability of the message being junk was near 100%. When we checked our MTAs "Received" headers, they indicated that the messages were being sent from IP addresses in different countries and domains (as one would expect). Of those messages that passed, only about 30% of the messages were junk. Clearly there is 'signal' in the SPF score.
Interestingly, of those messages that passed and yet were junk (those that composed the 30%), all appeared to be sent by a legitimately registered user at the ISP. This is the double-edged sword of authenticating your messages if you are an ISP: if your own user base is sending junk, other ISPs and recipients will be able to figure it out. And you might be perceived poorly.
Yet this is exactly what should happen; it's the point of authentication. There should be motivation for ISPs, either financial or brand-related (which ends up being financial), to establish and operate procedures that screen members or deter them from sending unwanted messages. Reputation (or concern of damage to it) is a great motivation.
The real promise in sender-authentication though is DKIM. While SPF is easier to implement for senders than DKIM, SPF is rather fragile; it doesn't survive forwarding without re-writing the envelope-from. Too few systems are set up to do this (list management software is the exception), and although changing the behavior of MTAs is just software, doing so will effect the efficiency of status (bounced mail) reporting. Messages that would be delivered 'point to point' in the past end up being 'source routed' with many unnecessary hops, increasing the odds of failure. DKIM is a little more involved to set up, but doesn't have these fragility issues (setting up checks when receiving is about the same level of difficulty for SPF and DKIM).
At Boxbe, we check both DKIM and SPF. The reason is that strong sender identity gives a pre-approval policy its teeth. We quarantine messages which fail EITHER form of authentication, but because DKIM is "forward-friendly" and SPF is not, if a message passes a DKIM check but fails an SPF check, we let the message pass (according to our member's preferences). Using both has merit as each type is a little different. Gmail has been signing/authenticating with both DKIM and SPF for quite some time. We also use both forms of authentication when we send out messages or forward messages to our members.
As other organizations adopt sender authentication (Comcast has announced [emailexperience.org] it is implementing DKIM by year end) it will become a very effective tool.
--
Thede Loder
E: thede@boxbe.com
SPF and DNS amplification (Score:3, Insightful)
1) People typically don't have a good idea of all of the IPs that originate email for their domain. Sometimes they are overly restrictive, causing blocks to their legitimate mail. Sometimes they're overly permissive and indicate that lots of the internet can email as them. This is like having a firewall with policies that unintentionally permit and/or block traffic.
2) SPF is a pretty poorly designed framework. RFC4408 is almost comical in how many times it says "You should never do this, it's terrible. Here's how to do it..." If the designers realized what a bad idea the PTR check is, why did they include it? I now have thousands of useless reverse DNS queries per second, sent only because someone didn't understand what they were talking about and didn't read the author's warnings.
3) Finally, TXT records make for a fabulous DoS attack tool. Since they are typically larger than other RRs, adding TXT records to your DNS reflection attacks can amplify the amount of generated traffic with very little effort on the part of the attacker. Interesting paper on this at http://www.isotf.org/news/DNS-Amplification-Attac
So all in all, I say that the payoff is very little for high costs. If you are going to publish an SPF record, and you aren't 110% sure what you are doing and what you want, just publish "v=spf1 ?all" and get on with doing better things.
Re: (Score:2)
Since we're on the subject... I think the system could use a -1 metadiscussion moderation to boot.
Re:AOL DOES NOT SUPPORT SPF in a way that will hel (Score:2)
FYI - see my post above regarding Barracuda's SPF bouncebacks, that's been taken care of recently.