Clayton Keller wrote:
I have been reading throught the Shortcircuit manpage as well as some
articles within the Wiki, and the manner in which I see it performing
within our install does not seem to coincide with how I am reading and
presumably understanding it to work.
First off, we are using SpamAssassin 3.2.4 provided by the rpmforge
batch of rpm's.
I have about a dozen priorities specified mainly handling URIBL,
SURBL, as well as DCC, Razor, Pyzor and Bayes.
What I am seeing is that although the first shortcircuit rule hits and
scores appropriately. Subsequent short circuit rules will continue to
fire. The scores themselves are then totaled along with the original
scores for the rules.
My understanding of how the shortcircuit should work is that once a
shortcircuit is triggered any subsequent rules should be bypassed and
the message wither classified as spam/ham or if set to on, it would
use the current score specified for the rule.
As a for instance:
I have the following:
priority URIBL_BLACK -500
priority URIBL_JP_SURBL -498
priority URIBL_SC_SURBL -488
priority URIBL_OB_SURBL -487
priority SC_URIBL_SURBL -480
priority SC_URIBL_SBL -479
priority RAZOR2_CHECK -450
priority DCC_CHECK -449
priority PYZOR_CHECK -448
priority SC_URIBL_HASH -440
meta SC_URIBL_SURBL (URIBL_BLACK && (URIBL_SC_SURBL
|| URIBL_JP_SURBL || URIBL_OB_SURBL))
meta SC_URIBL_SBL ((URIBL_BLACK || URIBL_SC_SURBL ||
URIBL_JP_SURBL || URIBL_OB_SURBL) &&
URIBL_SBL)
meta SC_URIBL_HASH ((URIBL_BLACK || URIBL_SC_SURBL ||
URIBL_JP_SURBL || URIBL_OB_SURBL) &&
(RAZOR2_CHECK || DCC_CHECK || PYZOR_CHECK))
meta SC_URIBL_SBL ((URIBL_BLACK || URIBL_SC_SURBL ||
URIBL_JP_SURBL || URIBL_OB_SURBL) &&
URIBL_SBL)
shortcircuit SC_URIBL_SURBL spam
shortcircuit SC_URIBL_SBL spam
shortcircuit SC_URIBL_HASH spam
score SC_URIBL_SURBL 100.00
score SC_URIBL_HASH 100.00
score SC_URIBL_SBL 100.00
I do not have a recent debug to show but I can say that from the debug
I do see the SC_URIBL_SURBL trigger, after the earlier priority rules
are ran. However, the remaining priorities are then ran, and if
meeting critera, the RAZOR, DCC, and PYZOR rules run and then the
SC_URIBL_HASH rule would trigger. Thus giving a total score of 200 +
the scores for the URIBL/SURBL scores that hit and if included the
Razor, DCC, and Pyzor scores as well.
I was thinking after the SC_URIBL_SURBL was triggered remaining rules
would not run, and the spam classification would take precendence.
Am I overlooking the obvious, have I misunderstood how the SC should
work, is it something with the rpm that was released by rpmforge? Any
thoughts or insight would be appreciated.
SA is, rather fortunately, circumventing what you're trying to do
because of how DNS is handled internally.
DO NOT try to split up the priority of DNS based tests. Priority and
shortcircuiting is intended to be used on *fast* rules, not slow ones.
If you were successful, you would make the performance of SpamAssassin
absurdly slow by serializing DNS queries. *OUCH*. SA normally runs these
in parallel, and running them in serial would very seriously impact
performance.
Currently, all DNS based tests "run" at their priority, but that only
launches the DNS queries. All the results are gathered together at
HARVEST_DNSBL_PRIORITY, which is currently set to 500. None of the rules
will actually trigger until this point.
