Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321
Sam Varshavchik <mrsam@courier-mta.com> Mon, 05 October 2020 00:34 UTC
Return-Path: <mrsam@courier-mta.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 C29C13A0ACB for <ietf-smtp@ietfa.amsl.com>; Sun, 4 Oct 2020 17:34:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 FBVsRz0443Ko for <ietf-smtp@ietfa.amsl.com>; Sun, 4 Oct 2020 17:34:29 -0700 (PDT)
Received: from mailx.courier-mta.com (mailx.courier-mta.com [68.166.206.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEF863A0AC8 for <ietf-smtp@ietf.org>; Sun, 4 Oct 2020 17:34:28 -0700 (PDT)
Received: from monster.email-scan.com (monster.email-scan.com [::ffff:192.168.0.2]) (TLS: TLSv1.3,256bits,TLS_AES_256_GCM_SHA384) by www.courier-mta.com with UTF8ESMTPS id 00000000002A0127.000000005F7A6A11.00004CB0; Sun, 04 Oct 2020 20:34:25 -0400
Received: from monster.email-scan.com (localhost [127.0.0.1]) (IDENT: uid 1004) by monster.email-scan.com with UTF8SMTP id 000000000001C6F6.000000005F7A6A10.00007C6E; Sun, 04 Oct 2020 20:34:24 -0400
References: <20201004214603.5C63B22EE214@ary.qy> <3b9f2e02-24e7-a3c6-d763-e07eb2912fb2@network-heretics.com> <cone.1601852941.177733.29744.1004@monster.email-scan.com> <ff12dbef-0ce0-ac8a-c099-122c76aacc2c@network-heretics.com>
Message-ID: <cone.1601858064.579130.29744.1004@monster.email-scan.com>
X-Mailer: http://www.courier-mta.org/cone/
From: Sam Varshavchik <mrsam@courier-mta.com>
To: ietf-smtp@ietf.org
Date: Sun, 04 Oct 2020 20:34:24 -0400
Mime-Version: 1.0
X-Mime-Autoconverted: from 8bit to quoted-printable by mimegpg
Content-Type: multipart/signed; boundary="=_monster.email-scan.com-29744-1601858064-0002"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/HPke-KJP_u8uoOYCItIT65JZ_jA>
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, 05 Oct 2020 00:34:31 -0000
Keith Moore writes: > On 10/4/20 7:09 PM, Sam Varshavchik wrote: > >> 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. It's unclear to me how they could end up handling something that's not their own mail. Doing so would, at least, involve hijacking DNS records to repoint someone else's mail to their own mail server. But that would fall waaaaaay out of scope, here. >> 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. That's neither here, nor there. One can publish anything. Whether they abide by what they publish, in practice, it's a different story. But everyone should make their own decisions, for themselves. To my knowledge, none of the widestly used, and most popular third party E- mail reputation services have any kind of authoritative, published manifesto about how they go about doing what they do. Anything beyond very, very general and non-specific description of what they're all about, and what their lofty goals are. Some are more specific than others, but nobody will actually state, for the record, exactly how they get from point A to point B. And that has always been the way as far as I can remember. And they are still used. And this has been a frequent criticism from their detractors, and I suspect that you're using this rigorous standard as an indirect way of attempting to discredit all third party E-mail reputation services. Well, be it as it may. But this does not discredit them in my eyes. But that's only because I think most of them are already discredited, for other unrelated reasons. I stopped using all of them, some time ago, after I concluded that things have changed sufficiently, over the years, for them to be worth anything, any more. But I certainly have no objection to anyone else still using them. It's a free world. Who am I to tell someone who they should or should not accept mail from, and why? >>> 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". You are entitled to your opinion. But you need to understand that, insofar as the operators of those mail servers go, they don't really value your opinion that much. Most of them don't even know who you are. Or who I am. They only see what's incoming on their port 25, and they will make their decision accordingly, and they won't really care whether someone else across the world thinks of it. >> 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. And specifying how EHLO/HELO, MAIL FROM, RCPT TO, and DATA works, on a purely technical level – this can't be any more interoperable than it already is. Whether or not someone accepts mail from someone else is a matter of policy, not interoperability. Interoperability is promoted by having a rigid, unambiguous, technical specification for something. That spells everything out in detail. SMTP is much more interoperable than other mail protocols that better be left unsaid, which had poor specs from the beginning that created many interoperability headaches, for decades. As far as that goes, I think that SMTP is remarkably interoperable. But I don't think there's anything technical in requiring any particular validation or non-validation criteria, or a policy, for the sender's IP address, or a domain, that falls outside of SMTP's strict boundaries. That's a matter of policy, and not a technical specification, and bears no relevance on interoperability. >> 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 You concluded that it was meritless to yourself. You did not make that conclusion for anyone else. > seen lots of examples of operators engaging in completely arbitrary behavior. Arbitrary in your eyes. In their eyes, it's unclear how arbitrary or not arbitrary it was. You cannot know that without asking them and getting their answer. They may have perfectly legitimate reason for engaging in the behavior you deemed to be arbitrary. You don't know that. >> And the only ones whose opinion counts, with respect to their mail server, >> is them. > > Emphatically disagree. This has been alluded to before, briefly. Back in the 1990s, there was a rather …vocal group who proferred the notion that mail server administrators have no standing to control E-mail sent or received by their users. That their users had some kind of a right to receive all E-mail unfettered and that mail administrators have no right, of some sorts, to block it for any reason. Let's just say that the group of individuals I'm referring to – and some on this list know exactly who they are – were not saying much different from what you are saying here. … and at about this point I started describing how well their ideas were received, what everyone thought of them and how everyone else assessed their … faculties, but when I reread it I realized that this came off too negative, so I decided to delete all of that, and just get to the bottom line: No matter how much someone asserts to the contrary, the administrators of mail servers will always have complete, and have the only say, as to their mail servers' administrative policies. And there's nothing that anyone will be able to do about it. No matter how much anyone else, you or anyone else, thinks of the merits of their work. Sorry. Write any requirement into the next SMTP specification, that attempts to dictate policy. It won't work. > And that path leads to a thoroughly dysfunctional > mail system, in which senders cannot assure the reliable delivery of mail This has never been the case, sorry. E-mail, as it stands, has never been a reliable, guaranteed message delivery medium. At most, E-mail has always been on a best-effort basis. >> 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. Well, I'm somewhat skeptical that they're looking for IETF's support on anything. And I don't really know what "IETF should support it" means in this context. Is IETF about setting everyone's mail acceptance mail policies, by decree?
- [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