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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
