Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321

John C Klensin <john-ietf@jck.com> Sun, 27 September 2020 15:24 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 0261F3A0FC5 for <ietf-smtp@ietfa.amsl.com>; Sun, 27 Sep 2020 08:24:00 -0700 (PDT)
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 x1dO_8FaFLHr for <ietf-smtp@ietfa.amsl.com>; Sun, 27 Sep 2020 08:23:58 -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 C0AE23A0A2B for <ietf-smtp@ietf.org>; Sun, 27 Sep 2020 08:23:58 -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 1kMYWq-000ME5-CG; Sun, 27 Sep 2020 11:23:56 -0400
Date: Sun, 27 Sep 2020 11:23:50 -0400
From: John C Klensin <john-ietf@jck.com>
To: Sam Varshavchik <mrsam@courier-mta.com>
cc: ietf-smtp@ietf.org, Keith Moore <moore@network-heretics.com>
Message-ID: <6DE405E366F059EA697D51D5@PSB>
In-Reply-To: <cone.1601211696.103163.24342.1004@monster.email-scan.com>
References: <cone.1600468578.784468.161845.1004@monster.email-scan.com> <da460777-824b-1f13-be7c-32bfa9664d02@network-heretics.com> <cone.1601211696.103163.24342.1004@monster.email-scan.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/bp5RV9OR1_PZm78d0GTA_RZRCrQ>
Subject: Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321
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: Sun, 27 Sep 2020 15:24:00 -0000

Responding to the thread, rather than any specific note...

(1) We need to tread rather carefully here.  These checks are
closely connected to checks involving address-> name mappings as
well as name-> address ones.  SMTP did not anticipate single
clients sending from multiple interfaces/addresses, nor clusters
or clouds of machines sending out traffic without clear
discrimination about the actual sending host.  While the DNS has
mechanisms that, IMO, are quite adequate for associating
multiple addresses with the same host name, my anecdotal
experience suggests that reverse-mapping records with one
address and a long list of host names are quite rare.  SMTP also
did not anticipate clients (especially when ones communicating
with submission servers are ignored) running on addresses
(whether static or dynamic) assigned by ISPs rather than
regional registries.  Independent of clients who are part of
clouds and business arrangements large enough to push ISPs
around, many ISPs refuse to create reverse mapping records at
all [1] or will not create ones that that match client
perceptions of their names rather than server-location based
names following the ITU model [2]/

And that is even before we get to questions of gateways or NATs
between IPv6 and IPv4 systems.

So, without taking a position on whether we should make changes
in this area, they, and their implications, need to be thought
through very carefully.  We should also, IMO, try to preserve
the "if two, why not more" logic used when 2821 created an
explicit prefix model for IPv6 address literals rather than
simply assuming IPv4 and IPv6 literals could be distinguished
from each other by a simple heuristic test and that we would not
ever need to worry about, e.g., candidates for IPv7, IPv10, etc.

Also, a substantive note:  people decided (fwiw, over my
objections) to create a separate email list for the emailcore
effort.   With the very recent formal creation of that WG, I'm
not going to track proposed changes for the potential 5321bis
posted to this list (and hope that the WG Chairs will soon take
that responsibility off my hands).  So, if someone would like to
see changes, take them there.

     john




[1] As handy examples pulled from this thread, 68.166.206.83 and
64.147.123.25 apparently have no reverse mapping records at all.

[2] Highly informative (if you happen to be the ISP) reverse
mappings to things like
70.88.254-40-Lynn.MA.hfc.comcastbusiness.net are fairly common.