Slashdot Mirror
Are You Using SPF Records?
gravyface writes "I've been setting up proper Sender Policy Framework records for all my clients for past year or so, hoping to either maintain or improve their 'reputation' in the email universe. However, there's a lot of IT admins I speak with who either haven't heard of SPF records or haven't bothered setting them up. How many of you are using SPF records for your mail domains? Does it help? How many anti-spam vendors out there use SPF records as part of their 'scorecard'?"
SPF is harmful.
it has cut down tremendously on the spam claiming to be from my domains.
any other benefit I am unaware of.
If I could walk that way I wouldnt need cologne.
And yet none of these solutions will actually do very much good at all. This was all hashed over several years ago. SPF, DomainKeys and so forth are little more than feel-good half-measures. If the sole reason you're using any of them is so that Google doesn't reject your email, then I think that's pretty much demonstrated the worthlessness of them.
The world's burning. Moped Jesus spotted on I50. Details at 11.
Four years ago, I got hit by a Joe-job, i.e. some spammer used my domain in the 'From' field. I deleted the thousands of resulting messages in the following days and then didn't think about it anymore.
Two years ago, I shut down my mail server and moved it to Google Apps. Basically it involves creating a Google Apps account which tells you to point your domain its MX (mail exchange) records to GMail. The second, optional, step was to add SPF records. I thought about the Joe-job. Since the GMail wizard is good and explains everything, I just executed that step. It's actually really simple.
Anyone else have this experience? I.e. creating SPF records was too easy to just skip it?
8 of 13 people found this answer helpful. Did you?
Some spam filters score on SPF. So not having SPF increases chance of false positives for your legitimate mail when you don't have SPF. And since SPF is free and painless to implement (just few DNS records) I don't see any reason not to use it. Also not like it is something that much significant either.
Where is logic in that?
Two facts:
- you use SPF for own domains
- your shool's Zimbra installation scores mails from your domains as spam
Based on above facts how have you come to conclusion that SPF doesn't work in general? The fact that your school's Zimbra scores your mail as spam is just a single cases and most probably not related to SPF in general.
Have you looked at headers of these message marked as spam? Have you contacted the postmaster?
I don't use them personally and we have very few customers at my current job that will request them.
I used to work for an anti-spam company and the request would come in from time to time to have SPF checking built into our appliances. As developers, we did see the benefit of it. But at the time, there was the SPF vs SenderID vs Domain Keys battle going on. Who would win out?
As it appears years later, no one really did.
The problem with the technology is adoption rates. Unfortunately, many of these technologies are not being adopted by the masses. I'm not saying its hurting you by having these in place, but it also might not be doing as much good as you think that it is.
If you aren't using SPF, you aren't doing your job. I've become merciless in my dealings with other sites who don't use SPF, or even worse publish incorrect SPF.
I also use SPF records for all my domains, most are simply: "v=spf1 a mx -all". "-all" as in hard fail. I don't know why there is a soft fail "~all" option, if it's not from a known host / IP, it should fail. What's the point in returning an unknown response? Like as if there was no SPF record in the first place? It's amazing how many domains actually use soft fail. Anyone know why? They only help stop backscatter and other IPs from sending emails from @youdomain.com as long as the other mail server does a SPF lookup. We have become dependant on the email protocol and the way it works, pitty it's in such a mess :( Damn you SPAMBOTS!!!
Pretty much the same here - SPF records aren't particularly hard to implement, after all. On the receiving side, I just check for SPF failure (i.e. somebody e-mailing from somewhere other than the domain's SPF-registered mail server), and even those just get sent to users' junk mail folders. I'm certainly not bouncing anything because of them. Based on my mail server reports, it looks like the low SPF filtering is catching about 0.5% of the mail volume that flows my direction, which isn't much, but it's 0.5% less than I would be dealing with otherwise and was implemented "for free", so I'm not complaining.
Not just to add a 'me too' but I recently removed SPF completely - mostly because other people couldn't get their entries correct, or just completely failed to update it when they add in extra servers. Legitimate messages were hitting our spam folders. Since I can't train our fine worker drones to actually look in their spam, I opted just to remove it. With greylisting and spamassassin its removal hasn't made any noticeable difference aside from the false positives now being delivered properly.
I agree. The only point at which SPF or DKIM comes into play is the last few percentage points of filtering and even then other measures can suffice. For instance, I use a Barracuda Spam Firewall and out of the box it catches probably 80% with no false positives. Train the Bayesian filter and pick up easily another 10%. For my use, I can do some TLD blocking without worry such as CN, BR, and RU to name a few and I pick up additional percentage points. A few Regex for things like Viagra and Rolex net me a few more points. Doing a little header blocking for things like XMailer: The Bat and I am down to around 1% spam or less.
Doing things like NOT white-listing your own domain work just as well as SPF or DKIM if you implement quarantining. When you put email handling rules into play like Junk or Spam boxes and allow a per user quarantine with personalized Bayesian settings you can really knock the junk down to virtually nothing.
I think the thing here to take into account is that things like DKIM and SPF are not major solutions to spam. They can help reduce a point or two on percentages depending on your overall configuration, but they are nowhere near global solutions within your enterprise.
Yes, I use SPF to identify the MX's of three domains I own, and Yes I use SPF as one of the things SpamAssassin uses for identifying spam. Granted these domains are tiny in the grand scheme of things (one is for family, one for some shareware I wrote, and one for a non-profit my brother is involved in), but it definitely helps. I wrote a script that sends me monthly stats of spam, and here are the results for the last month:
sa score : 1 messages :299 :194 :235 :299 :477 :597
sa score : 2 messages
sa score : 3 messages
sa score : 4 messages
sa score : 5 messages
sa score : 6 messages
sa score > 10 messages : 31678
highest sa score = 57
total probable spam (sa score of 5 or more) : 32752
total spam blocked outright by sa : 37110
e-mail blocked via SPF : 3007
Unique IP's that passed SPF check : 1389
We only block spam if the SpamAssassin score is above 10, but we tag anything above 5 as spam so the end users can decide what to do with it. As far as SPF goes, in the last month over 3000 bogus e-mails were dropped due to SPF failures, and 1389 other e-mails that were accepted were approved in part because the domains had SPF records that passed the check.
I didn't used to use SPF records for my domains. I always felt that it was a pretty half-assed way to prevent forged spam from my domain since it required the admins of other mail servers to enable SPF checking in the first place.
Then I started getting a ton of backscatter in my inbox. Just out of the blue, some spammer had decided to start using my domain name for cialis spam and next thing I know, my inbox is flooded with rejected messages bouncing back to me. I set up SPF as kind of a desperation play more than anything else and the backscatter disappeared almost overnight. I'm sure someone out there is still receiving spam which appears to be sent from my domain, but the volume of backscatter I'm getting isn't even a tenth of what it once was. SPF is good for something.
...No, we do not use or publish SPF records in any way. Spamassassin assigns a score of zero to the SPF_PASS rule for incoming email.
Every 6-12 months or so, someone asks why. The reasons have not changed in the several years that I've been here:
* For a large, non-centralized research institution like ours, any SPF record we could conceivably come up with would have to be permissive to the point of rendering it useless. We have countless departments, nearly a hundred thousand users, and they all have their clients (both on and off campus) configured about a hundred different ways. Some relay through our servers, some through their ISPs (either by choice or due to a heavy-handed ISP filtering policy that restricts outbound SMTP on TCP/25 and/or TCP/587), some through departmental servers, some through sendmail running on their own workstations (damn you, CS faculty). The work necessary to construct, publish, and maintain an SPF record for our purposes has been deemed not worth the effort.
* SPF has been embraced widely by spammers, perhaps more so than legitimate institutions. This alone keeps us from assigning any stock to SPF records when making delivery decisions on our own incoming mail.
We have yet to encounter any notable issues getting our mail delivered to the "big boys" like Hotmail, Google, Yahoo, etc. based on our lack of SPF kool-aid consumption.
I'll second that. Y! defers everybody, it's just a fact of life. But I send about 2 million emails a day to the big-5 and don't use DKIM. I hope we don't end up having to, b/c it sounds like a real PITA.
U.S. War Crimes blog. Email for free Mandriva support.
I run a server farm somewhere between a /14 and a /17.
All authorized mail servers have SPF records. Ranges that clearly have no legitimate business sending email are clearly identified with XXX-XXX-XXX-XXX.dynamic.TLD and listed with SpamHaus's PBL.
No servers have DKIM/DK. The software to do so is opaque, testing is difficult to impossible, and the benefits over SPF are unclear at best, dubious at worst.
On about 1/3 of the servers, all Yahoo email is blocked out of hand due to the disgust and irritation of the server owner over Yahoo!'s blocking/delaying/spam problems. One server owner told me, "My mail TO them is blocked or delayed. But unless I use DKIM/DK, they won't tell me what the problem *is*. Since my own spam load is roughly 40% FROM yahoo!, screw 'em."
Yahoo!'s insistence on DKIM/DK is highly suspect in the cases, like mine, where a responsive, active abuse desk that will address a spam issue if it's from our clearly identifiable ARIN allocation is available.
For those customers that choose not to accept Yahoo email, we return an error message generally worded like so:
"We're sorry, but due to Yahoo! polices we strongly disagree with, we will not accept your email. Please use another email service that doesn't have it's head up it's ass."
It isn't phrased quite so bluntly, but the flavor is still there.
When I get complaints that Yahoo! won't take a customer's email, I tell them, "Yahoo! is a free service. Their customers are getting all they pay for. I'd like to help you, but frankly, I can't get them on the phone or to give a reasonable response via e-mail. Your best bet is to require a contact method that refuses or bypasses Yahoo!. They aren't in the business of giving their customers reliable email service."
Do I have problems? I'm sure I do. But since Yahoo! won't discuss them without jumping through their useless DKIM/DK hoops, I'll just ignore it and move on.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
The thing is that due to forwarding and vanity servers, you ARE asking people down the wire (which you can't predict and have NO control over) to throw away mail you sent. When you send to a buddy's vanity domain (that you don't know is a vanity domain) and it forwards your email to their ISP or work account that does check SPF records, your mail gets ditched. And you usually won't get any notice, so your email just disappears.
Using SPF increases the likelihood of your email getting sent into the ether to not return.
The SPF folks themselves acknowledge this as an issue and recommend using SRS to combat it. Of course, since no one uses SRS, it's still an issue.
Portable versions of Firefox, GIMP, LibreOffice, etc
How lucky you are. I have both SPF and DomainKeys implemented and one of my domains has plenty of problems with Hotmail and Yahoo. I send no lists. Never sent anything with a resemblance of spam. Only email confirmation emails. My IP is clean everywhere.
2011. The year Gnome decided Linux will never be on the desktop.