On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely <ves...@tana.it> wrote:
> On Tue 29/Dec/2020 22:02:20 +0100 Michael Thomas wrote:
> > 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 agree with Michael here. When a (trusted) dmarc=fail is seen
> downstream, its consumers neither know what policy was specified nor
> whether it was honored.
>
That depends on your definition of "downstream", I guess.
MDAs and local clients (web and mobile) at the mailbox provider will have
the information they need.
Third-party MUAs perhaps won't, but MUAs aren't really responsible for
message disposition in a way that is relevant to DMARC's primitive
disposition choices, except in those cases where they're POP clients that
download everything to a local message store, I guess; maybe in that case
DMARC policy request and DMARC validation results could be used to make the
Inbox v. Spam decision.
If the host recording the Auth-Res header is a true intermediary like a
mailing list server, there's no disposition information to record that will
matter to the downstream; in that case, if the intermediary rejects it, the
downstream will never see it, and if it doesn't reject it, then it's not
making any disposition decisions.
>
> >> As for the parenthetical bits, I believe they too are covered in RFC
> 7601
> >> section 2.7.6:
>
>
> For parenthetical info to be machine readable, A-R consumer software has
> to be dedicated to A-R producer. An blatant standardization shortcoming.
>
The text of 2.7.6 (RFC 8601) I believe indicates that the parenthetical is
just a comment:
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 were used to perform an evaluation, such information
could be relayed as a comment in the header field, such as:
Authentication-Results: example.com;
foo=pass bar.baz=blob (2 of 3 tests OK)
My position is that both the message handling request conveyed by the
domain owner in the p= value of their policy record and the message
disposition are "ancillary details of authentication results", because
while the disposition may be driven by those results, neither impacts the
results nor how those results are determined.
>
>
> > [...] 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".
>
> That is especially true for quarantine. As DMARC is often verified by a
> filter during the SMTP exchange, the filter has to commission the MDA to
> possibly honor a quarantine request. In order to do that, the filter needs
> to communicate the results of authentication to the delivery agent. Not
> using A-R for this task, or resorting to parenthetical info, is
> preposterous.
>
MDAs have been routing messages to spam folders on the instruction of MTAs
long before the Authentication-Results header existed. Many years ago when
I worked in email operations, our third-party software supported the
concept of the spam-filtering layer inserting an X- header to be read by
the MDA to use in inbox/spam folder placement. We're making assumptions in
this thread that the A-R header is driving things, but we really have no
idea how each mailbox provider does things unless we work there.
>
> I propose to add two new result name codes, named after the policy
> requests:
>
> dmarc=quarantine, and
>
> dmarc=reject (of course, you only see this if the filter didn't honor
> the request).
>
>
I do not support this, because quarantine, reject, and none are not
Authentication Results, but are instead both policy requests and
disposition decisions.
--
*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*p:* 703.220.4153
This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
