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

Ned Freed <ned.freed@mrochek.com> Wed, 22 July 2020 15:21 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 C35E73A0995 for <ietf-smtp@ietfa.amsl.com>; Wed, 22 Jul 2020 08:21:10 -0700 (PDT)
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 xsNrvPYYa6Xd for <ietf-smtp@ietfa.amsl.com>; Wed, 22 Jul 2020 08:21:09 -0700 (PDT)
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 789553A0964 for <ietf-smtp@ietf.org>; Wed, 22 Jul 2020 08:21:09 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RNJ675YLB4008GMU@mauve.mrochek.com> for ietf-smtp@ietf.org; Wed, 22 Jul 2020 08:16:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1595430965; bh=IG17TB+DdPIj1YGon0b00o9oG3OkVTHdyGlfvaLtsLw=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=qwi5hBjzgwl+idUAPKW9qec75TmcimB6o76/l5nbM6m4jYot2/zXRDVEK01gT6Lsk 82gXIvOcqtGCNEhgpAMPWM2QZ2qeldFXXNdiD42w3HRNysdICwkPRoiGx/xIn9PIh1 3RyDyRh3L6zrR7uPjIEPDyjmY1LTV20z2HudN/34=
MIME-version: 1.0
Content-transfer-encoding: 8bit
Content-type: TEXT/PLAIN; charset="utf-8"; format="flowed"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RNJ51YV9O00076ZY@mauve.mrochek.com>; Wed, 22 Jul 2020 08:16:02 -0700 (PDT)
Cc: John C Klensin <john-ietf@jck.com>, ietf-smtp@ietf.org
Message-id: <01RNJ67483900076ZY@mauve.mrochek.com>
Date: Wed, 22 Jul 2020 08:14:29 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Tue, 21 Jul 2020 23:16:37 -0400" <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>
To: Keith Moore <moore@network-heretics.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/WAXu6kxpupd2nmwKcpisH7UEl-8>
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 15:21:14 -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.

Doors, once opened, are hard to close.

Building a door where none existed before is even more difficult. Especially
when the costs of construction have yet to be justified.

				Ned