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

Richard Clayton <> Mon, 28 September 2020 00:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 057703A09C0 for <>; Sun, 27 Sep 2020 17:52:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mcOqMbYEp4yL for <>; Sun, 27 Sep 2020 17:52:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E084B3A0985 for <>; Sun, 27 Sep 2020 17:52:37 -0700 (PDT)
Received: from localhost ([]:53726 by with esmtp (Exim 4.94) (envelope-from <>) id 1kMhP9-0006Cg-Si for; Mon, 28 Sep 2020 00:52:35 +0000
Message-ID: <>
Date: Mon, 28 Sep 2020 01:51:16 +0100
From: Richard Clayton <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Turnpike Integrated Version 5.03 M <74w$+3BX77vcrNKLsib+d+vSDo>
Archived-At: <>
Subject: Re: [ietf-smtp] EHLO domain validation requirement in RFC 5321
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\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Sep 2020 00:52:40 -0000

Hash: SHA1

In message <>om>,
Keith Moore <> writes

>But this is a silly discussion.  

It seems backwards from where it started ... which effectively came down
to what would be good advice to proffer to a client to ensure that their
email deliverability improved.  The good advice "why don't you make sure
that forward and reverse DNS match up and say EHLO in a consistent
manner" is difficult (as has been pointed out) for some clients to
follow ... and that's why IMO it ends up as a SHOULD rather than a MUST.

>I certainly acknowledge that spam 
>filtering is hard, and that the state of the art is to use unreliable 

I would disagree ... state of the art is ML clustering algorithms using
a wide range of signals, where even the people who developed the systems
find it fairly hard to reliably predict beforehand which of those
signals are going to be of real significance.

Since the only practical way of tuning these algorithms is end-user
free-back that means that special precautions are needed to (a) ensure
that the bad guys do not detune them by "gaming" and (b) that even if
large numbers of people give the feedback that their cellphone bill is
spam this does not override the fact that treating everyone's cellphone
bill as spam would not be a Good Thing

"Heuristics" ... that is, human generated rules which give consensus
"scores" to the spammy-ness of email are far less effective (and we have
25 or so years of experience to demonstrate that).

Now of course, tuning the ML clustering algorithms is especially
difficult if you don't see enough email (ie not billions a day) because
almost everything is too unique to cluster.  But that doesn't make
heuristics "state of the art" -- it just indicates that there's a
failure to by the community as a whole (rather than a handful of very
large providers) to develop ways to share pre-tuned clustering models. 

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

Version: PGPsdk version 1.7.1