Link to home
Start Free TrialLog in
Avatar of David Spigelman
David SpigelmanFlag for United States of America

asked on

SPF permerror with +all

I thought I understood how SPF works, but I found something today that makes me question my assumptions. I think I know what's actually going on, but I'm hoping someone out there will be able to tell me for certain.

One of my associates had a syntax error in their SPF record, which was causing it to be ignored entirely. I suggested they fix it, which they did. But now they've changed it so that, after specifying a number of includes, etc. it ends in +all. Here's the actual (modified) record they set up:

v=spf1 a mx ptr include:_spf.google.com include:xxxx.com include:yyyy.com include:zzzz.net +all

Now, to my understanding this reads, this could effectively be shortened to: v=spf1 +all, since +all means "allow anything else." This would be bad. Worse, in fact, than having no SPF record at all. And I was preparing to tell them so, but I wanted to test it first a) just to make sure my understanding was correct, and b) to have something to show them, which would demonstrate why it was so bad.

To do this, I went to www.deadfake.com - a site that allows you to spoof mail. I entered my email address as the To, and an address at their domain as the From, and sent the message. My expectation was that it would show up in my email box, having passed the SPF filters without a problem.

But that's not what happened. Instead, I found it in my junkmail folder with the following notice in the mail header:
Authentication-Results: spf=permerror (sender IP is x.x.x.x)
 smtp.mailfrom=theirdomain.com; mydomain.com; dkim=none (message not signed)

Now this puzzled me because the +all should have permitted it, right?

Then I checked an email I received from the domain in question, after the SPF records had already been changed. This message got through just fine. When I checked the header there, I found this:
Authentication-Results: spf=pass (sender IP is y.y.y.y)
 smtp.mailfrom=theirdomain.com; mydomain.com; dkim=none (message not signed)

It didn't fail, and I don't understand why there's a difference.

But here's what I think is going on. Hopefully, someone can tell me if I'm right.

I'm guessing that, because +all is such a bonehead-stupid thing to put into an SPF record, some mail servers are rejecting them as if they were an actual error, even though that's technically against the spec. Now that doesn't mean ALL mail servers will do that, so it's still a bad thing to do. I'm also thinking that the SPF filter is functioning as a first-pass filter. In other words, it checks an incoming email against the filters specified in order, and the first one it passes, makes it a Pass. Since the one that actually came from their domain did pass one of the filter rules, it's showing up as a Pass.

Does that make sense? Or is there something else I'm missing?
Avatar of DrDave242
DrDave242
Flag of United States of America image

The problem is most likely one of the include mechanisms. If one of those refers to a domain that doesn't have a valid SPF record, permerror is the result, and even the +all at the end won't override a permerror.

See here for more info.

Also, you're correct: adding +all to the end of the SPF record basically renders everything else in the record moot, unless you're testing for errors.
ASKER CERTIFIED SOLUTION
Avatar of DrDave242
DrDave242
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of David Spigelman

ASKER

I see. Yeah, I guess you could, but you're right - it wouldn't make much sense.

Well, I just checked. All the includes do have SPF records. Most of them have their own includes that are redundant with the others (i.e. xxxx.com and yyyy.com and zzzz.com all have most of the same +ip4 filters), but they're there. One of them has a couple of includes of its own, and they also have valid SPF records.

So while your explanation makes sense as to why theirs passed, it still doesn't explain why the +all didn't pass the one from deadfake.com.
I'll admit, I don't like includes, especially nested includes, as they're a pain to troubleshoot.

My best guess is that the IP used to send the real message from the customer's domain matched a mechanism in the record before it was parsed to the point of the error (and that match gave a PASS result), but the IP used to send from deadfake.com didn't, so the error was encountered. Without knowing the specific mechanisms in the record, though, that's just a guess.
Well, it didn't sound right to me because everything seemed to pass, when I ran it through some of the web-based tools. (e.g. http://emailstuff.org, http://mxtoolbox.com, etc...) So I tested it. I changed the SPF record on one of MY domains so that it ended with a +all, to see whether it passed the SPF check. My SPF record for that domain was very light: Just Google's SPF include. Then I sent myself another message from Deadfake, expecting it to fail, thus proving me right.

But it passed the SPF check, just the way it is supposed to. Here's the mail header:
Authentication-Results: spf=pass (sender IP is x.x.x.x)
 smtp.mailfrom=myotherdomain.com; mymaindomain.com; dkim=none (message not signed)
So you're right. SPF is functioning properly, and there's still an error in their record, probably having to do with some of the nested includes, or the redundancy. Further research needed.

Thanks for helping me figure that out.
Oh - just one point of clarification, as I re-read the thread. To your last point, I'm actually guessing that Deadfake doesn't fail an earlier mechanism, because there are no explicit rejects involved, and there's a +all at the end. I'm guessing that your earlier thought, that there's an error in at least one of the nested includes, is the culprit. It's the only thing that makes any sense.