>>> http://www.hardwarefreak.com/fqrdns.pcre <-- Stan's big list
>> >> I've been curious about Stan's list of pcres. It looks massive, >> and Stan >> seems to be a regular expert contributer here. But I'm reluctant to >> start using a text file from a web site with nothing on it and only a >> bit of documentation in the file itself (not saying it's not >> sufficiently >> clear to implement, just that I don't feel like I have enough info to >> judge if the list will continue to be supported, if it's supported by >> more than one person, if it's supported just as a hobby or not, >> whether or not many other administrators are making use of it......) >> >> So who is using Stan's list? What do people have to say about >> it? What should I consider in regard to possibly implementing it? > > I use it. Stan occasionally updates it based his experience and > user feedback. I see the last update was 2011/08. Unlike a dnsbl, > this list does not require much updating; a few times a year is > adequate. > > I would consider the list a hobby like many other non-commercial > free antispam services. If Stan decides to stop supporting and/or > publishing it, it will still keep on working, and someone else might > volunteer "official" maintenance. Since it's basically a text > file, > any user is free to add/remove entries as they see fit. I expect > that even with zero updates the file would continue to be fairly > effective for years. > > As stated elsewhere, the intent of the file is to reject "consumer" > dynamic internet connections without the overhead of a DNS lookup. > Connections from these hosts are almost always spambots doing > direct-to-MX spamming. > > I would classify it as low risk of false positives, and fairly safe. > (but not 100% safe; few rules are. YMMV and such.) I've had a > couple of FP's from idiots that run their business mail servers on a > cablemodem with a dynamic rDNS name (their IP is static, but the > rDNS incorrectly says dynamic), so I added their IP to a local > whitelist. You may or may not run into the same easily-fixed problem. > > Use it like: > smtpd_client_restrictions = > permit_mynetworks > # uncomment next line if using SASL > # permit_sasl_authenticated > check_reverse_client_hostname_access pcre:/etc/postfix/fqrdns.pcre > > For testing, you can prepend warn_if_reject like this: > warn_if_reject reject_reverse_client... > This causes postfix to log a warning: message without actually > rejecting the mail. Then examine the log for anything interesting. > > It can alternately be used in smtpd_recipient_restrictions (or any > smtpd_*_restrictions sections), but be sure it's after > permit_mynetworks and permit_sasl_authenticated so you don't reject > your own authorized users. > > If you have an old postfix version that doesn't have the > check_reverse_client_hostname_access restriction, you'll need to use > check_client_access instead. The check_client_access will be a > little less effective, but doesn't affect safety. Noel, thank you for the thorough response. Thanks also to all the other responders. I'm definitely convinced. :) And of course, thanks to Stan!
