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

Dave Crocker <dhc@dcrocker.net> Sat, 15 August 2020 17:37 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 97D8B3A0855 for <dmarc@ietfa.amsl.com>; Sat, 15 Aug 2020 10:37:22 -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 CeXahbKj_Nd6 for <dmarc@ietfa.amsl.com>; Sat, 15 Aug 2020 10:37:20 -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 08C773A084E for <dmarc@ietf.org>; Sat, 15 Aug 2020 10:37:19 -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 07FHe4WC016694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 15 Aug 2020 10:40:04 -0700
To: Steve Atkins <steve@wordtothewise.com>, dmarc@ietf.org
References: <20200811034740.BA1831E7FDBF@ary.local> <0c8afc68-bc51-702a-c794-610b2d355836@dcrocker.net> <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com>
From: Dave Crocker <dhc@dcrocker.net>
Reply-To: dcrocker@bbiw.net
Organization: Brandenburg InternetWorking
Message-ID: <116c9644-8116-564b-5f76-feb53815ef08@dcrocker.net>
Date: Sat, 15 Aug 2020 10:37:13 -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: <83a8e95f-d85d-634e-0c93-eb2ddab2c69d@wordtothewise.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/pzTm_Z7DnR3yq5SSF8yg8bn-avQ>
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: Sat, 15 Aug 2020 17:37:23 -0000

Steve, et al,

On 8/12/2020 8:16 AM, Steve Atkins wrote:
> On 12/08/2020 04:32, Dave Crocker wrote:
>> 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.
>
> I think we disagree on the goal of DMARC. The entire point of DMARC is 
> brand protection.

Yes, but...

High-level goals are fine.  But then they meet lower-level technical and 
operational pragmatics.

For its originally-intended use, DMARC linked high and low pretty well.

The expanded use doesn't and essentially was adopted more to do with 
stemming a denial of service attack.


> Control over what is displayed to the user,

I'm confused.  I thought this was a technical forum, not a marketing forum.

User's typically don't see the email address and typically it won't 
matter if they do.  And this has been pointed out repeatedly.

So while, yes, these have driven many people's thinking, that thinking 
isn't based on empirical realities.

In this forum, we should not have to constantly be reminded that, in 
actual practice, none of these activities involve direct user behavior.  
Operationally, they are only relevant to the receiving filtering engine.

To the extent someone wants to claim otherwise, they should produce 
empirical evidence, not summaries of marketing views. (And this request 
also should not need this constant repetition.)


> not what's in any particular header. You could use it for other 
> things, but that's what informed publishers of DMARC say they're using 
> it for (sometimes phrased as "protection against phishing" but that 
> too is all about what's displayed to the recipient).

No doubt. But, really, there is no closed-loop mechanism to validate 
that it is achieving what they think it is for, namely getting users to 
make fewer bad decisions about their mail content.

Certainly unauthorized use of a domain name in the From: field 
/correlates/ positively and perfectly with an assessment of spam, but it 
correlates negatively and perfectly with authorized uses, such as 
mailing lists.

So in statistical terms, folk using DMARC see utility, but that's as a 
detector of some spam, and not other spam. And they are dismissive of 
the negatives, because it doesn't affect /them/.


The tone that seems to permeate here is that we need to prevent any new 
identity -- addressing -- fields  because bad actors will abuse them.

What this misses is whether that abuse matters.  I realize that it 
bothers us to see such abuse, but whether the abuse matters ought to be 
relevant.


> If you display the contents of Author to the user, then DMARC 
> publishers will want to control that.

So we need to cater to folk who want to do things that have no empirical 
validity?  Seems a poor basis for technical work.

The reason the Author: field is being proposed is to regain 
author-to-recipient MUA-level utility.

Also there's the small matter of anticipating strategic behavior of 
operators without actually knowing that the anticipation is correct and 
having no history of such behavior other than a single, problematic data 
point.  As I recall, DMARC uptake is a small percentage of the industry. 
That makes invocation of a predicted industry behavior also problematic.


> If MUAs will display the contents of the Author: header where the 
> From: header is now then draft-crocker-dmarc-author-00 effectively 
> moves what used to be Sender: header to the From: header and what used 
> to be the From: header to the Author: header.

As I keep noting, that is what DMARC has already done.

It breaks basic, author-related utility of the From: field for MUA use.  
That should matter.

And the -sender- proposal can't fix that. (see below)


> You could achieve exactly the same result, with much less deployment 
> effort, by updating DMARC to enforce the Sender header and leaving 
> MUAs displaying the From: header. That wouldn't be acceptable to 
> anyone who wants to publish DMARC, so the Author: proposal won't be 
> either. 

It would be nice for that to be as effective as folk want to believe, 
but it can't.

1. Sender is an optional field.  DMARC needs something that is always 
present.  That's really why there was no choice other than From:, for 
its original design.

2. DMARC has an installed base and the 'legacy' receiving engines need 
to be able to operate with DMARC without having to convert ot use of the 
Sender: field.  I tried to find a way to make this work and failed, 
which is why the current -sender- draft works in parallel to the From: 
field, rather than taking precedence over it.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net