Re: [ietf-smtp] Should we update an RFC if people refuse to implement parts of it ?

Viktor Dukhovni <> Wed, 26 May 2021 21:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CB273A0CD4 for <>; Wed, 26 May 2021 14:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 75F428atm-gr for <>; Wed, 26 May 2021 14:59:51 -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 0A8D83A0CD2 for <>; Wed, 26 May 2021 14:59:50 -0700 (PDT)
Received: by (Postfix, from userid 1001) id C425BB851E; Wed, 26 May 2021 17:59:49 -0400 (EDT)
Date: Wed, 26 May 2021 17:59:49 -0400
From: Viktor Dukhovni <>
Message-ID: <>
References: <20210525182946.079748B872C@ary.qy> <EFDA46E00EFF0E48802D046A@PSB> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
Archived-At: <>
Subject: Re: [ietf-smtp] Should we update an RFC if people refuse to implement parts of it ?
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: Wed, 26 May 2021 21:59:55 -0000

On Thu, May 27, 2021 at 12:59:53AM +0800, Jiankang Yao wrote:

> > I recognize the distinction while also realizing that, as you know,
> > things often leak.  My recollection (if Jiankang is following this,
> > his memory is probably better than mine) is that the WG explicitly
> > discussed the issue and concluded that U-labels were a better idea
> > than A-labels.  
> Yes, I think so. The EAI WG discussed this issue.  Section 3.7.3.
> Trace Information  encourages to use UTF-8 form.  One reason I think
> is that trace information will be put into header for human reading.

But, and this is crucial, the human reading the trace information is
rarely either the sender or the ultimate recipient of the message, who
are generally presented with a subset of the headers fields ("To", "Cc",
"Date", "Subject" ...).  Examination of trace headers is far more likely
to a task for a mail system administrator.  They're used in abuse
reports and the like, and a uniform representation is more important
than familiarity to the community of readers of some given language.

Mail system administrators don't necessarily read the same scripts as
their end users.  Mail system administrators would reasonably expect
the EHLO name recorded in trace headers to match the name received in
the actual EHLO command on the wire (and recorded in their email logs).

> UTF-8 is better for human reading.  A-label is ugly for human reading,
> but ok for machine reading.

Sure, if the text is Russian, some Latin-based alphabet or at a stretch
Greek, I can more easily distinguish one U-label string from another
than an A-label form like "", ... and yet I'd much
rather see A-labels in trace headers than Arabic or Chinese.  The text
in 3.7.3 is not something I'm inclined to implement.

Specifying the use of U-labels in the "from" and "by" clauses rather
looks like a bad judgement call, rough consensus or not.  Until the
Protocol Police show up, I'm sticking with A-labels. :-(