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
- [ietf-smtp] EHLO domain validation requirement in… Sam Varshavchik
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… John Levine
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Sam Varshavchik
- Re: [ietf-smtp] EHLO domain validation requiremen… Sam Varshavchik
- Re: [ietf-smtp] EHLO domain validation requiremen… John R Levine
- Re: [ietf-smtp] EHLO domain validation requiremen… John C Klensin
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… John R Levine
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Dave Crocker
- Re: [ietf-smtp] EHLO domain validation requiremen… Dave Crocker
- Re: [ietf-smtp] EHLO domain validation requiremen… Russ Allbery
- Re: [ietf-smtp] EHLO domain validation requiremen… John C Klensin
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Dave Crocker
- Re: [ietf-smtp] EHLO domain validation requiremen… Dave Crocker
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… John R Levine
- Re: [ietf-smtp] EHLO domain validation requiremen… Ned Freed
- Re: [ietf-smtp] EHLO domain validation requiremen… John R Levine
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Dave Crocker
- Re: [ietf-smtp] EHLO domain validation requiremen… Sam Varshavchik
- Re: [ietf-smtp] EHLO domain validation requiremen… Claus Assmann
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Dave Crocker
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Sam Varshavchik
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Sam Varshavchik
- Re: [ietf-smtp] EHLO domain validation requiremen… Dave Crocker
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… John Levine
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Richard Clayton
- Re: [ietf-smtp] EHLO domain validation requiremen… Dave Crocker
- Re: [ietf-smtp] EHLO domain validation requiremen… Dave Crocker
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Sam Varshavchik
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Laura Atkins
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Laura Atkins
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Laura Atkins
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Laura Atkins
- Re: [ietf-smtp] EHLO domain validation requiremen… John Levine
- Re: [ietf-smtp] EHLO domain validation requiremen… Arnt Gulbrandsen
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… John Levine
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… John R Levine
- Re: [ietf-smtp] EHLO domain validation requiremen… John R Levine
- Re: [ietf-smtp] EHLO domain validation requiremen… Mark Andrews
- Re: [ietf-smtp] EHLO domain validation requiremen… Mark Andrews
- Re: [ietf-smtp] EHLO domain validation requiremen… John R Levine
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Sam Varshavchik
- Re: [ietf-smtp] EHLO domain validation requiremen… Richard Clayton
- Re: [ietf-smtp] EHLO domain validation requiremen… Arnt Gulbrandsen
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Dave Crocker
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Dave Crocker
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… John Levine
- Re: [ietf-smtp] EHLO domain validation requiremen… Richard Clayton
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… John Levine
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Sam Varshavchik
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Sam Varshavchik
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Sam Varshavchik
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Sam Varshavchik
- Re: [ietf-smtp] EHLO domain validation requiremen… Keith Moore
- Re: [ietf-smtp] EHLO domain validation requiremen… Alessandro Vesely
- Re: [ietf-smtp] own mail server: DNS / static IP … Claus Assmann
- Re: [ietf-smtp] own mail server: DNS / static IP … John Levine
- Re: [ietf-smtp] own mail server: DNS / static IP … Claus Assmann
- Re: [ietf-smtp] own mail server: DNS / static IP … Ned Freed
- Re: [ietf-smtp] own mail server: DNS / static IP … Sam Varshavchik
- Re: [ietf-smtp] own mail server: DNS / static IP … Claus Assmann
- Re: [ietf-smtp] own mail server: DNS / static IP … Arnt Gulbrandsen
- Re: [ietf-smtp] own mail server: DNS / static IP … John Levine
- Re: [ietf-smtp] own mail server: DNS / static IP … John Levine
- Re: [ietf-smtp] own mail server: DNS / static IP … Ned Freed
- Re: [ietf-smtp] own mail server: DNS / static IP … John R Levine
- Re: [ietf-smtp] own mail server: DNS / static IP … Ned Freed
- Re: [ietf-smtp] own mail server: DNS / static IP … Dave Crocker
- Re: [ietf-smtp] own mail server: DNS / static IP … John R Levine
- Re: [ietf-smtp] own mail server: DNS / static IP … Evert Mouw
- Re: [ietf-smtp] own mail server: DNS / static IP … Sam Varshavchik
- Re: [ietf-smtp] own mail server: DNS / static IP … Claus Assmann
- Re: [ietf-smtp] own mail server: DNS / static IP … Laura Atkins
- Re: [ietf-smtp] own mail server: DNS / static IP … Sam Varshavchik