Re: [ietf-smtp] broken signatures, was Curious

Michael Richardson <> Tue, 21 July 2020 22:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7FC83A0B3D for <>; Tue, 21 Jul 2020 15:25:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id elUm8IMOssXH for <>; Tue, 21 Jul 2020 15:25:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2F4553A0B39 for <>; Tue, 21 Jul 2020 15:25:33 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD53A38A24; Tue, 21 Jul 2020 18:05:06 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id CxEWtdNoCgjY; Tue, 21 Jul 2020 18:05:06 -0400 (EDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 65E4D38A23; Tue, 21 Jul 2020 18:05:05 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id ECA4EA8; Tue, 21 Jul 2020 18:25:30 -0400 (EDT)
From: Michael Richardson <>
To: Paul Smith <>
In-Reply-To: <>
References: <20200721201938.D4F7D1D5CAD3@ary.qy> <> <>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Tue, 21 Jul 2020 18:25:30 -0400
Message-ID: <6464.1595370330@localhost>
Archived-At: <>
Subject: Re: [ietf-smtp] broken signatures, was Curious
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 22:25:36 -0000

Paul Smith <> wrote:
    >>> Look at the headers of the mail in your inbox, particularly mail from
    >>> large providers, and you'll find megabytes of headers that nobody is
    >>> ever likely to look at or use.  This battle was over decades ago.
    >> I heard this stated by you a few times. I never brought into it. It wasn't
    >> a problem to be concern about a few decades ago.  Now it is. It's junk and
    >> its growing.  The more it grows the more overhead we have. It makes systems
    >> who are suppose to be ignorant about the junk, work harder.  It makes your
    >> "View Source" more cryptic.

    > Hmm, my view is that the headers should be at least vaguely useful at the
    > recipient end. That means that OK examples could be:


    > But useless ones could be:

But, how to tell which is which, and your X-PP-Email-Transimission-Id
scenario is actually a point.

    > The former set may be more useful if it was tagged with WHICH server added
    > those headers, but that's it.

It seems that we could write a BCP that says that X-Foo is bad, but is better?

I think that there is information in the DKIM header which can tell us what
we need to keep.
Any header mentioned in a validatable DKIM header needs to be kept, right?
That also tells us which server added, or was aware of those headers.

If the message goes through "mailman" or some other processor, then it seems
like it ought to rip pretty much every X-FOO out.  The rest of them ought to
be known headers at the time the processor was written, and it ought to
either know what they are, or it does not, in which case, it shouldn't pass
on things it does not know about.

I suspect that this would at least make a lot of us less grumpy about excess headers.

I don't subscribe to the idea that the target MTA should rip everything other
than From/To/Subject/Date out.  That would limit our ability to innovate, and
there sure has been a lot of that!  But, surely, any system that knows what
some header is, (such as X-BeenThere or X-GRID-REF) *is* ought to rip that
out as it knows whether or not its useful.

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-