Re: [ietf-smtp] Email standard revision

Michael <michael@linuxmagic.com> Tue, 18 February 2020 20:04 UTC

Return-Path: <michael@linuxmagic.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 5232C120813 for <ietf-smtp@ietfa.amsl.com>; Tue, 18 Feb 2020 12:04:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, 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 upHAM-N14184 for <ietf-smtp@ietfa.amsl.com>; Tue, 18 Feb 2020 12:04:47 -0800 (PST)
Received: from be.cityemail.com (mail-ob.cityemail.com [104.128.152.19]) by ietfa.amsl.com (Postfix) with ESMTP id 480A8120145 for <ietf-smtp@ietf.org>; Tue, 18 Feb 2020 12:04:47 -0800 (PST)
Received: (qmail 30398 invoked from network); 18 Feb 2020 20:04:44 -0000
Received: from localhost (HELO mail.cityemail.com) (michael@wizard.ca@127.0.0.1) by be.cityemail.com with (DHE-RSA-AES128-GCM-SHA256 encrypted) SMTP (e83f2d06-5289-11ea-bb31-3730beedca83); Tue, 18 Feb 2020 12:04:44 -0800
Date: Tue, 18 Feb 2020 12:04:44 -0800
To: John C Klensin <john-ietf@jck.com>, Alessandro Vesely <vesely@tana.it>
From: Michael <michael@linuxmagic.com>
Cc: ietf-smtp@ietf.org
Message-ID: <eda887204928335e7f21accdead2437e@be.cityemail.com>
X-Mailer: Wizard PHP Mail Library 1.1
User-Agent: MagicMail-Email/0.1
X-Originating-IP: 50.226.7.219
In-Reply-To: <118BA897BE380DA6BCE22C4C@PSB>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-MagicMail-OS: MagicMail 4.0-Stable
X-MagicMail-UUID: e83f2d06-5289-11ea-bb31-3730beedca83
X-MagicMail-Authenticated: michael@wizard.ca
X-MagicMail-SourceIP: 127.0.0.1
X-MagicMail-RegexMatch: 0
X-MagicMail-EnvelopeFrom: <michael@linuxmagic.com>
X-Archive: Yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/VQHGQE1BUtZlU85a-AQAZWg2HYw>
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 20:04:49 -0000

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?

On Tue, 18 Feb 2020 14:26:15 -0500
John C Klensin  wrote:
> 
> 
> --On Tuesday, February 18, 2020 19:08 +0100 Alessandro Vesely
>  wrote:
> 
>>...
>>  I don't think a cleanup, like e.g. the one you proposed[*],
>> would revert rfc5321bis to proposed standard.  However, I'm
>> not clear on how that works.  Certainly, rfc2821 was reverted
>> to proposed standard, but I wasn't there and I don't know
>> who/how decided to label that I-D to a lower standard.
>> 
>> BCP 9 is not so precise:
>>...
> 
> At the time, there was at least one important issue and it was
> independent of the BCP 9 text you cited.  2821 was essentially a
> merge of RFCs
>   821 (a full standard)
>   974 (don't remember its status at the time 2821 was in
> progress, but note that it is listed as part of STD 10, so I
> assume full standar)
>   some text from 1123 (another full standard)
>   1829 (another full standard)
>   and bits and pieces of text, some of it completely new, either
> picked up from assorted places or inserted to better align 2821
> with 2822 than 821 and 822 were aligned.
> 
> That new text, and the merger itself, were, in principle and
> maybe in practice, untested for how they would work in terms of
> comprehension, implementations, and deployment in the future.
> Hence PS.  Could we have pushed it through as full standard?
> Maybe.  But the experience of the changes that needed to be made
> to get to 5321 (virtually all of which were "cleanup") suggests
> that would have been a bad decision.
>   
>> Since there are quite some issues to be clarified[†], I
>> think the new WG will need some detailed guidelines about what
>> would be a very significant change.
> 
> Yes.  See my earlier note.  And, again, I'm skeptical that can
> actually be done by guidelines rather that a case-by-case review.
> 
>     best,
>      john
> 
> 
> _______________________________________________
> ietf-smtp mailing list
> ietf-smtp@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-smtp
> 


--
-- 
"Catch the Magic of Linux..." 
------------------------------------------------------------------------ 
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
------------------------------------------------------------------------ 
A Wizard IT Company - For More Info http://www.wizard.ca 
"LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada