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

John C Klensin <> Tue, 21 July 2020 22:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EBCB83A0AE9 for <>; Tue, 21 Jul 2020 15:01:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jesRz25pbdGC for <>; Tue, 21 Jul 2020 15:01:44 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B2DD23A0AE7 for <>; Tue, 21 Jul 2020 15:01:44 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1jy0KM-0000Gy-KX; Tue, 21 Jul 2020 18:01:34 -0400
Date: Tue, 21 Jul 2020 18:01:29 -0400
From: John C Klensin <>
To: Pete Resnick <>, Arnt Gulbrandsen <>
Message-ID: <>
In-Reply-To: <>
References: <> <52D9A14B4CDD14BB4C97C355@PSB> <> <DE8B2C33275660E19FFA513C@PSB> <> <5C6196E28FCDC4A312E73A00@PSB> <> <20200719144357.A64221D393E2@ary.qy> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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: Tue, 21 Jul 2020 22:01:46 -0000

--On Tuesday, 21 July, 2020 16:15 -0500 Pete Resnick
<> wrote:

> On 19 Jul 2020, at 11:57, Arnt Gulbrandsen wrote:
>> My personal server currently has 559 field names longer than
>> that. The  25 worst offenders:
>> X-Offlineimap-X706593913-6d61646475636b2e6e6574-494e424f582e6
>> 47261667473
>> X-Gemstorm-Computing-T/A-The-It-Company-Mailscanner-Informati
>> on
>> X-Ms-Exchange-Crosstenant-Originalattributedtenantconnectingip
>> X-Gemstorm-Computing-T/A-The-It-Company-Mailscanner-Spamcheck
>> X-Ssjmail.Ssjfinance.Com-Mail-Server-Mailscanner-Information
>> Staticcontent1_Header1_F731d3dc-Fd31-4161-Ad91-1083ba56853f
>> Staticcontent2_Header2_F731d3dc-Fd31-4161-Ad91-1083ba56853f
>> X-Mimedefang-Relay-15b21d6f94afe8e768c451e09085c007047aae7e
>> X-Mimedefang-Relay-89167b66339720c294cd81d33948afd6488b114f
>> X-Ssjmail.Ssjfinance.Com-Mail-Server-Mailscanner-Spamcheck
>> X-Ssjmail.Ssjfinance.Com-Mail-Server-Mailscanner-Spamscore
>> X-Gemstorm-Computing-T/A-The-It-Company-Mailscanner-From
>> X-Mailscan-242.Hostingdynamo.Net-Mailscanner-Information
>> X-Content-Pgp-Universal-Saved-Content-Transfer-Encoding
>> X-Kypusserverappliance-Kypus-Mailprotection-Information
>> X-Gemstorm-Computing-T/A-The-It-Company-Mailscanner-Id
>> X-Mailscan-242.Hostingdynamo.Net-Mailscanner-Spamscore
>> X-Mailer.Unfpa-Bangladesh.Org-Mailscanner-Information
>> X-Nugget-Enterprises-Antispam-Mailscanner-Information
>> X-Ssjmail.Ssjfinance.Com-Mail-Server-Mailscanner-From
>> X-Bangladesh-Open-University-Mailscanner-Information
>> X-Ironport.Danmargroup.Co.Za-Mailscanner-Information
>> X-Mail01lehostingservicesnet-Mailscanner-Information
>> X-First-Flight-Couriers-Ltd-Mailscanner-Information
>> X-Gemstorm-Computing-T/A-The-It-Company-Mailscanner
> Other than X- field names not doing what people think they're
> doing, I don't see the problem here. None of them are over 77
> characters, and none (including the ones you showed later with
> curly braces in them) are using problematic characters. So
> what's the problem?

Pete, I think the core issue is the amount of trash we are
accumulating and passing around.  I don't see that as a 5322bis

It might be a problem with how the registry is defined (probably
out of scope for emailcore but anyone who believes it isn't
should make a case at the BOF.   

Questions of how and what header fields a final delivery MTA
should discard before the message is dropped in the mailstore
(as I think Hector has been suggesting) because they might be
useful in transit but are not once received and just clutter up
long-term storage of mail (lots cheaper than it used to be but
still not free), or even what IMAP or POP servers should
suppress before hand-off to their clients might be A/S topics
too, although that would be getting, IMO, a bit far afield (and
adding additional options to IMAP to control delivery of this
stuff is almost certainly out of a reasonable interpretation of
emailcore's scope).

But the original inquiry was whether we need to restrict the
length of header field names.  That almost certainly is an
5322bis issue even though the examples given so far don't make a
strong case for doing it.