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

John C Klensin <john-ietf@jck.com> Wed, 22 July 2020 05:49 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 9139A3A0E06 for <ietf-smtp@ietfa.amsl.com>; Tue, 21 Jul 2020 22:49:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcRJ2oB98F55 for <ietf-smtp@ietfa.amsl.com>; Tue, 21 Jul 2020 22:49:22 -0700 (PDT)
Received: from bsa3.jck.com (bsa3.jck.com [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2EA3A0E04 for <ietf-smtp@ietf.org>; Tue, 21 Jul 2020 22:49:22 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1jy7d2-00010t-2o; Wed, 22 Jul 2020 01:49:20 -0400
Date: Wed, 22 Jul 2020 01:49:15 -0400
From: John C Klensin <john-ietf@jck.com>
To: Keith Moore <moore@network-heretics.com>, ietf-smtp@ietf.org
Message-ID: <3460DCD7D42390BD22FECF60@JcK-HP5.jck.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
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/vzwDjqdCHkTTT9-Lk-ZHTnrGSYc>
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.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: Wed, 22 Jul 2020 05:49:24 -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 [1] 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

[1] Noting Dave's comments about people who choose to try to
help a relative newcomer by examining possible cases and
agreeing with him that, if this list were exclusively dedicated
to emailcore work from the time the BOF proposal was announced,
those efforts would probably be inappropriate.