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

Viktor Dukhovni <> Tue, 25 May 2021 19:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2EA7A3A1A8E for <>; Tue, 25 May 2021 12:32:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FZoomfTbQvlv for <>; Tue, 25 May 2021 12:32:53 -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 780F63A1A8C for <>; Tue, 25 May 2021 12:32:53 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 63637D78D8; Tue, 25 May 2021 15:32:52 -0400 (EDT)
Date: Tue, 25 May 2021 15:32:52 -0400
From: Viktor Dukhovni <>
Message-ID: <>
References: <>
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: Tue, 25 May 2021 19:32:55 -0000

On Mon, May 24, 2021 at 07:05:53PM -0400, John R. Levine wrote:

> I've been doing some EAI tests.  RFC 6531 section 3.7.3 says that domain 
> names in trace headers SHOULD all be U-labels.  In practice, everyone uses 
> A-labels for reasons that are not absurd.  The FROM clause has the name 
> from the EHLO command which has to be sent as A-labels, and it's quite 
> plausible to have a message where the message itself is entirely ASCII, 
> sent to a UTF-8 address, which then could be forwarded to an ASCII address 
> except that it has those U-labels in the trace header which would have to 
> be downgraded.  I've talked to a couple of MTA maintainers who have told 
> me forget it, that's silly, not doing that.

Disclaimer: I'm one of the MTA maintainers who found the RFC advice in
question to be unworthy of implementation.

> In a situation like this, would it make sense in a future update to the 
> RFC to adjust the advice to the reality?

Without daring to generalise to broader questions of whether/when the
spec or the implementations have the final say, on the particulars of
this specific case I think it is easy to conclude that it best to amend
the specification.

    * The specification in question prescribes the format of some fields
      of trace headers that most users will not see.

    * The specifications causes the format used in the trace header to
      differ from the actual data exchanged on the wire.  These are the
      client-to-server EHLO name and the server-to-client greeting name,
      also repeated in the first line of the EHLO response.

      Because both are exchanged prior to negotiation of SMTPUTF8, they
      always in A-label form.

    * The trace headers should match data recorded in system logs and
      are mostly for the benefit of the postmaster.  There's more value
      in making them readable to any/all the postmasters along the
      delivery path, than to those versed in the native tongue of the
      message sender and ultimate recipients.

    * It is possible that the message headers are all ASCII, and the
      only presence of UTF8 is in the envelope, which may get rewritted
      or narrowed in transit.  By the time the message is delivered to
      some mailboxes, the only non-ASCII content that might remain could
      be the trace headers in question (if they follow the RFC).

      Given that not all IMAP clients, MUAs, ... support EAI, the
      conservative thing to do (a la Postel) is to not needlessly
      inject UTF8 content into the message headers.

Therefore, I find the specific RFC text to be misguided, and not
only inessential to interoperability/utility, but actually working
against both.  I am therefore inclined to ignore this part of the
RFC with prejudice.  If there's an opportunity to revise (remove)
the text, that'd be great.