2

I tried a website that supposedly sends spoofed email. I sent myself an email impersonating another email address and the message showed up in my yahoo mailbox even though according to the headers it did not pass the spf check because the server used to send the message was not authorized to send messages as the domain it impersonated. Why do these email pass? Is there a legitimate use for spoofing email headers?

Here are part of the headers:

From "Bill Gates" Sun Feb 28 16:31:51 2016
X-Apparently-To: MyEmailAddress@yahoo.com; Sun, 28 Feb 2016 16:31:06    +0000
Return-Path: <bill@microsoft.com>
Received-SPF: fail (domain of microsoft.com does not designate 46.167.245.71 as permitted sender)

I'm also looking for some information about SPF and DMARK, DKIM as well as technology related to smtp, smtp security and email spoofing (apart from the smtp rfc). I thought this would be a great place to ask.

8

When a message fails the SPF check, it doesn't necessarily mean that the message is spam. For example, it's possible that the sender of a legitimate message sent the message from his gmail address, but using an SMTP server other than Gmail's (e.g. his ISP's SMTP server, or a hosted SMTP service). In that case, the message would fail the SPF check, but the message is legitimate. So, the SPF check is just one of many checks that spam filters use to determine if a message is spam.

For this reason, some mail providers now publish DMARC records, which are used to tell spam filters how to handle a message based on the result of the SPF check (and/or DKIM check).

For info on SPF and DKIM, see https://www.ultrasmtp.com/kb/messageauthentication.php

For more info on DMARC, see https://dmarc.org/

6

It has been known since the original design of SPF that it could only provide some additional information in determining whether or some something is spam. Indeed there are many common circumstances that can lead to a false fail.

Forwarding breaks SPF and causes false fails

For example, suppose I have an email address that I don't use, say, JGoldberg@example.tld, and I set it up to forward all mail to my real address, jeffrey@domain.example. Now if Wilma sends me email from her system, foo.example and that is all valid in terms of SPF, it will still be still come into domain.example mail server from example.tld's mail server. example.tld's mail server is not going to be authorized under SPF for mail from foo.example even though there is no forgery or spam happening.

Now there are a couple of things that people can do to try to clear up cases like this. For example domain.example can whitelist example.tld. Alternatively different forwarding mechanisms can be set up. But none of these are ideal, reliable, or even available for all configurations.

Don't block when you know false fails are possible

Given the above (and some other ways to systematically get false SPF fails), it is important to weigh the information an SPF failure gives you instead of automatically rejected all SPF fails. Fortunately, even longer than SPF has been around, anti-spam mechanisms have used bayesian filters. This is more than just giving a score to each factor, it is a way of combining all of the little facts the system knows about what is and isn't spam and balancing that all out into a judgement that will bias toward false negatives (letting some spam through) instead of false positive (rejecting things that shouldn't be rejected).

SPF is terrible, but was necessary

I participated in some of the early discussions that lead to SPF. Everyone involved knows it is deeply flawed. But we were desperate for anything that would help control the flood of spam into the mail servers we were running. (Sure, individual users hate spam in their inboxes, but the people who run mail systems have to pay for real hardware and bandwidth to deal with all of the incoming mail even if most of it is filtered before it reaches your mailbox.)

DKIM largely supersedes SPF. I've been out of the email management business for a while, so I'm not entirely sure what the current state of thinking is on why SPF persists now that DKIM is more widely available. I can see cases where SPF is possible and DKIM isn't. For example, with SPF you can authorize a domain or network as a sender without having to give that sending domain your DKIM private key. SPF and DKIM place different requirements on the legitimate sending domains to coordinate their activity.

But still, I'm surprised to see that SPF is still around. At the time it was introduced I thought of it is a temporary desperate measure that would be replaced by somewhat more coherent mechanisms. But it appears to still have a role to play.

  • 1
    "But still, I'm surprised to see that [ x ] is still around. At the time it was introduced I thought of it is a temporary desperate measure that would be replaced by somewhat more coherent mechanisms." I think you just succinctly described most of the security protocols/mechanisms that are in wide use today. ;) – mostlyinformed Feb 29 '16 at 7:49
  • "with SPF you can authorize a domain or network as a sender without having to give that sending domain your DKIM private key." - this is moot, you can specify different selectors – rossnz Feb 29 '16 at 9:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.