On 2022-05-30 at 15:12:34 UTC-0400 (Mon, 30 May 2022 15:12:34 -0400)
Alex <mysqlstud...@gmail.com>
is rumored to have said:
[...]
$ spamassassin -t -D DMARC < dmarc-reject1 2>&1|grep -i dmarc
May 30 14:59:14.894 [1250699] dbg: DMARC: using Mail::DMARC::PurePerl
for
DMARC checks
May 30 14:59:15.034 [1250699] dbg: DMARC: result: pass, disposition:
none,
dkim: pass, spf: fail (spf: pass, spf_helo: fail)
DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DMARC_PASS,
Did SPF fail or pass above? It did hit SPF_PASS but it also
hit SPF_HELO_NONE.
SPF_PASS tells you that the envelope sender domain has a SPF record that
validates the connecting IP.
SPF_HELO_NONE tells you that the client introduced itself with a
hostname that has no SPF record.
Those two states are not in any fundamental conflict with each other.
It is curious that SA succeeds on its own but it's under amavisd that
it
appears to fail.
This would imply that amavisd has one of these issues relative to
running the spamassassin script from the command line:
1. It is using different user-level preferences.
2. It is using different systemwide rules & preferences.
3. It is unable to access something on the system due to security config
(permissions, SELinux, AppArmor, chrooting, etc.) that your login shell
is able to access.
4. Something substantive has changed between when amavisd ran and when
you are checking manually, e.g. DNSBL changes, custom DNS config, new
rules, etc.
If you can eliminate all of those, you will have established the
existence of magic.
I also see the following debug messages:
May 30 15:06:54.097 [1255659] dbg: check: tagrun - tag AUTHORDOMAIN is
now
ready, value: indeedemail.com
May 30 15:06:54.325 [1255659] dbg: askdns: rule
__KAM_DMARC_POLICY_REJECT
depends on tags: AUTHORDOMAIN
May 30 15:06:54.325 [1255659] dbg: check: tagrun - tag AUTHORDOMAIN
was
ready, runnable immediately: CODE(0x563c09e23d70)
May 30 15:06:54.325 [1255659] dbg: askdns: launching query
(__KAM_DMARC_POLICY_REJECT): _dmarc.indeedemail.com
May 30 15:06:54.325 [1255659] dbg: async: query 50034/IN/TXT/_
dmarc.indeedemail.com already underway, adding no.4, rules:
__KAM_DMARC_POLICY_REJECT
May 30 15:06:54.518 [1255659] dbg: async: calling callback on key
TXT/_
dmarc.indeedemail.com, rules: __KAM_DMARC_POLICY_REJECT
May 30 15:06:54.518 [1255659] dbg: askdns: answer received
(__KAM_DMARC_POLICY_REJECT), rcode NOERROR, query IN/TXT/_
dmarc.indeedemail.com, answer has 1 records
May 30 15:06:54.518 [1255659] dbg: askdns: domain
"_dmarc.indeedemail.com"
listed (__KAM_DMARC_POLICY_REJECT): v=DMARC1; p=reject; sp=reject;
rua=mailto:f48jz-9...@rua.dm
arc.emailanalyst.com,mailto:dm...@indeed.com; ruf=mailto:
f48jz-9...@ruf.dmarc.emailanalyst.com; adkim=r; aspf=r; pct=100
So it did hit __KAM_DMARC_POLICY_REJECT but just not whatever else was
necessary to fulfill the requirements for the KAM_DMARC_REJECT when
run
with SA manually.
__KAM_DMARC_POLICY_REJECT means that the DMARC record for the domain
part of the From header address has a p=reject attribute.
KAM_DMARC_REJECT requires __KAM_DMARC_POLICY_REJECT and NEITHER a
verified DKIM signature from the domain part of the From header address
(DKIM_VALID_AU) NOR a SPF_PASS for the domain part of the envelope
sender address, which must match the domain part of the From header
address.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
