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

Keith Moore <> Mon, 28 September 2020 13:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD5593A0ED6 for <>; Mon, 28 Sep 2020 06:26:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3il01ebmF2HP for <>; Mon, 28 Sep 2020 06:26:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2EEFC3A0ECF for <>; Mon, 28 Sep 2020 06:26:43 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 2CFC85C0053 for <>; Mon, 28 Sep 2020 09:26:42 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute4.internal (MEProxy); Mon, 28 Sep 2020 09:26:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=XTX41e Io/w/7OH8nYXW1x+NEPowcmF7fv1d0xwnfGXE=; b=vhpOdQIkbFvTp3MwWZo0gp 1xz48IGVhhfIUZ4DkzGBF1MveZJCsxDXnnlOuyAjtWEg6hSUMsTcUkIuZnMpOfzg SHpnk0zygnzq6oH5DE9B+j3C3Q6xINoDnZ7DVL7zvotzG4Je4igvLG8/mK+c/SS5 jJzQKwFqbr9zFtXgNvfeaRKqTvxVUOAVJ4KIicdco5xO0oJpyQtY8l2mMs2S/NIS qcmbJI/8QXioK9e5WcZ+eazjyXsMeQZCRwNYZerilyIeqYILckqRYFqFD8oEs3hA NZoK0VxjjZLNyMJvRQNFQHLQ8Uws+YVM75qzwrFCIfa6TuF3FRSsGSBPzlp6JEgg ==
X-ME-Sender: <xms:keRxX3w0dXIPdwOo-YXd0iJPospddpuF1Ss3WPFMfy7xnIOr2xJocQ> <xme:keRxX_TcVDu3A_KGpuMcKVZxnnVfXeiovBEa10Sz8tiptAMqDYR0GW-HG1IOTEIFK InfWuEtOMtyzg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdeigdeggecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtsegrtderre dtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthifohhr khdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeevfeetudeigedtle dvvddtudefjeejffdvfeetjeeiueelgfdtgfegtdffkeetudenucfkphepuddtkedrvddv uddrudektddrudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:keRxXxWk9cGtip4f7LZel7VQF6U5Iea79RuoR3eMhArAZODI6cZ_sg> <xmx:keRxXxgnQQX_gbyw1WU8Qjq-3ck3cdrFSX0KSUD7rpKtsRFGRQ7sfA> <xmx:keRxX5D5QNx9EP8q0O2FKOC5uWHI5raezwgdg28AApENO9Mp6Y1qCA> <xmx:kuRxX1wrInIm1k9dWqv-lyfkCNyLNBRN4x1mLrSZZXUkWyDA32WbZQ>
Received: from [] ( []) by (Postfix) with ESMTPA id 9D4DC3064610 for <>; Mon, 28 Sep 2020 09:26:41 -0400 (EDT)
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Keith Moore <>
Message-ID: <>
Date: Mon, 28 Sep 2020 09:26:40 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------610533B27B3614B38190B4A4"
Content-Language: en-US
Archived-At: <>
Subject: Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321
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\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Sep 2020 13:26:45 -0000

On 9/28/20 9:10 AM, Laura Atkins wrote:

>> I've made those arguments multiple times already.  "evidence" seems 
>> like the wrong thing to ask for because this is really a question of 
>> /design/ - what choices should be made to allow the email network to 
>> continue operating seamlessly and efficiently in the event of 
>> widespread use of NAT within the network (either to gateway between 
>> IPv4 and IPv6 or to economize use of IPv4 space)?
> I’ve seen lots of arguments, yes, but I’ve not seen any real evidence 
> backing up your assertions.

Most of this is what I've picked up reading IETF lists and trade 
publications for years.   I guess I thought it was common knowledge 
within IETF that NATs were increasingly being used in these ways - 
certainly there were many discussions about it in IETF several years ago.

> I’m trying to better understand your point of view and understand why 
> this is so important. But it’s been hard to find that in the sniping.
> The design question is one that should be discussed, but is this the 
> correct space for that?

Arguably the discussion should be taking place on the emailcore WG 
mailing list rather than here.   But we started the discussion here.

>> The changes I see happening include the increasing scarcity of IPv4 
>> address space and the consequent emergence of IPv6-only network 
>> providers using NAT to move packets between IPv4 and IPv6 addressing 
>> domains.  I'm also anticipating the need to eventually phase out the 
>> public IPv4 Internet altogether.
> Or we could write the BIS to recommend anyone running v4 services also 
> provide v6 services, couldn’t we? Take the burden off the v6 only 
> systems which are likely newer entrants and put it on the ‘old timers’ 
> who’ve been around for decades.

We could make such a recommendation.   Though I expect, that like spam 
filterers, network operators will do what they want, and consider 
themselves justified in doing so, regardless of what we recommend.

I suspect that the task before us is to make recommendations that both 
spam filterers and network operators will find palatable.

>> (From operators' perspective: how long does it make sense for every 
>> network to maintain its IPv4 baggage, just so that email won't be 
>> blocked?   At the very least we need input from network operators.)
> My experience is that folks running MTAs on IPv6 actually enact 
> stricter technical requirements on those systems. For instance, many 
> IPv4 servers will accept mail without valid rDNS on the sending IP or 
> will accept mail without SPF records, while the IPv6 servers run by 
> the same entities require those things directly.

It might even make sense for IPv6 operations to "raise the bar".   For 
example, PTR lookup of IPv6 addresses allows finer-grained delegation 
than PTR lookup of IPv4 addresses.   But regardless of what some 
operators are doing, I think this requires careful analysis to justify 
from a standards perspective.   I suspect there will be IPv4-only 
networks with a legitimate need to originate mail to IPv6-only servers.