Re: [ietf-smtp] How is EAI mail implemented ?

John C Klensin <john-ietf@jck.com> Wed, 16 June 2021 12:10 UTC

Return-Path: <john-ietf@jck.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 5257F3A1444 for <ietf-smtp@ietfa.amsl.com>; Wed, 16 Jun 2021 05:10:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 nGKemlQ7_F93 for <ietf-smtp@ietfa.amsl.com>; Wed, 16 Jun 2021 05:10:56 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0E73A143D for <ietf-smtp@ietf.org>; Wed, 16 Jun 2021 05:10:55 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1ltUNi-0009Pw-6o for ietf-smtp@ietf.org; Wed, 16 Jun 2021 08:10:54 -0400
Date: Wed, 16 Jun 2021 08:10:48 -0400
From: John C Klensin <john-ietf@jck.com>
To: ietf-smtp@ietf.org
Message-ID: <8A8324397259E9C5EE465422@PSB>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/9fqCFzUCUd-WLFirnXAyEIBfTIE>
Subject: Re: [ietf-smtp] How is EAI mail implemented ?
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 16 Jun 2021 12:10:58 -0000

Replying generally to the thread rather than any particular
message and from whatever perspective being former EAI co-chair
gives me....    I think the recent discussions about what people 
are (and are not) doing very helpful and I haven't been an 
implementer for decades.

Three observations, all of which I've said in more detail in
other recent threads:

(1) I believe that a significant fraction of the participants in
the WG were convinced that the global demand for non-ASCII
addresses was large enough that SMTPUTF8 would be widely
implemented  -- to the point of ubiquitousness -- within a
fairly short time.  A number of decisions were made, and a
number of issues probably not considered very carefully, because
of that conviction.  In particular, the fine points of what to
do under various scenarios of SMTPUTF8-capable systems
encountering ones that are not become largely irrelevant if
nearly every mail transport system on the Internet supports the
extension and the issues have been sorted out in nearly every
POP and IMAP server, MUA, and webmail interface.  

Obviously, that assumption was too optimistic.

(2) The WG also expected that implementation in an "8 bit clean"
MTA was going to be fairly straightforward.  I think that is
consistent with what we've heard in the last several days.
They/we anticipated that the difficulties would arise in or near
the MUAs, particularly those that aspired to be multilingual
(not just multi-script) rather than monolingual or bilingual.
AFAICT, they/we were probably right about that one, but not
having a good selection of high-quality, well-implemented, MUAs
cuts down on incentives for rapid and universal deployment of
good and interoperable MTUA and intermediate systems.

(3)  I think that getting the shared implementation experience
written down would be a good idea, whether in the form of an
A/S, a BCP, or just an informational description (perhaps
depending on the degree of consensus) would be a great idea if
someone wants to lead that effort and others have the energy.
However, I think it would be a mistake to do that without making
a very serious effort to involve the non-ASCII email advocates
who contributed very significantly to the EAI WG and who do not
appear to be active on this list.

back to lurking,
    john