#102 Strange spf results
Bug forwarded from a Debian user (the Debian package uses libspf2 for SPF):
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761451
I started importing opendmarc into a database and I'm trying to
understand what all the data is. In the messages table I
currently see:
opendmarc=> select spf, count(*) from messages group by spf;
spf | count
-----+-------
-1 | 12229
1 | 250
2 | 8
0 | 188
(4 rows)
opendmarc-reports changes that into:
case 0 { $spfresultstr = "pass"; }
case 2 { $spfresultstr = "softfail"; }
case 3 { $spfresultstr = "neutral"; }
case 4 { $spfresultstr = "temperror"; }
case 5 { $spfresultstr = "permerror"; }
case 6 { $spfresultstr = "none"; }
case 7 { $spfresultstr = "fail"; }
case 8 { $spfresultstr = "policy"; }
case 9 { $spfresultstr = "nxdomain"; }
case 10 { $spfresultstr = "signed"; }
case 12 { $spfresultstr = "discard"; }
else { $spfresultstr = "unknown"; }
So both -1 and 1 are "unknown". That doesn't seem to be making
much sense to me. I think most of those -1's come from domains
that do not publish SPF results, so I would expect the result to
be 6 instead of -1.
I think the 1s are actually SPF pass cases, at least for the few I
tried to look at.
In any case, the number of SPF passes seems to be too low, even if
both 0 and 1 are pass, lots more results actually have an SPF pass.
I also find it weird that the spfresultstr has the same cases as
the dkimresultstr.
-1 is the default SPF result. It will make its way through to the history file if anything at all causes the SPF check not to happen. That might happen if, for example, opendmarc is not doing its own SPF evaluation and there was no usable Authentication-Results field present. The definitions of "none" and "neutral" from RFC4408 and the one that replaced it simply don't apply in that case.
The codes actually map to the ARES_RESULT constants that can be found in opendmarc/opendmarc-ar.h, so the 0s are passes. I don't know where the 1s might be coming from; after a look through the code, I can't see how they're even possible. (1 is "ARES_RESULT_UNUSED", which isn't referenced anywhere.)
Can you produce a message and configuration that causes the 1s to appear?
I'm not sure what all the details are that you need. I'm using postfix and running things like postfix-policyd-spf-python, opendkim and opendmarc.
postfix-policyd-spf-python is set up with "Header_Type = AR". It was my understanding that opendmarc at some point needed headers in that format to pick it up, but for later versions that might have changed? It's set up as part of the smtpd restrictions using a check_policy_service.
opendkim and opendmarc are set up as milter instead. As far as I know they both should get run after the check_policy_service and the AR header should be present in what they get to see.
The last email with SPF result -1 had the following headers:
Authentication-Results: defiant.e-webshops.eu; dmarc=none header.from=gmail.com
Authentication-Results: defiant.e-webshops.eu;
dkim=fail reason="signature verification failed" (2048-bit key; insecure) header.d=gmail.com header.i=@gmail.com header.b=mSCVyAs1;
dkim-adsp=none (insecure policy); dkim-atps=neutral
Authentication-Results: defiant.e-webshops.eu; spf=none (no SPF record) smtp.mailfrom=openssl.org (client-ip=194.97.150.230; helo=mta.openssl.org; envelope-from=openssl-users-bounces@openssl.org; receiver=kurt@roeckx.be)
I was expecting 6 in this case, not -1.
I can't find any recent case of SPF having the value of 1. It seems the log file also only have the values for the past month. I think this is one of the cases where it indicated 1:
Authentication-Results: defiant.e-webshops.eu; spf=pass (sender SPF authorized) smtp.mailfrom=lists.mozilla.org (client-ip=63.245.216.66; helo=lists.mozilla.org; envelope-from=dev-tech-crypto-bounces+kurt=roeckx.be@lists.mozilla.org; receiver=kurt@roeckx.be)
Authentication-Results: defiant.e-webshops.eu; dmarc=none header.from=gmail.com
The dkim AR seems to be missing for some reason, the order of the headers seems to be strange.
Can you attach your configuration file? I'd like to get as close to your setup as possible to reproduce the problem.
I'm a bit confused now because you've got Authentication-Results that report SPF from some upstream filter, but also the original post says you're doing SPF evaluation using libspf2.
Anyway, it looks like you can also get -1 if none of the Authentication-Results can be used (wrong authserv-id, meaning you don't recognize "defiant.e-webshops.eu" as valid), and you don't have both "SPFIgnoreResults" and "SPFSelfValidate" set.
config file attached.
Can you give the complete message for the two failure cases you just cited? I need at least the From: field, for example, to see what the library decides about alignment.
The one returning 0
One returning -1
The one about 0 should say 1
I think Scott's comment about libspf2 is that the version in Debian is build against that.
Last edit: Kurt Roeckx 2015-02-09
I think this might fix it, though I'm still looking at other possible code paths. Please give it a try. It certainly explains the unexpected -1 case, but not the 1 case (for which I still think there's no possible code path).
Kurt,
Do you want me to make a test package for wheezy with this (I know you could do it, but I also don't want to assume you will and sidestep my responsibilities as maintainer)?
It looks like the patch solved the issue. I now only get 0 (pass), 2 (softfail) and 6 (none) so far.
It looks good. I see the following stats so far:
198 * 0 (pass)
4 * 2 (softail)
7 * 3 (neutral)
2 * 5 (permerror)
559 * 6 (none)
2 * 7 (fail)
Which are all the possible results for SPF other than temperror.
Excellent. The patch is part of the 1.3.1 release.
v1.3.1 released.