Absolutely agree with Todd's analysis and comments. +1 Michael Hammer
On Wed, Dec 30, 2020 at 8:48 AM Todd Herr <todd.herr= [email protected]> wrote: > On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely <[email protected]> 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:* [email protected] > *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 > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
