Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-author-01.txt

[Alessandro Vesely <[e-mail]>]

On Tue 28/Jul/2020 19:08:25 +0200 Dave Crocker wrote:
> On 7/28/2020 7:20 AM, Alessandro Vesely wrote:
>> On Tue 28/Jul/2020 13:09:29 +0200 Dave Crocker wrote:
>>> On 7/28/2020 4:00 AM, Alessandro Vesely wrote:
>>>> On Tue 28/Jul/2020 12:37:32 +0200 Dave Crocker wrote:
>>>>> On 7/28/2020 12:26 AM, Alessandro Vesely wrote:
>>>>>> Receivers can evaluate the Author: domain just like they would do if it 
>>>>>> were the From: domain. 
>>>>>
>>>>> So you want to define DMARC as applying to both the From: field and the 
>>>>> Author: field?  That will defeat the benefit intended for the Author: field.
>>>>
>>>> Yes.  In case of conflict, evaluation of Author: has to be omitted. For 
>>>> example, Author: fields containing multiple mailboxes are not considered.
>>>
>>> 1. I don't understand the details you have in mind that would make this useful.
>>
>>
>> It is an optional evaluation.  It's easy to do, if you already verified DKIM 
>> and SPF.  It is not terribly useful, admittedly, except that having two or 
>> three "pass" makes for a stronger authentication than just the From:.  The 
>> chief reason for evaluating it is to give feedback to the MLM.
> 
> There is no specification for doing this.  It means that there is no basis for 
> the creator of the Author field to expect such an interpretation and no basis 
> for a receiver to apply it and expect it to be valid.


It'd be enough to state that the "scrutiny and care comparable to that given to 
the From: header field" include evaluating the domain —if unique— against 
validated identifiers.


> An interoperability standard require a shared definition of action and 
> meaning.  The sharing is among the actors participating in that standard.
> 
> For one side to choose a behavior or an interpretation that is not documented 
> and shared by the other participants is to pretend that a heuristic is more 
> than that.


If the aggregate report format (see below) includes provisions for transmitting 
the result of those evaluations, the circle is closed.


>>
>>> 2. Again, this seems to defeat the purpose of having the Author field.
>>
>>
>> Why?
> 
> The field is intended to be free of the problematic treatment the From: field 
> is now getting.  You appear to want to encumber it, so that it experiences 
> those same problems.


One of the DMARC specs might suggest what dispositions make sense according to 
the evaluations and the various DMARC records found.  A "fail" result on the 
Author: domain should not compromise delivery (unless the domain is the same as 
the one in From:.)

I understand that asking to perform an evaluation for the sole purpose of 
transmitting the result may sound presumptuous.  However, it's not gonna be the 
only change affecting DMARC software, and it is an easy one to code and a 
lightweight one to run, and, if the Author: domain is significant, its results 
can be interesting for the receiver as well as for the sender.


>>>>>> As a new field, Author: doesn't wear a reliable-id trophy, hence 
>>>>>> receivers may refrain to apply policy dispositions.  However, the result 
>>>>>> of the evaluation, conveyed through aggregate report, can tell MLMs if 
>>>>>> rewriting From: was necessary.
>>>>>
>>>>> How, exactly?
>>>>
>>>> Author: and Sender: domains can be included in aggregate reports along with 
>>>> the From: one.  The policy_evaluated can also include more items, 
>>>> specifying which evaluations pass or fail.
> 
> Yes, one could modify DMARC to have its reporting include additional information.


Best
Ale
--