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

Keith Moore <> Mon, 28 September 2020 10:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C92CA3A0CB1 for <>; Mon, 28 Sep 2020 03:38:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 w4Hfruo6pthb for <>; Mon, 28 Sep 2020 03:38:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0BF293A0F80 for <>; Mon, 28 Sep 2020 03:38:17 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 53A21D47; Mon, 28 Sep 2020 06:38:17 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute4.internal (MEProxy); Mon, 28 Sep 2020 06:38:17 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding: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=NNEunxu2z87LVtZ6eD05KDy0ngSFZOFJapXc6cgF+ fw=; b=q6bWIXXXfhZqte7Rj2XA9I/AsDTNDsG7bWOegQ+L2mlqkswiwPf6yeOxD jNzoYBt2wjO5sNXs84pvnGWTS9mhEfUN2xVJcMcc3EcV3iCPcu4gefJ+4KbO1tYy DHQqQFFXE73VPao/+edRgsB4+XgbIMqlMkWwD/4qIKMADbJH6fuSA8/AH6f0wmGB ZnBYQtQwPNCqRJK8J/ALeK3kcbquiMmZXlAwIVdVpVdM7mzqp9ri1B2FED+Wc9D/ dFneTNjeXFMrA7Q0yr4Ntiri2yuBy46vfD9RHmLpaSc4IPuKtaZlHusbVY9PXCsL i3sF+KIS+iuOhdjrzlV/+M7z8QEkQ==
X-ME-Sender: <xms:GL1xX1fq-8GJ-3f7JHtsOpHWB4XkJFJI5QvxUOsdw6oOBajGbYJ5SQ> <xme:GL1xXzMN965w_7nietQuNgsuwJdNelNmcCuJlFua-A5uxuhkqcv-o_X3r4BAP8_ue 1tPKLdWHAhi9w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdeigdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeehnecuhfhrohhmpefmvghithhh ucfoohhorhgvuceomhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhmqe enucggtffrrghtthgvrhhnpeehudfhledugeeuteevvefhueejjeefffefteettddvleef gfekieekheejffdvffenucfkphepuddtkedrvddvuddrudektddrudehnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:GL1xX-jIcNHlwjNvlVVup957qY6DthM9YLl1DndxhG8_36ZRoDH0UQ> <xmx:GL1xX-9mSSwqvgbsfhefurmuFCWd4YCIc99_Y4fPZJQjoJR-1nhcrQ> <xmx:GL1xXxtSUzAgc-2DVpVXMUm1bf6vTaPHgyP8PiFLvyOap2vkuuaXoA> <xmx:GL1xX_6o6OtOzW4MW7Nq8-BDebcefJ1Dw8NXZlJfwbayo7-_NRFGWA>
Received: from [] ( []) by (Postfix) with ESMTPA id 642ED3064687; Mon, 28 Sep 2020 06:38:16 -0400 (EDT)
To: Laura Atkins <>
References: <> <> <> <> <> <> <> <> <>
From: Keith Moore <>
Message-ID: <>
Date: Mon, 28 Sep 2020 06:38:15 -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: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
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 10:38:25 -0000

On 9/28/20 4:38 AM, Laura Atkins wrote:

> Do you think if the wording in the RFC is changed that established 
> behavior will change? That the SMTP servers will be reconfigured to 
> stop doing what they are doing?

I think most operators will not bother to change their existing 
practices if/when the RFC wording changes.   But if the RFC recommends 
poor practice, it will be harder to change that poor practice, because 
some people will say "but the RFC says...!"   So the RFC should not 
recommend poor practice.

If, OTOH, the RFC recommends NOT filtering based on EHLO arguments, then 
it will be at least a bit easier for operators to stop doing that when 
they start seeing that it's a bad idea.

I'm thinking long term here.   I expect 5321bis, if we do our jobs 
right, to be around for decades.   So its recommendations need to make 
sense in the long term rather than the short term.

It doesn't actually bother me that much if existing operators filter 
based on EHLO validation as long as they re-evaluate that policy over 
time.   I expect operators to be pragmatists.   But I really do expect 
use of NAT64 to increase, and I really think it's unhelpful to network 
operators if reliable email operation requires them all to maintain 
static IPv4 addresses and connections to the public IPv4 Internet.   
It's silly for email to delay a transition away from IPv4 for this reason.