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:
[EMAIL PROTECTED] 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 ;-)
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
