Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication

Dave Crocker <dhc@dcrocker.net> Mon, 10 June 2019 20:17 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 BA80B1200B9 for <dmarc@ietfa.amsl.com>; Mon, 10 Jun 2019 13:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net
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 tKEqyv8T7dOT for <dmarc@ietfa.amsl.com>; Mon, 10 Jun 2019 13:17:05 -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 04B1A12003E for <dmarc@ietf.org>; Mon, 10 Jun 2019 13:17:04 -0700 (PDT)
Received: from [192.168.1.87] (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 x5AKJEYa024483 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 10 Jun 2019 13:19:14 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1560197955; bh=dwmbmt+ayjyzeWwxhoNY9dgT0qcSoAFXg8nmsPcyK3E=; h=Subject:To:References:Reply-To:From:Date:In-Reply-To:From; b=hm5GRspwN4hSfxzvCnmVLgp3N6PTPOfE00slqBjq18ZlaeA4OMsXBE7e7q2TPjObS eeXni/JftLuqRGiTcxr4IEhblY2MP4ynE+u5I78o8HX87paRAdofQRGcNgqtFlqetd nQtljR//uIzhcUpntnO5MyfFcrXPwKsEZR2B+zdY=
To: Alessandro Vesely <vesely@tana.it>, dmarc@ietf.org
References: <20190603142956.66B31120252@ietfa.amsl.com> <45cdc0da-5243-3a62-b217-8d5e4ea9ea11@dcrocker.net> <941abdbf28684283b972f69f25876220@bayviewphysicians.com> <5524dbb3-27ff-4aa8-aaf0-fc3a3fc23418@dcrocker.net> <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it>
Reply-To: dcrocker@bbiw.net
From: Dave Crocker <dhc@dcrocker.net>
Message-ID: <1e096404-6b00-8896-0b79-841c243cacec@dcrocker.net>
Date: Mon, 10 Jun 2019 13:17:01 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <1df2cc6b-c169-59ca-08f6-dadc06a702c6@tana.it>
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/GVxwzIkCw0gu50UN4qj3TJFqCIo>
Subject: Re: [dmarc-ietf] Display address, was Mandatory Sender Authentication
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: Mon, 10 Jun 2019 20:17:07 -0000

On 6/10/2019 1:17 AM, Alessandro Vesely wrote:
> On Sat 08/Jun/2019 18:49:03 +0200 Dave Crocker wrote:
> 
>> Except that most users don't actually see that address because these days most
>> MUAs only display the display address.
> 
> 
> We often came across this realization.  Since DMARC hinges on that field, I
> think the spec should include some advice to MUA implementation.

Unfortunately there is no 'advice' to give that has any utility.

If you feel otherwise, please try to formulate it, including the basis 
for believing it useful, and then try to get community support for it.


> A trust on first use (TOFU) approach would seem to be possible. 

In practical terms, what does that mean?  Who does what, exactly?  What 
is the basis for believing anyone will actually do it?


>  On getting the
> same display name linked to a different domain part, a user would be required
> to configure the MUA's behavior for this particular name / domain.

Specifying user behavior is both outside the usual scope of IETF work 
and a task with frustratingly poor utility.


> Does this subject deserve a ticket?

Since it has nothing to do with errors or problems with the current 
spec, I don't see how to justify a ticket.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net