Justin Mason wrote:
Clayton Keller writes:
Justin Mason wrote:
Matt Kettler writes:
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.
actually Matt, you're wrong ;) if some of the network rules are
at a higher priority than others, and are used in shortcircuit rules,
SpamAssassin 3.2.x will indeed sleep until the results of those rules
arrive.
The idea is that, if you have the memory to support that degree of
concurrency, you can make a local policy decision to do that, instead
of doing the lookups at the MTA level which does effectively the
same thing.
This wait is logged, so you can spot it with --debug on.
--j.
With that said Justin, is the behavior I am seeing correct? Even though
the first prioritized shortcircuit rule hits, and I see that in the
debug log, shouldn't it be bypassing the remaining rules rather than
continuing to process until all the shortcircuit priorities have ran?
From reading the initial bug when this was originally featured, along
with the man page, as well as a wiki post with an example by you, that
is how I understood it to function.
actually, no, it sounds like a bug. could you open a bugzilla with
a demonstration config/test message?
--j.
Just to add, with my previous debug, I can confirm the waiting of the
tests to finish as you mentioned from the debug. I'll make sure this is
included when the bug is filed.
Also, what happened to independently enabling/disabling autolearning via
tflags? From a previous post a while back, I was informed that due to
performance gains shortcircuit rules were not learned as either ham or
spam due to their results due in part to creating additional performance
gains with the extra bayes processing that is required. Looking through
the original patch thread it appears this was a part of the discussion
to some degree, but I was just wandering what the final say on that was
as well.
Clay
