Hi, > 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.
I have also discovered that some report sender does not send valid aggregate reports because the DKIM and SPF auth Result type are not in the right position. According to the RFC 7489 XSD, Auth Result type is as follows: <xs:complexType name="AuthResultType"> <xs:sequence> <!-- There may be no DKIM signatures, or multiple DKIM signatures. --> <xs:element name="dkim" type="DKIMAuthResultType" minOccurs="0" maxOccurs="unbounded"/> <!-- There will always be at least one SPF result. --> <xs:element name="spf" type="SPFAuthResultType" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> According to XML definitions, the position cannot be swapped and the DKIMAuthResultType (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? Best, Olivier De: "Matthäus Wander" <[email protected]> À: "dmarc" <[email protected]> Envoyé: Dimanche 23 Juillet 2023 22:05:44 Objet: [dmarc-ietf] Why does DKIM fail when SPF succeeds (was: DMARC2 & SPF Dependency Removal) 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 [email protected] https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
