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/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@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