spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Hardin <>
Subject Re: Calling spamassassin directly yields very different results than calling spamassassin via amavis-new
Date Wed, 16 Jan 2013 16:00:12 GMT
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,
> 	reject_rbl_client,
> 	reject_rbl_client,
> 	reject_rbl_client,
> 	reject_rbl_client,

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.)


> 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.


> 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              FALaholic #11174     pgpk -a
  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

View raw message