MesQuilla

There is very little experience with newsgroup management of junk mail in Thunderbird, so I would be happy to hear your experiences. In general though, the more tokens the better, so if you are not having performance problems (that is speed issues), then you could increase that. But it takes roughly 10x more tokens to double accuracy, so there is clearly a point of diminishing returns here.

Currently, there is a core bug that prevents the tokenization of newsgroups messages from separating headers from the body, so it would be less accurate than email (plus it looks very different). But the newsgroup spammers are not as clever as those in email (they haven't had to be!) so overall my guess is it works OK. But I have little actual experience with it.

But to directly answer your question, yes it is probably a good idea, but don't expect dramatic changes.

"Thanks. I tried to raise it to 1 mio. and I see no slowdown on my system."

You would not see it right away. As you train, the number of tokens in use goes up. Eventually you will hit the limit, then the algorithm to prune the database kicks in, which will reduce the number of tokens by about half all at once. So it might take months or years for you to increase the number of tokens up to the point that such a large limit starts to affect your system. (You can see the number of tokens currently in use with JunQuilla, by the way, under tools/options/security.)

"The problem with usenet is not only spam but also usenet-"trolls"."

What you are describing is closely related to junk, but is a little different. You would get a better result if you used a bayes filter trained specifically for that purpose. In TB3, the internal bayes filter now supports multiple such characteristics (which I call "traits"), but there needs to be user interface provided to it. My extension TaQuilla was a first attempt to do that, but that extension is now effectively obsolete. I hope to soon get back to it to see if perhaps we could support use cases such as you are describing.