RE: [exim] Reducing Spam Assassin Load

Peter Bowyer wrote:
> On 01/10/05, Marc Perkel <marc@???> wrote:
> > One of the things that is creating SA load is processing
> good email.
> > I'm trying to figure out a way to bless stuff that I know
> is ham so I
> > can bypass spam assassin. And it has to somehow just learn
> it automatically.
>
> But that's what SA does - learns what's spam and what's ham
> by Bayesian analysis. I'd have thought any attempt to do this
> up front would end up duplicating what SA does?

Probably yes, it he does it as stated by the OP,
i.e., "find ham" rather than as you (Peter) suggest
below:

> You could experiment with a reputation system which applies
> positive scores whan an IP sends you ham and negative scores
> when it sends spam or fails an up-front test (DNSBL, HELO
> checks and so on). And set a threshold for whitelisting
> around the SA check. But that would prevent SA learning from
> known ham - which is an important part of the Bayesian process.

Yes, other than whitelisting, the way that really
works is to use all of these "suspicion indicators"
to drive GREYLISTING in front of SpamAssassin.

Greylisting has some perceived disadvantages that
are overcome so completely by this "driver" technique
as to become irrelevant.

90% of what we send through greylisting "never returns".

Now it is not perfect as most of that other 10% and
some of what we never send to greylisting is also
spam.

But given the other checks, the load on SpamAssassin
is only about 85-90% of what it would be otherwise.

We also use SA to drive greylisting (but only if
the SA score is high, and the greylist process has
NOT YET been greylisted. This is the unusual (i.e.
low probability path however.)

--
Herb Martin