On Mon, May 10, 2004 at 09:14:21AM -0600, Ryan Thompson wrote: > Johann Spies wrote to [EMAIL PROTECTED]: > > Am I the only one who experience this type of behaviour? > > No. See, at least, the thread that I started, beginning with "Bayes went > nuts". Aside from a couple of "me too" responses, I'm not aware of any > resolution yet. The workaround was to replace the DB, as you discovered. > > On a system like yours, you might want to tune the expiry settings. Or, > if you want control, don't auto-expire. Manually expire periodically, > but back up the database first, manually expire on the backup (use > everything looks OK. If things *do* go wrong, you'll have a recent > backup, *and* an excellent way to diagnose expiry-related problems.
Thanks for this tip.
> If you want to be part of the solution, let us know which version of SA
> you're running, what your expire settings were when this happened, and
> what sa-learn --magic tells you.
Version 2.63 on Debian Woody
I have switched off auto_learn and auto_whitelisting after the
incident.
My expire settings were the default setup.
sa-learn -D --dump --magic (as it is now):
debug: Score set 0 chosen.
debug: running in taint mode? yes
debug: Running in taint mode, removing unsafe env vars, and resetting PATH
debug: PATH included '/home/spamd/bin', keeping.
debug: PATH included '/usr/local/bin', keeping.
debug: PATH included '/usr/bin', keeping.
debug: PATH included '/bin', keeping.
debug: PATH included '/usr/bin/X11', which doesn't exist, dropping.
debug: PATH included '/usr/games', keeping.
debug: Final PATH set to:
/home/spamd/bin:/usr/local/bin:/usr/bin:/bin:/usr/games
debug: using "/usr/share/spamassassin" for default rules dir
debug: using "/etc/spamassassin" for site rules dir
debug: using "/home/spamd/.spamassassin/user_prefs" for user prefs file
debug: bayes: 28973 tie-ing to DB file R/O /home/spamd/.spamassassin/bayes_toks
debug: bayes: 28973 tie-ing to DB file R/O /home/spamd/.spamassassin/bayes_seen
debug: bayes: found bayes db version 2
debug: Score set 2 chosen.
debug: Initialising learner
debug: bayes: 28973 untie-ing
debug: bayes: 28973 untie-ing db_toks
debug: bayes: 28973 untie-ing db_seen
debug: bayes: 28973 tie-ing to DB file R/O .spamassassin/bayes_toks
debug: bayes: 28973 tie-ing to DB file R/O .spamassassin/bayes_seen
debug: bayes: found bayes db version 2
debug: bayes: 28973 untie-ing
debug: bayes: 28973 untie-ing db_toks
debug: bayes: 28973 untie-ing db_seen
debug: bayes: 28973 untie-ing
0.000 0 2 0 non-token data: bayes db version
0.000 0 95955 0 non-token data: nspam
0.000 0 34941 0 non-token data: nham
0.000 0 7675576 0 non-token data: ntokens
0.000 0 855632523 0 non-token data: oldest atime
0.000 0 1744971492 0 non-token data: newest atime
0.000 0 1084263215 0 non-token data: last journal sync atime
0.000 0 1084235277 0 non-token data: last expiry atime
0.000 0 2764800 0 non-token data: last expire atime delta
0.000 0 88754 0 non-token data: last expire reduction
count
>
> > How can I prevent this? I can not watch spamassassin 24 hours per day
> > to jump in when something goes wrong.
>
> If it's that important, you can't afford *not* to watch SpamAssassin 24
> hours per day to jump in when something goes wrong. Problems can occur
> with *any* system. Automate the monitoring of it, or hire someone who
> can.
I would like to see a way of automated monitoring that can pick up
false positives! The problem is that you only know about them when
people start to complain and then the damage is done.
Or do you mean that by monitoring the expiry of the database like the
debug output above, one can pick up early warning signs?
I do not have enough knowledge about this and how this affects the
possibility of false positives.
Regards
Johann
--
Johann Spies Telefoon: 021-808 4036
Informasietegnologie, Universiteit van Stellenbosch
"Search me, O God, and know my heart; try me, and know
my thoughts. And see if there be any wicked way in me,
and lead me in the way everlasting."
Psalms 139:23,24
signature.asc
Description: Digital signature
