I hope you will indulge this posting to the dev list as it really is more a dev matter than a using matter. I was going to file a bug about this but I thought it warranted some discussion first.
My issue is with how Junk is handled in conjunction with the markasjunk[2?] plugin(s).
As you know, with the markasjunk plugin, when you press the junk button it moves the mail message to the $rcmail_config['junk_mbox'] (i.e. Junk by default).
But that does not recognize that there are two types of junk: the mail that the mail system determined is spam (let's call this tagged spam) and wants to quarantine for the user to sift through for false positives[1]. The other type of "Junk" is the spam that the mail system did not determine for the user (let's call this untagged spam) and that the user wants to tell the mail system is spam so that it can learn.
So the user needs two folders for these different types of messages, for a couple of reasons. First reason is that it's a waste of the users time to put the untagged spam into the same folder that is meant to be the folder that the user to sifts through to find falsely tagged spam. Secondly, the user does need a folder to put untagged spam so that the mail system has somewhere it can go get messages that the user wants it to use to learn about what spam is. And this folder shouldn't be same folder that the tagged spam has gotten put into since we don't want/need the mail system to learn from messages it's already tagged as spam.
On my system here those two folders are "Junk" and "spam" (respectively). Mail that has the X-Spam-Flag header set to "YES" is put into "Junk" (and does not need to be used to learn about spam from) and messages that are in the user's INBOX that are actually spam should be moved to "spam". A process on the mail system goes through the "spam" folders of all of the users and pushes those messages through the spam-learning process.
Am I going about this all wrong? Does anyone else see the need for two different folders (three if you bring the "ham" into the discussion) for spam processing?
Cheers, b.
[1] One must have one of these folders lest risk throwing out the occasional non-spam message without the user's consent/knowledge. This is where the user goes to look for that message that somebody says they sent but that the user never received.
--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/Eq/Uv9TvoDD/signature.asc Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---
List info: http://lists.roundcube.net/dev/ BT/aba52c80
Would it not be a better idea to use only 1 junk folder and use another indicator for user identied spam and system identified spam? I think this will be more clear for the user.
On Sat, Feb 25, 2012 at 11:26 PM, Brian J. Murrell brian@interlinx.bc.cawrote:
I hope you will indulge this posting to the dev list as it really is more a dev matter than a using matter. I was going to file a bug about this but I thought it warranted some discussion first.
My issue is with how Junk is handled in conjunction with the markasjunk[2?] plugin(s).
As you know, with the markasjunk plugin, when you press the junk button it moves the mail message to the $rcmail_config['junk_mbox'] (i.e. Junk by default).
But that does not recognize that there are two types of junk: the mail that the mail system determined is spam (let's call this tagged spam) and wants to quarantine for the user to sift through for false positives[1]. The other type of "Junk" is the spam that the mail system did not determine for the user (let's call this untagged spam) and that the user wants to tell the mail system is spam so that it can learn.
So the user needs two folders for these different types of messages, for a couple of reasons. First reason is that it's a waste of the users time to put the untagged spam into the same folder that is meant to be the folder that the user to sifts through to find falsely tagged spam. Secondly, the user does need a folder to put untagged spam so that the mail system has somewhere it can go get messages that the user wants it to use to learn about what spam is. And this folder shouldn't be same folder that the tagged spam has gotten put into since we don't want/need the mail system to learn from messages it's already tagged as spam.
On my system here those two folders are "Junk" and "spam" (respectively). Mail that has the X-Spam-Flag header set to "YES" is put into "Junk" (and does not need to be used to learn about spam from) and messages that are in the user's INBOX that are actually spam should be moved to "spam". A process on the mail system goes through the "spam" folders of all of the users and pushes those messages through the spam-learning process.
Am I going about this all wrong? Does anyone else see the need for two different folders (three if you bring the "ham" into the discussion) for spam processing?
Cheers, b.
[1] One must have one of these folders lest risk throwing out the occasional non-spam message without the user's consent/knowledge. This is where the user goes to look for that message that somebody says they sent but that the user never received.
--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/Eq/Uv9TvoDD/signature.asc Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---
List info: http://lists.roundcube.net/dev/ BT/0bf96065
List info: http://lists.roundcube.net/dev/ BT/aba52c80
Hi,
2012.02.26 00:26, Brian J. Murrell wrote:
But that does not recognize that there are two types of junk: the mail that the mail system determined is spam (let's call this tagged spam) and wants to quarantine for the user to sift through for false positives[1]. The other type of "Junk" is the spam that the mail system did not determine for the user (let's call this untagged spam) and that the user wants to tell the mail system is spam so that it can learn.
So the user needs two folders for these different types of messages, for a couple of reasons. First reason is that it's a waste of the users time to put the untagged spam into the same folder that is meant to be the folder that the user to sifts through to find falsely tagged spam. Secondly, the user does need a folder to put untagged spam so that the mail system has somewhere it can go get messages that the user wants it to use to learn about what spam is. And this folder shouldn't be same folder that the tagged spam has gotten put into since we don't want/need the mail system to learn from messages it's already tagged as spam.
It's probably a matter of personal taste, but I feel OK with the mail system simply not accepting messages that are clearly spam and prepending "***SPAM***" to the subjects of messages that look very much like spam, but could possibly be legitimate. None of that requires a separate folder. On the other hand, if you don't delete positives, there are two options:
- your filter is suspicious and marks most spam as spam. In this case,
there probably aren't that many messages for user to mark as spam manually, so even if you put them all in one place, the increase of work to find that important false positive won't be noticeable. 2) the filter is relaxed and the user marks more spam manually than the system does automatically. In this case, false positives are soooo unlikely that it's not even worth considering
And even if you don't fall into one of those categories, there's still another argument not to bother about two folders: the search field. The user can always use it to look for that particular ham message in the spam folder. All she has to know is (a part of) the sender address or the subject.
As for the second reason (learning), I think you could easily teach the system not to learn from messages that already have "X-Spam-Flag: Yes" or a similar header that it has set itself. In any case, with your setup, additional measures of preventing the system from learning from the same message again are needed: it has to either delete the messages it has learned from, or move them to another (third?) folder, or keep a track of them, or add a header to them and look for it next time. Either way, it's troublesome.
Add to it the fact that what one user considers spam, might be ham for the other (and vice versa) and such learning becomes even more complicated.
There is an alternative to having untagged spam learned from. Mark as Junk plugin allows you to specify commands to run with a message to teach spamassassin about (non-)spam. Why not use these?
On my system here those two folders are "Junk" and "spam" (respectively).
No offence, but to me, this distinction in names looks rather lame. If I saw those two folders next to each other, my first idea would be that there is/was a glitch/misconfiguration somewhere which resulted in this situation. On the other hand, "Junk (auto)" and "Junk (manual)" would be obvious enough.
Mail that has the X-Spam-Flag header set to "YES" is put into "Junk" (and does not need to be used to learn about spam from) and messages that are in the user's INBOX that are actually spam should be moved to "spam". A process on the mail system goes through the "spam" folders of all of the users and pushes those messages through the spam-learning process.
Am I going about this all wrong? Does anyone else see the need for two different folders (three if you bring the "ham" into the discussion) for spam processing?
Again, I think it's a matter of personal taste and perspective, but to me, your proposed set up looks more confusing than useful.
Best regards, Rimas _______________________________________________ List info: http://lists.roundcube.net/dev/ BT/aba52c80
I seem to have found a suitable solution to this problem owing at least slightly to a suggestion I got in response to my original posting.
The solution is to use a single Junk folder but alter my spam-training process to instead of learning from all messages in the Junk folder, to skip messages that are already flagged as spam (i.e. "NOT HEADER X-Spam-Flag YES" in IMAP search language).
Additionally, the messages which were used for learning (i.e. that were put there by the user) get deleted so the user doesn't have to sift through them as they look for false positives.
Much thanks for all of the input.
Cheers, b.
--- 8< --- detachments --- 8< --- The following attachments have been detached and are available for viewing. http://detached.gigo.com/rc/4N/wTxLbvw5/signature.asc Only click these links if you trust the sender, as well as this message. --- 8< --- detachments --- 8< ---
List info: http://lists.roundcube.net/dev/ BT/aba52c80
-
Brian J. Murrell -
Peter Overtoom -
Rimas Kudelis