ConfigServer Community Forum

There are no more Bayes reports on the emails received by our servers since Saturday, 26 Apr aproximately at 18:45 (See the Bayes Database information bellow).

It looks like something cleared my Bayes filters. or something is broken with Bayes filtering.

Questions:
1) Is it possible to set it not to "Expiry" anymore? How?
2) Is it possible to restore our bayes database to the previous state? How? Where is it saved?
3) Any other sugestions to fix this?

Thanks in Advance

Hilário
P.S. mailwatch/bayes_info.php give the following information:
Bayes Database Information
Number of Spam Messages: 6,647
Number of Ham Messages: 1,383
Number of Tokens: 125,510
Oldest Token: Wed, 16 Apr 2008 12:59:39 -0300
Newest Token: Sun, 27 Apr 2008 20:12:33 -0300
Last Journal Sync: Sun, 27 Apr 2008 10:32:57 -0300
Last Expiry: Sat, 26 Apr 2008 18:45:54 -0300
Last Expiry Reduction Count: 25,166 tokens

You should do a spamassassin lint test to see where the problem is. You can do this in MailWatch under Tools - SpamAssassin Lint (Test). Then search the output for any lines relating to bayes.

1) You do not want to disable the expiry, because you will then end up with a huge bayes database which will cause problems itself.

2) No.

3) See above.

MailWatch - SpamAssassin Lint results:
I eliminated sare results. Apart from the lines marked R/O I do not see anything suspect.

...
[305] dbg: plugin: loading Mail::SpamAssassin::Plugin::Bayes from @INC
...
[305] dbg: config: fixed relative path: /var/lib/spamassassin/3.002003/updates_spamassassin_org/23_bayes.cf
[305] dbg: config: using "/var/lib/spamassassin/3.002003/updates_spamassassin_org/23_bayes.cf" for included file
[305] dbg: config: read file /var/lib/spamassassin/3.002003/updates_spamassassin_org/23_bayes.cf
...
[305] dbg: bayes: tie-ing to DB file R/O /var/spool/mqueue/.spamassassin/bayes_toks
[305] dbg: bayes: tie-ing to DB file R/O /var/spool/mqueue/.spamassassin/bayes_seen
[305] dbg: bayes: found bayes db version 3
[305] dbg: bayes: DB journal sync: last sync: 1209382037
...
[305] dbg: bayes: DB journal sync: last sync: 1209382037
[305] dbg: bayes: corpus size: nspam = 6654, nham = 1385
[305] dbg: bayes: score = 0.572412433856079
[305] dbg: bayes: DB expiry: tokens in DB: 126602, Expiry max size: 150000, Oldest atime: 1208361579, Newest atime: 1209387493, Last expire: 1209246354, Current time: 1209395543
[305] dbg: bayes: DB journal sync: last sync: 1209382037
[305] dbg: bayes: untie-ing
...
[305] dbg: rules: ran eval rule BAYES_50 ======> got hit (1)
...
[305] dbg: check: tests=BAYES_50,MISSING_DATE,MISSING_HEADERS,MISSING_SUBJECT,NO_RECEIVED,NO_RELAYS
...


Anyway, the problem is that spamassassin is not giving any scores based on Bayes anymore. Please see the example bellow:
cached not
score=0.179
5 required
-1.44 ALL_TRUSTED Passed through trusted hosts only via SMTP
0.00 HTML_MESSAGE HTML included in message
0.00 MISSING_MID Missing Message-Id: header
1.62 TVD_RCVD_IP

Thanks for your kind help

Hilario

This is the solution for "Bayes Stoped Working"

Reference: http://wiki.apache.org/spamassassin/BayesNotWorking

There are other topics in the reference webpage above, but the important one is copied bellow (and edited/adapted so non-experts may understand easily)

"You might be using spamd, and running 'sa-learn' as a different user. Check your spamd switches and configuration, to see what username the mail is being scanned as.

Obviously, if you learn messages into one user's database, the learning will not be used when scanning messages as a different user."

I thus checked the owner of the files in /var/spool/mqueue/.spamassassin/ and noticed that the owner of "bayes_journal" and "bayes_toks" files had changed to root while they should be mailnull:mail

To implement the fix just type the following lines in the console:
cd /var/spool/mqueue/.spamassassin/
ls -la
chown -vhR mailnull:mail /var/spool/mqueue/.spamassassin/

I hope this may help anyone who may find the same problem.

Best Regards,

Hilário Fochi Silveira
P.S. I did not change the owner of those files manually, thus it is obvious that the automatic feature that runs the expire script has done it. It probably is a bug in the scripts.

Hi Hilario,

Thank you for posting your solution to this issue.

Regards,
Sarah