On 22/10/10 19:55, Stan Hoeppner wrote:
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.
Indeed.
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.
That argument doesn't convince me.
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.
That's fair enough, but that's not what you said. You said "Zero FP
rate" which by my understanding is different from needing to whitelist
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?
No, in an ideal world I would rather everyone adhere to best practice
which would help eliminate FPs. But in reality that's simply not the
case and there are lots of email servers out there that aren't
configured to best practice standards and will trigger FPs against
stricter rules. It's the same reason I see FPs when using the
reject_unknown_helo_hostname HELO restriction. It's a judgement call
each of us who operate mail servers make on a daily basis.
I guess we can agree to disagree - I simply wanted to highlight the fact
that using such rules can result in ham being blocked, regardless of how
you want to define that.
