[opendmarc-users] Deployment problems with Postfix + pypolicyd-spf + OpenDKIM

[Nic Bernstein]

Scott,
Could you please post (or email off-list) the contents of a history file
pertaining to a message for which DMARC worked?  That's the only way I
know of to tell if it is, in fact, scoring SPF.  According to earlier
list posts, OpenDMARC will pass a message as long as either SPF or DKIM
pass, so without the history file data, it's hard to tell what's happening.

For completeness, the default setting of "smtpd_delay_reject = yes" is
in place, there are no "smtpd_data_restrictions," and
"policyd-spf_time_limit = 3600."

Cheers,
    -nic

PS - To enable writing the history file (disabled by default) either add
or uncomment the "HistoryFile" directive in opendmarc.conf:
    HistoryFile /var/run/opendmarc/opendmarc.dat

On 08/16/2013 05:20 PM, opendmarc-users-request at trusteddomain.org wrote:
> On Friday, August 16, 2013 16:42:07 Nic Bernstein wrote:
>> > Folks,
>> > We are attempting to deploy opendmarc(1.1.3) for receiving, with Postfix
>> > (2.9.2), pypolicyd-spf(1.2) and OpenDKIM(2.6.8).  We are getting mixed
>> > results, in that while we do see the proper Authentication-Results
>> > headers in our messages, opendmarc seems not to see the SPF headers.
>> > Here is a sample from a recent test message:
>> > 
>> >     Authentication-Results: smtp.onlight.com; spf=pass (sender SPF
>> > authorized) smtp.mailfrom=gmail.com (client-ip=209.85.212.68;
>> > helo=mail-vb0-f68.google.com; envelope-from=nb1onlight at gmail.com;
>> > receiver=nic at onlight.com) Authentication-Results: smtp.onlight.com;
>> > dkim=pass
>> >     	reason="2048-bit key; insecure key"
>> >     	header.d=gmail.com header.i=@gmail.com header.b=gzXzLLLE;
>> >     	dkim-adsp=pass; dkim-atps=neutral
>> >     <...>
>> >     Authentication-Results: ujiji.onlight.com/E85322025F; dmarc=pass
>> > header.from=gmail.com
>> > 
>> > However, in the history file we see this:
>> > 
>> >     job E85322025F
>> >     reporter smtp.onlight.com
>> >     received 1376684253
>> >     ipaddr 209.85.212.68
>> >     from gmail.com
>> >     mfrom gmail.com
>> >     dkim gmail.com 0
>> >     spf -1
>> >     pdomain gmail.com
>> >     policy 15
>> >     rua mailto:mailauth-reports at google.com
>> >     pct 100
>> >     adkim 114
>> >     aspf 114
>> >     p 110
>> >     sp 0
>> >     align_dkim 4
>> >     align_spf 5
>> >     action 2
>> > 
>> > We have postfix configured like so:
>> > 
>> >     /etc/postfix/main.cf:
>> > 
>> >         smtpd_recipient_restrictions = permit_sasl_authenticated,
>> >                 permit_mynetworks,
>> >                 reject_unknown_recipient_domain,
>> >                 reject_unauth_pipelining,
>> >                 reject_unauth_destination,
>> >                 check_policy_service unix:private/policyd-spf,
>> >                 permit_auth_destination,
>> >                 reject
>> >         smtpd_milters = unix:/var/run/opendkim/opendkim.sock
>> >                 unix:/var/run/opendmarc/opendmarc.sock
>> > 
>> >     /etc/postfix/master.cf:
>> > 
>> >         policyd-spf  unix  -       n       n       -       0       spawn
>> >                 user=nobody argv=/usr/bin/policyd-spf
>> > 
>> > Yet it appears that the Authentication-Results header from pypolicyd-spf
>> > is not in the message when it is processed by opendmarc.  We turned on
>> > full debugging in pypolicyd-spf, and added some debugging to mlfi_eom in
>> > an effort to see what's going on, but while we do see the opendkim
>> > headers being processed (result_method=1,5,7), we do not see the
>> > SPF(result_method=4) stuff at all.  It appears we're not even entering
>> > the  "if (ar.ares_result[c].result_method == ARES_METHOD_SPF)" section
>> > of mlfi_eom(), even though pypolicyd-spf appears to be prepending the
>> > proper header, and we do see that header in the final email:
>> > 
> ...
>> > 
>> > Anyone have any thoughts?  It seems as though the milters are getting
>> > the message before the policy daemon, and yet the logs would appear to
>> > say otherwise (and they should get it after).
>> > 
>> > Any guidance would be greatly appreciated.
> I have almost this exact setup and it's working.  I'm specifying the milters 
> using -o for the relevant service in master.cf instead of in main.cf, but 
> other than that, I think it's identical.
>
> The logs clearly show that the SPF check is being done and I don't see how it 
> couldn't be accomplished prior to the DMARC check as it's done at RCPT TO and 
> the DMARC check can't be done until after DATA.
>
> Do you have any smtpd_data_restrictions defined?
>
> You might try defining TrustedAuthservIDs in your opendmarc.conf to include 
> smtp.onlight.com if you haven't already.
>
> Scott K
>

-- 
Nic Bernstein                             nic at onlight.com
Onlight, Inc.                             www.onlight.com
219 N. Milwaukee St., Suite 2a            v. 414.272.4477
Milwaukee, Wisconsin  53202