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

John C Klensin <john-ietf@jck.com> Mon, 12 June 2023 15:54 UTC

Return-Path: <john-ietf@jck.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 A987CC15C522 for <ietf-smtp@ietfa.amsl.com>; Mon, 12 Jun 2023 08:54:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.508
X-Spam-Level: *
X-Spam-Status: No, score=1.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_96_XX=3.405, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FJTaDS3MdrA for <ietf-smtp@ietfa.amsl.com>; Mon, 12 Jun 2023 08:54:20 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C187C151998 for <ietf-smtp@ietf.org>; Mon, 12 Jun 2023 08:52:10 -0700 (PDT)
Received: from localhost ([::1] helo=HPp2019) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1q8jpx-000PUO-AY; Mon, 12 Jun 2023 11:52:09 -0400
From: John C Klensin <john-ietf@jck.com>
To: Keith Moore <moore@network-heretics.com>, ietf-smtp@ietf.org
Message-ID: <D66A1454D54E217D4C7C572E@HPp2019.jck.com>
In-Reply-To: <f821254c-bba7-5a69-edb9-b40ddf0b4f95@network-heretics.com>
References: <81c2a19c-f19e-b495-3441-22c2a112037c@linuxmagic.com> <52D9A14B4CDD14BB4C97C355@PSB> <CAKFo7w=9_eZda47ZMUv_NE9iN1FEnGM7m3nUFy3_Wq4se+W8XQ@mail.gmail.com> <DE8B2C33275660E19FFA513C@PSB> <CAKFo7wmsm+1ck5G7Sj-NpnyXgeHd14cxGQ6K9KFeVG0_CTM1sw@mail.gmail.com> <5C6196E28FCDC4A312E73A00@PSB> <CAKFo7wk+jLGqjs6mU=Gv3G1xAg+O5OyTmt66fjW4DLzUT5kuPw@mail.gmail.com> <20200719144357.A64221D393E2@ary.qy> <ce227a65-05f8-4b3a-b464-5720cd39fc3b@gulbrandsen.priv.no> <49CA9C38-1A30-4456-869D-60D5B70C27B1@episteme.net> <65855E18CFC3E02EB145F68C@JcK-HP5.jck.com> <fbd28f17-a048-c2aa-9691-77aa4e08ea13@network-heretics.com> <B60451A4F812EFB326A5FA43@JcK-HP5.jck.com> <f821254c-bba7-5a69-edb9-b40ddf0b4f95@network-heretics.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/WM2tBx4Q19iWXzdW5siAEPVNJFQ>
Subject: Re: [ietf-smtp] Curious, with this now being associated to emailcore, should list name change?
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.39
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>
Date: Mon, 12 Jun 2023 15:54:20 -0000
X-Original-Date: Tue, 21 Jul 2020 23:28:01 -0400
X-List-Received-Date: Mon, 12 Jun 2023 15:54:20 -0000


--On Tuesday, July 21, 2020 23:16 -0400 Keith Moore
<moore@network-heretics.com> wrote:

> 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.

Agreed.  But also agree with Dave that it is difficult to
imagine how cleaning up such a dump (even if there were
consensus on that characterization) could be within scope for
emailcore.   It probably is in scope for this list but I hope we
don't need to separate emailcore to a separate list in order to
get anything done there.   ...Another decision I hope we can
defer until after the BOF.

  john