Internet Storm Center

Handler on Duty: Guy Bruneau

Threat Level: green

SPF how useful is it?

Published: 2010-06-01. Last Updated: 2010-06-01 00:15:11 UTC
by Mark Hofman (Version: 1)

Chris wrote in and mentioned a talk at Auscert which highlighted that (Sender Policy Framework) SPF would have helped in the instance of an intrusion and suggested a diary outlining some of the things that can and can't be achieved using SPF. I have my own experiences with SPF and the effectiveness, but I'd like to hear you experiences with SPF, good or bad. so I can write a more complete diary on the topic.

For those that are not familiar with SPF. The idea behind it is to create a DNS entry that specifies those machines in your network that are allowed to send email from your domain. The receiving mail server checks this record and if it does not match it will drop the message. There is a little bit more to it, but hat is the crux of it. So if you have had any experiences with SPF (good or bad) please let me know via the contact form or directly markh.isc at gmail.com.

Thanks Chris for the idea and thanks in advance for your contributions. I'm aiming to get a diary out on this later this month.

Cheers

Mark H

Keywords: SPF how useful is it

Comments

"How useful is SPF?"

Ask that question on slashdot and you'll have thousands of nerds telling you that SPF is a useless waste of time.

We don't use it... .edu environment with two different cable modem ISPs and a half-dozen others with fewer customers, many faculty and staff send @XXX.edu mail from home using their ISP's mailer because the machine at home is also used for spouse/family e-mail from the ISP.

Yes, it could all be arranged so that the employee used authenticated SMTP via our servers and the family used the ISP's servers, but how many of you have ever tried to tell university faculty to do something? It's kind of like teaching a pig to sing...

Re: Ken's comment above, yes that's the most difficult part, but probably brings the greatest payoff if you can see it through.

Fully adopting SPF (the o=- tag) may force everyone to authenticate with your own server[s] in order to send mail addressed from your domain. That applies to human users as well as any servers that send mail (such as website signup/registration/notification emails). You may as well require SMTPS, and authentication with either a passphrase or client certificate.

The immediate benefit to your own organisation is that you can completely lock out external mail purporting to be internal. This will stop some phishing emails, and all kinds of other spam too. The default heuristic scanning of SpamAssassin would mark such emails as SPF_FAIL but potentially allow them through if they seemed otherwise genuine, in which case you can review these to see if someone or some system is not properly configured.

And then you're also in a position to scan your outgoing mail for viruses, phishing scams, or whatever else. This is not due to SPF itself, but because all mail is probably going via one or more of your own server[s] now.

Finally, not to forget, any SPF-checking recipients of your mail can then be sure whether email addressed from your domain is just spam, or whether it came through systems under your careful control.

We work with clients on anti-spam solutions and strongly encourage them to implement SPF with a hard fail to protect their brand and reputation as well as help reduce back scatter and invalid NDR delivery. We had 1 client that was getting over 3.5 Million NDR's to an invalid e-mail address every 24 hours. They implemented an SPF record and immediately saw a reduction though it took a few months before the spammer started picking on someone else entirely. :)

I didn't find much that was useful with SPF.
re: NDR's - I'm amazed that any SMTP boxes that still do NDR's would be configured to correctly use SPF.

We use it with some success, but it should be noted that you'll not actually see the direct results; it works by telling *others* to not accept fakemail, meaning that *they* see the effect, not you. More than anything, it should be considered an attempt at protecting your brand and rep. It can supposedly reduce backscatter, but as Brandioch said... it's limited.

There's no point in putting in SPF rules unless you put in a hardfail. If your organization pushes back on using the hardfail, then you aren't ready to be a single source email system.

If you're big enough, some of your users will want to have third parties send email as well. You need to find a solution for these users - although it can be as simple as splitting the sender (Return-Path) and From addresses for third party-sourced email. If you don't solve that issue, you'll never get SPF rolled in.

Bounce Address Tag Validation (BATV) will do far more to reduce your *own* backscatter.

One other key point - it should be useful (and completely harmless) to implement hardfail-only SPF rules (no legit senders!) for any non-email domains you run. Those should never have email in them, so make that point completely clear.

We find it works well as a heuristic to identify spam, but not as the sole criteria. Eg, we don't dump email just because it flat out fails the SPF check. It's also a good way to control email going out of your organization; keeps users from either running their own mail client or using unapproved external services.

we used it with a limited amount of success at the medical community I used to work at. I was "stationed" there as support for the doctors.

it worked well when everyone was on board and trying to help, but there were a number of doctors who did not/would not adopt the system since they had to change mail servers to do so.

Ken mentioned university faculty....I think they are second behind doctors about being reluctant to do things differently than they already are.

I should add that this was similar to ken's setup in EDU. multiple ISPs and DSL/cable modem connections to deal with throughout the santa cruz area.

Login here to join the discussion.

Diary Archives