516604 - run junk mail controls on folder marks all messages as junk

Status: RESOLVED DUPLICATE of bug 383873

(Thunderbird :: General, defect)

Description

[brandt24]

User-Agent:       Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4pre) Gecko/20090914 Shredder/3.0b4pre

I added a new IMAP account to TB. I noticed a couple of messages that were junk and instead of checking them manually I ran the junk mail controls on that folder. Now all of my messages got marked as junk and were (luckily!) moved to the Junk folder. I can only imagine if I had chosen to have junk messages deleted instead.

Reproducible: Didn't try

Actual Results:  
I would have expected it to mark only the obvious junk as junk and leave my years worth of corresponce intact.

Comment 1

[Kent James (:rkent)]

The design of the junk UI in TB does not really provide any good feedback to the user encouraging them to train good messages. The only thing that is there (and this was added before I was involved, and I have not changed it) is to mark everything as junk when a user has only trained junk messages, and not good messages. The inevitable result of that is what you experienced, and I agree it is far from optimal, and even dangerous.

With TB3 so close to release, this is not like to change for TB3. As for me, I hope to do a lot of experimenting with possible fixes to this kind of problem in my JunQuilla extension (though the current experimental release does little for this). Perhaps in the future some of the JunQuilla features will also migrate to core.

Comment 2

[brandt24]

I just don't understand why it decided to mark ALL of my messages as junk? As you said something like this can be very dangerous...

Comment 3

[Kent James (:rkent)]

It marks ALL of your messages as junk, because the command "run junk mail controls on folder" analyzes the junk status of ALL messages in the folder. The current junk message backend will classify any message as junk, if only junk messages have been trained. Once you train even a few messages as good, that will no longer happen.

Comment 4

[brandt24]

Ok, I see, at that point I had not trained a single message.

Comment 5

[Ludovic Hirlimann [:Usul]]

Kent shall we close invalid ?

Comment 6

[Kent James (:rkent)]

No, I think the reporter has a legitimate complaint. Within the current junk training model, one possible resolution would be to disable "run junk controls on folder", and also "delete" of junk messages, until a minimum number of messages have been trained for good and junk. The correct long-term solution is some method of training good messages that does not require that some good messages be marked as junk to "encourage" the user to train some good messages.

Comment 7

[Ludovic Hirlimann [:Usul]]

Couldn't we provide an empty or so db from which training would pick things up ?

Comment 8

[Kent James (:rkent)]

Sorry, I don't understand the suggestion. By "db" do you mean the internal message hdr database, or an external source of trained messages?

With JunQuilla, I want to experiment with having a small corpus of "good" training that would just be a list of common words, and a small corpus of "junk" training that would be a summary of existing junk corpus information. That could be used as an initial training corpus for TB, and eliminate the immediate symptom of this bug. But the underlying problem is a central contradiction in the junk management of TB, that users are only encouraged to train good messages when they are falsely classified as junk, yet the ideal (even the requirement of the delete junk model) is that no good messages are ever classified as junk. We need a solution for that, which is some method of automatically training messages as good.