Eddy, > So I spin it again with "-L -D"
> 09:24:10.109 16.022 0.036 [20476] dbg: rules: ran rawbody rule > __SARE_HAS_FG_COLOR ======> got hit: ""color:" > 09:45:09.826 1275.740 1259.717 [20476] dbg: rules: ran eval rule > __SARE_HTML_HAS_BR ======> got hit (1) > So, after the 20 minutes delay, it says: > 09:45:09.826 1275.740 1259.717 [20476] dbg: rules: ran eval rule > __SARE_HTML_HAS_BR ======> got hit (1) > > Can I assume that the 20 minutes delay is caused by the > __SARE_HTML_HAS_BR rule ? More likely some other rule inbetween the __SARE_HAS_FG_COLOR and the __SARE_HTML_HAS_BR, which didn't produce any hits and was therefore not logged. > Is there some way to find the culprit rule ? > other that removing all rules and adding them one at the time. Perhaps the best timing tool for rules is the HitFreqsRuleTiming plugin, which can be found in masses/plugins/HitFreqsRuleTiming.pm in the distribution. Should work with 3.2.5 and with 3.3.0. It is quite primitive in that it does not have any configurables, but just dumps its results to a file 'timing.log' in the current working directory (make sure it is writable for the UID under which SA is running, no error is issued if it can not write there). To activate it, copy it to some place, then add a loadplugin command to one of your .pre files, such as a local.pre, providing the path to the .pm file, e.g.: loadplugin HitFreqsRuleTiming /etc/mail/spamassassin/HitFreqsRuleTiming.pm Then run a command line spamassassin giving it a sample message, e.g.: $ spamassassin -t <test.msg and after it finishes, you should have a sorted timing report in file 'timing.log' for all the rules, e.g.: T DCC_REPUT_13_19 1.724 1.724 1 T RAZOR2_CF_RANGE_E8_51_100 0.525 0.525 1 T CRM114_CHECK 0.093 0.093 1 T DKIM_ADSP_DISCARD 0.060 0.060 1 T SPF_HELO_PASS 0.041 0.041 1 T AWL 0.028 0.028 1 T BAYES_99 0.022 0.022 1 T T_FILL_THIS_FORM_LONG 0.006 0.006 1 Mark
