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

Dave Crocker <dhc@dcrocker.net> Tue, 28 July 2020 17:08 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1833A0ECD for <dmarc@ietfa.amsl.com>; Tue, 28 Jul 2020 10:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tu-29j-7wAds for <dmarc@ietfa.amsl.com>; Tue, 28 Jul 2020 10:08:32 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2B03A0EC9 for <dmarc@ietf.org>; Tue, 28 Jul 2020 10:08:32 -0700 (PDT)
Received: from [192.168.1.67] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06SHB8n1028979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2020 10:11:08 -0700
To: Alessandro Vesely <vesely@tana.it>, dmarc@ietf.org
References: <159585176595.9170.11320655994332663370@ietfa.amsl.com> <a8cecb8d-bf71-20d8-eec6-cbf82421f364@dcrocker.net> <2885a4dd-910a-3ad3-d827-35eb4118dfd5@tana.it> <fb50abdb-8313-2f7d-6091-07d4d5d70d27@dcrocker.net> <081a3640-67c1-d32c-2dad-1197f9599e34@tana.it> <cff8e075-11f8-4ddd-829a-a774bbf0f9c7@dcrocker.net> <384b7617-ed9c-de2b-a18e-43a268c989d5@tana.it> <9ebd2ca5-4552-93d1-4e8d-50fc816a639d@dcrocker.net> <339b15d6-d845-0a46-ac07-25b40aa020e0@tana.it>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Reply-To: dcrocker@bbiw.net
Message-ID: <6dc2bf95-6f0b-13d5-49cb-1ab0b9a6a37c@dcrocker.net>
Date: Tue, 28 Jul 2020 10:08:25 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <339b15d6-d845-0a46-ac07-25b40aa020e0@tana.it>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/WuHfOB1aZh2Fh5jBfGA-MLtNjAo>
Subject: Re: [dmarc-ietf] Fwd: New Version Notification for draft-crocker-dmarc-author-01.txt
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jul 2020 17:08:34 -0000

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 an expect it to 
be valid.

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.


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



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


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net