Re: [ietf-smtp] Email standard revision

John C Klensin <john-ietf@jck.com> Tue, 18 February 2020 21:30 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74F512029C for <ietf-smtp@ietfa.amsl.com>; Tue, 18 Feb 2020 13:30:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEFuR7tkaSsp for <ietf-smtp@ietfa.amsl.com>; Tue, 18 Feb 2020 13:30:46 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D6851200C7 for <ietf-smtp@ietf.org>; Tue, 18 Feb 2020 13:30:46 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1j4AS2-000FQo-Er; Tue, 18 Feb 2020 16:30:42 -0500
Date: Tue, 18 Feb 2020 16:30:36 -0500
From: John C Klensin <john-ietf@jck.com>
To: Michael <michael@linuxmagic.com>, Alessandro Vesely <vesely@tana.it>
cc: ietf-smtp@ietf.org
Message-ID: <F80D3A8689793FE461FA0732@PSB>
In-Reply-To: <eda887204928335e7f21accdead2437e@be.cityemail.com>
References: <eda887204928335e7f21accdead2437e@be.cityemail.com>
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-Connect-IP: 198.252.137.10
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/Bn8bcJ2gQFeMqM1D_cXvxZWLxlI>
Subject: Re: [ietf-smtp] Email standard revision
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, 18 Feb 2020 21:30:48 -0000

Michael,

They can and should speak for themselves, but as I understand
Dave's (and Barry's) proposal, changing authentication models or
requirements would definitely be excluded under "clean up only"
criteria.  

If you, or others, disagree, that reinforces my impression that
we are going to need to work through the issues list, one at a
time, and decide on each on a case by case basis.  FWIW, note
that authentication issues are listed in
draft-klensin-rfc5321bis-02 in G.4 and G.6.  If you look at
those descriptions and think they are inadequate to identify the
issues, please suggest text (noting that, at this point, I [1]
am interested only in problem descriptions, not specific
proposals

best,
   john

[1] As editor, working draft curator, and self-appointed keeper
of the list.  That role changes, and my personal opinions become
irrelevant, as soon as there is a WG (with, of course, a
character and designated leadership).


--On Tuesday, February 18, 2020 12:04 -0800 Michael
<michael@linuxmagic.com> wrote:

> Curious, does this cleanup fall under the auspices of email
> security, as a whole? Wondering if it fits into the idea that
> I proposed under the DISPATCH to consider a WG that covers
> email security issues, including deprecating some of the older
> recommendations that allow sending authentication over
> insecure channels?