Re: [ietf-smtp] Make username optional in email addresses

Keith Moore <moore@network-heretics.com> Mon, 20 February 2023 04:52 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47F6C14CEFF for <ietf-smtp@ietfa.amsl.com>; Sun, 19 Feb 2023 20:52:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4sjWCCX_epC for <ietf-smtp@ietfa.amsl.com>; Sun, 19 Feb 2023 20:52:50 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8154C14E515 for <ietf-smtp@ietf.org>; Sun, 19 Feb 2023 20:52:50 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id D253D5C0070 for <ietf-smtp@ietf.org>; Sun, 19 Feb 2023 23:52:49 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Sun, 19 Feb 2023 23:52:49 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1676868769; x=1676955169; bh=M +8LODPsiz4jlJjvCNmTuhH2KnIvt7tn3bkADYBu4PM=; b=tt7ASvAukChqG5T4P Zx6C8stzcYO7OX1w3Sjtz9508hObzXZba7Fv9IVd9R/XMOpP865PLMM6q8aLiE6y xEdTehaDRJku2rwShR1LhnXBQvga8n7okfn8QQW0PsDa1L4td0Qv3g6KbKWGay46 VdthQj3Pr+OPeCjym2fB6i9cm73CAlNAXVr/7aMy/+49URcru4C5Y0snQHIy8XbP QC0GxFR2Xi1uETdjWS2QYpG+6dBy2iXPDhHqKfWpCo6kOgJXS1r373M/RGcunzeV TcCkdCbqh1BCD/ZzSTN575KvSDVH4xeKFpL3Ex/PHSkHECAl+E0JC0m4mw9zqzcO te0BQ==
X-ME-Sender: <xms:ofzyYzjm4-CnLd_WmQ5TrnUYoiaS0xapxYWMFwfWlxJu5NjpJ9d2wA> <xme:ofzyYwBydZVrHXAINrEqeHrNdc0P5q4i6S_B0XAr2K5p_qXqTF7Lf6lS8nTh2CPZr Jf_lbFrY9-u5g>
X-ME-Received: <xmr:ofzyYzHizTax70K2uX9kAvDYuUHTDgRwAVNnQ7mZ_Vh4LknKuFdfZ8zS_mIC9O2RYb0ttvqH7vZuVUWFJIe6X8l6he0-VTWw5PYR7szn2eLI_Eh5Y1s2EQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudejgedgjeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeefhfeluddtue fgjefhiefgfffgleeghfeugfduieevgeffgefghfeltedtvdelgfenucffohhmrghinhep ihhfthhhvggunhhslhhoohhkuhhpohhnfhhoohdrtghomhenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhh vghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:ofzyYwTB8JYsqraI4zaGvoHt2J9qUMmy2hP1wSJRYUuCWFdNukvHAQ> <xmx:ofzyYwyL3zUFiWeAnFYSXuEkWmTp7T-1nvoZsXmXrMwTW5oCG9gNqQ> <xmx:ofzyY26YEd8gi3u-kzUzJIxgbvLIyo6lRQYPRJXS4X4zO56mhvqV5g> <xmx:ofzyY__fxSOlQhc_f7h0N8bVFUsFIJOIqff9DxAcdD-9opUqU6A9Jw>
Feedback-ID: i5d8c41f0:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for <ietf-smtp@ietf.org>; Sun, 19 Feb 2023 23:52:49 -0500 (EST)
Message-ID: <748ffaeb-c437-71a8-dc8e-0d8f69addb2d@network-heretics.com>
Date: Sun, 19 Feb 2023 23:52:48 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1
To: ietf-smtp@ietf.org
References: <CAG6nNWe_7-JN4mzTcsfHBj-cO9qO8twXr+GOg=kiQ8e5XataPA@mail.gmail.com> <87mt5cezkb.fsf@hope.eyrie.org> <00442A7D2E63E30765843D13@PSB>
Content-Language: en-US
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <00442A7D2E63E30765843D13@PSB>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/65bi77P5IFK39239wk7fn0iyzRc>
Subject: Re: [ietf-smtp] Make username optional in email addresses
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Feb 2023 04:52:55 -0000

On 2/17/23 17:26, John C Klensin wrote:

> That would give you something almost completely non-disruptive.

I don't think there's any non-disruptive way to make usernames optional 
in practice.   Even if there are zero changes to the protocol and 
nothing that breaks any existing protocol implementation, what is being 
proposed are significant changes to the function of user agents and also 
of people's habits of interacting with email.

The analogy that comes to my mind is the behavior of web browsers which, 
if a user types in "foo.com" to the address bar, adds "www." to the 
front and probably "https://" in front of that. (note that this 
convention has changed over time and works differently on different 
browsers.)  The problem is that different browsers behaved differently 
in response to typed-in URLs, and also over time, which degraded the 
ability of people to type URLs into different browsers.  And that's 
actually a vital function. (And yes, browsers have tried to be slightly 
more clever about this over time, for example by only prepending "www." 
if the DNS lookup on "foo.com" didn't work by itself, and falling back 
to "http://" if "https://" didn't work - the latter being somewhat 
dangerous if the user expects the connection to be encrypted and the 
browser downgrades the connection without asking.)

What's being proposed in this case is similar - the MUA would have to 
behave differently if "foo.com" is typed into the To: or Cc: field.  And 
some MUAs would implement this and others wouldn't, and users would have 
to learn what worked in their particular MUA(s).

IMO we should consider changes to user interfaces to be as potentially 
disruptive as any protocol changes.  It might not affect software, but 
it still affects the robustness and predictability of the system as a 
whole.   (Or to put it differently, some of the protocol implementation 
is in users' brains.)

And far too many changes to email user interfaces have, IMO, been 
harmful to email.

In conclusion, let's please not lend credibility to this idea.

Keith