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

Keith Moore <> Sun, 04 October 2020 18:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89CB03A09A8 for <>; Sun, 4 Oct 2020 11:21:16 -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 yvXVSokBBvT8 for <>; Sun, 4 Oct 2020 11:21:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1BA373A099F for <>; Sun, 4 Oct 2020 11:21:15 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 8C3AB391 for <>; Sun, 4 Oct 2020 14:21:12 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute3.internal (MEProxy); Sun, 04 Oct 2020 14:21:12 -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=F4jHyQeFSEWdm3kF3RYjnvoaCFMM1C21IjekwCrSB Vs=; b=aFlr/HZgAbt72wKZBOPa2qD5zvxFwIX2fkjardguV7mmvznTQObwexASJ 3YGZfyhO+7zcFrrRgzQ38atYWYk44QGc4m+3d9JWJez2pRjPHD7pDq5RX4Kbv3vu 1U+RWlIgeMkQKHtE3HToxJmAg3Mc8jzb0Izwr+0Ek51FDCX/u4za0BiorX553eRS 3CnBxTR7o++LHwqGZccagJFTkbS1U/hTD3uK8feQH6EdKipy9aL0/cQ1qPQ8Wkcw m27m4wOYteG3MpdDizCMntQy0i6TNQ+bDatTHuPndVbrD6eruSOqLUsZ8AeTSG85 7DJXk9CUu5E6HQc51x1ISnTy2Q9Tw==
X-ME-Sender: <xms:lxJ6X_sgH6fdnV5zhvfRHOKIqpv60XTRKJlcdQXCI413PRrNE1HBBA> <xme:lxJ6XwepPHmVB20gXBCQD1QyCHAdNHMhk3CjJXaAhl9azvTPBi9i0xW1CFGV_IiRn OgZcASgpO5RUA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrgedtgdduvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeehhfeutdehfe fgfefghfekhefguefgieduueegjeekfeelleeuieffteefueduueenucfkphepuddtkedr vddvuddrudektddrudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:lxJ6XyyahPoG49aIGlRjEc7uG0QYxDdVhWLMQEd0ed5fMBK0SwOczg> <xmx:lxJ6X-OYbFodsDQHcAo6vv5dHv5Rl20RJHMQq_iuI_bzn8Sz_zLoWw> <xmx:lxJ6X__OIBmtso3L4qc3OaFAYBBpsqrLLGFg16kCQfydX6DLm6xfkA> <xmx:mBJ6X9cOIyUQtE1LBALhOLrqY60qibEAhwonTIUWyOZfnnBRJ0jdtA>
Received: from [] ( []) by (Postfix) with ESMTPA id BDE6D306467D for <>; Sun, 4 Oct 2020 14:21:11 -0400 (EDT)
References: <20200928221602.046CE22A35B3@ary.qy> <> <> <> <> <>
From: Keith Moore <>
Message-ID: <>
Date: Sun, 4 Oct 2020 14:21:11 -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=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 18:21:17 -0000

Thanks for providing a list, though I wonder if this is the same as the 
list that John referred to.

I do suspect that the list could use some updating.   For example:

On 10/4/20 1:52 PM, Richard Clayton wrote:
> For the next few years however:
> *  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.  
(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)


- Provide inbound SMTP service at one or more public IPv6 addresses.

- Also, if possible, provide inbound SMTP service at one or more public 
IPv4 addresses.

- Provide at least outbound SMTP relay using public IPv6.

- If possible, relay outbound SMTP mail using a public address of the 
same type as the destination address, rather than through a NAT46 or NAT64.

> *  Do not share this IPv4 address with user machines
Do not share addresses of client or server (inbound or outbound) SMTP 
with user machines.
> *  Do not host your email system ‘in the cloud’
I'm not sure what this actually means or why it's still a bad idea.   
Cloud hosting makes a lot of sense for various reasons.
> *  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).

> *  Provide an MX record
> *  Provide meaningful and consistent reverse DNS
> *  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.

IMO that might be a bit limiting - I would really like to see TLS with 
client certs used for relay in the future if the details can be worked 
out, and in that case EHLO name should probably match client cert name.

> *  Keep your software completely up-to-date
up-to-date != minimal bugs.
> *  Use a submit port with effective authentication or strict
>     IP access controls
Could be reworded, I think.   Ideally a site would not relay any 
unauthenticated mail, no matter how it got into the site's mail system.
> *  Limit outgoing email volumes
> *  Accept reports of problems with your systems
Is there a more recent standard for doing so than postmaster@?
> *  Review the mail system logs on a regular basis
> *  Ensure your system is highly reliable
> *  Don’t create backscatter
> *  Maintain a good reputation

Anyway, looks like a good start, though I wonder what "well established 
anti-abuse metrics" others might have in mind.

I'd support an effort to update and formalize these.