IETF Logo Mail Archive

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

Laura Atkins <laura@wordtothewise.com> Mon, 28 September 2020 12:04 UTC

Return-Path: <laura@wordtothewise.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 8864F3A107E for <ietf-smtp@ietfa.amsl.com>; Mon, 28 Sep 2020 05:04:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wordtothewise.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 WsOfQ6ts2uGz for <ietf-smtp@ietfa.amsl.com>; Mon, 28 Sep 2020 05:04:15 -0700 (PDT)
Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id C43193A109C for <ietf-smtp@ietf.org>; Mon, 28 Sep 2020 05:04:15 -0700 (PDT)
Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id 51DC19F1F7; Mon, 28 Sep 2020 05:04:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1601294655; bh=TigR8XIBmjxstk4yJms+zQTrzd2nGzFnBTmSXKj+uT8=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=JhWeZEcVxwliFTJddSiFe9zPLNXKEHR4IYDmKoYWRFdjdXMphmwXWKw6mIyANsCZj rltHLA/v5YWrCbR+320kCc7yFh3kRo4QxQf8zeCexnIpr4pvmPeAnVdH6K2gsa3Txc iSP0w99EAfC6jJ7yr6WrnytlGZtJfJRJt7HuZz0w=
From: Laura Atkins <laura@wordtothewise.com>
Message-Id: <F2BFE794-A258-4617-93BC-56ECE582CCE7@wordtothewise.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_554D3475-09CE-454A-A6B1-B4192ABC149D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Mon, 28 Sep 2020 13:04:11 +0100
In-Reply-To: <7df1611b-e664-131d-376d-1cab87ad6409@network-heretics.com>
Cc: ietf-smtp@ietf.org
To: Keith Moore <moore@network-heretics.com>
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>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/jSQ1Xq4FrmslBaLPRr03QJJFNQk>
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:04:18 -0000


> On 28 Sep 2020, at 11:38, Keith Moore <moore@network-heretics.com> wrote:
> 
> On 9/28/20 4:38 AM, Laura Atkins wrote:
> 
>> Do you think if the wording in the RFC is changed that established behavior will change? That the SMTP servers will be reconfigured to stop doing what they are doing?
> 
> I think most operators will not bother to change their existing practices if/when the RFC wording changes.  

That’s what I thought. 

> 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'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. What changes do you see happening that will make this currently good practice become a bad one. 

> 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? 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
laura@wordtothewise.com
(650) 437-0741		

Email Delivery Blog: https://wordtothewise.com/blog

v2.23.0 | Report a Bug | By Email