Re: [ietf-smtp] Endless debate on IP literals

John C Klensin <john-ietf@jck.com> Tue, 31 December 2019 23:23 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 E4A8112004E for <ietf-smtp@ietfa.amsl.com>; Tue, 31 Dec 2019 15:23:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.104
X-Spam-Level:
X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 jgTm2xV2g_s8 for <ietf-smtp@ietfa.amsl.com>; Tue, 31 Dec 2019 15:23:44 -0800 (PST)
Received: from bsa3.jck.com (unknown [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68350120019 for <ietf-smtp@ietf.org>; Tue, 31 Dec 2019 15:23:44 -0800 (PST)
Received: from hp5.int.jck.com ([198.252.137.153] helo=JcK-HP5.jck.com) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1imQrV-000FDF-P8; Tue, 31 Dec 2019 18:23:41 -0500
Date: Tue, 31 Dec 2019 18:23:36 -0500
From: John C Klensin <john-ietf@jck.com>
To: John Levine <johnl@taugh.com>, ietf-smtp@ietf.org
cc: moore@network-heretics.com
Message-ID: <357D24576FFBC2C56FE0FF07@JcK-HP5.jck.com>
In-Reply-To: <20191231185722.B47A411DDA7C@ary.qy>
References: <20191231185722.B47A411DDA7C@ary.qy>
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/ah1gKMIuzg1UQp4tJpj4rc-AsKQ>
Subject: Re: [ietf-smtp] Endless debate on IP literals
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, 31 Dec 2019 23:23:46 -0000


--On Tuesday, 31 December, 2019 13:57 -0500 John Levine
<johnl@taugh.com> wrote:

>...
> I am reasonably sure that if we compare the number of MTAs
> sending legit mail with numeric HELO to the number of spambots
> doing so, mail reliability would be greatly improved by
> completely forbidding them.
>...

I am reasonably sure that if we compare the number of MTAs
sending legit mail with HELO, rather than EHLO, to the number of
spambots doing so, mail reliability would be greatly improved by
completely forbidding them.

Noting that the logic above is the same, anyone want to make a
case that people have had circa 27 years to adapt to EHLO (i.e.,
since RFC 1425 was published), that a number of important and
heavily-used features (such a the 8BITMIME extension) are
dependent on it as are other options that people in many part of
the world consider important (e.g., SMTPUTF8), and it is
therefore time to just deprecate HELO.  

Or course, it one makes the argument that any embedded (IoT
included, but not limited to that) or other non-upgraded client
should be using a submission server with responsibility for
cleaning things up rather than an SMTP client, it further
strengthens that argument.  FWIW, IMO advocating that change
also strengthens the case for making the terminology
change/reversion mentioned in Appendix G.3 of rfc5321bis-02.

Again, not taking a position on any of this, just pointing out
questions that probably need asking, especially if we are going
to start deprecating previously-valid (or, especially,
previously-required) features.

   john