[opendmarc-users] Deployment problems with Postfix + pypolicyd-spf + OpenDKIM
Nic Bernstein
nic at onlight.com
Mon Aug 19 08:59:01 PDT 2013
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
--
Nic Bernstein nic at onlight.com
Onlight, Inc. www.onlight.com
219 N. Milwaukee St., Suite 2a v. 414.272.4477
Milwaukee, Wisconsin 53202
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.trusteddomain.org/pipermail/opendmarc-users/attachments/20130819/91ff06e6/attachment.htm>
More information about the opendmarc-users
mailing list