|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: To CAIS Engineers - WAKE UP AND TAKE CARE OF YOUR CUSTOMERS
[email protected] 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/
|