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

Keith Moore <> Sun, 27 September 2020 15:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14CA93A0FD0 for <>; Sun, 27 Sep 2020 08:34:06 -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_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 rEpbjJpPd7y7 for <>; Sun, 27 Sep 2020 08:34:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 558203A0FCE for <>; Sun, 27 Sep 2020 08:34:04 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id C4914B3D; Sun, 27 Sep 2020 11:34:01 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute4.internal (MEProxy); Sun, 27 Sep 2020 11:34:01 -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=iLHshh tjLHhxiTL/T4d4HeciH/GYjjFQX4qitO9NZ5g=; b=BfY0Beun46raY8hz/eYmgH V1uXwZeyNTMRy5xRwR+KOBeJxb6pKtY6RWOLceqiLByGpb1iDB6IE4lvDsecNejI e/tH947aam30jUrRMu/vcKTz4ZQUZwkpo3uvzy/ZBjAQ5kb8gx06ge6auJXSH2SR hnjF1UWXNk41CaXXjUxwae3b+C5FaqltEtjn+A83l/4RSUZ9N5HILnwrzDi9uAn0 zit8I4B/252IPJZNovBq4DJXQutwgzT//Y2mtaxLq5nJvBJA5fk80bjb53u67O7H a2tgsShiXHOT9IAApkovd/jc8YXOZP8mG+PsBr8VtXoQtzcxH7mypgpiwQQpSCAQ ==
X-ME-Sender: <xms:6LBwX9qyswoSaK0Ol-D4WIISVX-y_1JfzwF38cLh2kerobuBr-gVLw> <xme:6LBwX_oeITZ6P93omv2gnbsoCfFKpqTjbMAxUqI4mnt6dFSKb5W2lH6oQYpfSw7tF y6txQzVP6XvTg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdeggdeludcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgesrgdtreertdefjeenucfhrhhomhepmfgvihhthhcu ofhoohhrvgcuoehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomheqne cuggftrfgrthhtvghrnhepveefteduieegtdelvddvtddufeejjeffvdefteejieeulefg tdfggedtffektedunecukfhppedutdekrddvvddurddukedtrdduheenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:6LBwX6Mkxx_-rR5Texo9ADHTQ739tK9F0aMpv_6ZdJgO6EwRTpUdWg> <xmx:6LBwX4533NfevcBUh2xHtP-9XHPH2lRdlQlg6adMpfHW_d4EBxdzXQ> <xmx:6LBwX84_dJMDVNrg_wizAat0ZNeZpHicOtjz3vfcEiQ252LOMVoewA> <xmx:6bBwX-HeEcmoUo9esVxphAJjFzd4doSkrsU1bh-ghm79qeHZTo6NVw>
Received: from [] ( []) by (Postfix) with ESMTPA id 82FF0328005D; Sun, 27 Sep 2020 11:34:00 -0400 (EDT)
To: John R Levine <>,
References: <20200927052221.E0A1A21D3A2D@ary.qy> <> <>
From: Keith Moore <>
Message-ID: <>
Date: Sun, 27 Sep 2020 11:33:59 -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="------------BAE872F96E0990813E5386E7"
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, 27 Sep 2020 15:34:06 -0000

On 9/27/20 11:04 AM, John R Levine wrote:

> On Sun, 27 Sep 2020, Keith Moore wrote:
>> For example, should the standard insist that client SMTPs have and 
>> use an outgoing IPv4-capable interface any time the server SMTP is 
>> reached (directly or indirectly) via IPv4?   Or should client SMTPs 
>> be forced to use IPv6-to-IPv4 SMTP relays rather than NAT64?    
>> Should we have to keep maintaining a public IPv4 network indefinitely 
>> (or at least until IPv6 is globally ubiquitous)?
>> To me NAT64 seems like an essential tool for transitioning to IPv6 
>> and one quite often chosen by carriers, and I don't see the benefit 
>> in adding complexity to the SMTP signal chain  (with the consequent 
>> degradation of reliability)  just to preserve this rule.
> This seems backward to me.  Keeping in mind that upwards of 90% of all 
> mail is spam, and reliable spam signals are valuable, we know from 
> experience that real mail servers have static addresses and matching 
> forrward and reverse DNS. 

I would say instead that because some subset of inbound MTAs do EHLO 
verification, "real mail servers" (i.e. those which manage to continue 
to deliver mail with some reliability) are forced to have static IPv4 
source addresses for which PTR lookup results match EHLO arguments.

In other words, "real mail servers" (i.e. client SMTPs that manage to 
deliver mail with some reliability) are forced to jump through arbitrary 
hoops in order to overcome SMTP servers' arbitrary restrictions.

> Anything that comes from a dynamic or NAT pool is invariably spam from 
> a botnet.

No, because nobody is looking that closely.   It's basically just 
prejudice that assumes that "legitimate" senders have static IP 
addresses, delegation of the corresponding zone in, and the 
knowledge to populate the PTR records.   Or to put it differently - it's 
prejudice that assumes that the only people who should be able to send 
mail are those with the resources to arrange for all of that.   (Which, 
given the shortage of IPv4 addresses, is getting more and more difficult 
to do.)

And the prejudice (like many kinds of prejudice) becomes 
self-fulfilling, because those who don't have the resources to do those 
things fail at their businesses, while those who don't necessarily care 
about delivering mail reliably (spammers, botnets) but only care about 
being able to deliver mail in significant volume, aren't eliminated.    
It's exactly the same thing as a belief that "/those/ people don't drive 
nice cars and live in nice neighborhoods, so clearly they're doing 
something sketchy and should be treated with suspicion", which then 
causes those people to be marginalized and can force some of them to 
resort to sketchy means of making a living.

So yeah, I'm not a big fan of this kind of mechanism even if it seems to 
work under current conditions.    I certainly don't think it belongs in 
a stable protocol specification, because it relies on conditions that 
can and should change over time.

> Small mail servers send and receive on the same address, so if they're 
> going to work on IPv4 at all, they need a static v4 address.  Large 
> providers do NAT64 for their customers, but that's not where they put 
> their mail servers (or any servers that need an A record.)  They have 
> a chunk of static v4 space for that, and that's where they put their 
> outgoing mail hosts, too.

We need to give some thought to how this works across a transition away 
from a ubiquitous public IPv4 Internet, to an Internet that is a mixture 
of IPv4 and IPv6 (where not all parties have IPv4 access) and tied 
together by NATs of various kinds and interception proxies, and 
subsequently to an Internet in which IPv6 is ubiquitous and IPv4 is the 
rare exception.

To me it appears that EHLO argument verification imposes unreasonable 
constraints on enterprise networks, mail providers, and network 
operators which have nothing to do with the legitimacy of their content.

> Also remember that mail hosts don't need a lot of address space. I've 
> seen estimates of the total number of SMTP hosts in the 100,000 range.

Fair, but why should we need to retain _any_ semblance of a public IPv4 
Internet just so mail can be delivered reliably as the Internet 
transitions to IPv6?   Or alternatively, why should there need to be a 
flag day at which SMTP servers have to turn off EHLO verification?