On 3/28/2013 8:03 AM, /dev/rob0 wrote: > "... maintaining it ..." see? I would think that something which is > maintained generally isn't outdated. Depends how well the maintainer > maintains it, of course.
Precisely. Let me add that ISPs introduce new consumer rDNS strings very infrequently. Thus, the table doesn't change very often, as it already has most dynamic/generic patterns used by ISPs for consumer endpoints. When I come across a new rDNS string, or one is reported by a user, I add a regex to match it. In the past twelve months I'd guess I've added maybe a half dozen patterns at most. > Not entirely. Think of Stan's PCRE list as a compact, local version > of Spamhaus PBL. It lists patterns which have been identified in > reverse DNS names for dynamic hosts, which should not be sending > mail. Dynamic, but also generics that may/not be dynamic. It also has patterns matching generic static rDNS, which return a PREPEND action instead of a reject. This can be used for scoring in a policy daemon or content filter. This table serves the same purpose as the PBL, but using a different method: rDNS instead of IP address. > If you are checking PBL, or more likely, Zen (which includes PBL), > you're not likely to benefit much from Stan's PCRE list, except for > those networks which slipped through the PBL cracks. There are quite a few PBL doesn't list, or at least this used to be the case. Also, as we've discussed, a query to this table takes <100 µs. A DNS query to Zen takes from 10-100ms, assuming you're not a data feed customer serving the zones locally. So fqrdns has a big latency advantage, and it can dramatically decrease DNS packet traffic. Worth noting here is that fqrdns and things like it decrease the burden on the world's dnsbl servers. While this doesn't benefit MTA operators, it benefits dnsbl operators. Bandwidth costs money. > But there too, > you can also use it as a HELO check after postscreen (things that > make you go "hmmm": postscreen is actually a prescreen!) ... > If postscreen DNSBLs are your only protection, what happens if your > DNS breaks? Spam flood! Here too, Stan's PCRE list can help, again, > at least as a HELO check (client name checks won't fire if DNS is > gone.) And many people use the table for HELO checks as well for this very reason. Spambots quite often do a PTR lookup on the local IP and use the rDNS name in the HELO string. > Consider the "onion" approach, multiple layers of protection. When I > went to postscreen I left all my old spam restrictions alone. On rare > occasions I have seen where they are used. Layered, exactly. And the cost of leaving them enabled is miniscule. > All that said, I personally have not used Stan's PCRE list, but I've So much for that layered defense Rob. ;) > seen it discussed here and elsewhere for a lot of years. I guess that > means I'm outdated also. ;) It lost much of its appeal when Wietse introduced Postscreen due to the overlap of coverage. It does have three advantages over Postscreen. 1. Ease of implementation. One line added to main.cf. You don't have to touch master.cf, configure dnsbl sites, nor turn any other knobs. It's great for low volume MXen. Postscreen was designed to keep spambots from tying up smtpds. If you're smtpds aren't being tied up then fqrdns is an easier option. 2. Usable with any Postfix version--Postscreen requires 2.8+ 3. It will reject a connection from consumer land even if the sending client is a valid MTA, not a bot. Postscreen lets these through unless the IP is listed in a postscreen dnsbl. Recall that the first convicted US spammer, Jeremy Jaynes, had 6 aDSL lines to his house and was using real MTAs to send his spam. -- Stan
