Re: To CAIS Engineers - WAKE UP AND TAKE CARE OF YOUR CUSTOMERS

["Eric A. Hall" <ehall () ehsco com>]

Valdis.Kletnieks () vt edu wrote:

> I once did a similar check in a Sendmail configuration, and found it
> to be incredibly useful in reducing the spam load without significantly
> impacting actual traffic.

> There's a second-order effect here - the sort of clueless ISP that is
> unable to get a PTR entry correct is *ALSO* the sort of clueless ISP
> that is very likely unable to detect/eliminate hacker/spammer/etc
> nests in their address space.

The problem with this approach is that it assumes a bunch of other stuff.
In particular, it assumes that the ISP even delegates control over the
IN-ADDR space to the end-user (while many here have stated they do not).
It also assumes that the ISP will make/maintain the pointers locally if
they do not delegate.

It also assumes that the root servers are working. A couple of weeks ago,
a.root-servers.net was periodically returning SERVFAIL on lookups for my
ISP's address block, rather than returning referrals, so no reverse
lookups ever got to their servers, and so never got to mine either. While
this isn't a failure mode that is common, that's exactly the problem,
somebody else' unexpected failure prevents it from being an accurate
measure of a particular admin's clueness.

Finally, it also assumes that the destination mail server and/or its
resolver is capable of dealing with CNAME (when CIDR delegation is in use)
or multiple PTR records (when a box belongs to multiple domains)
associated with an IN-ADDR entry. This is by no means guaranteed.

In short, filtering mail based on PTR matches is unpredictable and
unenforceable. You might as well use a random number generator.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/