ietf-smtp
[Top] [All Lists]

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

2020-07-21 17:01:56


--On Tuesday, 21 July, 2020 16:15 -0500 Pete Resnick
<resnick(_at_)episteme(_dot_)net> 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
problem.  

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.

    john



_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>