Re: [dmarc-ietf] auth-res vs. dmarc

[Michael Thomas <[e-mail]>]

On 12/29/20 12:47 PM, Todd Herr wrote:
> Unless those values in parens are a MUST requirement, the dmarc=fail 
> is highly misleading. I haven't even seen any specification for the 
> dmarc part of auth res in rfc  7601, which may be part of the problem. 
> I don't see any normative language which would update rfc7601 in dmarc 
> with the syntax and semantics of the dmarc field.
>
> We're going to have to agree to disagree here. I had no hand in 
> writing RFC 7601 or its predecessors, but I believe DMARC is covered 
> under "Extension Methods" in section 2.7.6 
> (https://tools.ietf.org/html/rfc7601#section-2.7.6 
> <https://tools.ietf.org/html/rfc7601#section-2.7.6>) and "Email 
> Authentication Results Names" in section 6.6 
> (https://tools.ietf.org/html/rfc7601#section-6.6 
> <https://tools.ietf.org/html/rfc7601#section-6.6>), which references 
> RFC 7489 section 11.2, which in turn defines pass, fail, temperror, 
> and permerror as it pertains to DMARC.
>
> As for the parenthetical bits, I believe they too are covered in RFC 
> 7601 section 2.7.6:
>
>     Authentication method implementers are encouraged to provide adequate
>     information, via message header field comments if necessary, to allow
>     an MUA developer to understand or relay ancillary details of
>     authentication results.  For example, if it might be of interest to
>     relay what data was used to perform an evaluation, such information
>     could be relayed as a comment in the header field, such as:
>
>          Authentication-Results:example.com  <http://example.com>;
>                    foo=pass bar.baz=blob (2 of 3 tests OK)

So Google is just adding an informative comment which is free style text 
that just happens to have the juicy bits (the interesting parts dmarc 
record), which cannot be counted on. So that's useless for the MUA 
trying to use auth-res. You would never display a DMARC FAIL or fail of 
any kind for p=none. It doesn't make sense to the user. Likewise, even 
if we're talking about a downstream MTA parsing the auth-res, it will be 
useless to it as well because it has the same problem not knowing the 
context of the "failure".


>     At the very least this needs to be straightened out because
>     auth-res, to Ned's earlier point, can have consumers in the form
>     of MUA's.
>
> The format/contents of an auth-res header and its impact on MUA 
> development seem to be a bit off-charter for this working group, but 
> I'll say that it might be a heavy lift to try to get major mailbox 
> providers who run their own highly customized MTAs to comply with any 
> effort to fully standardize. Their interpretations of the headers that 
> they insert are done to optimize usage with their message storage 
> infrastructure and their web and mobile clients, the latter of which 
> the vast majority of their mailbox holders use. I don't think they 
> have much incentive to standardize to make things easier for an open 
> source MUA developer, but the MUA developer can probably cover most 
> variations relatively easily with a simple bit of if-then-else logic 
> based on the provider.
>
To Ned's point though: what is auth-res's purpose and why is it standard 
track if it can't provide a complete encapsulation of the state of 
authentication necessary for downstream consumers? For DMARC in 
particular, it falls far short since there is no way of knowing the 
policy. I do think that's DMARC's problem to solve somehow, regardless 
of process. And if process is a problem, that's processes fault.

Mike, coming at completely from the standpoint of modifying thunderbird 
plugin code