[opendmarc-users] pypolicyd-spf integration

[Murray S. Kucherawy]

On Tue, 25 Mar 2014, Nic Bernstein wrote:
> We have been seeing similar behavior with pypolicyd-spf with Postfix 
> (we're using the postfix-policyd-spf-python package with Ubuntu).  It 
> looks to us, from extensive snooping on the opendmarc milter connection, 
> that the header added by pypolicyd-spf never gets to opendmarc, so all 
> messages result in a "spf -1" in the history file.

This sounds like a bug in the postfix implementation of milter, assuming 
your investigation didn't miss anything of course.  The one 
key factor is that the order of the filters in the MTA 
configuration is significant.  For example, in sendmail's 
configuration, I have:

O InputMailFilters=gmilter, sid-filter, spamass-milter, opendkim, opendmarc

The filters are processed in sequence by the MTA.  That means changes made 
by one filter are only visible to filters later in the list.  Header 
fields added, modified, or removed by opendkim are seen by opendmarc. 
However, they would not be seen by gmilter, sid-filter, or spamass-milter.

Is it possible you just need to swap the order in your MTA configuration?

> We have also experimented with various SPF milter implementations, also 
> with Postfix, in an effort to get something working, but have been met 
> with problems there, as well.  Most SPF milters use the insheader() 
> function to "insert" their header (either Authentication-Results: or 
> Received-SPF:) with index -1, which means before the MTA's first header. 
> In that case, however, the milter-added header isn't seen by subsequent 
> milters, even though one sees it in the resulting email message.

Inserting a header field using smfi_insheader() with an index of -1 is an 
error.  libmilter will return an error for such requests.  Maybe that 
filter is doing something improper and failing to detect the resulting 
error?

> We have modified a version of spf-milter-python (the Ubuntu package
> name, not sure of the official name) wherein we removed the "-1" index,
> which allows it to be appended to the header rather than inserted, and
> that works just fine.

That would work.  Also changing the index to 0 or (better) 1 should be 
fine.  The position of the header field in the header doesn't matter.

> We'd love to find a solution with all native Postfix policy daemons, but
> at present this isn't possible.  We're currently looking into adapting
> opendmarc from a milter to a policy daemon, to get around this problem.

What's the difference between a milter and a policy daemon?

-MSK