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

Keith Moore <moore@network-heretics.com> Mon, 28 September 2020 13:26 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 DD5593A0ED6 for <ietf-smtp@ietfa.amsl.com>; Mon, 28 Sep 2020 06:26:44 -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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H3=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 3il01ebmF2HP for <ietf-smtp@ietfa.amsl.com>; Mon, 28 Sep 2020 06:26:43 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EEFC3A0ECF for <ietf-smtp@ietf.org>; Mon, 28 Sep 2020 06:26:43 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 2CFC85C0053 for <ietf-smtp@ietf.org>; Mon, 28 Sep 2020 09:26:42 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 28 Sep 2020 09:26:42 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=XTX41e Io/w/7OH8nYXW1x+NEPowcmF7fv1d0xwnfGXE=; b=vhpOdQIkbFvTp3MwWZo0gp 1xz48IGVhhfIUZ4DkzGBF1MveZJCsxDXnnlOuyAjtWEg6hSUMsTcUkIuZnMpOfzg SHpnk0zygnzq6oH5DE9B+j3C3Q6xINoDnZ7DVL7zvotzG4Je4igvLG8/mK+c/SS5 jJzQKwFqbr9zFtXgNvfeaRKqTvxVUOAVJ4KIicdco5xO0oJpyQtY8l2mMs2S/NIS qcmbJI/8QXioK9e5WcZ+eazjyXsMeQZCRwNYZerilyIeqYILckqRYFqFD8oEs3hA NZoK0VxjjZLNyMJvRQNFQHLQ8Uws+YVM75qzwrFCIfa6TuF3FRSsGSBPzlp6JEgg ==
X-ME-Sender: <xms:keRxX3w0dXIPdwOo-YXd0iJPospddpuF1Ss3WPFMfy7xnIOr2xJocQ> <xme:keRxX_TcVDu3A_KGpuMcKVZxnnVfXeiovBEa10Sz8tiptAMqDYR0GW-HG1IOTEIFK InfWuEtOMtyzg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdeigdeggecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtsegrtderre dtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthifohhr khdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeevfeetudeigedtle dvvddtudefjeejffdvfeetjeeiueelgfdtgfegtdffkeetudenucfkphepuddtkedrvddv uddrudektddrudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:keRxXxWk9cGtip4f7LZel7VQF6U5Iea79RuoR3eMhArAZODI6cZ_sg> <xmx:keRxXxgnQQX_gbyw1WU8Qjq-3ck3cdrFSX0KSUD7rpKtsRFGRQ7sfA> <xmx:keRxX5D5QNx9EP8q0O2FKOC5uWHI5raezwgdg28AApENO9Mp6Y1qCA> <xmx:kuRxX1wrInIm1k9dWqv-lyfkCNyLNBRN4x1mLrSZZXUkWyDA32WbZQ>
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 9D4DC3064610 for <ietf-smtp@ietf.org>; Mon, 28 Sep 2020 09:26:41 -0400 (EDT)
To: ietf-smtp@ietf.org
References: <cone.1601250950.437858.35945.1004@monster.email-scan.com> <ac132a1a-ec83-1ec6-dd34-85fd3bba95c5@network-heretics.com> <cone.1601252021.530626.35945.1004@monster.email-scan.com> <6330c607-5ede-4766-1823-5c8be8a9097b@network-heretics.com> <s1Gob6BEOTcfFAg3@highwayman.com> <3b1279c2-ce25-2c74-cfe4-89fe31075c06@network-heretics.com> <cone.1601257917.859397.35945.1004@monster.email-scan.com> <e37088fc-ccad-1a4b-7216-a7c11a365e0b@network-heretics.com> <399AEACC-81F0-4355-AB98-74896A772147@wordtothewise.com> <7df1611b-e664-131d-376d-1cab87ad6409@network-heretics.com> <F2BFE794-A258-4617-93BC-56ECE582CCE7@wordtothewise.com> <aff3fde6-f120-1fb7-f8fb-eec8e16ac86e@network-heretics.com> <FB243215-59BA-424F-9E31-2954561E22E8@wordtothewise.com>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <acc2e690-dff0-02c3-33f3-780d071df695@network-heretics.com>
Date: Mon, 28 Sep 2020 09:26:40 -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: <FB243215-59BA-424F-9E31-2954561E22E8@wordtothewise.com>
Content-Type: multipart/alternative; boundary="------------610533B27B3614B38190B4A4"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/6oWFm_VDFWZrEuIzmf3IVK_vaxk>
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: Mon, 28 Sep 2020 13:26:45 -0000

On 9/28/20 9:10 AM, Laura Atkins wrote:

>> I've made those arguments multiple times already.  "evidence" seems 
>> like the wrong thing to ask for because this is really a question of 
>> /design/ - what choices should be made to allow the email network to 
>> continue operating seamlessly and efficiently in the event of 
>> widespread use of NAT within the network (either to gateway between 
>> IPv4 and IPv6 or to economize use of IPv4 space)?
>>
> I’ve seen lots of arguments, yes, but I’ve not seen any real evidence 
> backing up your assertions.

Most of this is what I've picked up reading IETF lists and trade 
publications for years.   I guess I thought it was common knowledge 
within IETF that NATs were increasingly being used in these ways - 
certainly there were many discussions about it in IETF several years ago.


> I’m trying to better understand your point of view and understand why 
> this is so important. But it’s been hard to find that in the sniping.
>
> The design question is one that should be discussed, but is this the 
> correct space for that?

Arguably the discussion should be taking place on the emailcore WG 
mailing list rather than here.   But we started the discussion here.


>> The changes I see happening include the increasing scarcity of IPv4 
>> address space and the consequent emergence of IPv6-only network 
>> providers using NAT to move packets between IPv4 and IPv6 addressing 
>> domains.  I'm also anticipating the need to eventually phase out the 
>> public IPv4 Internet altogether.
>>
> Or we could write the BIS to recommend anyone running v4 services also 
> provide v6 services, couldn’t we? Take the burden off the v6 only 
> systems which are likely newer entrants and put it on the ‘old timers’ 
> who’ve been around for decades.

We could make such a recommendation.   Though I expect, that like spam 
filterers, network operators will do what they want, and consider 
themselves justified in doing so, regardless of what we recommend.

I suspect that the task before us is to make recommendations that both 
spam filterers and network operators will find palatable.


>> (From operators' perspective: how long does it make sense for every 
>> network to maintain its IPv4 baggage, just so that email won't be 
>> blocked?   At the very least we need input from network operators.)
>>
> My experience is that folks running MTAs on IPv6 actually enact 
> stricter technical requirements on those systems. For instance, many 
> IPv4 servers will accept mail without valid rDNS on the sending IP or 
> will accept mail without SPF records, while the IPv6 servers run by 
> the same entities require those things directly.

It might even make sense for IPv6 operations to "raise the bar".   For 
example, PTR lookup of IPv6 addresses allows finer-grained delegation 
than PTR lookup of IPv4 addresses.   But regardless of what some 
operators are doing, I think this requires careful analysis to justify 
from a standards perspective.   I suspect there will be IPv4-only 
networks with a legitimate need to originate mail to IPv6-only servers.

Keith