They do yes. However I use fetchmail to retrieve emails from some
services; fetchmail presents into the inbound stack as being from
127.0.0.1 - so I do not use the milters' "whitelists" to decide
whether or not to run on inbound email, I use directed flow through
postfix and amavisd to decide whether or not the milters are run.
make your fetchmail use mda, problem solved
In the context of my query here on *outbound* email... I do *not* run
milters on outbound email, so it is only the KAM DMARC rules which
were running regardless which generated an issue.
fetchmail is inbound not outbound, kam rule is not a milter
Hi Benny,
The original issue was OUTbound all-internal email. You mentioned
milters whitelisting 127.0.0.1 which as my milters only run on INbound
is irrelevant to the original issue (none of my milters run on
internal-->internal email). My comment on fetchmail was to point out
one example of where I change milters to *not* ignore localhost: you
cannot assume milters *always* ignore localhost just because they do
by default. And I do not have a problem with fetchmail to solve - it
works well, configured to drop to my smtphost where milters *do*
process it as inbound email, even though it is seen as being from
localhost (the fetchmail daemon smtphost drops it to a specific
postfix instance).
Anyway, back to OUTBOUND internal-->internal :)
When SA runs in this scenario email has not been DKIM signed, SPF is
irrelevant, and the email has never left my perimeter - a DMARC
evaluation should NOT be run. It looks like there are some good ideas
on how to resolve that, for which I am grateful.
FWIW...
Whilst I can see the value of the KAM DMARC rules for an "out of the
box" install of SA, I will likely leave them disabled on ALL email: I
have a robust inbound milter setup which adds sequentially trusted
headers for SPF, DKIM, ARC and DMARC.
My preference is for SA to use \existing trusted headers/ to base
DKIM, SPF, ARC, DMARC score decisions on - *NOT* to run additional DNS
lookups to do its own when they have already been done (even though
likely nameserver-cached).
I already do this with DMARC, which SA does not do DNS-checking tests
for (out of the box, i.e. without KAM rules). I have custom rules in
local.cf which use the headers provided by OpenDMARC:
e.g.
header DMARC_FAIL_REJECT Authentication-Results =~
/mail\.simonandkate\.net; dmarc=fail \(p=reject/
describe DMARC_FAIL_REJECT DMARC check failed (p=reject)
score DMARC_FAIL_REJECT 6.0
That works fine, and has the bonus of only running when I expect it to
- which is when I have ensured the relevant milters have run and added
trusted headers on inbound email.
Simon.
--
Simon Wilson
M: 0400 12 11 16
