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.
