OLIVIER HUREAU wrote on 2023-07-24 11:20:
> 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.
[...]
According to XML definitions, the position cannot be swapped and
theDKIMAuthResultType (if there is one) must appear before the
SPFAuthResultType.
However, some reporter does not follow this implementation.
E.g: the no longer maintained Linkedin dmarc-sys :
https://github.com/LinkedInAttic/dmarc-msys/blob/master/dmarc_report.py#L240
<https://github.com/LinkedInAttic/dmarc-msys/blob/master/dmarc_report.py#L240>where
SPFAuthResultType appears before DKIMAuthResultType.
Are you talking about the same error?
Good catch. These are two different issues, though.
In the issue I mentioned, the mail receiver performs DMARC validation
and sends an aggregate report, but does not perform DKIM verification
even though the mail has a DKIM-Signature.
I think the following screenshot offers an explanation of what causes
the issue:
<https://dmarcian.com/wp-content/uploads/2023/02/Cisco-ESA-Maal-Flow-Policies-update-defaults-1024x611.png>
The admin GUI of a mail gateway offers the option to deactivate DKIM
verification (next to DKIM signing), thus some people click it by
accident or by lack of understanding. Not an issue that can be fixed by
the DMARC spec.
Regards,
Matt
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
