Chris, > Thanks Mark, yes that did fix the problem though only after I changed > the order in which my "add_header all" statements were placed in my > local.cf. For instance, with 3.2.5 I had: > > add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ > tests=_TESTSSCORES_ _TESTS_ shortcircuit=_SCTYPE_ autolearn=_AUTOLEARN_ > version=_VERSION_ > add_header all Bayes bayes=_BAYES_, > N=_BAYESTC_(_BAYESTCLEARNED_-_BAYESTCHAMMY_+_BAYESTCSPAMMY_), > ham=(_HAMMYTOKENS(5,short)_), spam=(_SPAMMYTOKENS(5,short)_) > > at the bottom of my list of add_header statements and it worked > correctly. After installing the patch I was still seeing: > > X-spam-token: Summary Bayes not run. > > However, as an experiment I placed the above two add_header statements > as the very first two in my list and: > > X-spam-token: Summary Tokens: new, 13; hammy, 67; neutral, 36; spammy, > 1. > > Odd that it appears that now the add_header statements need to be in a > certain order or at least the ones above appear to have to be first. Of > course I could be wrong and it just worked out that way but at least > it's working.
Hmm. I'd say thanks for trying swapping the order and catching this, except ... I can't reproduce the problem here. It tried all combinations of add_header and clear_header I could think of, to no avail. I could imagine this were possible somehow if Bayes::check() were called more than once, but I don't think it happens in reality. Would you be so kind and repeat your experiment (still with the patch applied), perhaps with minimalized set of add_header following a clear_header. Does a debugging output show anything unusual about the bayes plugin operation? Is a debug line: dbg: bayes: corpus size: nspam = ..., nham = ... perhaps logged twice or none at all? Mark
