Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?

Dave Crocker <dhc@dcrocker.net> Wed, 12 August 2020 03:32 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 081FA3A0EBC for <dmarc@ietfa.amsl.com>; Tue, 11 Aug 2020 20:32:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.849
X-Spam-Level:
X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, 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 eiNN3j0QTi73 for <dmarc@ietfa.amsl.com>; Tue, 11 Aug 2020 20:32:30 -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 F14E83A0EBF for <dmarc@ietf.org>; Tue, 11 Aug 2020 20:32:29 -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 07C3ZCVv021405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <dmarc@ietf.org>; Tue, 11 Aug 2020 20:35:13 -0700
To: dmarc@ietf.org
References: <20200811034740.BA1831E7FDBF@ary.local>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Reply-To: dcrocker@bbiw.net
Message-ID: <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net>
Date: Tue, 11 Aug 2020 20:32:23 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <20200811034740.BA1831E7FDBF@ary.local>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/F_kNiKVi0GGzqMBsSSTo9lHrdiY>
Subject: Re: [dmarc-ietf] draft-crocker-dmarc-author-00 ?
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: Wed, 12 Aug 2020 03:32:32 -0000

>> I was quite surprised -- at the level of astonished -- to see the
>> pushback on the Author header-field proposal, since it is such a simple
>> and straightforward mechanism.
> 
> The different bits in the message are simple enough.
> 
> The problem is that it might as well be called Really-From, and then

Your opening item is that you don't like the name of the field?

In any event, I suggested "Author" because it is simple and accurate. 
Something like what you suggest - on the off-chance you are serious -- 
offers distracting tone and baggage.


> when enough systems do mutant DMARC to cause the same problems with
> Really-From that we have with From, 

That's a premise with no foundation and arguably no validity.

At the least, if you are going to use this as the substance of your 
concern, perhaps you could explain with some care why you are so certain 
this will happen.

Here's why I think it won't:  They already have From:.

The real value in DMARC is not what is displayed to the end-user but in 
having a required field that cites the originating domain name.  That 
doesn't change if there are additional fields that might or might not 
mention the originating domain.


> the step after that is
> Really-Really-From, so on ad nauseam. While that happens (or maybe
> doesn't) we have no idea whether MUAs will display it or let you enter

The question of whether any MUAs will implement this is the same concern 
for any proposal.  So on its own, that would mean we never do anything 
unless implementers and operators promise to use it.  Absent an IETF 
formal policy to that end...


> it or automatically make it the same as From or maybe something else,
> likely making it a disaster for interoperability.
> 
> I think the DMARC sender draft is a lot more promising.

It has it's own problems.

There's no perfection here, since the task is retro-fitting work-arounds 
to an established mechanism that has been altered.  As I've noted, 
realistically, DMARC makes the From: field be the Sender: field.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net