On 1/16/2013 10:49 AM, Ben Johnson wrote:
On 1/15/2013 5:22 PM, John Hardin wrote:
On Tue, 15 Jan 2013, Ben Johnson wrote:
Wow! Adding several more reject_rbl_client entries to the
smtpd_recipient_restrictions directive in the Postfix configuration
seems to be having a tremendous impact. The amount of spam coming
through has dropped by 90% or more. This was a HUGELY helpful
suggestion, John!
Which ones are you using now? There are DNSBLs that are good, but not
quite good enough to trust as hard-reject SMTP-time filters. That's why
SA does scored DNSBL checks.
smtpd_recipient_restrictions =
reject_rbl_client bl.spamcop.net,
reject_rbl_client list.dsbl.org,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client cbl.abuseat.org,
reject_rbl_client dul.dnsbl.sorbs.net,
I acquired this list from the article that I cited a few responses back.
It is quite possible that some of these are obsolete, as the article is
from 2009. I seem to recall reading that sbl-xbl.spamhaus.org is
obsolete, but now I can't find the source.
I'm not sure if it is considered "obsolete", but it has been generally
replaced by zen.spamhaus.org instead. Zen incorporates SBL, XBL, CSS,
and PBL. (See http://www.spamhaus.org/zen/)
These are "hard rejects", right? So if this change has reduced spam,
said spam would not be accepted for delivery at all; it would be
rejected outright. Correct? (And if I understand you, this is part of
your concern.)
Exactly.
The reason I ask, and a point that I should have clarified in my last
post, is that the *volume* of spam didn't drop by 90% (although, it may
have dropped by some measure), but rather the accuracy with which SA
tagged spam was 90% higher.
These rejects will drop the total volume of spam. SA's accuracy may
appear to go up if some of the more difficult spams are now being
blocked by the blacklists.
Ultimately, I'm wondering if the observed change was simply a product of
these message "campaigns" being black-listed after a few days of
circulation, and not the Postfix configuration change.
At this point, the vast majority of X-Spam-Status headers include Razor2
and Pyzor tests that contribute significantly to the score. I should
have mentioned earlier that I installed Razor2 and Pyzor after making my
initial post. The only reasons I didn't are that a) they didn't seem to
be making a significant difference for the first day or so after I
installed them (this could be for the snowshoe reasons we've already
discussed), and b) the low Bayes scores seemed to be the real problem
anyway.
That said, the Bayes scores seem to be much more accurate now, too. I
was hardly ever seeing BAYES_99 before, but now almost all spam messages
have BAYES_99.
Is it possible that the training I've been doing over the last week or
so wasn't *effective* until recently, say, after restarting some
component of the mail stack? My understanding is that calling SA via
Amavis, which does not need/use the spamd daemon, forces all Bayes data
to be up-to-date on each call to spamassassin.
Amavis incorporates the SA code into itself. So in any instance where
you would normally need to restart spamd, you should instead restart
Amavis. In effect, Amavis is its own spamd daemon.
--
Bowie
