Ask Slashdot: How Do You Handle SPF For Spam Filtering? 187
An anonymous reader writes "Our organization had had a decent SPF record of our own for a long time. Recently, we decided to try using SPF for filtering inbound mail. On the up side, a lot of bad mail was being caught. On the down side, it seems like there is always a 'very important' message being caught in the filter because the sender has failed to consider all mail sources in writing their record. At first, I tried to assist sending parties with correcting their records out of hope that it was isolated. This quickly started to consume far too much time. I'm learning that many have set up inaccurate but syntactically valid SPF records and forgotten about them, which is probably the worst outcome for SPF as a standard. Are you using SPF? How are you handling false positives caused by inaccurate SPF records?"
Use it for scoring, not blocking (Score:5, Informative)
Too many users are still careless with it. This is because it was proposed as a DNS standard, but was poisoned by Microsoft cluttering it with the entirely distinct "DomainKeys" project, then deliberately mislabeled the SPF version that they use. (See the history at spf.pobix.bom)
The result is that SPF has been less useful than expected. Also, SPF does not work well over mail relays unless they're configured to to indexing and re-writing of the "From " field, and pass the bounces through the relay server on its way back to the original sender. But it has been enormously effective to add to spam *scores*, to give anything with a bad SPF result a much lower score as a potentially valid email message.
We don't reject, but we send some "helpful info" (Score:4, Informative)
We had the same problem.
Our solution: if the message makes it past all our spam filters and the only problem is that the sender's client isn't allowed by their SPF record, we send a friendly, plain-english informational message back to the sender, then deliver their message to our users.
"Please tell your company's IT staff that your mail server isn't set up correctly. This may cause your messages to be rejected or classified as spam. Please forward the following information to your system administrator: [SPF record] [sender's IP]. Thank you!"
Usually the issue is that the sender has set up GMail to send "from" their company email without sending through the company SMTP servers, usually without authorization.
We do the same thing with broken DKIM signatures.
This has worked well for us, since senders get tired of the message and seem to get things dealt with. We considered adding a "threat" saying that if the problem wasn't fixed, we'd block the sender, but that was rightfully shot down as pretty mean.
Re:Use it for scoring, not blocking (Score:5, Informative)
Re:Forget about them (Score:4, Informative)
I don't think you know what SPF is or how it works.
SPF specifies, by leveraging the DNS, which servers are allowed to send you mail from that domain. The problem it addresses is "spoofing" - I send an email to your servers claiming to be from you. If you have a SPF record, you can say servers x,y,z,a-c are allowed to send email claiming to be from foo.com.
There's three possibilities:
1) No SPF record - process normally
2) SPF record, sent from valid host - generally downweight spam score, since verifiably the server that sent the email was in that organization
3) SPF record, sent from invalid host - the subject of this Ask Slashdot. It should be "always bad" but Incompetent admins set up SPF, then get it wrong or don't update it and mail bounces. Hence the problems discussed here.
"sender was sending all his email through a local MTA because his ISP doesn't have an externally accessible MTA" - no problem if the SPF record is correct. Or if you can't be bothered to do that, just get rid of it.
Filtering on missing SPF records is stupid. Filtering on bad (i.e., sending host was marked as disallowed) SPF records should be 0% false positives, were it not for idiot admins - again, the subject of this AS