[opendmarc-users] pypolicyd-spf integration

[Patrick Ben Koetter]

* Murray S. Kucherawy <msk at blackops.org>:
> 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 tested milters in Postfix recently and we *could not* observe that Postfix
would mix up the the order of the filters in the MTA configuration. It
followed the order at all times.


> >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?

A policy daemon uses the "Postfix policy delegation protocol". It only sees
SMTP session data. A MILTER additionally sees anything that is transmitted
within DATA and END_OF_DATA.

"Postfix policy delegation protocol"
<http://www.postfix.org/SMTPD_POLICY_README.html>

p at rick


-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein