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

[John C Klensin <[e-mail]>]

--On Sunday, July 19, 2020 18:57 +0200 Arnt Gulbrandsen
<[e-mail]> wrote:

> On Sunday 19 July 2020 16:43:57 CEST, John Levine wrote:
>> Adding new names to the registry requires expert review and I
>> expect the expert would be sceptical of proposed names that
>> were a lot longer than the existing ones. I don't see any
>> over 35 characters which seems reasonable.
> 
> 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
>...

<Sounds of virtual vomiting>

It is interesting that every one of these starts in "X-".

Presumably, by putting "X-" in front of their field names, the
perpetrators believe that they are exempt, not only from the
registry and its rules, but any rules at all.  That would be my
concern here: maybe it would be worth getting a stake in the
ground that long, or very, long field names are a bad idea
and/or a bigger stake in the ground about "X-" prefixes.  Unless
we accompany it with a really strong, clear, and persuasive
discussion of the problems it causes, which might help, I wonder
if the offenders would pay any attention at all?  

The rest of this note is more or less a rejection of the notion
that because there are no protocol police, we can't do anything
(or anything useful), with some questions, speculation, and
examples about what might be done.  I haven't made my mind up
yet whether doing something would be worthwhile; I just want to
get past the idea of impossibility.  Those who aren't interested
in that speculation, or who would prefer to leave it for the BOF
or WG, should probably stop reading here.

    -----

Perhaps more important than what the perpetrators do today,
user-defined-fields using "X-" were deprecated by RFC 2822
nineteen years ago, with that message reinforced by RFC 6648
more than eight years ago.  Much as, on principle, I hate the
idea of intermediate MTAs messing with non-trace headers, would
relays or anti-malware systems consider just deleting the things
as potentially-dangerous noise?  Do they check now for embedded
nastiness in header field data as well as body parts?   Should
we be encouraging Submission Servers to discard them (there is
enough flexibility in RFC 6409 to allow that and, given that
such servers are not supposed to inject non-conforming stuff
into the public Internet SMTP system, our banning them would
make a Submission Server that let them pass non-conforming)? How
about the interface between the mailstore and receiving MUAs:
could these things be tossed out there?  Would any of that help
and would our saying something even stronger than what RFC 6648
says (it mostly applies to new header field names, not older
ones, but I'd guess the vast majority of these were invented
after June 2012 and almost certainly after April 2001) be
useful?  Even if the fields are, as John Levine points out,
probably just clueless rather than spammy, it is probably not a
wonderful idea to encourage noise in mail headers, those whose
intent is malicious are likely to uncover opportunities sooner
or later, and perhaps (just perhaps) people getting a little
proactive now might prevent or head off future attacks.

There aren't any protocol police, but there are certainly
implementers who can decide, especially if we make a strong
recommendation in that area to help them defend against angry
folks who produce this stuff, to not tolerate this particular
type of nonsense any more.  Should we register a
"Deleted-NonConforming-Headers:" field, treat it as an optional
trace field with "By" and timestamp information, and then have
the rest of the value showing either the number of such fields
tossed out or the header field names (but not values)?

Would the suggestion that started this thread be consistent with
an applicability statement, either in 2822bis or the separate
document for which draft-klensin-email-core-as-00 is a
placeholder, that said something like "Header field names
starting in 'X-' or longer than NNN are prohibited unless they
are legacy registrations in the IANA registry.  They MUST NOT be
transmitted in messages and Submission Servers and other systems
encountering them MAY, and in most cases SHOULD, delete them"? 

At a whole different level, at least several of these examples
appear to be loop detection tools.  Should we be taking another
look at the loop detection support machinery in 5321 (IIR,
although there have been some clarifications and details, that
machinery is not significantly changed since RFC 821) either as
part of the proposed emailcore effort or separately?

Again, I don't yet have an opinion as to whether we should take
those, or other, actions on this topic.  I'm just wondering what
actions might be effective if we did decide to take them.

best,
   john