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