Bug Tracker item #2836838, was opened at 2009-08-13 12:38 Message generated for change (Comment added) made by whyscream You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126467&aid=2836838&group_id=250683
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: daemon Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: The Duck (duck207) Assigned to: Stevan Bajic (sbajic) Summary: group retraining does not update the right log/stats Initial Comment: Using the GIT version b62513e (quite recent), i added a shared group. Mail logs shows up properly in the user webui's history, but retraining does nothing. I fact, i activated debug logs, and found the retraining was perfectly working, But, as it uses signatures, the user is then switched to the global user for learning, and never switched back to the real user later. This results in logs and stats not being updated properly for the right user, and users then think nothing happenened, as nothing changes in the webui. Attached is a small fix which is working nicely for shared groups. It should not interfere with configurations without groups, but i'm not totally sure it would behave properly for all other types of groups. ---------------------------------------------------------------------- >Comment By: Tom Hendrikx (whyscream) Date: 2011-08-18 00:04 Message: This problem is still true now. I use a shared group for all users, contents of group file is like this: globaluser:shared:* All incoming e-mails are logged to user.log under the actual users' dir in /var/spool/dspam/data, which is correct. But when someone retrains a message, this is written to the logfile of 'globaluser', which is a bug and a privacy problem. ---------------------------------------------------------------------- Comment By: The Duck (duck207) Date: 2010-09-29 14:20 Message: I can confirm this for GIT version b62513e, but as i don't have this architecture in charge now, i won't be able to test fixes, sorry. That's what my patch tried to fix, but i may have fucked up the shared stats in the process. ---------------------------------------------------------------------- Comment By: Stevan Bajic (sbajic) Date: 2010-05-17 20:38 Message: > Ho, i forgot part of the reply: yes, each person has its own directory > under DSPAM_HOME. And they need it to hold all the private information > about their own mails. > If I understand you right then a retraining of a message does not update their history/quarantine. Right? If that is the case then this is definitely something that should be fixed. Can you confirm that a retraining does not update the history/quarantine of the user initializing the retraining? > I'm not using this setup anymore, as my company decided to move to another > (bloated) solution, but i'll try to help as much as possible with my > souvenirs, as i think it is a very useful mode. ---------------------------------------------------------------------- Comment By: Stevan Bajic (sbajic) Date: 2010-05-17 20:36 Message: > The shared group mode seems to be intended to share learning among a group > of people having the same kind of wanted HAM, like in a company, so they > benefit from the training made by everyone, increasing accuracy rapidly. > Well... shared groups are not only for HAM. They affect both HAM and SPAM training. > The current behavior is to learn using the shared group, which is fine, but > normal users don't have access to it, and so cannot have access to any > stats. > That is right. > What is more problematic: a user can see its own mails, retrain, but > is unable to see any result on its own view, and then unable to know what > was already retrained, or even cancel a mistaken retraining. > Yeah. That is true. The whole shared group thing is tricky. All users of a shared group share THE SAME tokens. So any retraining done is done FOR ALL members. And there is the problem. A user (lets call him John Doe) does retraining and he is affecting the statistics FOR ALL members of the shared group. So the update to the statistics has to be updated on the shared group while still the status inside the history should be only updated for John Doe. For sure John Doe does not want to share his quarantine and/or history view with others. But there is now way to hide the statistics of the whole shared group from the other members. Hiding the statistics from the other members would invade the purpose of the shared group. > I think you miss the point in understanding the shared group mode. if > people want to share training, they absolutly don't want to share the email > view, their private emails, or anything related, but should be able to > manipulate them themself without any right on the shared group itself. > That would then not be anymore a shared group. I mean how is one supposed to benefit from a shared group training without having any right to write/read the shared group data? I do understand the purpose of hiding the quarantine and/or the history. But the statistics can not be hidden from the other members. Doing that hiding would be wrong. > So > it's a bit tricky because all the training operations must occur on the > shared group, but the history, quarantine, and stats must stay private. > Yes. That is true. History, quarantine must stay private BUT statistics CAN NOT stay private. That is not possible. I mean in that moment where someone is retraining he/she is influencing the statistics for all members of the shared group. You can not keep that statistics private. It is just not possible in shared group mode. > Nevertheless, the shared group manager should be able to see global stats, > and perhaps correct mistakes (if the privacy policy allows it). But this is > another problem not discussed here. Maybe a shared group is not the right approach for your needs? Maybe something like a inoculation group is a better group model for your needs? ---------------------------------------------------------------------- Comment By: The Duck (duck207) Date: 2010-05-17 20:20 Message: Ho, i forgot part of the reply: yes, each person has its own directory under DSPAM_HOME. And they need it to hold all the private information about their own mails. I'm not using this setup anymore, as my company decided to move to another (bloated) solution, but i'll try to help as much as possible with my souvenirs, as i think it is a very useful mode. ---------------------------------------------------------------------- Comment By: The Duck (duck207) Date: 2010-05-17 20:16 Message: The shared group mode seems to be intended to share learning among a group of people having the same kind of wanted HAM, like in a company, so they benefit from the training made by everyone, increasing accuracy rapidly. The current behavior is to learn using the shared group, which is fine, but normal users don't have access to it, and so cannot have access to any stats. What is more problematic: a user can see its own mails, retrain, but is unable to see any result on its own view, and then unable to know what was already retrained, or even cancel a mistaken retraining. I think you miss the point in understanding the shared group mode. if people want to share training, they absolutly don't want to share the email view, their private emails, or anything related, but should be able to manipulate them themself without any right on the shared group itself. So it's a bit tricky because all the training operations must occur on the shared group, but the history, quarantine, and stats must stay private. Nevertheless, the shared group manager should be able to see global stats, and perhaps correct mistakes (if the privacy policy allows it). But this is another problem not discussed here. ---------------------------------------------------------------------- Comment By: Stevan Bajic (sbajic) Date: 2010-05-13 22:09 Message: Correct me if I am wrong but are shared groups not supposed to act that way? All users from a shared group share the same tokens, statistics, etc... so if a user from a shared group does the training then the statistics should be updated for the shared group name and not for the user doing the training. Right? I never played around with shared groups. Anyway... can you answer me some things regarding shared groups? Assuming I have this in my group file: shgroup:shared:ste...@bajic.ch,anot...@user.net Does then "ste...@bajic.ch" have his own directory under DSPAM_HOME? With all the stuff like .stats, .rstats, etc? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1126467&aid=2836838&group_id=250683 ------------------------------------------------------------------------------ Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 _______________________________________________ Dspam-devel mailing list Dspam-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspam-devel
