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

Mark Andrews <marka@isc.org> Mon, 28 September 2020 22:59 UTC

Return-Path: <marka@isc.org>
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 436613A145B for <ietf-smtp@ietfa.amsl.com>; Mon, 28 Sep 2020 15:59:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 nCykUgVUtlKZ for <ietf-smtp@ietfa.amsl.com>; Mon, 28 Sep 2020 15:59:40 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 5503E3A145A for <ietf-smtp@ietf.org>; Mon, 28 Sep 2020 15:59:40 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 874223AB006; Mon, 28 Sep 2020 22:59:39 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7C21A160069; Mon, 28 Sep 2020 22:59:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 67BF716006C; Mon, 28 Sep 2020 22:59:39 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id fc8KK8LaoDFa; Mon, 28 Sep 2020 22:59:39 +0000 (UTC)
Received: from [172.30.42.67] (unknown [49.2.101.160]) by zmx1.isc.org (Postfix) with ESMTPSA id 94D5E160069; Mon, 28 Sep 2020 22:59:38 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <20200928221602.046CE22A35B3@ary.qy>
Date: Tue, 29 Sep 2020 08:59:34 +1000
Cc: ietf-smtp@ietf.org, moore@network-heretics.com
Content-Transfer-Encoding: quoted-printable
Message-Id: <ADA8052C-2B7D-4C50-8FFF-A3D88EC3BA58@isc.org>
References: <20200928221602.046CE22A35B3@ary.qy>
To: John Levine <johnl@taugh.com>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/4KtcyYhHR69B4IEuewvauYZyp48>
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: Mon, 28 Sep 2020 22:59:42 -0000


> On 29 Sep 2020, at 08:16, John Levine <johnl@taugh.com> wrote:
> 
> In article <b47992c5-17dc-f461-c1cd-1e4277f52c00@network-heretics.com> you write:
>> On 9/28/20 10:27 AM, John Levine wrote:
>> 
>>> Keith is asking us to expect that mail clients will move behind NAT64
>>> even while their associated servers do not,
>> 
>> No, I expect IPv4 to go away.   Gradually at first, and then much more 
>> quickly.    Are people here really going to insist that operators have 
>> to maintain IPv4 servers (or ALGs or whatever they need to maintain the 
>> illusion that the client and server see the same source IP address?).   
> 
> I'm sorry but this is making less and less sense.
> 
> You appear to be saying there will be mail systems that need to send
> mail to IPv4 systems, but will not have an IPv4 mail server so the
> recipients can't reply to them.  Really?

Actually I expect there will be systems where just 25/<ipv4-address> is
statically NAT46’d to a 25/<IPv6-address> and all the outbound traffic goes
back through the NAT64 with no linkage to the IPv4 address except for those
established by the inbound connections.

I expect that setups like this will happen dynamically in the future and the
A records will be dynamically updated to reflect whatever IPv4 address the
server happened to negotiate out of the NAT64.  The protocols to do this
have existed for years now.  They just haven’t been initiated from SMTP
servers yet.

The same thing will happen for other services like HTTP{S} that needs to
supported in house.

> If you do expect the recipients to be able to reply, why wouldn't the
> inbound IPv4 mail server's address be the one it uses to send mail,
> like it has for the past 40 years?
> 
> R's,
> John
> 
> _______________________________________________
> ietf-smtp mailing list
> ietf-smtp@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-smtp

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org