This is happening on a brand new DB, training with imapfilter. It's happened on two separate PCs (home and work), but with similar setup (Win XP, Python 2.2, pybsddb) and the same training data. I'll give it a go under Linux when I get round to rebooting.

Hopefully someone else will chime in here - I haven't really paid much attention to this bug (other that noting that it needs to be fixed before beta1) since I've never come across it myself.

...

(b) Use dbimpexp.py to convert your database to a text file. Change the ham and spam counts at the top to something like the numbers they should be Tried that. It works. Not sure yet what further training wiil do to those counts though.

Obviously it's not something you want to do all the time, anyway. If this happens regularly for you, it would be great if you were able to track down where the problem is occurring - I think that that is part of the problem - we're not sure what is causing the problem. A question for TimP (or any of the other stats people): if the ham/spam count does get lost, would setting them to the highest number of occurrences in the db screw things up? i.e. if my most spammy word appeared in 423 emails, and my most hammy word appeared in 233 emails, could I then set hamcount to 233 and spamcount to 423? =Tony Meyer