Re: [ietf-smtp] Is this a valid Message-ID header ?

John C Klensin <> Fri, 06 March 2020 17:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 95A893A0BC7 for <>; Fri, 6 Mar 2020 09:25:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sqUZ1hqYOSwW for <>; Fri, 6 Mar 2020 09:25:00 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F7CE3A0BD3 for <>; Fri, 6 Mar 2020 09:25:00 -0800 (PST)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1jAGiW-0006Jl-Pi; Fri, 06 Mar 2020 12:24:56 -0500
Date: Fri, 06 Mar 2020 12:24:50 -0500
From: John C Klensin <>
To: Ned Freed <>, John R Levine <>
Message-ID: <8A038F33582A9A5BA1E43AD6@PSB>
In-Reply-To: <>
References: <20200305043414.0E7C515740C2@ary.qy> <87055.1583465260@turing-police> <> <alpine.OSX.2.22.407.2003052339010.19976@ary.qy> <961C7C4EA24A110554D88BFA@PSB> <alpine.OSX.2.22.407.2003061129530.22046@ary.qy> <>
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-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
Subject: Re: [ietf-smtp] Is this a valid Message-ID header ?
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: Fri, 06 Mar 2020 17:25:03 -0000


Complete agreement.  And thanks for reminding me/ us about the
additional details.   An additional problem with at least the
ones of these Message-ID (and occasionally the mailbox addresses
in "From:" header fields) is that there is no "@" present in the
encoded form.  So anything that follows the principle of parsing
before trying to do any decoding will fail; only those systems
that, contrary to the clear intend of the spec (for the reason
you give), decode everything that looks like an encoded word
before examining or parsing the relevant fields has even a
chance of imagining that these things are valid.


--On Friday, March 6, 2020 08:37 -0800 Ned Freed
<> wrote:

> The main issue here is that encoded-words are are only defined
> in the
> context of specific pieces of RFC 5322 syntax, and done in a
> way so that
> they don't break the syntax. This is essential so that agents
> that don't
> support RFC 2047 won't have a problem. So this business of
> encoding the
> whole header field, which wrecks the syntax, is simply broken.
> However, this doesn't mean something that things which meet
> the syntax criteria
> for encoded words can't appear in other contexts. For example,
> nothing prevents
> you from using an encoded word as a local-part of an address.
> But if you do,
> its interpretation is just that of a local-part, which is a
> local matter by
> definition. And it can't break the overall syntax of the field.
> The larger problem is that a lot of agents blindly decode all
> the encoded words
> they find in a field, rather than parsing first and only
> undoing the ones that
> appear in specific places where they have meaning. This has
> the effect that a
> lot of invalid encoded-word usage works, kinda sorta.
> And yes, we were well aware that this would be a problem when
> the RFC was
> written. The problem is every other approach we came up with
> had even bigger
> issues. Keith deserves a lot of credit for this work.
> 				Ned
>> On Fri, 6 Mar 2020, John C Klensin wrote:
>> > In the interest of clarity, what you are referring to as
>> > "MIME entities" are encoded words as specified in RFC 2231.
>> > Right?
>> Right.
>> > And because encoded words are not permitted in Message-IDs
>> > or the other fields you mention, those fields must conform
>> > to the specified syntax without decoding.   If they don't,
>> > it is pretty much up to the receiving system what to do
>> > about it. ...
>> That was my understanding, too.  I'm finding these MIME
>> message-ID's in the IETF's IMAP server, so now I'm wondering
>> if they were in the original message.  Here's one that showed
>> up today.  I think they're all from Microsoft.
>> wyvFVaOicn2P-I/#
>> Regards,
>> John Levine,, Taughannock Networks,
>> Trumansburg NY Please consider the environment before reading
>> this e-mail.
>> _______________________________________________
>> ietf-smtp mailing list