Re: [ietf-smtp] How wrong is this EAI implementation

Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> Sun, 21 June 2020 06:47 UTC

Return-Path: <arnt@gulbrandsen.priv.no>
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 A68D63A09AF for <ietf-smtp@ietfa.amsl.com>; Sat, 20 Jun 2020 23:47:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gulbrandsen.priv.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 20n3oUVSWMIh for <ietf-smtp@ietfa.amsl.com>; Sat, 20 Jun 2020 23:47:31 -0700 (PDT)
Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [144.76.73.169]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 733613A09AA for <ietf-smtp@ietf.org>; Sat, 20 Jun 2020 23:47:29 -0700 (PDT)
Received: from stabil.gulbrandsen.priv.no (stabil.gulbrandsen.priv.no [IPv6:2a01:4f8:191:91a8::3]) by stabil.gulbrandsen.priv.no (Postfix) with ESMTP id 3CA2CC008C; Sun, 21 Jun 2020 07:52:53 +0100 (IST)
Authentication-Results: stabil.gulbrandsen.priv.no; dmarc=none (p=none dis=none) header.from=gulbrandsen.priv.no
Authentication-Results: stabil.gulbrandsen.priv.no; spf=none smtp.mailfrom=arnt@gulbrandsen.priv.no
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gulbrandsen.priv.no; s=mail; t=1592722373; bh=PHhWLS3TXFz7srhpATLzB7GFz/J/CsaNGVXWIokgfJE=; h=From:To:Subject:Date:References:From; b=kMYZ5lPI+PmomsElWTLp70A1QNFWBMv2Bysky6DdRA5V2JN46+brp1DjsnugP1106 E1oBOCL1+X2BlHHRtlzUw927RrIJiTozRyq4nHuhPeO2RjxF7ZKIsGcSL+046m5kdK ZNnkZaL48Fin8hJJa0fA5RZChtb5QIpiNZH+qbDk=
Received: from arnt@gulbrandsen.priv.no by stabil.gulbrandsen.priv.no (Archiveopteryx 3.2.0) with esmtpsa id 1592722372-9695-9692/9/67; Sun, 21 Jun 2020 06:52:52 +0000
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
To: ietf-smtp@ietf.org
Date: Sun, 21 Jun 2020 06:52:52 +0000
Message-Id: <kzlyExy/3YBZVUSNURxDqMLjYwWYAVGpn6yogCjhITg=.sha-256@antelope.email>
References: <alpine.OSX.2.22.407.2006201429080.28792@ary.qy> <2B0EB3A9E99431F86620038A@[10.1.10.18]> <alpine.OSX.2.22.407.2006201823060.29484@ary.qy> <DC26ED76E7E316714AB2B820@[10.1.10.18]> <a058a5bf-487e-63ca-70bd-4e2765d3b9b9@network-heretics.com> <alpine.OSX.2.22.407.2006201429080.28792@ary.qy> <2B0EB3A9E99431F86620038A@[10.1.10.18]> <alpine.OSX.2.22.407.2006201823060.29484@ary.qy> <DC26ED76E7E316714AB2B820@[10.1.10.18]> <a058a5bf-487e-63ca-70bd-4e2765d3b9b9@network-heretics.com>
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/_RpMz_xwlCYH_XjovpZv1hwHbk0>
Subject: Re: [ietf-smtp] How wrong is this EAI implementation
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: Sun, 21 Jun 2020 06:47:33 -0000

I note that there is no explicit requirement to treat incoming a-labels 
as equivalent with u-labels anywhere in the EAI RFCs. Which means that 
you can convert labels before sending, but you cannot rely on the 
receiver to interpret the result as desired.

Bit too subtle, 
really.

Arnt