On Wed, 16 Jan 2013, 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,
Several of those are combined into ZEN. If you use Zen instead you'll save
some DNS queries. See the Spamhaus link I provided earlier for details, I
don't offhand remember which ones go into 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.)
Correct.
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.
That's odd. That suggests you SA wasn't looking up those DNSBLs, or they
would have contributed to the score.
Check your trusted networks setting. One difference between SMTP-time and
SA-time DNSBL checks is that SMTP-time checks the IP address of the client
talking to the MTA, while SA-time can go back up the relay chain if
necessary (e.g. to check the client IP submitting to your ISP if your
ISP's MTA is between your MTA and the Internet, rather than always
checking your ISP's MTA IP address).
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.
Maybe.
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.
Odd. SMTP-time hard rejects shouldn't change that.
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.
That shouldn't be the case. SA and sa-learn both use a shared-access
database; if you're training the database that SA is learning, the results
of training should be effective immediately.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
One difference between a liberal and a pickpocket is that if you
demand your money back from a pickpocket he will not question your
motives. -- William Rusher
-----------------------------------------------------------------------
Tomorrow: Benjamin Franklin's 307th Birthday
