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

Dave Crocker <> Wed, 22 July 2020 01:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA67C3A07EA for <>; Tue, 21 Jul 2020 18:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-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 08T0BLaKkRrA for <>; Tue, 21 Jul 2020 18:31:40 -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 C772A3A07E6 for <>; Tue, 21 Jul 2020 18:31:40 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06M1YDhe010555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <>; Tue, 21 Jul 2020 18:34:13 -0700
References: <20200721201938.D4F7D1D5CAD3@ary.qy>
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Tue, 21 Jul 2020 18:31:35 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <20200721201938.D4F7D1D5CAD3@ary.qy>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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: Wed, 22 Jul 2020 01:31:42 -0000

On 7/21/2020 1:19 PM, John Levine wrote:
> The amount of bandwidth used by e-mail is a rounding error of the
> Internet's total, which is mostly video these dayts, and the amount
> used by broken headers is a rounding error on that rounding error.


My understanding is that the goal of the emailcore work is to do the 
minimum necessary to enable promoting the core email specifications to 
full standard.

Each of us has a worthy list of wonderful enhancements, cleanups, and 
the like, that we would love to see pursued for email.  None of them is 
likely to be within scope for this round of effort.

To the extent that someone thinks otherwise, consider that each item 
added to the task list delays completion of this round of effort, and 
possibly for quite awhile.

So, as fascinating as this thread has been, unless someone can explain 
how it is essential to the work of the emailcore effort, I'll ask why it 
is worth taking up this much list energy? Absent compelling 
justification, is there a chance people could stop feeding this thread?

As an aside: X- was deprecated.  It's not illegal, but it's no longer a 
formal construct.  I thought it quite a clever suggestion, when we were 
doing RFC 822 -- though I don't remember who suggested it -- but as with 
many good suggestions, it had downsides we hadn't anticipated.

Also, as for cleanup of email header fields in transit, I'm pretty sure 
that it is fully out of scope for SMTP, IMAP, Mail Format and any other 
emailcore work.  It certainly should be, since it isn't causing actual 
operational problems.


Dave Crocker
Brandenburg InternetWorking