On Sat, 7 Aug 2010 15:30:04 +0200 (CEST)
"Imposit.com - webmaster" <webmas...@imposit.com> wrote:
>
>
> | DSPAM 3.9.0 had totally messed up and wrong working group support. We
> | got that fixed:
> |
>
> Is that the reason for the following error:
>
> My fresh dpsam database with osb
> oen regular training user dspam
> group: dspam:shared:*
>
> incomming mail to user can be retrained in his history - not a valid signature
>
> (i wanted to use shared for a short time to bring up traings as fast as
> possible because of the new database)
> i set back to merged and the issue was gone
>
btw: what is bad at the documentation? I ask because IMHO the documentation is
not badly describing how shared groups work:
------------------------------------------------------------------------------
SHARED
Enables users with similar email behavior to share the same dictionary
while still maintaining a private quarantine box. The benefits of this
type of group are faster learning, and sharing a single spam alias. Shared
groups can have both positive and negative effects on accuracy. If a shared
group consists of users with similar, predictable email behavior, the users
in the group can benefit from a larger dictionary of spam and faster
learning (especially for newcomers in the group). If a group consists of
users with different email behavior, however, the users in the group will
experience poor spam filtering and a higher number of false positives.
NOTE: The SQL-based storage drivers support shared groups, but has one caveat:
If you are NOT enabling "virtual users" support, you will need to create
an actual user on your system named after each group you create.
On top of shared group support, a shared group can also be made to be
'managed'. Using the group type 'SHARED,MANAGED' will cause the group to
share a single quarantine mailbox which could be managed by the group's
administrator (aka: the group name). This would enable one individual to
monitor quarantine for the entire group, however personal emails marked as
false positives could potentially be viewed as well. For this reason,
managed groups should only be used when this is not an issue.
NOTE: Use the dspam_stats tool to keep an eye on the effectiveness of
shared groups. If a shared group experiences poor performance, find
the users whose email behavior is inconsistent with that of the group
and remove them from the group.
The format for a shared or shared,managed group is:
group1:shared:user1,user2,userN
group2:shared,managed:user1,user2,userN
group3:shared:*...@domain.tld
group4:shared:*
The group name (in the example above 'group1', 'group2', 'group3', 'group4')
can be anything you like. If you set the shared group to be managed then the
groupname (in the example above 'group2') will be used by DSPAM as the shared
group administrator.
The user/member list for shared group allows the following syntax:
user1 : Exact match of user with the name "user1"
* : Match any user
*...@domain.tld : Match any user having '@domain.tld' at the end of ther
username. The matching only works for the '@' character.
You can not use something like '*user' to include user
'infouser', 'testuser', 'dummyuser', etc.
------------------------------------------------------------------------------
--
Kind Regards from Switzerland,
Stevan Bajić
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
Dspam-devel mailing list
Dspam-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspam-devel
