Re: [dmarc-ietf] Why does DKIM fail when SPF succeeds (was: DMARC2 & SPF Dependency Removal)

[OLIVIER HUREAU <[e-mail]>]

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" <mail=[e-mail]> 
À: "dmarc" <[e-mail]> 
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 
[e-mail] 
https://www.ietf.org/mailman/listinfo/dmarc