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

Ned Freed <ned.freed@mrochek.com> Fri, 06 March 2020 16:59 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1609A3A0B1D for <ietf-smtp@ietfa.amsl.com>; Fri, 6 Mar 2020 08:59:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvGYeK4VRCDx for <ietf-smtp@ietfa.amsl.com>; Fri, 6 Mar 2020 08:59:46 -0800 (PST)
Received: from plum.mrochek.com (plum.mrochek.com [172.95.64.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A873A0B1C for <ietf-smtp@ietf.org>; Fri, 6 Mar 2020 08:59:46 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RI6FBEM2ZK004HR2@mauve.mrochek.com> for ietf-smtp@ietf.org; Fri, 6 Mar 2020 08:54:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1583513682; bh=69qTLKEzLBAHFvRd9QgmuO9PuKdsK++yTizBmMq5CKw=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=naZyColkIdfKVJSiR8AF/kFMLHrrTOQ9GJmGXM37ZZ1J7U1G9LU7DKv27BXp0a5Nn Ub6BUcEDmwn45DOAK8mU5CwVUeUy91JVrvdCys0myTIz+gTYWGb40p3O+EkjkjklsV X3BTymTAAVx8blbZx5Am8W6AZ7VmddZt18Gzoao0=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii; Format=flowed
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RHZJJQONQO000058@mauve.mrochek.com>; Fri, 6 Mar 2020 08:54:40 -0800 (PST)
Cc: John C Klensin <john-ietf@jck.com>, ietf-smtp@ietf.org
Message-id: <01RI6FBD2O66000058@mauve.mrochek.com>
Date: Fri, 06 Mar 2020 08:37:48 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Fri, 06 Mar 2020 11:34:50 -0500" <alpine.OSX.2.22.407.2003061129530.22046@ary.qy>
References: <20200305043414.0E7C515740C2@ary.qy> <87055.1583465260@turing-police> <9DF11014-4C79-49DE-B17E-12B87F2FF17C@isc.org> <alpine.OSX.2.22.407.2003052339010.19976@ary.qy> <961C7C4EA24A110554D88BFA@PSB> <alpine.OSX.2.22.407.2003061129530.22046@ary.qy>
To: John R Levine <johnl@taugh.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/_sy_F-x3Uy-uzeZwUcQXm8YL_vE>
Subject: Re: [ietf-smtp] Is this a valid Message-ID header ?
X-BeenThere: ietf-smtp@ietf.org
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\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Mar 2020 16:59:48 -0000

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.

> https://mailarchive.ietf.org/arch/msg/last-call/xTEWTOyy4HOX-wyvFVaOicn2P-I/#

> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly

> _______________________________________________
> ietf-smtp mailing list
> ietf-smtp@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-smtp