The resolution to this one... it turns out that the chi-squared function was giving back bogus numbers due to, of all things, a perl install whose log() function wasn't working right! Now that our perl install's log() works (don't know why it wasn't, but a fresh install of perl fixed it), bayes is giving us sensible results.
Yeesh.
-glenn
Glenn Little wrote:
Can anyone at all help here? I am really at a loss. Since writing the previous msgs, I threw away our bayes db and re-seeded it with all new ham and spam. But still, the bayes numbers come back (when seen in spamassassin -D mode) as either 0.5, or something really wacky.
Help? What would cause that? Does this make any sense at all?
Thanks in advance...
-glenn
Glenn Little wrote:
Can anyone at least confirm my belief that when I run in debug mode, the bayes *is supposed to be* between 0 and 1?
I've just run several more mails through, and each one either gets a 0.5 on the nose, or something wild like "1073741825" or "5.5456855864500381703780513521021e+239" or a negative number like in "b" below.
The listing of tokens and their bayes values are all themselves between 0 and 1.
Do we have a problem? Any guesses on what causes the multitude of 0.5? How about the super big or super small or negative scores?
-glenn
[EMAIL PROTECTED] wrote:
Most of our spam is not getting a BAYES_nn component. It looks like this is for two reasons:
a) most of the spam scores as exactly 0.5 (which is the only score that gets no BAYES component, if I read 23_bayes.cf correctly):
debug: bayes: score = 0.5 debug: bayes: 27847 untie-ing debug: bayes: 27847 untie-ing db_toks debug: bayes: 27847 untie-ing db_seen
b) some of the spam scores with a number like this:
debug: bayes: score = -2.71172928721008841549952206070871e+1133
What does that mean?
So my question is, is something wrong? What does it mean for the majority of our spam to get a bayes score of exactly 0.5?
And why do we get numbers like in b)? Thanks in advance for any help or pointers.
-glenn
