Ned Slider put forth on 10/22/2010 10:50 AM:
> On 20/10/10 04:35, Stan Hoeppner wrote:
>> Jeroen Geilman put forth on 10/19/2010 8:09 PM:
>>
>>> You're missing some of the better spam prevention methods here, such as
>>> decent HELO checks, and an RBL or two.
>>>
>>> I'd suggest at least adding reject_unknown_reverse_client_hostname in
>>> there, as well as (testing out)
>>> reject_[invalid|unknown|non_fqdn]_helo_hostname.
>>
>> This will probably be a big help to Steve.
>>
>> smtpd_recipient_restrictions =
>>          permit_mynetworks
>>     permit_sasl_authenticated,
>>          reject_unauth_destination
>>     ...
>>          check_client_access pcre:/etc/postfix/fqrdns.pcre
>>     ...
>>          reject_rbl_client zen.spamhaus.org
>>          reject_rbl_client psbl.surriel.com
>>          reject_rhsbl_client dbl.spamhaus.org
>>          reject_rhsbl_sender dbl.spamhaus.org
>>          reject_rhsbl_helo dbl.spamhaus.org
>>          check_policy_service inet:127.0.0.1:60000
>>
>> http://www.hardwarefreak.com/fqrdns.pcre
>>
>> This pcre rdns checker kills tons of bot spam from consumer IPs that
>> should not be sending direct smtp mail.  It picks up where the PBL
>> leaves off.  Zero FP rate.
> 
> 
> Hi Stan,
> 
> I will dispute the zero FP rate. I was interested enough to pull the
> file and have a quick look, and found an example FP from today's mail
> spool almost immediately:
> 
> Received: from hornett-bros.co.uk
> (host81-143-22-5.in-addr.btopenworld.com [81.143.22.5])
> 
> Quite simply there are a lot of legitimate servers out there running on
> consumer IP space. It's not all dynamic, much of it is static and your
> pcre doesn't differentiate. I'm not arguing for or against the virtues
> of running/not running mail servers on consumer IP space, just
> highlighting the fact that many do it and therefore your block list,
> whilst no doubt highly effective, will cause FPs - i.e, it will block
> ham originating from such servers. The above example has neglected to
> set a PTR address for his IP and thus triggers a hit against your pcre
> file.

I guess this all depends on one's definition of false positive.  That
set of expressions is designed to block connections from IPs with
consumer'ish rDNS names.  If it blocks what it is designed to block,
that's not an FP even if the connection is sending ham.

In this context you point out, consider:  How many ham servers have
btopenworld consumer rDNS names?  How many zombies of the same?  We've
had dozens of lengthy discussions of this subject on spam-l over the
last couple of years.  Common sense says to block it all and whitelist
the extremely rare exceptions.

Would you rather that "FP" regex be removed from the list, and allow all
the zombie crap through simply to avoid rejecting ham from one of a few
hundred thousand IPs?

> PS - love your reject_rhsbl_* dbl.spamhaus.org suggestions - those are
> catching a fair amount of new snowshoe ranges yet to make it onto my
> IP-based blocklists

When I first started using the DBL in this fashion it wasn't catching
much.  It ramped up pretty nicely.  It's also pretty effective in
header_checks using Sahil's excellent checkdbl.pl TCP server, which also
queries URIBL and SURBL.  If you're not using it yet you really should
give it a shot.  It's perl based, so you'll need to make sure you have
all the modules installed, specifically Net::DNS and Sys::Syslog.

http://people.freebsd.org/~sahil/scripts/checkdbl.pl.txt

Sahil, if you're reading this, you may want to consider adding some
basic instructions on installing cpan and the two required modules.
This may help drive wider adoption for checkdbl.pl.  I think perl is a
black box in many OPs minds and they shy away from it.

-- 
Stan

Reply via email to