On 03/11/10 19:04, Stan Hoeppner wrote:
Charles Marcus put forth on 11/3/2010 8:49 AM:
On 2010-11-02 10:07 PM, Stan Hoeppner wrote:
...
check_client_access pcre:/etc/postfix/fqrdns.pcre
...
I keep meaning to say/ask - thanks for this - and do you update this
frequently/ever? Meaning, would anyone using it want to download new
versions periodically (I'm thinking the answer is no, but just want to
confirm)?
I've only added a single entry, the very last one, which breaks
tradition with the rest of the file. The expression I added targets a
snowshoe operation, whereas the rest target PBL type hosts. Other than
that all I've done is clean up a few errors in the original expressions
so the file could run as a PCRE instead of a regexp.
Ned Slider asked the same thing off list recently regarding making this
a project. I think it would be a great idea for this to become a larger
community project. I'm just not in a position to lead it or host it.
I'd probably try to contribute a little to it here and there though.
Yes, to me this looked like just the type of thing that might benefit
from multiple contributors in terms of growing the list. I had a quick
look through my own logs and made a few additions so there's certainly
lots of room for growth. I also spent some time searching my inbox(es)
for false positives (ham from servers who would have been blocked) and
identified a couple ranges (these will most likely depend on your mail
flow and the country you're in), and have been giving some thought as to
how best to handle these. In terms of contributing data, it could be as
easy as deploying the file before any DNSBLs in postfix restrictions and
then submitting missed dynamic/generic rDNS strings that subsequently
get blocked by the DNSBLs (from pflogsumm or similar).
However, I'm in two minds. For my own personal usage (small home server)
there's little point atm as I'm easily able to block the vast majority
of spam using standard postfix restrictions and greylisting - even the
DNSBLs only see crumbs now I've switched postgrey to return "451", and
what does make it through wouldn't be caught by this list. I simply
don't need to deploy this measure and risk the concomitant false
positives that it might create. OTOH the concept appeals and I can see
how such a file might be invaluable for smaller organisations who don't
qualify for free Spamhaus usage and can't afford/don't want to pay for a
subscription.
Stan, and others who are using this file - have any of you looked at the
overlap with greylisting? I would imaging that the vast majority of
clients with dynamic/generic rDNS would be spambots and as such I would
expect greylisting to block the vast majority anyway, and without the
risk of FPs. IOW what percentage of connection attempts from clients
with dynamic/generic rDNS will retry? Of course the benefits of growing
such a list now would become immediately apparent the day spambots learn
to retry to overcome greylisting.
