[ietf-smtp] Issueds listed in 5321bis Appendix GRe: and pending I-Ds (wasL Proposed agenda for EMAILCORE BOF)

John C Klensin <john-ietf@jck.com> Tue, 28 July 2020 11:29 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B763F3A0B2C for <ietf-smtp@ietfa.amsl.com>; Tue, 28 Jul 2020 04:29:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id g03P2DNPdsGl for <ietf-smtp@ietfa.amsl.com>; Tue, 28 Jul 2020 04:29:42 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD6C3A0B2B for <ietf-smtp@ietf.org>; Tue, 28 Jul 2020 04:29:42 -0700 (PDT)
Received: from [] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1k0Nnh-0006xs-2T; Tue, 28 Jul 2020 07:29:41 -0400
Date: Tue, 28 Jul 2020 07:29:34 -0400
From: John C Klensin <john-ietf@jck.com>
To: Alessandro Vesely <vesely@tana.it>, ietf-smtp@ietf.org
Message-ID: <3E53E48FEE763A817842F2FD@PSB>
In-Reply-To: <717549a3-a94c-0eae-dd28-5a3eb4250805@tana.it>
References: <20200723185852.43E3C1D6C234@ary.qy> <f68186e9-3996-a412-25ee-2f5edc0e4d6b@isode.com> <717549a3-a94c-0eae-dd28-5a3eb4250805@tana.it>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/ucT1BKBucMdOWAVjLsGALFnHUGE>
Subject: [ietf-smtp] Issueds listed in 5321bis Appendix GRe: and pending I-Ds (wasL Proposed agenda for EMAILCORE BOF)
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: Tue, 28 Jul 2020 11:29:44 -0000


Two small comments...

--On Tuesday, July 28, 2020 12:17 +0200 Alessandro Vesely
<vesely@tana.it> wrote:

> Nevertheless, some coordination is needed.  The discussion in
> Section 7.1 of RFC 5321, "Mail Security and Spoofing", needs
> revision.  This question is already addressed in Appendix G.4,
> "Originator, or Originating System, Authentication" of John's
> I-D.

As I mentioned on-list when what is now Appendix G was started
and ;east until there is a WG, I'm trying to remain strictly
neutral about the items listed there.  So the listing of a
particular topic doesn't mean it has been addressed, at least as
I would use that term, only that someone has raised the issue
and I wrote it down.  The question as to what should be done
about it and, if anything, where is a potential BOF discussion
topic and eventually up to the WG.

> For RFC 5322, Dave's Author: and Sender: I-Ds might happen to
> become RFCs before rfc5322bis.  Can they be considered in that
> case?  Certainly, it won't make sense to publish contrasting
> specifications, such as, for example, the number of email
> addresses allowed in a From: field.

No opinion, right now, about what should be done.  But a
procedural point is probably relevant: while the draft charter
talks about things that could be discussed with its scope,
actual incorporation of those features into 5322bis would
require that they be published as Proposed Standards, wait some
months, and then that the specifications be implemented and show
"widespread deployment of multiple implementations from
different code bases" [RFC 6410].   

As far as I can tell, there is little energy for working on
RRC5321bis/5322bis and then reissuing them as Proposed
Standards.   If the goal is to finally get SMTP and the Header
specification to Internet Standard and definitively (finally)
replace 821/822 --something I read into the draft charter-- that
would be seriously counterproductive.  If there are
specifications in the pipe whose results should really be
incorporated into the revised documents, than we should probably
postpone the WG until those specifications are ready.  If you
believe that is the case, please make the argument at the BOF.