Re: [ietf-smtp] Possible contribution to moving forward with RFC5321bis SMTP

Dave Crocker <dhc@dcrocker.net> Thu, 02 January 2020 19:27 UTC

Return-Path: <dhc@dcrocker.net>
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 5B011120120 for <ietf-smtp@ietfa.amsl.com>; Thu, 2 Jan 2020 11:27:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 5RwryLH95nTU for <ietf-smtp@ietfa.amsl.com>; Thu, 2 Jan 2020 11:27:52 -0800 (PST)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4D92120113 for <ietf-smtp@ietf.org>; Thu, 2 Jan 2020 11:27:52 -0800 (PST)
Received: from [192.168.1.85] (108-226-162-63.lightspeed.sntcca.sbcglobal.net [108.226.162.63]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1.1) with ESMTP id 002JSiN0028238 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 2 Jan 2020 11:28:44 -0800
To: John C Klensin <john-ietf@jck.com>, Keith Moore <moore@network-heretics.com>, ietf-smtp@ietf.org
References: <20200101175510.8549A11E2905@ary.qy> <D441E0BE-1F32-4329-9296-A5026540E8D0@dukhovni.org> <994e7a23-9e80-4751-6067-8863ad0ee72f@network-heretics.com> <2Iq+URBKeODeFANB@highwayman.com> <5E0E04AA.5070408@isdg.net> <986919d8-613b-7e13-c39b-0f7f978ca763@network-heretics.com> <B7644591809D5C3CBB682F56@JcK-HP5.jck.com>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Reply-To: dcrocker@bbiw.net
Message-ID: <7afd6574-9e18-261b-ce66-d61050b08208@dcrocker.net>
Date: Thu, 02 Jan 2020 11:27:45 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <B7644591809D5C3CBB682F56@JcK-HP5.jck.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/oLXxNr_TL-etaZUHBLAUsEcAJww>
Subject: Re: [ietf-smtp] Possible contribution to moving forward with RFC5321bis SMTP
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: Thu, 02 Jan 2020 19:27:54 -0000

On 1/2/2020 10:17 AM, John C Klensin wrote:
>    Whether we
> change the spec to follow their practices or retain and clarify
> the recommendation, it seems to me that we are going to need
> text, somewhere, that explains our decisions, why we are giving
> whatever advice we are providing, and why people should follow
> that advice.  That text, which probably belongs in a separate
> document from RFC531bis, may actually be more important than
> whatever we put in 5321bis. 

If it turns out to be more important than the actual protocol spec, 
we've got bigger problems.

But explanatory text certainly can be helpful.  Here is is worth 
distinguishing text that explains utility of what is specified -- and 
one of the benefits of the IETF style of specification, as opposed to 
that of many other standards organization, is that such text can be 
inline with the spec -- versus discussion of group decision-making that 
produced the spec.

While production of this latter type of history review can be 
interesting, I'm not aware of that being a regular -- or even 
established? -- practice in the IETF.

I don't recall specific examples, but believe it has been done, though 
not very often.  Perhaps you can cite some examples?


> Absent our providing a persuasive
> explanation of why people should, or should not, do something,
> experience, both on the anti-spam side and based on continuing
> references to 2821, suggests that sites will do whatever they
> (locally) think best and that some of those decisions will be
> ill-informed.

Such explanation has pretty much never altered independent 
decision-making in the adoption or rejection of Internet mail practices. 
  Perhaps you have counter-examples?


> The same principle applies, IMO, to suggestions that we pull
> material out of 5321 that is considered obsolete, irrelevant, or
> not belonging there. Some of the arguments about what should be
> included ultimately date from the 1980s and involve questions of
> whether the envelope-message body (with headers) separation
> arrived at then was correct, whether we should have placed more
> reliance on message processing rather than transport processing
> or vice versa, and so on.  

The topic of the envelope received significant discussion during the 
development of RFC 5598:

> 4.1.  Message Data
> 
>    The purpose of the Message Handling System (MHS) is to exchange an
>    IMF message object among participants [RFC5322].  All of its
>    underlying mechanisms serve to deliver that message from its Author
>    to its Recipients.  A message can be explicitly labeled as to its
>    nature [RFC3458].
> 
>    A message comprises a transit-handling envelope and the message
>    content.  The envelope contains information used by the MHS.  The
>    content is divided into a structured header and the body.  The header
>    comprises transit-handling trace information and structured fields
>    that are part of the Author's message content.  The body can be
>    unstructured lines of text or a tree of multimedia subordinate
>    objects, called "body-parts" or, popularly, "attachments".
>    [RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289], [RFC2049].

and

> 4.1.1.  Envelope
> 
>    Internet Mail has a fragmented framework for transit-related handling
>    information.  Information that is used directly by the MHS is called
>    the "envelope".  It directs handling activities by the transfer
>    service and is carried in transfer-service commands.  That is, the
>    envelope exists in the transfer protocol SMTP [RFC5321].
> 
>    Trace information, such as RFC5322.Received, is recorded in the
>    message header and is not subsequently altered [RFC5322].

If there has been discussion that deviates from this and/or calls for 
modifications to this, please cite it.


>       That even includes such questions as
> whether RFC 974 was the right solution to that problem and
> remains the right solution in a world in which the DNS is being
> optimized for other things and we have strongly discouraged open
> relays (something else 5321 says little or nothing about) and
> whether, when we introduced EHLO, we should also have introduced
> a three-layer envelope [2] and whether we should do that now via
> a new but strongly-recommended extension.

Again, please document indications of current community concern of these 
issues.


> In any event, I believe the discussion we need now is how we get
> to a WG and how to sort out the details of Barry's suggested
> approach for moving forward.

Whereas I think there's been some significant attempt to do just that.


>  As just one example, as I read his
> suggestion, I don't think it allows making major scope changes
> in 5321bis, especially because, because of the way it is
> constructed, different parts of that document are sufficiently
> intertwined that simply adding or removing a substantive
> sections or two may lead to inconsistencies that would require
> very careful examination and revisions to sort out [3] [4].

Ahh.  I think there's been some very useful discussion about work to be 
done, but apparently you think that Barry's suggestions somehow 
constrain what constructive discussions we are permitted to have?  So, 
ummm, his suggestions were really a mandate?



> [2] Somewhat like the X.400 P1/P2/P3 distinction but not
> necessarily using that model.  I note that many of the rough
> edges associated with the relationship between trace information
> from xx21 and the header specifications of xx22 and many of the
> issues with signatures over message headers would be at least
> considerably simplified by pushing that type of information into
> an intermediate layer or structure.

Whereas I think that any issues with disparities, ambiguities, etc. 
between RFC *21 and RFC *22 involves the occurrence of redundant text 
rather than thoughtful incorporation by citation from one to the other.


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net