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

Ned Freed <> Sun, 21 June 2020 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A3063A078C for <>; Sun, 21 Jun 2020 10:43:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Au58dOzn-cPL for <>; Sun, 21 Jun 2020 10:43:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F1A043A0789 for <>; Sun, 21 Jun 2020 10:43:33 -0700 (PDT)
Received: from by (PMDF V6.1-1 #35243) id <> for; Sun, 21 Jun 2020 10:38:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=201712; t=1592761110; bh=qcl6Nkh32kwYLl6aO9Rb5IJnqLCZw0LzpYK00Y8cUvU=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=OxOr84lNxBmvk6n/k3UK0b/ZqNUqrT/toprYPyCU9olBIliwEnQJelGs/r8kHABqX Jmujz/3yfrcZd808Son60PLvBqtJcsGFEVuo3f1B435iqICHb4EL86ZZrnSE6KhjKW SHrYpJ4yRscXEK38TYyb/PmegbVNPsv49cMULUsE=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from by (PMDF V6.1-1 #35243) id <>; Sun, 21 Jun 2020 10:38:28 -0700 (PDT)
Message-id: <>
Date: Sun, 21 Jun 2020 10:11:48 -0700 (PDT)
From: Ned Freed <>
In-reply-to: "Your message dated Sun, 21 Jun 2020 10:53:42 -0400" <20200621145342.7364B1B4460D@ary.qy>
References: <kzlyExy/> <20200621145342.7364B1B4460D@ary.qy>
To: John Levine <>
Archived-At: <>
Subject: Re: [ietf-smtp] How wrong is this EAI implementation
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\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 21 Jun 2020 17:43:35 -0000

> In article <kzlyExy/> you write:

> > 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.

The EAI documents repeatedly refer to there being two different "forms" for
domains, u-label and a-label. The only reasonable interpreration of such
statements is that the they are equivalent. RFC 6531 even goes so far as to
say that u-labels form should be used when the SMTPUTF8 extension is available,
a-label form when it isn't.

Additionally, the point that always seems to be elided in these discussions is
that MTAs do NOT have the luxury of treating addresses as opaque strings.
Elimination of duplicate addresses, alias lookup, and canonicalization  of
local address forms are all things that MTAs do routinely, and all of them
require at a minimum the ability to compare addresses and get correct results.
This combined with the "mutiple forms" notion in the documents leaves very
little wiggle room for implementers, explicit requirements or not.

And yes, it's a bit of a PITA to code.

> I don't think that 5321 requires that and bob@EXAMPLE.COM
> be treated the same, either.

Section 2.4 explicitly says domains are case-insensitive. Not a lot of wiggle
room here either.

> Beyond some point, you can't force people to be reasonable.

No, but I think you can make a case that any implementation that fails to treat
the forms as equialent is incompliant.

> In the particular case I mentioned, my MTA is Courier which treats
> A-labels and U-labels equivalently in mail addresses, but not in
> identifiers for authentication.  It was easy enough to add both versions
> to the identifer table, but I think I'm going to send a bug report to
> roundcube.

Yet another case where comparisons are unavoidable.