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

Dave Crocker <> Wed, 22 July 2020 03:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE58A3A0AAD for <>; Tue, 21 Jul 2020 20:53:48 -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 MZaTkfQpuzYW for <>; Tue, 21 Jul 2020 20:53:47 -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 D002F3A0AAA for <>; Tue, 21 Jul 2020 20:53:47 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 06M3uKMq025371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <>; Tue, 21 Jul 2020 20:56:20 -0700
References: <20200721201938.D4F7D1D5CAD3@ary.qy> <> <>
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
Message-ID: <>
Date: Tue, 21 Jul 2020 20:53:41 -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: <>
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 03:53:49 -0000

> This collection of threads actually started with a claim that
> long header field names were causing operational problems. It

When someone makes a claim like that, they need to document it.  Nothing 
in this thread has done anything like documenting the existence of an 
operational problem.  Unless I missed it, but I don't think I did.

Rather, what happened was a claim that then led to lots of /other/ 
people putting quite a bit of energy into evaluation of all sorts of 
information, none of which demonstrated any operational problems.

Or even tried to, IMO.

> I'm not convinced.  I infer that you are not convinced.  From

Things that cause operational problems are described very differently 
than what's been happening here.  They state the problem(s) that are 
caused and then give details about how, when, and where.

>    So, if someone really wants to make the case that the
> language about <optional-field>s in 5322 causes problems without
> some addition specification or restrictions, I think that is,
> sadly, in scope. 

There is a difference between saying "I think bad-thing-x is happening 
and causing problems" from saying "bad-thing-x is causing the following 
problems, in the following ways and with the following systems."

Someone claiming a problem has the burden of documenting that the 
problem is real.

It is not reasonable for them to raise a question and expect other 
people to do the work of proving/disproving.  The latter approach is, 
effectively, a denial of service attack. (There are, of course, 
exceptions, but the framework of legitimate vs. questionable is really 
quite straightforward.)

  I would hope that we could handle it in the
> Applicability Statement that I hope will accompany
> 5321bis/5322bis but that is ultimately up to the WG.

People continue to love ASs, but my impression is that they have no 
field utility.

> And I hope we don't have to fuss with optional header fields at
> all and will conclude that the text in 5322 is adequate without
> even a reference to the registry.   But I don't think we can
> shut off the discussion and prevent those who think there are
> operational problems from making their case until someone is in
> a position to make a consensus call.

In formal terms, that is of course correct.

But people can choose to not respond to postings lacking in-scope 
relevance or substance.

That's why I refrained from posting, but the fact that this thread 
persisted suggested a meta-issue worth broaching early in the wg effort, 
in the possibility it has continuing relevance.  I mean, it's just 
possible that people will have other opportunities to lose focus from 
the actual goals of emailcore.  Shocking, I know, but...

Dave Crocker
Brandenburg InternetWorking