Google doesn't get SPF

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.

Enhanced by Zemanta

Comments

17 responses to “Google doesn't get SPF”

  1. 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.

    1. 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.

  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).

    1. 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.

      1. 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.

        1. 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.

    2. 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.

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

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

    1. I run that too, still getting backscatter from Google.

  4. 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.

    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.

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

Leave a Reply to Craig Cancel reply

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