Closed Bug 413320 Opened 17 years ago Closed 17 years ago

Feature request: centralize junk mail filtering on one client when sharing an account with multiple clients

Categories

(Thunderbird :: Preferences, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 208197

People

(Reporter: michael.mess, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.13pre) Gecko/20071022 Ubuntu/dapper-security Firefox/1.5.0.13pre
Build Identifier: 

We use one imap account with multiple clients.
Currently we have junk control enabled for each client.

The following problems arises from that:
* Sometimes mails are being marked and moved as junk in error (false positive).
  This could happen if someone hit a mail as junk accidently.
  If that person didn't notice that accident, his mail client keeps on moving 
  mail to Junk, and nobody knows which mail client is doing that.
  It is hard to track down which client is responsible for that.
* Sometimes junk mails are marked as junk, but not moved to the junk folder.



Reproducible: Sometimes



Expected Results:  
A solution for that problem would be:
One client, let us call it "Junk Master", has to be configured in the junk mail settings to do the following tasks:
 * move mail detected to be junk to junk folder.
 * move mail marked as junk to the junk folder and learn from that: This is Junk.
 * move mail from the Junk folder which is not marked as junk back to the inbox and learn from that: This is not junk.

On the other clients Junk mail control has to be turned off.
Then if you see junk mail, you just mark it as junk with your client and leave it there and let the Junk Master move it for you. Then the Junk Master learns how to detect Junk mail.
If you find a false positive (Mail moved to Junk-folder which was not really Junk), you just mark it as Not Junk and leave it there and let the Junk master move it back to the inbox for you (It will learn from that).
I think bug 208197 covers as much of this as will ever get implemented, the rest if just about what conventions and settings you set up.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
Currently we have that problem that in our common imap mail folder often junk mail is marked as junk but not moved to the junk folder.

When there are mails marked as Junk in the inbox or mails which are not junk in the Junk folder, nothing happens, even when junk mail controls is configured to move junk mail.

Most people have junk mail control configured to move Junk away, but when junk arrives, only one client learns from it when the user markes it as junk.
Thus if the same junk mail arrives again, the mail might stay untouched, if not the client which knows it already finds it first. 
When a message is already marked as junk and not moved, no client will move it away automatically.
When running Junk mail control on the folder containing much junk, some of the junk mails get unmarked as junk as the client don't know them. Only the mails which the client knows to be junk are moved away.

As we are getting plenty of junk mails, the folder gets filled up with junk mails that are already marked as junk, but not moved.
Thus we have to do much work manually for moving junk away to avoid that our good mails become like needles in a haystack.

Just turning on "move messages to Junk folder" in the configuration doesn't help as it processes only messages which have just arrived and not been touched by another client .
When implementing the Junk Master configuration it is necessary to search the whole inbox and junk folder for messages which do not belong there because of their Junk status and learn from them (training.dat) before running junk mail control on the folder to find other junk.

The goal is that we have only one client which sorts out Junk and maintains its training.dat (Junk Master) while the other clients just mark messags as Junk or Not Junk manually by user interaction and thus teach the Junk Master.
You need to log in before you can comment on or make changes to this bug.