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

Sam Varshavchik <mrsam@courier-mta.com> Sun, 27 September 2020 20:30 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 C00263A0C82 for <ietf-smtp@ietfa.amsl.com>; Sun, 27 Sep 2020 13:30:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rPuexchfFqM for <ietf-smtp@ietfa.amsl.com>; Sun, 27 Sep 2020 13:30:40 -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 EF4E83A0C36 for <ietf-smtp@ietf.org>; Sun, 27 Sep 2020 13:30:39 -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 00000000002C0013.000000005F70F66E.000042EE; Sun, 27 Sep 2020 16:30:38 -0400
Received: from monster.email-scan.com (localhost [127.0.0.1]) (IDENT: uid 1004) by monster.email-scan.com with UTF8SMTP id 000000000001C7BA.000000005F70F66E.00008055; Sun, 27 Sep 2020 16:30:38 -0400
References: <cone.1600468578.784468.161845.1004@monster.email-scan.com> <da460777-824b-1f13-be7c-32bfa9664d02@network-heretics.com> <cone.1601211696.103163.24342.1004@monster.email-scan.com> <6DE405E366F059EA697D51D5@PSB>
Message-ID: <cone.1601238637.735385.31996.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, 27 Sep 2020 16:30:37 -0400
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="=_monster.email-scan.com-31996-1601238637-0001"; micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/GtqXQMOO94x3HfTx1M9NX0fu_T8>
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, 27 Sep 2020 20:30:42 -0000

John C Klensin writes:

> regional registries.  Independent of clients who are part of
> clouds and business arrangements large enough to push ISPs
> around, many ISPs refuse to create reverse mapping records at
> all [1] or will not create ones that that match client
> perceptions of their names rather than server-location based
> names following the ITU model [2]/
>
> [1] As handy examples pulled from this thread, 68.166.206.83 and
> 64.147.123.25 apparently have no reverse mapping records at all.

;; ANSWER SECTION:
83.206.166.68.in-addr.arpa. 4156 IN	PTR	mailx.courier-mta.com.

;; AUTHORITY SECTION:
166.68.in-addr.arpa.	71418	IN	NS	ns3.gtt.net.
166.68.in-addr.arpa.	71418	IN	NS	ns2.gtt.net.
166.68.in-addr.arpa.	71418	IN	NS	ns1.gtt.net.

The somewhat cumbersome https://mxtoolbox.com/ReverseLookup.aspx verified  
that it's not just the little bubble of the Intertubes that I live in can  
see this reverse mapping.

Anyway, the only point I made is that I believe that the MUST NOT, when it  
comes to EHLO/HELO validation, is frequently ignored in practice. Those who  
are of the opinion that validation is bad practice, nobody will force them  
to do it. And those who do believe that it filters out a bunch of crap will  
do it; they will ignore the MUST NOT. That's it.