openARC handles Authentication-Results parsing badly, and thus ignores valid auth headers.

[MrPeteH]

Various RFC-compliant DKIM and ARC softwares produce headers that OpenARC does not understand. I've tracked down the issue to lack of RFC compliance in OpenARC header parsing. This issue report provides a few sample headers that OpenARC doesn't like, then describes the challenge in some specificity.

SUMMARY OF TWO KEY PARSE ISSUES

1. OpenARC doesn't parse CFWS whitespace properly (Folding White Space and Comments.) This ABNF is ubiquitous in key headers.
2. OpenARC doesn't parse AuthServe-ID as dot-atom - appears to assume it is FQDN?
3. OpenARC appears not to handle the AAR header produced by Microsoft. (I am honestly not sure if this is compliant ;) )

SAMPLES CAUSING TROUBLE (ALL are RFC-compliant headers)

1. Produced by OpenDKIM on my own server. (Problem: the comment is standard CFWS and breaks parsing)

    dkim=pass (1024-bit key; unprotected) header.d=their.dom.ain [email protected] header.a=rsa-sha256 header.s=1000073432 header.b=eKmreZ4p;
    dkim-atps=neutral
   

2. Produced by DKIM on a popular hosting service (not sure what SW they use) (Problem: the AuthServe-ID is dot-atom)

    rspamd-786cb55f77-65p7t;
    auth=pass smtp.auth=sample-host [email protected]
   

3. Produced by Microsoft.com (I suspect the issue is the extra " 1" after mx.microsoft.com. Not sure what this is! Is it possible MS is non-compliant??)
   ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dom.ain; dmarc=pass action=none

etc.

DISCUSSION OF THE ISSUE
AFAIK (from experience -- see above -- and code examination), OpenARC parsing is not RFC-compatible with CFWS. What's that?

(ARC-)Authentication-Results header definition ABNF make many references to RFC 5322 CFWS -- Folding White Space and Comments -- which is essentially folded white space plus any amount of [ \t\n] white space plus optional, nestable, () comments which can contain any text at all other than "(", ")" or "\".

Here are ABNF references in the RFC's:

• CFWS in RFC 5322
• Authentication-Results in RFC 5451
• ARC-Authentication-Results in RFC 8617

As a dev, that sounds complex to me. I searched for some help towards a functioning implementation. To get us started, here is a regexp definition for CFWS, extracted from http://www.watersprings.org/pub/id/draft-seantek-mail-regexen-01.html#rfc.section.3.2

(?(DEFINE)
 (?<FWS>(?:[\t ]*\r\n)?[\t ]+)
 (?<CFWS>(?:(?&FWS)?(?&comment))+(?&FWS)?|(?&FWS))
 (?<ctext>[!-'*-\[\]-~])
 (?<ccontent>(?&ctext)|(?&quoted_pair)|(?&comment))
 (?<comment>\((?:(?&FWS)?(?&ccontent))*(?&FWS)?\))
 (?<quoted_pair>\\[ -~])
)

[MrPeteH]

NOTE: openDKIM verification also parses Authentication-Results badly in the same way. I'm tired... gotta sleep...

[abeverley]

Hi @MrPeteH - I wondered if you ever got to the bottom of any of this? I have done some limited testing, and I am also finding that ARC signatures from Microsoft.com are showing as failed (the only other ones I have tried are Gmail, and they seem to be passing).

[flowerysong]

@abeverley This issue is unlikely to cause signature verification failures; you're more likely to be hitting #121, because Microsoft does not include the optional t tag in their signatures.

[abeverley]

Brilliant, thanks @flowerysong that has indeed fixed that problem :-) I'm now finding that although the messages are passing ARC at my end, the ARC signature that I am creating is showing as failed at the receiving end (only for the same Microsoft emails). This is a different problem though so I will continue investigating (I'm trying some of the other PRs, but no luck yet).

[MrPeteH]

@abeverley I've proven that it IS an issue... someone needs to write some code to fix it. I will eventually get around to that, but I don't have spare Round Tuits these days... my 23 year coworker suddenly passed away last June and I've been scrambling ever since.

[flowerysong]

Having recently touched the Authentication-Results code, I found a number of other issues with it but can't see any sign that this report is correct.

 dkim=pass (1024-bit key; unprotected) header.d=their.dom.ain [email protected] header.a=rsa-sha256 header.s=1000073432 header.b=eKmreZ4p;
 dkim-atps=neutral

This was parsed correctly by the unmodified upstream code, which handles CFWS fine. It was unclear whether you meant that this was the entire header, so for testing I added an authserv-id. If this is in fact the entirety of the header, it is not RFC compliant and a parsing failure should be expected.

 rspamd-786cb55f77-65p7t;
 auth=pass smtp.auth=sample-host [email protected]

This was also parsed correctly.

Without more information (like what behaviour you saw that led you to believe that they were not being parsed correctly) there's not anything actionable in this report.