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

[Alessandro Vesely <[e-mail]>]

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.


>> 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)
>> and "Email Authentication Results Names" in section 6.6 


By convention, each method specifies the same meanings for the same result names.  Yet, methods can have unique codes, for example softfail.  If you look at IANA table[*], the meaning of dmarc method is referred to [RFC7489] section 11.2.  That section does indeed give the definition of "fail" that Todd has extensively described.  However, we are going to obsolete that document, so redefining result names is not out of our reach.


[*] https://www.iana.org/assignments/email-auth/email-auth.xhtml#email-auth-result-names


>> 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.


> [...] 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.

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).


Best
Ale
--