Re: [ietf-smtp] Curious, with this now being associated to emailcore, should list name change?

Keith Moore <> Wed, 22 July 2020 03:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BBBCD3A0A24 for <>; Tue, 21 Jul 2020 20:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 n93mZ6bF9NQw for <>; Tue, 21 Jul 2020 20:16:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F40B13A0A20 for <>; Tue, 21 Jul 2020 20:16:41 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 382995C0090; Tue, 21 Jul 2020 23:16:41 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute4.internal (MEProxy); Tue, 21 Jul 2020 23:16:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=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=fm3; bh=BpVhQB k9gZYhG6kK8b57gaYKg7c2JuTohWoUtg1zZ9g=; b=N5jf/B0BvhSaNKa15HV+zL udaLn9mnZVfV2/p6zfBQpme/VXzOISVeo+0IXDPsCt/BGxrpqP4MQl3UPBXaPMMn +MbVlbormE/txT8Skl/HWFMEWo3a9zCjHGtn/7jMUZ0AWgfmoArfU4cdXfWLbiKY 5mpI648c7fFKS7nHg5XjZclI2gLqESIlForAd48N2aA6LuK+f7vi4JjxoDHae/47 JTnaqK7ZmFpKSN8Iesta8VY/B+fN4l+zjdh80ELBLVc0846pUT04zNb/F6klHXwo 11/+eLATsQwaeIeidIQgUTynJIjSQH72D6wtT+EFcp6/ZMcjFXmQn7pShTWKqVDw ==
X-ME-Sender: <xms:lq8XX3F2Ar0NDe4iaiuBNXP5Ik_TN7fSWZD_dbgHCzbkZxpc9lLXBg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrgeekgdeikecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtsegrtderre dtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthifohhr khdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeevfeetudeigedtle dvvddtudefjeejffdvfeetjeeiueelgfdtgfegtdffkeetudenucfkphepuddtkedrvddv uddrudektddrudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:lq8XX0UQmCZs1l9Ei3NV-Jdwbm3r1oFWI3Ar_T3_u-t2FEd58J7HSQ> <xmx:lq8XX5JDWdo6y85wy646Ku-DdPXRDMgdVrRxGyclssEqKwo17Q025Q> <xmx:lq8XX1FdMlZ1YyKETxIa8UppXY-Zrp3ddan1_Xj6ouXlKpb_DbrTJA> <xmx:ma8XXyXsESb8M3sfRNdnFMu0-gI_BIFmownT3B5FBd6dLhrM0wm6rA>
Received: from [] ( []) by (Postfix) with ESMTPA id 1D8C0328005E; Tue, 21 Jul 2020 23:16:38 -0400 (EDT)
To: John C Klensin <>,
References: <> <52D9A14B4CDD14BB4C97C355@PSB> <> <DE8B2C33275660E19FFA513C@PSB> <> <5C6196E28FCDC4A312E73A00@PSB> <> <20200719144357.A64221D393E2@ary.qy> <> <> <> <> <>
From: Keith Moore <>
Message-ID: <>
Date: Tue, 21 Jul 2020 23:16:37 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------767916C605E429DEDE4B52FE"
Content-Language: en-US
Archived-At: <>
Subject: Re: [ietf-smtp] Curious, with this now being associated to emailcore, should list name change?
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, 22 Jul 2020 03:16:44 -0000

On 7/21/20 9:08 PM, John C Klensin wrote:

>> I think it's slightly deeper than that, which is that every
>> time one party adds a new header field, some number of other
>> parties decide that they can delete or modify that field, or
>> use it to validate or invalidate the message.   So random
>> parties making random decisions about message headers are
>> detrimental to email reliability.
> I agree with that.  But that is the justification for registered
> header field names, preferably well-documented and stable ones.

I suspect this is not an issue that can be addressed by any combination 
of registration and/or field-naming constraints in the absence of 
instructions to message-handling software about which fields (if any) 
they can add, modify, or delete.

I love the format's extensibility but I suspect there's a point of 
diminishing returns.   The message header has become a garbage dumping 
ground, and it might need some cleaning up.