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

Keith Moore <moore@network-heretics.com> Sun, 27 September 2020 01:45 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F043A0E46 for <ietf-smtp@ietfa.amsl.com>; Sat, 26 Sep 2020 18:45:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
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, NICE_REPLY_A=-0.213, RCVD_IN_DNSWL_BLOCKED=0.001, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nFv_ls3efpO for <ietf-smtp@ietfa.amsl.com>; Sat, 26 Sep 2020 18:45:20 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74B4A3A0E3B for <ietf-smtp@ietf.org>; Sat, 26 Sep 2020 18:45:20 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 40664CBA for <ietf-smtp@ietf.org>; Sat, 26 Sep 2020 21:45:19 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sat, 26 Sep 2020 21:45:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=fm3; bh=wqeUBgRADpWkJapK1E9RbUEic3aQd+aUkHr0Cg4zN zE=; b=QbURsUTzQLSWL/ldyE3tB1e5IlahJPwRctdeDvw6q3cq3K7cNB22pQv+6 srkwP89HXy1OAT6sqZwCWHAalzBlZhxVEDQ1ULWe24wZBxYlo9lCYuz++Kq/9HRM oe8SPYP7yNrVHlPfvgodvIEEMs7RqEPPEUvL/sFTx+Qh5ECXUPp19iWbUiZB9vZ9 8xJKSUmvDEz2kvyub6J9Jis77YZaiq5nLD6wM1KfRwlNsyvbmziXB/Cq18uduGQJ pRgYOonFmY98momGoWCHfLOc3lyBjuSKOB8m3azampnCdYuVrHgmsHb6PdwfSHpG FS1UIRXa+PI9eSrcU16+S6Qp7Xr4A==
X-ME-Sender: <xms:re5vXzO3Cd1-YzLPGjrqJ26UaLiG6WOcxYmz_KPpl4tXcfo8ZKKoVA> <xme:re5vX9_utDy-jMFgVmu0Nnvh9TC83mrR5V-lBVcjmcbjMB-VhJoJNuYpnVtjCs5Ko MS3YwfJF4zBpw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdefgdeggecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekre dttdefheenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepheduhfeludegue etveevhfeujeejfefffeettedtvdelfefgkeeikeehjeffvdffnecukfhppedutdekrddv vddurddukedtrdduheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:re5vXyRnmvbbSHZFjg1UjCi-fhr7iH2HGckYYhQwynKzYtTEqa3JpQ> <xmx:re5vX3uue0p7Z32RxVPg0ruwhI9_yHF2WOM9F1e0Tz2GNz2MBp7Pow> <xmx:re5vX7eQE5VSh8nU3Lw6zA5ZI5trxCN_vy-gWvM-GII8-kRt1lWERA> <xmx:ru5vX-_lRg3lB6FOx37w-ED-iBhK3xvVeac-d6bsMdATrFuP3kc0VA>
Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 12FA6328005A for <ietf-smtp@ietf.org>; Sat, 26 Sep 2020 21:45:16 -0400 (EDT)
To: ietf-smtp@ietf.org
References: <cone.1600468578.784468.161845.1004@monster.email-scan.com>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <aeab531c-d249-a45f-8da5-3d5555a49202@network-heretics.com>
Date: Sat, 26 Sep 2020 21:45: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: <cone.1600468578.784468.161845.1004@monster.email-scan.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/jEUkvnUJVeYHg8dtWhVA2GiBOH0>
Subject: Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321
X-BeenThere: ietf-smtp@ietf.org
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\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Sep 2020 01:45:22 -0000

On 9/18/20 6:36 PM, Sam Varshavchik wrote:

> RFC 5321 declares:
>
> #  An SMTP server MAY verify that the domain name argument in the EHLO
> #  command actually corresponds to the IP address of the client.
> #  However, if the verification fails, the server MUST NOT refuse to
> #  accept a message on that basis.
>
> It's been my experience that this is frequently ignored in practice: 
> in varying ways whatever is seen in EHLO gets validated against DNS 
> and if found to be unacceptable mail gets rejected based solely on 
> that criteria. This is not a very popular thing to do overall; but it 
> is not a rarity either, and I hear about this regularly. This very own 
> E-mail was prompted by a thread on my mailing list from someone who 
> had this happen to them this week. I don't know how common this 
> practice is, but it's not uncommon.

Ok, this will probably look a bit like a rant.   Apologies in advance, 
and this is not meant to be disparaging to anyone.

1. Especially these days in the widespread presence of NATs and proxies 
of various kinds, it is meaningless to "verify" the domain name argument 
in HELO/EHLO.   Really it has never made any sense to compare HELO/EHLO 
argument against PTR lookup results on the source IP address because (a) 
hosts commonly had multiple interfaces with different names, and clients 
might not bother checking which outgoing interface was being used; (b) 
the longstanding practice of two-faced DNS means that the client host 
and server  may legitimately see different results from PTR lookup; (c) 
ISPs have (unfortunately) been polluting in-addr.arpa for years with 
made-up names which add no value; (d) historically the most likely 
reason for HELO/EHLO arguments to be "wrong" (assuming one could even 
define what that meant) was client MTA misconfiguration unrelated to 
message content; (e) there was never any requirement that Internet hosts 
have distinguished names anyway.   Also, these days it's quite 
commonplace for servers to log source IP addresses independently of 
anything said in HELO/EHLO, so insisting that EHLO arguments match 
source IP address as viewed by the server, really adds no value.

2. The HELO/EHLO argument is historically (and should continue to be) 
simply what the client host thinks its name is.   This is useful in 
Received header fields and logs, to diagnose problems that occurred on 
the sender's end of things.  (e.g. "Which host is generating this 
garbage Content-Disposition field?"  "It's the one that thinks its name 
is 'mumblefrotz'".)  So when you find an MTA config with its name set to 
mumblefrotz, you know you've found it.   This is useful in a different 
way than source IP address is, because nothing (that I'm aware of) 
requires client SMTPs to have stable source IP addresses.  So I would 
argue that it SHOULD NOT be derived from the client host's idea of its 
source IP address. (I could make a case for encouraging HELO/EHLO 
arguments to be UUIDs or some other kind of globally-unique identifier, 
but it's probably about 30 years too late for that.)

3. 821, 1123, and subsequent revisions all seem to be based on the 
assumption that if you're operating an SMTP server, you're trying in 
good faith to deliver (legitimate) email reliably.   I'm not sure this 
assumption holds true anymore, or has held true in general for the past 
20 years or so, because a lot of providers these days seem instead to 
regard all externally-originated email with suspicion, and to be trying 
to find every possible excuse to reject email.

Seen from that perspective, maybe 5321's language about EHLO arguments 
could use some updating along the following lines:

- For a very many reasons [which could be listed, or not], SMTP servers 
have no reasonable expectation of being able to determine the validity 
or legitimacy of a message based on comparison of the EHLO command 
argument with anything else at all.   Therefore if what you're trying to 
do is reliably deliver legitimate mail (for some meaning of legitimate), 
validation of EHLO arguments is useless and strongly NOT RECOMMENDED.

Of course, if your goal is really to discard mail for no good reason, 
and you're not handling incoming mail for anyone but yourself, have at 
it!   Just have the decency to blackhole the mail rather than bounce it, 
since you're really not doing anyone any favors.

(If it were normal for SMTP clients to relay mail with TLS and use 
client certificates to do so, maybe it would then make sense to check 
EHLO arguments against the client certificate's name. But we're a long 
way from being there.)

>
> Then there's also this part:
>
> #  o  The domain name given in the EHLO command MUST be either a primary
> #     host name (a domain name that resolves to an address RR) or, if
> #     the host has no name, an address literal, as described in
> #     Section 4.1.3 and discussed further in the EHLO discussion of
> #     Section 4.1.4.
>
> Not sure how to square this away. If it's a MUST, and this fails this 
> test, it seems to me that a mail server is no longer under any 
> obligation to continue to attempt to do something useful with a sender 
> that does not comply with this RFC. But this requirement conflicts 
> with the other requirement. I do not see how to reconcile these 
> conflicting assertions. Either it is permissible to disengage from a 
> non-compliant client, or not. Both can't be true.
I would argue for making this a SHOULD or perhaps a MAY, because making 
it a MUST tempts servers to perform meaningless checks against it.

Keith