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

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.

pgp4HljtrZWPc.pgp
Description: PGP signature

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp