Forgot your password?
typodupeerror
Spam

Ask Slashdot: How Do You Handle SPF For Spam Filtering? 187

Posted by samzenpus
from the false-positive dept.
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?"
This discussion has been archived. No new comments can be posted.

Ask Slashdot: How Do You Handle SPF For Spam Filtering?

Comments Filter:
  • by jjeffries (17675) on Wednesday February 06, 2013 @07:07PM (#42815419)

    Or anything else, for that matter--mark it as "spf failed" and score it as you feel appropriate for your filtering setup.

    • by smash (1351) on Wednesday February 06, 2013 @07:45PM (#42815801) Homepage Journal

      This.

      If email filtering was as simple as dropping non-SPF approved mail, spam would not exist. There is no single silver bullet in the war against spam. And besides, when domains cost a couple of dollars to register, it's entirely possible to set up an SPF enabled domain and spam from that.

      • by hedwards (940851)

        You're supposed to combine SPF with DKIM so that you know who is sending messages from where. The point isn't to kill spam completely, just to make it as inefficient as possible. If you make it inefficient enough that they're all losing money, they'll move onto another scam.

        • Re: (Score:3, Interesting)

          by Anonymous Coward

          When I worked at a spam company (I got hired to write software to handle 20 million mails per day on a single server - not proud of it, but I needed the job), we had SPF and DKIM on everything. Except the corporate exchange server, at least for a while. But the spam mails, having both SPF and DKIM on those was very important.

          Ever since, I've considered blocking mails with SPF or DKIM headers. Only spammers care enough to set those up correctly. And a few of the big mail companies (like GMail and Hotmail), b

  • Spamassassin (Score:5, Interesting)

    by icebike (68054) on Wednesday February 06, 2013 @07:12PM (#42815469)

    Spamassassin handles SPF, reasonably intelligently, that is, not trusting it completely, not giving it more weight than it deserves.
    Hanging your spam fighting hat on any single hook is problematic. and SA uses a wealth of tools with constantly updating itself via
    scripts. Its been largely trouble free, and we have it set up so that it will learn false positives and false negatives when users
    move these to the corresponding folders.

    I've been well served by Spamassassin [apache.org] for some time now, it runs quietly
    on our mail server. SA does not block mail. It flags it. Our mail server will evaluate these flags and trash outright the most
    egregious spam, but we have the limits set low enough such that we will allow the questionable things through.

    We error on the side of caution, but we still dump a lot of mail right after SA flags it. (Our business can do that, your business
    may not be able to do that.)

    • Yup. We run SpamAssassin along with ClamAV and postgrey on top of Postfix to filter all the incoming mail and it does a pretty good job. Here and there a spam will get through, but I can look at my logs to see all the rejections. It's not rocket science, and the solution has been tested and proven for over a decade now.

      • by rahvin112 (446269)

        My personal experience was postgrey alone knocked out 99% of spam as the spam sender never retries regardless of error message type.

        • by EvilIdler (21087)

          Just the default tools included with a big package like Zimbra have done a marvellous job stopping spam from reaching users on my server. After training them to mark spam in the webmail the filters have learned enough to outright reject nearly all spam, but you're right Postgrey can really help. I ran it when I used a simpler setup with Postgres, Dovecot and Roundcube, and we enjoyed a very long period of sweet, spamless service. Then more spam started slipping through at some point.

          After I moved to Zimbra

    • by Albanach (527650)

      I think this makes sense where your organization cannot devote additional resources. However it's important to work out how much staff time is wasted by your spam volume.

      Personally I would reject if the sending server lacked a PTR record, or if the PTR record was invalid, or on SPF failure. I use templates to quickly reply where someone had trouble contacting us, directing them to contact their IT department and referencing RFCs where necessary. Even large ISPs would get it wrong sometimes, but invariably f

  • by Anonymous Coward on Wednesday February 06, 2013 @07:13PM (#42815479)

    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.

    • by dshk (838175) on Wednesday February 06, 2013 @07:34PM (#42815703)
      A small correction: Forwarders must rewrite the reverse-path, which is the address they submit in the MAIL FROM SMTP command, not the From field in the mail content. They leave the From field as it is. Actually they should not tamper with the mail content at all. I believe that all large forwarders have been SPF compatible for years. Otherwise they could not deliver their mail to a very large percentage of recipients.
    • by MightyMartian (840721) on Wednesday February 06, 2013 @08:02PM (#42815965) Journal

      Less expected by whom exactly? I was part of the major discussions a decade ago surrounding SPF and there was a large contingent of damned good mail admins and SMTP experts who said the whole thing was flawed.

      • by dshk (838175)

        After reading the comments here, it is obvious that there is one and only one significant issue with the SPF system: 95% of system administrators do not get it. I try to clean things up (therefore it will be long, and nobody will read it, but anyway...).

        First of all, fortunately, SPF is very simple to implement it, so most admins do no harm, even if they do not understand it.

        Nor they get SMTP. Specifically the most important promise of SMTP: Your mail will be either delivered, or you will get a notificat

    • by thogard (43403)

      SPF was broken from the start but it was a step towards a better solution.

      I liked the idea of using dns or snmp to ask the server that should have sent the message "did you send message id foo_xyz? That alone would have fixed a massive amount of spam if you tie it back to mx records of what should be sending the messages.

  • whitelist (Score:4, Insightful)

    by shentino (1139071) on Wednesday February 06, 2013 @07:16PM (#42815517)

    Use SPF as part of a whitelist/blacklist scheme.

    For sources that have their shit together, trust their SPF records as an absolute metric.

    SPF does work if set up correctly.

    • by urbanriot (924981)
      I'm fully in agreement and I'm questioning whether some of the commenters here suggesting to use scoring over blocking, for senders that have enabled SPF, are actively involved in the administration of high volume email servers. If a company has created an SPF record, clearly they want people to block email that is not originating from their servers. This does not result in 'false positives' as its an SPF record with the DNS server - the address doesn't change.
  • by neiras (723124) on Wednesday February 06, 2013 @07:19PM (#42815553)

    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.

    • by hawguy (1600213)

      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!"

      That's nice if you don't rely on email for communication with your customers. Generally, customers (and potential customers) don't respond well to nagging -- especially if whatever you're asking is outside of their control. They may be too small to have anyone to complain to (and no idea how to fix it themselves), or they may complain to the corporate helpdesk who says "Nope, our server is set up the way we want it".

      If I got an email like that from a vendor I was trying to reach, I wouldn't be doing service

      • by neiras (723124)

        If I got an email like that from a vendor I was trying to reach, I wouldn't be doing service with that vendor.

        One vendor that we were paying support to was trapping our entire domain's email in a spam filter - none of our emails could go through...

        I see what you're saying. Just wanted to emphasize that email messages are never dropped in our system, they are always delivered. The SPF check is still part of the spam checks, but by the time we get to the "send informational message" stage we've already decided the message isn't spam. We also check the sending IP against the Backscatterer RBL, which hopefully keeps us from sending to domains that have been hijacked.

        The informational message is only sent once per week to any given sender. We do have an "

    • by smash (1351)

      Of limited usefulness. MD walks in "i'm expecting this email for a potential tender, the client tells me we are rejecting their email, and submissions close today!".

      The MD receiving the odd spam is not a career limiting prospect. Missing a multi-million dollar contract due to non-delivery of business correspondence (or that reason being used as a scapegoat by your company's tendering department) potentially is.

      • Relying on any form of email for multi-million dollar tender delivery is the career limiting move here.

        • by smash (1351)
          Sure. But shit rolls down-hill, and it's not the MD who's going to get fired.
          • by smash (1351)
            Put it this way - in an ideal world, I agree with your premise. But the reality is that people expect email to work, and don't care WHY it failed. The fact that you bounced their legitimate correspondence is unacceptable to the business side of the company. The one that brings IN money.
        • by mcrbids (148650)

          Except that email is commonly used for such. I have negotiated contracts worth hundreds of thousands of dollars by email. (not yet multi-million, but well on my way, nonetheless)

    • In other words you're generating soft bounces and making your server vulnerable to being used as an attack vector.

      • by neiras (723124)

        In other words you're generating soft bounces and making your server vulnerable to being used as an attack vector.

        Nope, we do limits - one message per week per sender. So no effective attack vector.

        • by mvdwege (243851)

          So you get hit with a 10.000 address spam run.

          Are you still contending that you are not a nuisance?

          Shut. that. system. down.

    • by Bogtha (906264) on Wednesday February 06, 2013 @09:28PM (#42816557)

      we send a friendly, plain-english informational message back to the sender

      Please don't do this. One of the problems SPF solves is that spammers pick some random domain then spoof emails from that domain to send to millions of people. If you happen to be one of the unlucky people whose domain is targeted, you get a million bounces in your inbox.

      The whole point of SPF is that if an email fails an SPF check, the email may not have come from the purported sender, and you should not treat it as genuine. You're completely undermining what SPF is for by doing this.

      • by neiras (723124)

        The whole point of SPF is that if an email fails an SPF check, the email may not have come from the purported sender, and you should not treat it as genuine. You're completely undermining what SPF is for by doing this.

        Yeah, if everyone did this it would be bad - zillions of polite informational messages. You make a good point.

        On one hand we're a small shop with a low-traffic email server. We've had good success getting sending domains to fix their record. On the other hand, perhaps we should go back to passive mode. I'll mention it to the system administrators.

  • Thanks, Google!

    I can't be bothered to run my own damn SMTP/IMAP/etc any more.

  • by wbr1 (2538558)
    Here is how I increased my SPF using one weird trick!
  • DMARC (Score:4, Interesting)

    by MillerHighLife21 (876240) on Wednesday February 06, 2013 @07:39PM (#42815735) Homepage

    That's what DMARC is for. It let's companies specify exactly how to handle their SPF (and DKIM) rules based on how thoroughly they have covered their bases. The company I work for deals with a ton of phishing against our user base and implemented SPF, DKIM, and DMARC with great success.

    Google has excellent documentation on the protocol.

  • You CAN'T reject based on SPF, as you have learned. You'll lose too much valid mail.

    So the best you can do is use it as part of a spam-scoring system, like SpamAssassin. Unfortunately, anti-spam systems that try to assign a "score", or try to analyze mail content, are ALSO worthless. Spammers have *completely* figured out how to get past any anti-spam system that analyzes content.

    The sad fact is that the only way to effectively stop spam is to pay for an anti-spam service like Postini (which is going away,

    • by dbIII (701233)

      Basically, professionally-maintained, commercial blacklists are the ONLY really effective anti-spam system.

      I've been on the wrong end of a few of those since I have a mail server on an address that used to be a dynamic address something close to ten years before I got it and it gets blacklisted every now and again when people accidently dredge stuff out of old lists. To sum up those events, commercial rarely means "professionally-maintained" with spam blacklists.

    • by smash (1351)

      I manage to cut over 75% of spam before it gets to content filtering by greylisting, and the spamhaus zen block list. The vast majority of spam doesn't even get to my content filter.

      No, it's not perfect, but if your boss isn't willing to shell out for an ironport or you're trying to do it yourself, cutting 75% out before it even sends the content to your server is a win in my book.

      • by allo (1728082)

        > spamhaus
        do not use them. they are making money with unblocking. so potential clients are not reachable, just because spamhaus blocked them and they do not even know it (or do not see the point in paying for the spamhaus blackmailing)

  • Add DMARC to your processing (http://www.dmarc.org/). It's a 'yes, I really meant it' notification for senders to communicate to receivers.

    Other than that, the other suggestions already posted are about as good as it gets: use SPF as one element in scoring a message. Mark the message if your e-mail system allows it (e.g. label:authenticated in green, or label:authfail in yellow).

  • by dshk (838175) on Wednesday February 06, 2013 @07:50PM (#42815837)

    We reject mails which fail the SPF check immediately within the mail session. That is the only safe way, because then the sender will receive a bounce message from his own mail server.

    We never received complaints regarding SPF rejects, but maybe because we do not have large incoming mail traffic.

    Even if there were false positives, it would not hurt anybody, because the sender is guaranteed to be immediately notified that his message had not reached its recipient. He could contact us using a different method, not mail - in addition to complaining to his (so called) system administrators.

    • by urbanriot (924981)
      I don't believe I've ever heard of an SPF false positive failure but the sender would be notified with a bounce back, at which point the issue could be corrected, so I don't think false positives should be a concern.
    • by anom (809433)

      This; a thousand times this.

      If I issue a 250 Queued response, it means that the email coming in is actually going to be deposited in a user's mailbox, otherwise the sender is notified by some component of the sending mail system.

      Not only does this make the failure message itself more reliable, but it makes the sending user more likely to complain to his/her own IT department, as that's where the bounce message will likely be sourced from.

  • Of course SPF filtering is not perfect; no one filter method ever is, thanks to all the badly configured mail servers out there. So, try not to build mail servers that reject incoming mail based on any one test, like one for SPF, or else you'll probably end up maintaining a lengthy whilelist, which will not only make you unpopular with the users, but is also a waste of time.

    Instead, I built a mail system, using Exim (an extremely flexible MTA), that keeps track of a total number of 'strikes', as I call t

  • The idea is good, but in practice it's horrible. Here's what we do:

    We never give a bonus to anything scoring SPF "pass" unless its from one of a few large domains that we know have good SPF records.

    We add a small score (1 SpamAssassin point) for SPF softfail.

    We add a moderate score in most cases for SPF fail.

    For specific, often-phished domains like paypal.com and ebay.com, we add lots of points for SPF fail and softfail.

  • We use Postini (now Google message security), and we turned on their SPF checks. Unfortunately, there are no knobs for this, so SPF pass is "good", SPF softfail is "bad", and SFP fail is "always quarantine, even if the address is whitelisted".

    Despite some high-profile mail getting snagged by this, we educated our users and let them know that while we're more stringent with SPF than most places, it's not "our fault" that other people can't configure their domains correctly. After an initial spate of 10 or

  • For the past year, one of our business domains has been a patsy for a continual bombardment of spam against the internet. Typically our catch-all account would receive at least 200 bounce back failures a day. Since then, we enabled SPF on our domain and it drastically increased the amount of bounce-backs considerably... which is good, as it means less people are seeing our domain in a malicious light as they're immediately denying the spam as it's caught by an SPF filter before it goes through other filters
  • SPF's great benefit is protecting your users against phishing attacks. Common phishing targets such as Paypal, eBay and Gmail, as well as banks and other finance organisations have very well managed SPF records. The onus for ensuring SPF records are correct falls on the sender, not the recipient. If someone inputs an SPF record for their server, then sends an e-mail via a different server you're doing exactly as requested by blocking the message. Problems of misconfigured SPF records will ease once more org
  • I havent seen it in a while, but for a while we kept having issues with some implementations of Exchange refusing email based on our perfectly valid SPF records. The problem only occurred if we had both SPF AND SenderID (M$' so called "SPF 2.0") records for our domain. If we deleted our SPF records and only left the SenderID record, the mail would be delivered.

    Way to go Microsoft in taking a perfectly good standard and deciding its not QUITE good enough and muddying the waters with your own crap.

  • You can use SPF as a hint. A bad SPF record could trigger longer greylisting delay, therefore lowering the ability of a spammer to reach destination before been known by blacklists. milter-greylist [hcpnet.free.fr] allows such setup.
  • Antispam measures are effective only when methods are combined, with no single method being more important than everything else.

    Also, graylisting in front of your mail server is one of most effective methods to defend. Legitimate mail infrastructure will rarely (if ever) use different IP address for every delivery tried.

    Graylisting, combined with RBL, combined with spamassassin (with SPF and most other methods used through it)... And you have decent solution. What remains is to define your policies and your

  • Not only I use SPF, but I also maintain the tumgreyspf package in Debian [debian.org], which does both SPF and greylisting.

    And for those who have bad SPF records, and send email from the wrong IP? Well too bad, they wont be able to write to me. But as well to so many other persons (gmail, hotmail, etc.) that it's not really a huge concern, and that I don't feel like I should be the one having to spend the time explaining how to configure things.
  • Is the sender IP whitelisted? Allow.
    Is the sender IP not presenting a valid reverse DNS name? Block.
    Is the sender IP listed on SpamHaus? Block.
    Does the sender IP not match the domain SPF record (even soft-fail is a fail)? Block.
    Is the sender IP not retrying after being told to try again in five minutes (greylisting)? Block.

    And then you can do things to do with the actual message itself, like DKIM signing, spam-detection, etc.

    Instantly cut out 99.9% of your spam, and at the same time anyone who fails th

  • by allo (1728082) on Thursday February 07, 2013 @08:25AM (#42819335)

    If you have correct SPF, you will most likely get more spam. Why? Someone spams mailservers with your domainname, then it bounces because of failed SPF, and many mailservers are configured wrong, so you will get backscatter spam.

    The irony of this is, that SPF says "it wasn't me" and the wrong configured mailservers then send YOU an answer saying "hey, we're not accepting your mail, because your SPF says it is not your mail".

  • Here's the problem, and it's a fundamental problem with the SPF framework, as a business process. The consequences of error should reside with the entity that has the most direct control over what causes or prevents that error. What is happening here is that Entity A has their SPF set up wrong, but potentially all the impact could land on Entity B. SPF isn't rocket science, but it's the kind of thing that needs to be checked periodically and tied tightly into change control processes...in other words, a

The reason why worry kills more people than work is that more people worry than work.

Working...