Re: [dmarc-ietf] Spirit of RFC8601 section 5 for invalid A-R headers

[Damian Lukowski <[e-mail]>]

>>> Authentication-Results: domain.tld, spf=pass smtp.mailfrom=x@y.z
>>
>> Needs to be removed? I say no.
> 
> 
> Yes, and log it.

Please notice the comma instead of the semicolon, it wasn't a typo.
Would you still remove it?

>>> Authentication-Results: domain.tld; {garbage}
>>
>> Needs to be removed? I say no.
> 
> Yes, and log it.

Interesting, you suggest to parse "lazily", i.e. as soon as a token
looks like an authserv-id, treat it as such.

> Both cases are renamed to Old-Authentication-Results anyway.  The part that
> would log it, however, doesn't recognize the quotes (I'm going to fix it now)
> and intermittently removes the header.

I wanted to object that the RFC does not allow to tamper with "innocent"
headers, but it actually does not forbid it. That said, I could even
remove previous A-R headers altogether and be RFC compliant, so a lazy
evaluation parser can be compliant as well.

Thanks.

> Note that some tools, e.g. Thunderbird DKIM-Verifier[*] can be configured to
> either "Read Authentication-Results header" or not.  Hence is makes sense to
> rename all on entry.
> 
> Note2: even if a tool accepted a list of trusted authserv-id's, consider a MUA
> simultaneously accessing two mailboxes, at example.com and example.org, say.
> Of course you would configure the tool to trust both of their authserv-id
> (which is already beyond what an average user is willing to configure).  Then,
> a malicious party can send you a message at your @example.com address, bearing
> a faked Authentication-Results by example.org.  Should the tool trust it?

Wouldn't a trust-list per mailbox solve the issue, instead of a global
trust-list?