Re: [exim] Very weird Spamassassin error, $spam_score and $s…

Stian Jordet wrote:

> Hi,
>
> I have with great luck been using Exim and Spamassassin for a while, but
> recently I discovered something very weird. Look at this (excerpt from
> the headers):
>
> X-Spam-Score: 3.0
> X-Spam-Status: No, score=2.9 required=3.0 tests=LONGWORDS autolearn=no version=3.1.0
> X-Spam-Flag: YES
> X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on buick.jordet.net
>
> How on earth can it claim in the second line that the score is 2.9 when
> it just has said 3.0? This is from my config file:
>

*details snipped*

> Could this be a problem with my setup, a bug in exim or a bug in SA?
> Hope someone can share some insight on this.
>
> Best regards,
> Stian
>
>

There are two issues - rounding - discussed extensively by others

- and the relative timing of *when* an acl asks SA for the contents of
the $spam_score 'bucket', which is being progressively added-to as SA
goes through its many test suites.

You may not have seen this yet, but if/as/when you pull the score more
than once, and if/as/when one acl makes the request before SA has
finished its run, and the other acl after, you can get *very* different
scores.

e.g: Same message caught early-on with a 'fakereject' acl, and again
later after SA was fully finished, by a 'discard' acl:

2005-11-21 18:04:58 1EeG1t-0003e2-RS H=(203.194.153.81)
[210.193.211.53]:2631 I=[203.194.153.81]:25 Warning: D12S5 Temp-rejected
as spam (score 11.4): Analysed for Spam. Questions to:
inquire@???\n Content analysis details: (11.4 points, 5.0
required)

2005-11-21 18:05:01 1EeG1t-0003e2-RS => blackhole (DATA ACL discarded
recipients): This message scored 26.6 spam points. [1]

This would not, however, be a common acl configuration - just part of
our testing.

Goal:

If one can 'trigger' fast enough, one can jam a limited-life 'deny' or
'divert' rule into the firewall, effectively dropping the connection w/o
handing any messages out, and w/o queuing a collateral-damage bounce to
what will always be the wrong/unreachable sender.

Likewise blocking some types of immediate retry attempts 'cheaply', by
CPU-cycle count.

- ongoing research, that....

HTH,

Bill Hacker


[1] BTW - this sender had used *our* 203.194.153.81 IP in part of his
HELO ID as well... so could have been rejected earlier.
But we need the test traffic ;-)