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

Keith Moore <> Sun, 08 March 2020 01:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC8C73A1E2C for <>; Sat, 7 Mar 2020 17:00:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id n4XSzYPfT6MA for <>; Sat, 7 Mar 2020 17:00:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 89CC13A1E2B for <>; Sat, 7 Mar 2020 17:00:01 -0800 (PST)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id A5ADD220A7; Sat, 7 Mar 2020 20:00:00 -0500 (EST)
Received: from mailfrontend1 ([]) by compute4.internal (MEProxy); Sat, 07 Mar 2020 20:00:00 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=/LQl5ZiiIDM8gsL2X9xRpwr/GWuZO/KMp/D44/+jP tg=; b=2UquVTcCEMX0EukNVwEATwZSWrDMCfjlSwXtVVszxF2eqxNF1kAGH1Wmq /FJR1wFS6NHUkPn1kxzHForWkx9Ek8Gexi2oeqvNk4bmc6qPPENzoMnUPo9hRaHi 0Y//AU3P0KBsJUfxgoS6jDXFRUv+Idc2ARBnv5JKJOUXdzVhLyFW2D0gYUFU0BQu FhX5peO6XOtmAp5iJyg+YPqUkVWehloGBhfjFhYFed85sDvSAzs08DCNo2OnlLMe QQ+wE0UkJtyjO5fR+7tkkV8PxSTP2LygkmbmXf4LG2dr6KVGWM28UUVy8zBxovQL yPPE7pr5vXQ10klhkTarln4ocnV1A==
X-ME-Sender: <xms:kENkXrRg5Bf5929KJj2QbyxTu_fpcCLpYGlw6NrMAXMfYajDWj1I-w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudduhedgvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucfkphepuddtkedrvddvuddrudektddrud ehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhho ohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:kENkXhDaMzpbH7aceasVR252Ts66tixj8eb5SOlbBuCiLRKRGnZUrg> <xmx:kENkXr0laQblIlOm6oALWWJOfIelC8xjzSA4N8Beu2B6VHSDd4AKYQ> <xmx:kENkXvXo5_HUWCmfpc5gY6SEmT-WmCGF0v7AiEwnVDIeKP1yXbhYXg> <xmx:kENkXsLTOxJ63-GG_XK_bO7W-KF7pFeHEjw6rKknncK-r_xHaZCIpw>
Received: from [] ( []) by (Postfix) with ESMTPA id 2428B3280060; Sat, 7 Mar 2020 20:00:00 -0500 (EST)
References: <20200305043414.0E7C515740C2@ary.qy>
From: Keith Moore <>
Message-ID: <>
Date: Sat, 7 Mar 2020 19:59:59 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20200305043414.0E7C515740C2@ary.qy>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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: Sun, 08 Mar 2020 01:00:03 -0000

On 3/4/20 11:34 PM, John Levine wrote:

> I read IETF mailing lists on the IETF's IMAP server* and of late I've been
> seeing some awfully funky stuff.
> This is an actual Message-ID header in one of the messages in dnsop.
> Is that valid?  Even though the MIME decodes to a an ASCII message ID
> in the <string@domain> format, I think the answer is no.  That's not
> what RFC 5322 sec 3.6 allows.
> Message-ID: =?utf-8?q?=3CBN7PR11MB25474DF04998FF3AA9E0B80BC9E40=40BN7PR11MB2?= =?utf-8?q?547=2Enamprd11=2Eprod=2Eoutlook=2Ecom=3E?=

No, it's not valid.   The above field body scans as "atom atom", and a 
msg-id cannot begin with two atoms without some other symbol (e.g. ".") 
in between.

RFC 2047 encoded-words were designed to be compatible with the 
(then-current) RFC 822 grammar, so that they wouldn't break existing 
parsers.   That means that any decoding of encoded-words for 
presentation occurs after (header field-specific) parsing. Also, section 
5 of RFC 2047 limits use of encoded-words to very specific places in the 
message header.   Any text that parses as atom that appears elsewhere in 
a message header, should be treated as an ordinary atom, even if it 
looks like an encoded-word.