Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321
Keith Moore <moore@network-heretics.com> Mon, 28 September 2020 12:53 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 F146F3A10F5
for <ietf-smtp@ietfa.amsl.com>; Mon, 28 Sep 2020 05:53: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,
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 k6U75kqvvjJW for <ietf-smtp@ietfa.amsl.com>;
Mon, 28 Sep 2020 05:53:21 -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 9A0A23A10F8
for <ietf-smtp@ietf.org>; Mon, 28 Sep 2020 05:53:12 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44])
by mailout.nyi.internal (Postfix) with ESMTP id BF5415C0132;
Mon, 28 Sep 2020 08:53:11 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
by compute4.internal (MEProxy); Mon, 28 Sep 2020 08:53:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc: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=sSeFUH
XPEU6IzWhfeR/LfND5+2k9iyQc4R349vxetAQ=; b=DFNkrt1MrGdyBu9NoGsoCB
cucg3k1yLM09kKHbl1+ubZKXKEv94eqDnfBi+eIjKuYZ2Dzlm0ZCfa7nnvxvP9EM
Bnukyj5w7rrJdVmpyl3D1bdjltitBlr4nAI4aS/k9q7XlLpYBShz+KULe50BEy3A
VCAd8XRWFZNWpCSq/UoNJpCz0ubO26Jp0HC9l9tpJXfF/NiEpqO0SFT3oD1whAuo
erQ8ve9htrSXxp3sB5HXBpe7wzbPwZCwXvxYUQIht66E36Z6z//MmMeg7/tiHoPT
nPoiLTEM/m5O3ZXcmk2MhKYJ/yLBezu3OZYZSTFY7TqKAyTmF+AckCuS0jzIOCbQ
==
X-ME-Sender: <xms:t9xxX4KqjQFj7eDiJwdUmH81gi4Y5ARyQTBsk4tE6UnWIdc4kpszAw>
<xme:t9xxX4KBUCRuIGjNOKIvYff7ZiaGVFWxlmi4SatUO3bF2kdItELkyF888-dN82Xpr
fprYgNzyOuu6w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdeigdegtdcutefuodetggdotefrodftvf
curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
fjughrpefuvfhfhffkffgfgggjtgesrgdtreertdefjeenucfhrhhomhepmfgvihhthhcu
ofhoohhrvgcuoehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomheqne
cuggftrfgrthhtvghrnhepveefteduieegtdelvddvtddufeejjeffvdefteejieeulefg
tdfggedtffektedunecukfhppedutdekrddvvddurddukedtrdduheenucevlhhushhtvg
hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmohhorhgvsehnvghtfiho
rhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:t9xxX4tI2uF3QgkUJ1quperiIdfXKl9g92U6OKfT_pWT15Z2Hcu-Uw>
<xmx:t9xxX1YxJfZ3bUSgaBpZQnlgHiUYhLjMPcpuD4XqgtoTuZddIFHeng>
<xmx:t9xxX_YJtYPk6N6l1QVtsytWERucTCcxlM_Rqx48oDAmD0yT-mYs3A>
<xmx:t9xxX4kjRB-KwPecff44_R5-W4dyItCICtmj7X-1vwG1pZSaA_meyQ>
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 47CCB3064685;
Mon, 28 Sep 2020 08:53:11 -0400 (EDT)
To: Laura Atkins <laura@wordtothewise.com>
Cc: 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>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <aff3fde6-f120-1fb7-f8fb-eec8e16ac86e@network-heretics.com>
Date: Mon, 28 Sep 2020 08:53:10 -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: <F2BFE794-A258-4617-93BC-56ECE582CCE7@wordtothewise.com>
Content-Type: multipart/alternative;
boundary="------------9E0BCD7EB739A5137591738B"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/Ioj-rhlw2d9qw-dNSBncYTZqYWo>
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 12:53:23 -0000
On 9/28/20 8:04 AM, Laura Atkins wrote: > >> But if the RFC recommends poor practice, it will be harder to change >> that poor practice, because some people will say "but the RFC >> says...!" So the RFC should not recommend poor practice. > > What is your evidence that it is poor practice? > >> If, OTOH, the RFC recommends NOT filtering based on EHLO arguments, >> then it will be at least a bit easier for operators to stop doing >> that when they start seeing that it's a bad idea. > > What is your evidence that it’s a bad idea? 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'm thinking long term here. I expect 5321bis, if we do our jobs >> right, to be around for decades. So its recommendations need to >> make sense in the long term rather than the short term. > > That presumes that your recommendation makes sense and that allowing > any random NATed machine to connect to the internet and send mail is a > good thing. I think we have ample evidence that this is actually an > abuse vector and a bad thing. I disagree. At one time NAT was mostly associated with consumer grade routers, therefore NATted mail was unlikely to originate from a mail service provider, and more likely to originate from a compromised PC. But "carrier grade" or "large scale" NATs are increasingly being used within the network (rather than only at the periphery) in order to maximize use of IPv4 address space in the face of increasing address scarcity. Various flavors of NAT have also emerged as the likely best way to exchange traffic between IPv6 and IPv4, and their use is also increasing. > What changes do you see happening that will make this currently good > practice become a bad one. 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. (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.) >> It doesn't actually bother me that much if existing operators filter >> based on EHLO validation as long as they re-evaluate that policy over >> time. I expect operators to be pragmatists. But I really do >> expect use of NAT64 to increase, and I really think it's unhelpful to >> network operators if reliable email operation requires them all to >> maintain static IPv4 addresses and connections to the public IPv4 >> Internet. It's silly for email to delay a transition away from IPv4 >> for this reason. > > Can you explain this use case in more detail? I'm not sure what I've left out. 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… Arnt Gulbrandsen
- 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… 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 … 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 … Ned Freed
- 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