Kyle Johnson wrote, on 07. mar 2007 14:47:
[...]
[EMAIL PROTECTED] is only an example.
You want to create a new user that, and then run dspam_train on said
user. This will provide that user with some out-of-the-box accuracy.
You want to then add that user to a group, to provide that data to
others. I recommend a merged group, and if the created user's name (as
matches in the dspam_virtual_uids table) [EMAIL PROTECTED], the
group file would contain [EMAIL PROTECTED]:merged:*.
A merged (nor any other type than shared) group never worked "as
expected" for any of my sites, nor did individual users. I use a shared
group for all sites - that (empirically) gives the highest accuracy for
me. As for groups versus individual users, the difference is many GB (I
measured 15:1 per 1000 users) on a MySQL DB. per 1000 users.
I am pretty sure that, with a shared group, all data is shared between
users.
Yes. But each individual user can retrain on his details and dspam then
takes the user's tokens into account when adjudging messages. So that
each individual user gets to tell and lusers who don't reckon their *ss
from their t*ts benefit too.
So, [EMAIL PROTECTED]:shared:* would be wrong - you
would have generalgroupnameforreference:shared:*. I think.
generalgroupnameforreference would then be created, and you can check
him out in the WebUI. I think - never used one (a shared group).
I've never used the webui, so I don't know how it deals with a shared
group (my users get their own messages into their IMAP mailboxes,
whether it's spam or not - maildrop routes spam into their quarantine
folder and then they can resubmit it for training if necessary), but
that's the general gist of it.
--Tonni
--
Tony Earnshaw
Email: tonni at hetnet dot nl
