On Fri, 30 Apr 2010 09:48:41 -0400
Ed Szynaka <[email protected]> wrote:
> Yes that's how the README lists it as well. The only reason I tried the
> variations was to attempt to get the debug to let me know the user would also
> check the group. I attempted the group name as the same as the corpus
> username
> to see if it worked similar to merged groups.
>
Merged and shared groups use the groupname for internal processing.
Classification groups don't do anything with the group name.
> Mostly I tried the variations because the syntax for merged groups makes more
> sense to me.
>
In merged groups that makes sense. Right. In a global group it is completely
different. Let me explain:
groupname:grouptype:groupmember
groupname is the name of the group
grouptype is either "merged","shared","shared,managed","inoculation" or
"classification"
groupmember is a list of members separated by ","
for classification group (aka: "classification") you can turn the group into a
global group by using a "*" prefixed member name. Doing that transforms the
classification group (aka: classification network) into a global group.
A normal classification group lists members in the memberlist AND you have to
be one of them to be part of that classification network.
A global group is active FOR ALL users of the system and the member(s) ("*"
prefixed) in the memberlist is/are used when a user has less than 1000 innocent
messages or 250 spam messages AND the message is either SPAM or HAM and the
confidence is below 65% (aka: 0.65). Then DSPAM will consult the global group
members and query their data to get an score.
> I'm still not quite sure what the reasoning (if any) there is
> behind the Global Group name.
>
It is almost like an merged group but only kicking in under certain conditions.
> And the merged group syntax appears to allow for
> adding some users to the group where the Global Groups syntax only allows
> adding
> all users to the group.
>
Yes. That is. GLOBAL = for ALL.
> Any help would be greatly appreciated. Merged groups do appear to be doing
> an
> okay job but are less than ideal solution.
>
Why? Can you explain what you find not so good about merged groups?
> I'll probably be working on doing a
> second check against the corpus user instead of using the merged group today
> since it'll allow me to implement the low confidence corpus check instead of
> always merging in the corpus data.
>
Aha. I see.
> Again thanks for taking a look at this,
>
Well... it was anyway time to look at it and try to fix that broken thing.
> Ed
>
--
Kind Regards from Switzerland,
Stevan Bajić
------------------------------------------------------------------------------
_______________________________________________
Dspam-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspam-user
