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

Dilyan Palauzov <> Tue, 21 July 2020 07:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88B693A144A for <>; Tue, 21 Jul 2020 00:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (4096-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sPOCtScmy_9Q for <>; Tue, 21 Jul 2020 00:37:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6DA753A13F6 for <>; Tue, 21 Jul 2020 00:37:54 -0700 (PDT)
Received: from (localhost []) by (8.15.2/8.15.2) with ESMTP id 06L7bnj5723857 for <>; Tue, 21 Jul 2020 07:37:49 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=k4096; t=1595317069;; bh=43SSZiuCz7QXm1bsrKAKUyL9Ot24ixglIQTEJ9isuts=; h=Date:From:To:Subject:References:In-Reply-To; b=Qaos+9toK2NBagg467irw/jkfjsVEbLl4tiqsHEyT7cABgY9gX5VcFc5Q09KfOFTk mMlIcz1FVgpgPl4WaQtNDM0KvPvdgxVST8VeMNky05fr2psykRvLXFQvQISxFOVxgd XTJFKTppsKK8bwZnsn+8YCvfjq8RyDG23Vj5MXCivv1r3qTSR2hdOKLzMpSCd0CvTQ rGpIN00a2YYx62jb3GiaIJBHtNmHrDKwzMUNP7NmUUH0op5+0ZRiwrM2qmbsrVwJyP Fh/hRdJmsKE+P5VQs4TJ6sdNShTEwAgeTZB9vlUnpIaSO3g7mHoO/xR4FW0tN/xTc+ clmkidfksjthrOB+K7NqBkwj0qeZ8NcWE+O+Qch173k8rUuF2zC/cmFyyjj/GVG1Wv qCihz0FpApx4QnrHM9HhHnChCRlSMpZTY1w2Vdjwl4Wns8RX049vJzX4KhDipJowov baLzJEakpNIhPQK3tYpt7zdFafGYz+28xZUFqgVBf8hfi/C3m2EMLK6KcntzaAJKgf AsVh+ZLSAZQCoPtczBsAbJgKpcyw7AuLW73pzh8gSYxpT5yPgSaH5wMP3eAHCkdLHf dqjJmrtv+3eTfSA0S78IWMfo/ifvSz0DNQHAMgodpb4l3C4TXgXH5FyFbctbNVBFUY Ko5YpQjdBFKTEibC+Nbu4DbI=
Authentication-Results:; dkim=none
Received: from ( []) by (Horde Framework) with HTTPS; Tue, 21 Jul 2020 07:37:49 +0000
Date: Tue, 21 Jul 2020 07:37:49 +0000
Message-ID: <>
From: Dilyan Palauzov <>
References: <> <52D9A14B4CDD14BB4C97C355@PSB> <> <DE8B2C33275660E19FFA513C@PSB> <> <5C6196E28FCDC4A312E73A00@PSB> <> <20200719144357.A64221D393E2@ary.qy> <> <B7E061A14E80279E1E14D92F@PSB>
In-Reply-To: <B7E061A14E80279E1E14D92F@PSB>
User-Agent: Horde Application Framework 5
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.102.3 at
X-Virus-Status: Clean
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 07:38:00 -0000


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 [])
  by (Postfix) with ESMTP id 6B1623A08A2
  for <>om>; Sun, 19 Jul 2020 11:20:01 -0700 (PDT)
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 g-1uauMMW0n1 for <>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).


----- Message from John C Klensin <> ---------
    Date: Sun, 19 Jul 2020 14:19:52 -0400
    From: John C Klensin <>
Subject: Re: [ietf-smtp] Curious, with this now being associated to  
emailcore, should list name change?
      To: Arnt Gulbrandsen <>no>,

> --On Sunday, July 19, 2020 18:57 +0200 Arnt Gulbrandsen
> <> 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
> _______________________________________________
> ietf-smtp mailing list

----- End message from John C Klensin <> -----