On Dec 16, 2019, at 7:31 AM, Hector Santos <hsantos(_at_)isdg(_dot_)net>
wrote:
While the mail.ietf.org is raising the bar by requiring a FQDN, it is also
not checking the FQDN validity. I did two test using an existing FQDN that
does not match the connecting client IP and a non-existing FQDN from the same
IP machine:
EHLO santronics.com
EHLO foo.santronics.com
Each were acceptable, especially foo.santronics.com
So it wants a FQDN and yet doesn't check it. Why?
Because we have a history of this check being unreliable, hence why a MUST
NOT reject on the basis.
Correct, checking whether the FQDN exists (and even more so resolves to
the client IP) has too high a false positive rate.
But why the rejection of a IP-literal if it won't even check if the FQDN
is even exist or if it matches any of the IPs or even the SPF. I don't get
it.
That's easy, ... a sufficiently low false-positive rate allows this
check to weed some junk. That's all there to it.
"Real" inter-domain relays use FQDNs (whether valid or not), almost
none use address literals.
Mind you there are also reasonably good curated lists of HELO name
regexp patterns, that also have low FP rates, and do a decent job
at stopping lots of spam. These mostly match PTR records of various
dynamic IP ranges that haven't made into the SpamHaus PBL or similar.
Operators configure rules that work for their overall traffic mix.
The resulting FP rate is almost never zero, but given complaints
about the right kind of legitimate traffic many operators will
make accommodations. With the largest operators, if you don't
have personal contacts getting through can be difficult...
--
Viktor.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp