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

[Alessandro Vesely <[e-mail]>]

On Wed 30/Dec/2020 17:22:07 +0100 Dotzero wrote:
> On Wed, Dec 30, 2020 at 10:41 AM Michael Thomas <[e-mail]> wrote:
>> On 12/30/20 7:35 AM, Todd Herr wrote:
>> On Wed, Dec 30, 2020 at 9:01 AM Michael Thomas <[e-mail]> wrote:
>>> On 12/30/20 5:48 AM, Todd Herr wrote:
>>>
>>>>> 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.
>>>
>>> Then we should remove DMARC from auth-res altogether because it is not an
>>> authentication mechanism. Either we fully support DMARC in auth-res or
>>> remove it. This half-assed state of unlessness serves nobody.
>>>
>> I disagree. DMARC has rules that determine whether or not a message is 
>> deemed to be authenticated - did it pass SPF or DKIM and did it do so
>> with a domain that aligns with the RFC5322.From domain. The currently
>> valid states for those rules are pass, fail, temperror, and permerror.

They are not enough to convey the information needed.  That's why I propose an 
addition.


>> Policy and disposition (none, quarantine, reject) apply to decisions made
>> based on the authentication results; they are not states for the
>> authentication checks themselves.


They become states for the authentication check in the moment that we publish 
that dmarc=quarantine means the message failed DMARC check and the DMARC record 
asked that the message be quarantined in that case.

Todd clearly said that a mailbox provider currently has to resort to temporary 
header fields in order to communicate results of authentication checks to a 
downstream, non-standard agent.  Perhaps like so:

X-Authentication-Results: dmarc=quarantine?

Mail systems are not the prerogative of large mailbox providers who roll out 
their own code.  Standards exist to allow compliant code to interoperate.


>> DMARC != Auth-res. Auth-res provides all kinds of useful information than
>> just pass/fail. For DMARC Auth-res should provide what the policy was at a
>> bare minimum. But none of this seems to have any normative language
>> anywhere which is a problem unto itself. DMARC in auth-res seems to be an
>> orphan.
> 
> You just stated the case as to why this discussion should be ruled out of
> scope.  " DMARC != Auth-res." and " DMARC in auth-res seems to be an orphan"
> 
> This is the IETF DMARC working group, not the AUTH-RES working group.


Indeed.  Auth-Res values and meaning are defined precisely in the document we 
are writing.  RFC 8601 is extensible, and it only covers methods that were 
already in use in 2009, when RFC 5451 came out.


> You gave the example of someone writing a crappy Thunderbird extension as a 
> reason for the working group to change its focus.

The code that Philippe Lieser wrote is strictly conforming to standards.  It is 
crappy only because the DMARC standard is, at least as far as specifying 
authentication methods is concerned.


> Perhaps getting the extension author to fix their extension might be a more
> fruitful effort.

By my bitty knowledge of Philippe's reasoning, I'd bet he'd ask what RFC says 
where to get a different status than what his add-on displays.  Of course he's 
not going to tentatively parse every known A-R comment.


Best
Ale
--