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

John C Klensin <john@jck.com> Tue, 21 July 2020 16:14 UTC

Return-Path: <john@jck.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 5B6763A0B74 for <ietf-smtp@ietfa.amsl.com>; Tue, 21 Jul 2020 09:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 kj51RUiGUyLt for <ietf-smtp@ietfa.amsl.com>; Tue, 21 Jul 2020 09:14:05 -0700 (PDT)
Received: from bsa3.jck.com (bsa3.jck.com [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9873A0B71 for <ietf-smtp@ietf.org>; Tue, 21 Jul 2020 09:14:05 -0700 (PDT)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john@jck.com>) id 1jxuu1-000PpP-HK; Tue, 21 Jul 2020 12:14:01 -0400
Date: Tue, 21 Jul 2020 12:13:56 -0400
From: John C Klensin <john@jck.com>
To: Dilyan Palauzov <Dilyan.Palauzov@aegee.org>
cc: ietf-smtp@ietf.org
Message-ID: <F91418308CF666ED6BA9A2C1@JcK-HP5.jck.com>
In-Reply-To: <20200721073749.Horde.BvL2fIPJNN50jFlj5GWcj_e@webmail.aegee.org>
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> <B7E061A14E80279E1E14D92F@PSB> <20200721073749.Horde.BvL2fIPJNN50jFlj5GWcj_e@webmail.aegee.org>
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: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/rDGArOfD3iDstkOl3nQ0IX3pWlc>
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: Tue, 21 Jul 2020 16:14:07 -0000

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
<Dilyan.Palauzov@aegee.org> 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 <ietf-smtp@ietfa.amsl.com>om>; 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 <ietf-smtp@ietfa.amsl.com>om>;
>   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 <john-ietf@jck.com> ---------
>     Date: Sun, 19 Jul 2020 14:19:52 -0400
>     From: John C Klensin <john-ietf@jck.com>
> Subject: Re: [ietf-smtp] Curious, with this now being
> associated to emailcore, should list name change?
>       To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>no>,
> ietf-smtp@ietf.org
> 
> 
>> --On Sunday, July 19, 2020 18:57 +0200 Arnt Gulbrandsen
>> <arnt@gulbrandsen.priv.no> 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
>> ietf-smtp@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-smtp
> 
> 
> ----- End message from John C Klensin <john-ietf@jck.com> -----
> 
> 
> 
> _______________________________________________
> ietf-smtp mailing list
> ietf-smtp@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-smtp