When upgrading from older crm114 releases and trying to retain your existing configuration it is important to check that all the configuration options that the new version expects to be set have been set. While some will cause errors if they’re omitted others will appear to work but will cause unwanted behaviour at runtime. For example, omitting good_threshold and spam_threshold will cause everything to be flagged as spam in X-CRM114-Status even though the classifier is working well.
In practice there are relatively few configuration options that users are expected to configure so it may be easier to redo the configuration based on the example provided. For safety it’s best to delete your existing CSS files too in case they’ve been invalidated by a configuration or format change.
It’s all a bit manual but it’s worth it for what it does for my inbox.
I’ve tried crm114 a few times, but it often seems to mysteriously crash when processing email, and various information I’ve seen suggests that it has compiled-in buffer size limits which lead to the crashes. Furthermore, the language itself seems even more like line-noise than badly written Perl. And after months of training it, it still threw half my mail in the UNSURE folder.
@anonymous: I’ve not had any stability problems – the problems I’ve had have only been with misreporting the status of mails.
Constantly flagging mail as unsure is to be expected (since that’s how it learns before it starts getting false positives) but in my experience it’s only ever a very small proportion of the mail I’m filtering, and usually only mail that stands out in some way (mails from companies I’ve not dealt with before and new types of spam are the classic ones).
… and not to forget: the CSS files are not interchangeable from 32 to 64bit systems. if moving from 32bit to 64bit you have to use mailtrainer with your corpus to build up new ones.