[opendmarc-users] Deployment problems with Postfix + pypolicyd-spf + OpenDKIM
Scott Kitterman
sklist at kitterman.com
Mon Aug 19 09:09:16 PDT 2013
That doesn't work here either, so I'll send one of those to Murray too.
Scott K
On Monday, August 19, 2013 10:59:01 Nic Bernstein wrote:
> Scott,
> Opendmarc /does/ know about Received-SPF. Check the RELEASE_NOTES:
>
> 1.1.3 2013/04/13
> Fix reporting of nonexistent SPF results. Problem noted by
> Andrei Ioachim.
> Fix extraction of data from Received-SPF. Problem noted by
> Todd Lyons.
> <...>
> 0.2.0 2012/08/24
> Feature request #15: If there's no SPF Authentication-Results field,
> look for a Received-SPF field to get SPF results.
>
> In opendmarc.c there is an explicit check for Received-SPF headers in
> case no Authentication-Result header is found for SPF [look for line
> 2239 "if (!wspf)"]. Failing that [look for line 2271 "if (!wspf)"] we
> end up with "spf -1" in the history, which means no SPF information at all.
>
> Thanks for forwarding test data to Murray.
>
> Cheers,
> -nic
>
> On 08/19/2013 10:22 AM, Scott Kitterman wrote:
> > I'm reasonably certain that's a test methodolgy error in Maarten's case.
> > Opendmarc doesn't know anything about Received:SPF. I can make it fail
> > locally with the opendmarc milter in test mode. I'm going to send Murray
> > the messages (one fails, one doesn't) offlist to see what he can figure
> > out. Since it fails in test mode with a message read from a file, it's
> > not a processing sequence issue.
> >
> > Scott K
> >
> > On Monday, August 19, 2013 09:48:56 Nic Bernstein wrote:
> >> Scott,
> >> Thanks much. Also, for completeness, I have tested this using the "SPF"
> >> mode (Received-SPF header) of pypolicyd-spf, as Maarten Oelering reports
> >> success with, and have the same results. The Received-SPF header is in
> >> the final message, but is not seen by opendmarc.
> >>
> >> Cheers,
> >>
> >> -nic
> >>
> >> On 08/19/2013 09:29 AM, Scott Kitterman wrote:
> >>> So I'm about 98.7% sure I tested this before and it was working
> >>> correctly.
> >>> It's not now, so let me troubleshoot.
> >>>
> >>> Scott K
> >>>
> >>> On Monday, August 19, 2013 09:07:04 Nic Bernstein wrote:
> >>>> 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
> >>>
> >>> _______________________________________________
> >>> opendmarc-users mailing list
> >>> opendmarc-users at trusteddomain.org
> >>> http://www.trusteddomain.org/mailman/listinfo/opendmarc-users
> >
> > _______________________________________________
> > opendmarc-users mailing list
> > opendmarc-users at trusteddomain.org
> > http://www.trusteddomain.org/mailman/listinfo/opendmarc-users
More information about the opendmarc-users
mailing list