Re: [Emailcore] Two extra issues
John C Klensin <john-ietf@jck.com> Fri, 18 December 2020 20:24 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: emailcore@ietfa.amsl.com
Delivered-To: emailcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62663A0115 for <emailcore@ietfa.amsl.com>; Fri, 18 Dec 2020 12:24:31 -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 4HbUWydo_A9j for <emailcore@ietfa.amsl.com>; Fri, 18 Dec 2020 12:24:30 -0800 (PST)
Received: from bsa2.jck.com (ns.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 BD12B3A00F7 for <emailcore@ietf.org>; Fri, 18 Dec 2020 12:24:30 -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 1kqMIf-0007Js-B0; Fri, 18 Dec 2020 15:24:29 -0500
Date: Fri, 18 Dec 2020 15:24:22 -0500
From: John C Klensin <john-ietf@jck.com>
To: Alexey Melnikov <aamelnikov@fastmail.fm>, emailcore@ietf.org
Message-ID: <C3DCB2EDD5C01F06F62F355B@PSB>
In-Reply-To: <a06b2c13-dc97-418c-8edd-2f1661fd39d9@www.fastmail.com>
References: <9ABCA62E3E54C4356D09E1EE@PSB> <20201217205413.D68C32AC973F@ary.qy> <01RTABPBJB7C004QVR@mauve.mrochek.com> <43b5a838-c94b-7690-c62f-8ef69aeb338@taugh.com> <7d8d3332-209e-85d9-957c-dec9c0e4c830@tana.it> <a06b2c13-dc97-418c-8edd-2f1661fd39d9@www.fastmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
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/emailcore/ZWW-cnHbS-HFpx71nyqMMyYO7QE>
Subject: Re: [Emailcore] Two extra issues
X-BeenThere: emailcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EMAILCORE proposed working group list <emailcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emailcore>, <mailto:emailcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emailcore/>
List-Post: <mailto:emailcore@ietf.org>
List-Help: <mailto:emailcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emailcore>, <mailto:emailcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Dec 2020 20:24:32 -0000
--On Friday, December 18, 2020 17:47 +0000 Alexey Melnikov <aamelnikov@fastmail.fm> wrote: > On Fri, Dec 18, 2020, at 5:23 PM, Alessandro Vesely wrote: >> On Fri 18/Dec/2020 02:24:26 +0100 John R Levine wrote: >> > On Thu, 17 Dec 2020, Ned Freed wrote: >> >> There's still quite a few HELO's being sent by IOT stuff >> >> that supports email. And I can understand why - when every >> >> byte counts, code to fall back from EHLO to HELO isn't >> >> going to be written. >> > >> > Is that SMTP or submission? I think we will continue to >> > tolerate a lot more sloppiness in submission than in SMTP >> > relay. >> >> >> What is going to be gained by not tolerating HELO on port 25 >> any more? The server code is not going to shrink >> considerably, especially if the same code also supports port >> 587. >> >> Sometimes I use HELO for a quick test with telnet[*] if for >> some reason I don't want the terminal window to scroll by >> the amount of lines that EHLO responses imply. > > [As a participant] > > For reasons stated by Alessandro and Ned I have a weak > preference to leave HELO as is in rfc5321bis. (As a participant and for the same reasons) I share that preference (And, as author) I recommend that the bar for making substantive changes, even to drop things previously required or allowed, should be fairly high. My inclusion of that item was because I found it in my notes from prior suggestions and comments; it was not a recommendation for any particular action. john
- [Emailcore] Two extra issues John C Klensin
- Re: [Emailcore] Two extra issues John Levine
- Re: [Emailcore] Two extra issues Ned Freed
- Re: [Emailcore] Two extra issues John R Levine
- Re: [Emailcore] Two extra issues Alessandro Vesely
- Re: [Emailcore] Two extra issues Alexey Melnikov
- Re: [Emailcore] Two extra issues Alexey Melnikov
- Re: [Emailcore] Two extra issues John C Klensin
- [Emailcore] RESOLVED: Ticket #43: G.13. Deprecati… Alexey Melnikov
- Re: [Emailcore] RESOLVED: Ticket #43: G.13. Depre… Alessandro Vesely