Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321
Keith Moore <moore@network-heretics.com> Sun, 04 October 2020 23:39 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 21BDE3A0AA0 for <ietf-smtp@ietfa.amsl.com>; Sun, 4 Oct 2020 16:39:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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_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 twfF23gwa_ZN for <ietf-smtp@ietfa.amsl.com>; Sun, 4 Oct 2020 16:39:08 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95CB13A0A9D for <ietf-smtp@ietf.org>; Sun, 4 Oct 2020 16:39:08 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id B6BD2745 for <ietf-smtp@ietf.org>; Sun, 4 Oct 2020 19:39:07 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Sun, 04 Oct 2020 19:39:07 -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=fm1; bh=CaV66z58FaU/XOnZzGrykCCgr2QWFGl35Y42Qe3gl VQ=; b=bgczorLQL3KEdmpQM8Yhp/Ny2P99LvzBfCBOvsZ1X59dDQg7IxDtvCT7a AW9MC7E1u+Y/8okWpAcLqXAZ4gCxvnwun9Jwg1BjO2cjvywPdjLfWbHE1648Njhx A9dO+BXKWLlfpRQDucKQDL5T7BwUQ8LlZm9aU4XBewyPCjA/0G9mRkrCUfp9shcH 4wbKvdHLADx+8++4ilS/rjn3ed5uQCpyN/393lrk0rhE4j3BkABbvoctqQ7fZ/lo XWq2NtoS2ZWIImvk14QUKcrKq+5o3RrtoePLfMA8yvAon4Pe2KwQ4mzJ8dO/LJ7i OzlkDeeU/LF1cfV+eeLhG1KqaZCIg==
X-ME-Sender: <xms:Gl16X97N5qmAaXa3Ey4LIWeKyUrU4ZAripKD5WOYx46uoLltjo_QZA> <xme:Gl16X6432UhJHEQSxLxDc2vZ0A6rEQpfPp_SkRSRRQTm1vATyPRUz-Eb6k2ihBirZ -jcK5hoEJjomg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrgedugddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekre dttdefheenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepfeeggeevteetff ehleeggeejtdfhgedvieekjedvtdejhfejhffhffegvedthffhnecuffhomhgrihhnpehp rhgvjhhuughitggvrdhsohenucfkphepuddtkedrvddvuddrudektddrudehnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhrvgesnhgv thifohhrkhdqhhgvrhgvthhitghsrdgtohhm
X-ME-Proxy: <xmx:Gl16X0dhS1y8FFPfQuex931V-GH5cnTbf89jrHvfc49ludlhA7MLRA> <xmx:Gl16X2Kh1YkIqzFTfhW5g0cGYa7AseobjhgwekHegeoPiApDJU6UoQ> <xmx:Gl16XxKHj52cOtsB9zzs3VJ8bcE5anCeKV_bOLheOHjt3bwrMBDq7Q> <xmx:G116X0bAF8T_J5SWFF1iWaozVdjHM74JPsaP87uB9MKI7wJD2nEudA>
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 BF6CF3064610 for <ietf-smtp@ietf.org>; Sun, 4 Oct 2020 19:39:06 -0400 (EDT)
To: ietf-smtp@ietf.org
References: <20201004214603.5C63B22EE214@ary.qy> <3b9f2e02-24e7-a3c6-d763-e07eb2912fb2@network-heretics.com> <cone.1601852941.177733.29744.1004@monster.email-scan.com>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <ff12dbef-0ce0-ac8a-c099-122c76aacc2c@network-heretics.com>
Date: Sun, 04 Oct 2020 19:39:05 -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.1601852941.177733.29744.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/DJV_Jf7KKmncZAjn6LP41MgERSA>
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, 04 Oct 2020 23:39:10 -0000
On 10/4/20 7:09 PM, Sam Varshavchik wrote: > Keith Moore writes: > >> On 10/4/20 5:46 PM, John Levine wrote: >> >>> * Do not host your email system ‘in the cloud’ >>>> I'm not sure what this actually means or why it's still a bad idea. >>>> Cloud hosting makes a lot of sense for various reasons. >>> It's a bad neighborhood, since you can expect your neighbors to be >>> poorly managed botted spam-spewing web servers. It varies by cloud >>> provider but the median is pretty bad. >> >> Is it really fair to assess senders based on their >> "neighborhoods"? At > > Life's not fair. > > Whether it's fair, or not, if someone wishes to evaluate an individual > IP address based on its "neighborhood", a.k.a., the hosting provider, > it is their prerogative to do so. Their mail server, their rules. As long as they're only handling their own mail, I'd agree. > Or, if someone decides to willingly outsource their evaluation to a > third party provider, it is their prerogative to do so as well. Sure, though one hopes that the third party operates by published criteria that helps the client evaluate that provider's effectiveness and sanity. >> what point does this depart from common sense and into the realm of >> pure prejudice? ("That IP address is from across the tracks, which >> is a bad part of the net.") > > Yes, it is prejudice. So? At least you're willing to admit it. See, I'm fine with penalizing operators that have clearly established bad reputations through bad behavior. I'm not so fine with penalizing operators that merely have the misfortune to have "bad IP addresses", or send traffic from "bad neighborhoods". If there's a threshold for responsible behavior such that an operator's traffic should be trusted, it seems like that threshold should be widely known so that all operators can decide for themselves whether to meet that threshold or not. If, on the other hand, it's completely arbitrary, well that's not a recipe for reliable mail service. > I'm prejudiced against Chinanet, China Unicom, Digital Ocean, and a > few others. All I see from those providers are dictionary attacks, and > spam. And no response to abuse complaints. So, goodbye. Is it fair to > the lessors of the IP addresses that do not launch dictionary attacks > or spam outbursts? Yes, it's unfair. Well, that's life. Sorry. I don't > have to the time to keep track of bad IPs, on a one by one basis. I > have other things that are more important on my priority list. > > There happens to be some entities who do not like the side of railroad > tracks that I live in, by the way. Or, they outsource their mail > filtering to third parties that carry that opinion. I never whined > about how unfair it is. And it never entered my mind to complain to > them as well. I recognized that it's their mail server, their rules. > They are free to take care of their business, and I'm free to take > care of mine, in whichever way I see fit. The purpose of IETF (and therefore this list) is to promote interoperability, not to degrade it or shield those who do so. >> In most respects outsourcing of server provisioning, maintenance, and >> connectivity has become normal, widely accepted, often recommended >> practice. Why should email be different? > > Who said it should be? This part of the discussion was about a rule to not host mail servers "in the cloud". To me "cloud" means the kinds of outsourcing I listed above. Or would you define "cloud" differently? > >> It's hard to escape the impression that a lot of spam filters are >> based on imposing completely arbitrary restrictions on senders, on >> the belief that "good senders" will know which hoops they have to >> jump through (and have sufficient funding to do so) while "bad >> senders" won't. > > Yes, they may seem to be arbitrary to an outside observer. But, they > must have merit to whoever is using that spam filter. If it didn't > have any merit, then they would not be put into place, by definition. I disagree. I've seen lots of spam filtered for meritless reasons, I've seen lots of examples of operators engaging in completely arbitrary behavior. > And the only ones whose opinion counts, with respect to their mail > server, is them. Emphatically disagree. And that path leads to a thoroughly dysfunctional mail system, in which senders cannot assure the reliable delivery of mail even if it's legitimate content sent from a willing sender to a willing recipient. Which is an accurate description of what we have today. > If it makes sense, to them, to enable EHLO domain verification > (dragging this subject matter back into the thread kicking and > screaming), then they're going to do that no matter what verbiage > remains in the successor to RFC 5321. You can take that to the bank. Yes, people will defend their own stupidity and irresponsibility until their deathbeds. That doesn't mean that IETF should support 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