>>> Authentication-Results: domain.tld, spf=pass [email protected]
>>
>> 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?
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
