Dropbear

Google doesn't get SPF

Written by

dropbear

in

Someone has decided to use my email address for a spam source.  They have even used google to relay it which, given Googles current policies seems like a winning idea.

I keep getting emails from Google’s servers with header lines like this:

X-Original-Authentication-Results: mx.google.com; spf=hardfail (google.com: domain of [email protected] does not designate 66.80.26.66 as permitted sender)

You don’t say? You mean even though my SPF records do not include some dodgy server in California, even though Google knows I don’t include this in my SPF records… well we will let the email go through anyhow.

SPF records mean that’s where my email comes from. If the record has a -all at the end of it, like mine do, then it means don’t accept it from anywhere else. The hardfail means Google sees the -all and still does nothing about it.

Related articles
Enhanced by Zemanta

Comments

17 responses to “Google doesn't get SPF”

  1. gnomon Avatar
    gnomon

    Sadly, Gmail *does* get SPF. I have a couple of years of experience dealing with SPF in a professional capacity, and it pains me to say this, but that well is poisoned. The number of admins who use it well, or even properly, disappears into the round-of error of admins and site deployments done wildly wrong.

    I’m sure it pains someone greatly at Gmail to put in place a policy to explicitly disregard SPF directives, but in prod, pragmatism must trump purity. The merits and shortcomings of its design notwithstanding, SPF has become a poor tool.

    Reply
    1. Craig Avatar
      Craig

      That’s for your reply. SPF definitely has mixed results. It’s a shame really because this problem (spammers hijacking source domains) is exactly what it is supposed to stop, and would of had Google implemented it. It almost makes them an open relay the way it works now.

      I’ve mainly seen problems on the receive side, where someone has an outside and inside mailserver and the inside mailserver runs SPF checks and rejects the mail because it came from the outside server. If admins get that wrong, then I can see they’d get the other side of the mailserver/DNS setup wrong too, which is what you used to see.

      Reply
  2. Richard Salts Avatar
    Richard Salts

    I think it is reasonable to deliver email even in the presence the -all. How can you guarantee that someone hasn’t setup a forwarder, most people who do so wouldn’t use sender rewriting as the SPF authors suggested as a workaround for this case. I agree that it could be okay to reject if there was no record in the Received headers of one of the authorized hosts. However this is easily forged by a spammer so doesn’t actually add much to help. In my opinion SPFs greatest strength is in whitelisting messages from trusted sources for a domain you know of as legitimate and an indicator of possible spam along with other heuristics (e.g. spamassassin score modifier).

    Reply
    1. Craig Avatar
      Craig

      That’s an easy one to solve. If you are certain that a forwarder hasn’t been setup, or its listed, then use -all
      If you’re not sure, don’t use it.

      I use -all, my ISP (because you can send email from anywhere in the world from their domain potientially) doesn’t. That’s the right way of doing it.

      Reply
      1. Philipp Kern Avatar
        Philipp Kern

        Uhm, no, sorry. The burden is shifted. The question is if the *receiver of your mails* uses a forwarder that does not do SRS. You cannot possibly know that. Google cannot know either if the mail has been forwarded from another freemail account that user has, for instance.

        As a mailserver admin, I concluded that SPF is largely useless and merely a hint. -all still seems actively harmful to me given that no mailserver has SRS enabled in its default configuration.

        For instance, if you mail me at my debian.org address then your envelope from is not rewritten. In practice I’d then need to reject your mail because it’s clearly not coming from an allowed host to my real mail account, but instead from my forwarder. Now, I do operate my own mailserver and do whitelist the debian.org mail-in. But most of the users will not bother.

        Reply
        1. Craig Avatar
          Craig

          That doesn’t make sense. If my domain says it only comes from these sources and the email comes from another source, then it is not legitimate email. The debian.org example is a good example. If I email from my own domain, it has SPF and specific sources. If I email from debian.org domain it does not have either. The system then works, it would only be if debian.org used a SPF record that it would fail.

          Reply
    2. Kristof Provost Avatar
      Kristof Provost

      No, this is worse. They decide to reject the mail based on the SPF records (which I think is reasonable, but you can disagree there). Fine so far, but because they reject the e-mail they decide to send a bounce message to the source domain, which is stupid as they’ve just rejected the mail because they think the source domain is fake.

      They’ve also been doing it for ages. I posted a similar rant almost a year ago.

      Reply
      1. Craig Avatar
        Craig

        That’s the problem. I’m getting email reject messages from a source they know is wrong.

        Reply
  3. Anon Avatar
    Anon

    What about opendkim? Thats probably a better solution than spf.

    Reply
    1. Craig Avatar
      Craig

      I run that too, still getting backscatter from Google.

      Reply
  4. Elessar Avatar
    Elessar

    This is probably because there is a high number of badly configured email services and they do not want to drop that mail.

    Anyway, there is a new draft standard to indicate (among other things) what to do with messages that appear to be from you but lack both SPF and DKIM validation: DMARC. While this is only a draft standard, it has already been deployed widely, so you may consider publishing a strict DMARC record.

    Reply
    1. Jimmy Kaplowitz Avatar
      Jimmy Kaplowitz

      Google respects DMARC, which also requires SPF and DKIM, and can be told to reject unauthenticated mail from your domain. Relevant links:
      https://support.google.com/mail/answer/2451690?hl=en
      https://support.google.com/a/answer/2466580?hl=en
      https://support.google.com/a/answer/2466563?hl=en

      Yes, the whole global email system is a mess, but others have explained here why SPF by itself is inadequate.

      Reply
      1. Craig Avatar
        Craig

        Thanks Jimmy, I’ve added DMARC too so let’s see how that happens.

        Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts