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

Keith Moore <> Sun, 04 October 2020 20:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 678213A09E1 for <>; Sun, 4 Oct 2020 13:17:13 -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_H4=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 W4-TVHeJa-f9 for <>; Sun, 4 Oct 2020 13:17:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE73F3A09E0 for <>; Sun, 4 Oct 2020 13:17:11 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id D797E7CA for <>; Sun, 4 Oct 2020 16:17:10 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute3.internal (MEProxy); Sun, 04 Oct 2020 16:17:10 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=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=fm1; bh=A0RIF3WLhAeUIPvnXDAyEY+NRK4WcYljqhzX7tA4q ys=; b=HdBDcriPG3BHyzWMfHgC13aGzM7iD6tbR9G9sg8bfc7ZvJ5KJaaRmzeNw fZRcdqyxxe+KrpRe8sQMWwfw7B0jPEZW/nfnHOYPtwvLl/wwjFJJA1qL9K9JjQ4H u9hdBtp+FDLgB19Us+quZu9Efp9WgPTt63OGWmpMekyJbO8Zzhys97+xdItvm7Yz KDm2DEAWVBJQN+2Ru0bH2NwEK4+n73OW+4v6rE+xa2lgRNYS7+A4Jf9KlV8dWkij x9fYHM8YMFtqT7OZHzYneXwmsyotg2qQFiKRKww5DZV0vEBUXEyGhncrcpZmHXIb eYWUnN3pJawrGNCQ1qiKcP6vejYZg==
X-ME-Sender: <xms:xS16Xzz3zY2RSmnJL7FkjQvmiwTTD_DiAmIwQ_iiQ22kTxpyoKNUIA> <xme:xS16X7RIGKi1nOACzllA_ufUpRpt6RdsAT9rO0JJvA3f2Lx8M4_YXZe-MSkA4TTgL gIUyKIUd-nGJA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrgedtgdduhedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeehhfeutdehfe fgfefghfekhefguefgieduueegjeekfeelleeuieffteefueduueenucfkphepuddtkedr vddvuddrudektddrudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:xS16X9UE-XjMAXHCaxitO1CjxF_1TkoTi7esiZxqTe_9B1-dqe4BWQ> <xmx:xS16X9jYnasKr6WFldDld1BzeqQ3GpNTGi_sAIF8Hhzzz2g0o9Q7qA> <xmx:xS16X1Aoa1aqYCEG9IcMOIz3Cq0ObkiHZJnCppR3q2TfNB2L5kZsbw> <xmx:xi16Xxw5QLHF4NdWdM49R7IeI3sZntK3JD4-SSeD65cOAZRadZGmLg>
Received: from [] ( []) by (Postfix) with ESMTPA id BC28C306467E for <>; Sun, 4 Oct 2020 16:17:09 -0400 (EDT)
References: <20200928221602.046CE22A35B3@ary.qy> <> <> <> <> <> <> <w0F$>
From: Keith Moore <>
Message-ID: <>
Date: Sun, 4 Oct 2020 16:17:08 -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: <w0F$>
Content-Type: text/plain; charset=utf-8; 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: Sun, 04 Oct 2020 20:17:13 -0000

On 10/4/20 3:46 PM, Richard Clayton wrote:

>>> *  Use a static IPv4 address for your email system
>> IMO this should change to support the reality that IPv4 addresses are
>> getting scarcer by the day, especially in some parts of the world.
> you may wish it to change (and I am sure it will in time) ... but a
> consensus view (albeit from 2013, but I would expect it was much the
> same in 2020) is that you will have much more success delivering email
> from a static IPv4 address than from an IPv6 address

Oh, no doubt.   But I am of the understanding that the situation with 
respect to IPv4 address availability is changing and that the rate of 
change may well accelerate.

(Of course at some point public IPv4 addresses may be quite plentiful 
again because they are no longer very useful.)

The purpose of a standard specification is not to be reactionary, it is 
to specify what is needed for the protocol/service to work well now and 
in the future.   Operational practice does change over time (e.g. web 
traffic is now much more likely to use TLS and/or IPv6 than it was even 
a few years ago.)

So today, the right answer is that you need to support sending from IPv4 
if at all possible, sending from IPv6 is less essential.   But in the 
future IPv6 should be the norm and IPv4 should be phased out.   IMO it's 
valuable for there to be a standard recommendation for how to smoothly 
make that transition in email.   I doubt I have exactly the right words 
(and I didn't really try to nail them down) but I do think it's worth 
discussing in IETF.

>> (Especially given the inertia that likely exists with such rules,
>> changing the rules now may be necessary to ensure smooth operation in a
>> year or two)
> the inertia is I suspect merely in the people whose views go to the
> consensus as to what is "a wise way to set up your email"... it may be
> that they miss changes, but I doubt that you will do considerably worse
> by using IPv4 for some time to come

Why should MTAs be saddled with having to use a legacy and increasingly 
obsolete Internet service?   Why should enterprises in parts of the 
world with less available IPv4 space have to jump through extra hoops to 
exchange email because of obsolete assumptions?   Isn't it worthwhile to 
encourage MSPs to make explicit transition plans to migrate to IPv6?

>>> *  Make sure that your IP address is not listed in the PBL
>> I suspect that this is something that sites will have less and less
>> control over in the future, at least in IPv4 space, especially given the
>> "marketplace" in IPv4 prefixes and the need to have different sites'
>> addresses in different IPv4 subnets (also has to do with limitations of
>> DNS delegation).
> I think you may misunderstand the nature of the PBL ... this is
> basically telling you that if you are using IPv4 addresses handed out by
> a consumer ISP then you are going to have to ensure that they don't
> settle for a quiet life for their abuse@ team by listing all their
> assets

I don't know that I'm specifically familiar with the PBL but I have been 
of the understanding that blackhole lists often operated on "reputation" 
and that the "reputation" of IP addresses were sometimes sullied by past 
usages, thereby penalizing users/sites who were subsequently assigned 
those same addresses.

Can we reasonably expect that there will continue to be a clean 
separation between IPv4 addresses used by consumers and IPv4 addresses 
used by enterprises?

>>> *  Your system should say HELO (or EHLO) with its hostname
>> Could use better definition of "its hostname".   Suspect you mean EHLO
>> name should match PTR lookup of client's source IP address.
> the document I'm quoting from has a paragraph or so of explanatory text
> accompanying each of the bullet points -- so although those bullet
> points should resonate with everyone here, to make really good use of
> the advice you would need the whole thing

Ah, good to know.   I'd be pleased to read it if it were made available.

>> IMO that might be a bit limiting - I would really like to see
> you miss the point -- the list is what you should do for success today.
> It is not a manifesto for how the world should be
> that said, of course there is value in identifying where success is hard just
> to achieve and so we should be promoting initiatives to address that

A document that says what you should do for success today is indeed 
useful.   IMO a document that outlined a transition (mostly to IPv6 but 
perhaps in other ways also) would also be useful, and that's what I'm 
arguing for.

>>> *  Accept reports of problems with your systems
>> Is there a more recent standard for doing so than postmaster@?
> if you are not reading abuse@ and security@ as well (and paying
> attention to email coming in to pretty much any email address in whois
> data (for IP or domains) then more fool you

ok, fair.