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

[Dotzero <[e-mail]>]

Absolutely agree with Todd's analysis and comments. +1

Michael Hammer

On Wed, Dec 30, 2020 at 8:48 AM Todd Herr <todd.herr=
[e-mail]> wrote:

> On Wed, Dec 30, 2020 at 4:42 AM Alessandro Vesely <[e-mail]> 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:* [e-mail]
> *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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>