Re: [Emailcore] Two extra issues

Alessandro Vesely <vesely@tana.it> Fri, 18 December 2020 17:23 UTC

Return-Path: <vesely@tana.it>
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 9F7FB3A0AF9 for <emailcore@ietfa.amsl.com>; Fri, 18 Dec 2020 09:23:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 ImDhhM0bct47 for <emailcore@ietfa.amsl.com>; Fri, 18 Dec 2020 09:23:38 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE60B3A0AF8 for <emailcore@ietf.org>; Fri, 18 Dec 2020 09:23:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608312215; bh=Bs4uICMByxcPQ02js2gChGBgR+n/pQcDmwiK1Jmaxk8=; l=878; h=To:References:From:Date:In-Reply-To; b=BNQEnkZN7E0D8fWm6hHLKy2KH72RyZohOiYvmM5k1xeQjVBZMpjX6ctzMi4NTykgE 0OFkwpjhqX8KN/RMzEJqHBl29jhqgda1hvD6APJSQD+rMLxLFEGfcdGR4zUOHMTSin aPLhEdp4cv4ddLJCKV5A1EzzoQpzJyUFpU9hF22zmRqztisetBA6LYCVb5ZPn
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC056.000000005FDCE597.00000282; Fri, 18 Dec 2020 18:23:35 +0100
To: emailcore@ietf.org
References: <9ABCA62E3E54C4356D09E1EE@PSB> <20201217205413.D68C32AC973F@ary.qy> <01RTABPBJB7C004QVR@mauve.mrochek.com> <43b5a838-c94b-7690-c62f-8ef69aeb338@taugh.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <7d8d3332-209e-85d9-957c-dec9c0e4c830@tana.it>
Date: Fri, 18 Dec 2020 18:23:35 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <43b5a838-c94b-7690-c62f-8ef69aeb338@taugh.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/emailcore/bHFfWv320top1zI9mdA_q6KSaic>
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 17:23:40 -0000

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.


Best
Ale
-- 

[*] Telnet: another candidate to historic which still comes in handy.