----- Message from Dan Mahoney <d...@prime.gushi.org> ---------
Date: Thu, 1 Apr 2021 16:19:05 -0700
From: Dan Mahoney <d...@prime.gushi.org>
Subject: Re: Milters and policy
To: si...@simonandkate.net
Cc: postfix-users@postfix.org
On Mar 31, 2021, at 18:23, Simon Wilson <si...@simonandkate.net> wrote:
...if multiple milters are called are they run in order specified?
smtpd_milters = inet:127.0.0.1:8891,inet:127.0.0.1:8893
yes
I.e. in the example above if OpenDMARC is to see and trust an
already-run OpenDKIM Authentication-Results header is the order of
specifying the milters important?
yes opendkim need to run before opendmarc, and if you have openarc
place that before opendkim, it can be messy if opendmarc checks
openarc results, remeber it also need to trust AR headers to be
considered good info
but i do not use milters self, only do all i need with fuglu
Thanks again Benny. I have policyd-spf set to insert an AR header,
and OpenDMARC set to trust the Authserv-Id added in
Authentication-Results headers by policyd-spf and OpenDKIM. All
working nicely and good to understand the sequence.
Please read CVE-2019-20790, and tell me you’ve found a way to tell
PyPolicyd not to trust the SMTP HELO to generate a passing AR header.
-Dan
In the interests of open disclosure of your interests, I assume
d...@prime.gushi.org = https://github.com/thegushi = OpenDMARC
developer?
This is possibly off-topic for the Postfix list... maybe not.
Re the risk from the CVE to my setup...
I run policyd-spf as a postfix check_policy with reject on fail (on
both HELO and MAILFROM), and assuming a mail gets past that (99% do),
I then use that Pass along with OpenDKIM and OpenDMARC to contribute
to Spamassassin scoring. My DMARC Spamassassin rules do not apply a
-ve on a pass, only a +ve on a fail.
The impact of a false pass from DMARC (particularly as our Webmail
system - Horde - does not show any added trust for a dmarc pass) would
be failure to apply a negative Spamassassin score from a the missed
DMARC fail. With my mail setup and users the impact of that is
probably manageable... but agreed it is not ideal.
What concerns me as much as anything is that each of the apps' devs in
question (pypolicyd-spf and opendmarc) are each pointing at each other
:-/
https://bugs.launchpad.net/pypolicyd-spf/+bug/1838816/comments/4:
"my belief that the issue here is a DMARC processor failing to do
alignment validation correctly"
https://github.com/trusteddomainproject/OpenDMARC/issues/49#issuecomment-802242666
"Honestly, this CVE seems more to belong to py-policyd than OpenDMARC."
What would be nice would be if the two of you worked together on
coming up with a fix...
Anyways...
I see two possible workarounds (not fixes).
1. Setting pypolicyd to HELO_Reject = No_Check. RFC7208 indicates that
MAILFROM and HELO are both equally valid for an SPF result, *BUT* the
vast majority of my SPF checks trigger pass or fail on MAILFROM (I've
had 3 spf HELO passes in 10 days on HELO, thousands on MAILFROM).
Testing pypolicyd-spf with HELO_reject = No_Check results in spf=none
for those. Removing the HELO check means that OpenDMARC can assume any
spf result it is given is based on MAILFROM.
2. Tell OpenDMARC to *NOT* trust any existing spf result and do its
own. I.e. SPFIgnoreResults true. This obviously doubles SPF processing
time, and relegates pypolicyd-spf to purely an inbound policy reject
check. If one is not using pypolicyd to reject then this would be
pointless, and it could be removed from the stack.
Thoughts?
Simon.
--
Simon Wilson
M: 0400 12 11 16
----- End message from Dan Mahoney <d...@prime.gushi.org> -----
--
Simon Wilson
M: 0400 12 11 16
