On 1/11/2012 3:56 PM, email builder wrote:
>>>> http://www.hardwarefreak.com/fqrdns.pcre <-- Stan's big list
> Noel, thank you for the thorough response. Thanks also to
> all the other responders. I'm definitely convinced. :)
>
> And of course, thanks to Stan!
Of all days for me to be away from the KB most of the day... ;)
Others have already hit the high points (thanks guys) so I'll simply try
to clarify a few points, confirm some things.
It may be maintained and hosted in a "hobby" manner, but I'd say the
file gets as much, if not more, professional use than hobby use. A
small sample of hosts that download the file 'regularly'. Yes, the top
two are Barracuda Networks, makers of anti-spam appliances. XS4ALL is a
large ISP in the Netherlands. Xelerence is a Canadian manufacturer of
DNSSEC security appliances, etc.
64.235.144.50: mail.ess.barracuda.com
64.235.150.204: mail.ess.barracuda.com
82.161.212.182: firehole.xs4all.nl
83.163.53.136: puzzled.xs4all.nl
193.110.157.188: mx.xelerance.com
83.139.103.70: dougie.bnet.hr
83.139.103.73: jimbo.bnet.hr
38.126.132.162: gateway.dclab.com
62.77.203.7: z.mx.invitel.net
67.217.170.17: ashburn1.wheelockweb.com
70.167.15.110: mailbox.dop.com
80.150.141.20: mail.ecka-granules.com
88.198.27.178: mx20.monline.it
173.220.103.45: oouser.polylogics.net
129.241.43.189: fender.itea.ntnu.no
147.215.1.189: cache.esiee.fr
147.32.9.2: nms.fjfi.cvut.cz
194.156.172.86: mail96.atlas.de
70.43.81.99: smtp.media-brokers.com
129.187.15.138: lxbsc02.ws.lrz.de
207.10.60.100: hide-inside.nemetschek.net
Very little time goes into this. Maintenance simply consists of adding
a expression to match a new or previously unknown rDNS string. This
typically occurs when an ISP receives a new netblock from its RIR and
puts it into service. Rarely, one ISP acquires another and renames
their generic rDNS patterns to reflect the new company name. Adding or
changing rDNS strings is typically a pretty major infrastructure change.
Thus don't simply don't occur very often. It's akin to adding new area
codes or prefixes to a telephone system.
It primarily targets 'consumer' rDNS patterns, both dynamic and some
static. Some static patterns are rejected, some have a prepend for use
with SA and the like.
Regarding Postscreen integration I don't see that as a win. Postscreen
and the fqrdns.pcre table both target bot spam, but in different ways.
Postscreen targets bot spam directly, fqrdns.pcre indirectly.
Postscreen tends to stop most bot spam on it's own without need of
dnsbls or this pcre table. Leaving fqrdns.prce in smtpd should kill any
that make it through Postscreen, if any do.
For those who don't know regular expressions, the table looks huge
because we use fully qualified expressions in most cases, making them
very long lines. And each expression has ISP specific optional
rejection text, taking up even more space.
As Noel mentioned you may get FPs if receiving mail from a host that
sits on a residential or small biz line. If that occurs the proper way
around it is to whitelist the client IP address, sending domain, or
sender address, with an access table. See 'man 5 access'.
Let us/me know how it works for you. Easiest way to check its
performance is with something like:
$ grep -i -c "please relay" /var/log/[your-mail-log-file]
--
Stan
