Barry Leiba wrote on 2023-06-10 01:50:
That's interesting and disturbing if it remains consistent.
Theoretically, DKIM should *never* fail when SPF succeeds, so if
that's happening it means there is:
1. bad signing software,
2. bad verifying software,
3. misconfiguration somewhere,
...or a combination of those three.
I would *really* like to see a current study of this, because I think
it's critical for the future viability of DMARC, whether or not we
accept the proposal to remove SPF.
Not a study, but some data points I've observed:
a) Signing with 3072-bit RSA leads to DKIM verification failures,
because a popular mail gateway product (Cisco ESA) does not support RSA
key lengths larger than 2048 bit.
b) Messages are generated by an automated system without a Date header
and signed by a central MTA. An outgoing mail gateway then adds the
missing Date header (Postfix option 'always_add_missing_headers'), thus
invalidating the DKIM signature.
Such misconfigurations go unnoticed for years until someone checks the
DMARC reports. While aggregate reports are incredibly helpful, it is
still difficult to identify the cause of subtle DKIM failures. I'd wish
that the <human_result> field would be filled by reporting software with
the DKIM verification error message ('body hash did not verify', etc.)
to aid with troubleshooting.
Contacting the report <email> or postmaster address has never worked for
me: if they don't bounce, nobody replies.
c) There is a pattern of similar looking reports, which omit the <dkim>
element in the <auth_results> altogether and always report
<dkim>fail</dkim> in the policy result. I suspect a product, which makes
it a bit too easy to enable DMARC validation without also enabling DKIM
verification, but I wasn't able to identify the product yet.
Regards,
Matt
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
