[opendmarc-users] pypolicyd-spf integration

[Scott Kitterman]

On Tuesday, March 25, 2014 11:45:33 Nic Bernstein wrote:
> Cristian,
> 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.
> 
> We did report this issue previously (via this list on 16 Aug, 2013) and
> never heard of any resolution.  But, we didn't fully understand the
> issue at the time.
> 
> From our investigations, it appears that the policy daemon modified
> headers are not passed along to the milters.
...
> 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.
...
Unfortunately, the box I could use to test/verify this for sure is dead at the 
moment, but here's what I have had set up which (co-incidentally, since I 
didn't know about this issue) works around the problem:

Instead of doing everything in one smtpd process, I have two.

Usual:

smtpd ------> post-delivery processing (massive oversimplification)
    |
    |
SPF policy daemon
opendkim
opendmarc

Mine:

smtpd    -> transparent    -> smtpd    -> post-delivery processing
    |             filter (spam/virus)     |
SPF policyd                                opendkim
                                                    opendmarc

My reason to do it this way was to mimimize pre-queue filtering, but as a side 
benefit, the SPF authentication results has already been inserted by a previous 
process before the smtpd that sends it to the milters acts on it.  That 
should, I think, avoid the problem.

Also, you can't do DKIM/DMARC as a policy daemon because the information you 
need isn't exposed to the policy interface.

Scott K