On 2021-04-19 14:42, Simon Wilson wrote:
askdns __KAM_DMARC_POLICY_REJECT _dmarc._AUTHORDOMAIN_ TXT
/^v=DMARC1;.*\bp=reject;/
run anyway?
note rulename starts with __ ?
Yes, and the doco says "...rules start with a double underscore, so
they are run and treated as having no score". So my question remains -
It says "are run", so do those rules run the askdns queries if or if
not the subsequent meta rules are enabled or disabled? If I am not
using the meta rules (by setting scores to 0) do I also need to
disable the askdns rules to stop any unneeded dns calls?
yes all __ is runnined, for all mails, even if domains have no dmarc
its a waste rule if this happend
please in dev@ make that sql cached result or drop it
Or only if the resultant metas which call on them have a
score value <> 0?
opendkim opendmarc openarc sid-milter all have 127.0.0.1 whitelisted,
and possible aswell ::1
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
the above kam rule is ment to be meta'ed with NO_RELAY or ALL_TRUSTED
or other tests that only hit on internal mails
so to ask now, did you configure trusted_networks internal_networks
in spamassassin ?, it have to know all wan ips for your own server /
servers
Yes, my trusted_networks, internal_networks and msa_networks are all
set correctly... I had a long discussion with this mailing list on the
subject last year and got excellent help on resolving that! :)
sometimes its needed to debug
all the best
