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.
