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

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

Dilyan,

It is a bit more than "questions the usefulness of".  Please see
the explanation in RFC 6648.  I'll let others respond to the
DKIM header suggestion.

best,
   john



--On Tuesday, 21 July, 2020 07:37 +0000 Dilyan Palauzov
<[e-mail]> wrote:

> Hello,
> 
> my reading is that this thread questions the usefulness of the
> X- headers, spread over the internet.  The message below
> contains:
> 
> Received: from localhost (localhost [127.0.0.1])
>   by ietfa.amsl.com (Postfix) with ESMTP id 6B1623A08A2
>   for <[e-mail]>; Sun, 19 Jul 2020 11:20:01
> -0700 (PDT)
> 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 g-1uauMMW0n1 for <[e-mail]>;
>   Sun, 19 Jul 2020 11:20:00 -0700 (PDT)
> 
> X-headers are useful to insert information about what and why
> intermediate hosts think about the spam probability of a
> message.  They can prevent manual communications on this.
> Unfortunately the above X-Spam headers do not include
> information about which host added that headers.
> 
> As useless mail headers do make emails heavier, I am in favour
> of removing DKIM-Signature headers, that are known to be
> broken, e.g. because the current host has modified (and
> resubmitted) the message.  Or if not completely removed, then
> at least shortened by substituting to "b=invalided" or
> "b=invalidated-on-host-A.B".  The latter is more useful
> than just having an invalid dkim-signature. (or removing the
> b=/bh= tags and putting instead a new tag containing the host
> where the signature was broken, which not really an
> Authenticated Receiver Chain, and does make the massage
> shorter).
> 
> Greetings
>    Dilyan
> 
> ----- Message from John C Klensin <[e-mail]> ---------
>     Date: Sun, 19 Jul 2020 14:19:52 -0400
>     From: John C Klensin <[e-mail]>
> Subject: Re: [ietf-smtp] Curious, with this now being
> associated to emailcore, should list name change?
>       To: Arnt Gulbrandsen <[e-mail]>,
> [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-494e424f582
>>>  e6 47261667473
>>>  X-Gemstorm-Computing-T/A-The-It-Company-Mailscanner-Informa
>>>  ti on
>>>  X-Ms-Exchange-Crosstenant-Originalattributedtenantconnectin
>>>  gip
>>>  X-Gemstorm-Computing-T/A-The-It-Company-Mailscanner-Spamche
>>>  ck
>>>  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
>> 
>> 
>> _______________________________________________
>> ietf-smtp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ietf-smtp
> 
> 
> ----- End message from John C Klensin <[e-mail]> -----
> 
> 
> 
> _______________________________________________
> ietf-smtp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-smtp