Re: [ietf-smtp] Should we update an RFC if people refuse to implement parts of it ?
John C Klensin <john-ietf@jck.com> Tue, 01 June 2021 18:59 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 7E10D3A23B5 for <ietf-smtp@ietfa.amsl.com>; Tue, 1 Jun 2021 11:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 uiIdzcp_W9Eb for <ietf-smtp@ietfa.amsl.com>; Tue, 1 Jun 2021 11:59:26 -0700 (PDT)
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 52AF83A23B6 for <ietf-smtp@ietf.org>; Tue, 1 Jun 2021 11:59:26 -0700 (PDT)
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 1lo9bm-000DOl-A6; Tue, 01 Jun 2021 14:59:22 -0400
Date: Tue, 01 Jun 2021 14:59:16 -0400
From: John C Klensin <john-ietf@jck.com>
To: Ned Freed <ned.freed@mrochek.com>
cc: Viktor Dukhovni <ietf-dane@dukhovni.org>, ietf-smtp@ietf.org
Message-ID: <8D581A6D5684C1A7EA71CA3A@PSB>
In-Reply-To: <01RZPUQVP8TU0085YQ@mauve.mrochek.com>
References: <20210525182946.079748B872C@ary.qy> <EFDA46E00EFF0E48802D046A@PSB> <2021052700585304660213@cnnic.cn> <YK7E1dBKneP8B8Ib@straasha.imrryr.org> <01RZNI90M6SS0085YQ@mauve.mrochek.com> <E23639ADA7487360C9B5A93C@PSB> <01RZPUQVP8TU0085YQ@mauve.mrochek.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/Y2R3R_VclPBybWy8fpisF_Ct65Q>
Subject: Re: [ietf-smtp] Should we update an RFC if people refuse to implement parts of it ?
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, 01 Jun 2021 18:59:33 -0000
Ned, I think we are mostly in agreement, especially about the current crop of MUA clients not being very helpful in these areas and the users not caring about security, having a very low level of knowledge, and not seeing either as a problem. A few comments below (text on which I have nothing to add elided) --On Monday, May 31, 2021 17:54 -0700 Ned Freed <ned.freed@mrochek.com> wrote: >... > To the extent Received: fields are relevant to our customers, > it's to track down the cause of some sort of problem, usually > but not always some kind of delivery delay. I find A-label > better suited to this usage than U-labels. In case I've given any other impression, so do I. But, like you, I know what an A-label is, how to convert it back if necessary, and so on. The WG made the assumption that users without that knowledge would be looking at that stuff. If today's reality, as we all seem to believe and have experienced, is that the knowledge level and inclination to dig into these issues of the typical user has, if anything, gone down significantly since that assumption was made, then using U-labels is optimizing for the very few users (percentage-wise) who are inclined and able to dig into headers _and_ who don't find dealing with A-labels convenient and don't know what to do with them. So, while I am profoundly sympathetic to a position I heard Doug Englebart describe by an analogy to letting people drive cars without any sort of training, it seems clear that war is over and we lost... and, as one of many consequences, that the EAI Wg's optimization decisions were probably wrong. >> And that brings me close to the reasoning I think the >> WG used more generally: that it was better to stick to "native >> character" forms (in this case, U-labels), especially when >> there was a possibility of a full mailbox name with a UTF-8 >> local part and a domain part containing IDN labels. That is >> obviously not the case for clauses of "Received:" fields >> other than "for", but, if the WG extrapolated from that >> principle to this particular case (and I don't remember how >> much detailed attention the particular case got. The other >> argument for U-labels is that, precisely as Ned points out, >> if an admin needs to translate an A-label, there are many >> tools and admins are likely to know where to find them. By >> contrast, if a user is presented with an A-label, the >> reaction is at least as likely to be "WT<rude word>" as "I >> have a tool handy that does that". > > But in the bigger picture, every time you use a U-label or a > UTF-8 local-part, you make it more difficult to deal with the > case when you hit a point where the SMTPUTF8 extension isn't > available. And that turns back into a comment I made earlier -- that the WG made a number of decisions that ultimately assumed that SMTPUTF8 would deploy rapidly, perhaps even as rapidly as 8BITMIME did. Obviously, at least to me, had the in-transit downgrading that the EAI WG first tried to define been workable, we'd be having fewer, or at least different, problems at this stage. We might have even been able to avoid the SMTP extension and done a Punycode-like extension for messages in transit and hence their MTA-supplied header fields. But we concluded that we couldn't, and so, as far as the protocol is concerned, hitting a point in transit where the SMTPUTF8 extension is not available means rejecting the message with all of the problems that implies. > We have two downgrading options defined, but neither of them > is terribly attractive. And both are post-delivery options, more concerned with MUAs or POP or IMAP servers accessing the message store. > What this argues for is to eliminate as much use of the > extension as you possibly can. And if that means using > A-labels, or even dropping the use of "for" clauses - which > are optional anyhow - so be it. In the context of the comments above, no disagreement. That gets us back to the original question of whether it is worth opening the SMTPUTF8 spec family of documents to review and change those specifications and, if so, whether there is energy to do so. If the answer is "no" --and that is not only my preference but what I think I am hearing -- then I'm not sure how useful continuing this thread actually is. >... >> On the other hand, and here comes the question: There are >> proposals floating around that would define new header fields >> that would reflect, include, or depend on, different sorts of >> forward-pointing and reverse-pointing addresses. Should we be >> taking the position that none of those should move forward >> unless they explicitly address what should be done when those >> fields are not traditional ASCII ones? > > Very good point. EAI is a standards-track format/protocol. An > unavoidable consequence of this is that proposal that involves > a new header field needs to say how it interacts with EAI, > even if it's only to say it doesn't interact at all. Agreed. I hope those of us who write and review documents, the IESG, and the ISE are paying attention. best, john
- [ietf-smtp] Should we update an RFC if people ref… John R. Levine
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… Viktor Dukhovni
- Re: [ietf-smtp] Should we update an RFC if people… John Levine
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… John Levine
- Re: [ietf-smtp] Should we update an RFC if people… Jiankang Yao
- Re: [ietf-smtp] Should we update an RFC if people… Viktor Dukhovni
- Re: [ietf-smtp] Should we update an RFC if people… Ned Freed
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… Ned Freed
- Re: [ietf-smtp] Should we update an RFC if people… Alessandro Vesely
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… Dave Crocker
- Re: [ietf-smtp] Should we update an RFC if people… Sam Varshavchik
- Re: [ietf-smtp] Should we update an RFC if people… Dave Crocker
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… Dave Crocker
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… Dave Crocker
- Re: [ietf-smtp] Should we update an RFC if people… John Levine
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… Alessandro Vesely
- Re: [ietf-smtp] Should we update an RFC if people… Dave Crocker
- Re: [ietf-smtp] Should we update an RFC if people… John C Klensin
- Re: [ietf-smtp] Should we update an RFC if people… John Levine
- Re: [ietf-smtp] Should we update an RFC if people… Valdis Kl ē tnieks
- Re: [ietf-smtp] Should we update an RFC if people… Viktor Dukhovni