196905 - With Junk Control set to auto-move junk mail to Junk folder, there is no obvious way to undo incorrectly moved messages.

Status: RESOLVED DUPLICATE of bug 207389

(MailNews Core :: Filters, defect)

Description

[Thomas Wolf]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210

I have junk mail controls set to move messages identified as junk to the local
Junk folder.  Every now and then, the algorithm makes a mistake (actually,
recently it has not been all that seldom) and incorrectly identifies something
as junk and moves it to the Junk folder.  But in the "Junk" folder, the messages
no longer have the "Junk icon" shown at the right, so how do you tell the system
about its error and move the file back to the Inbox?  The only thing I've been
able to do is manually move them.  And sometimes the system just moves them
right back again!

Reproducible: Always

Steps to Reproduce:
1. Go to Junk folder and try to identify something as not being junk!


Actual Results:  
There is no good interface for "unmarking" something.

Expected Results:  
Serveral possibilities.  One would be
In Junk folder, all messages should, by default, have the Junk
icon set.  If someone marks message(s) as "not junk", the message
should be returned to whence it came.  And Mozilla should no longer
evaluate that message as junk again.



Although I'm not currently running the most recent build, this has been
a problem in them as well.

Comment 1

[Alonso Acuña]

I've been running a build from around march 09 and it has that problem. I have
it move junk from my IMAP account to the local Junk folder. I guess the "junk
status" is lost when moving from IMAP to local. What I would like to know is if
when the junk status is lost Mozilla keeps that message's text in it's junk
words database (or whatever you call it). If it does then it's a big deal
because it thought it was junk and now there's no way to tell it otherwise. This
happens to me daily now, it seems to be getting worse with time.

Comment 2

[Thomas Wolf]

Oh, Alonso mentioned that he's using an IMAP server - so am I, in case
that is relevant.

Comment 3

[Jason M. Abels]

This has happened to me, using the Thunderbird builds of Mozilla Mail. The icon
seems to disappear for some new messages, but not necessarily all. This happens
whethere I manually move them or automatically move them. I've been forced to
turn off automatic movement because of this, so I can "unjunk" good messages.

Maybe this function shouldn't be a toggle. That way you could specify it as
either junk or non-junk, no matter what mozilla mail currently thought of it.

Comment 4

[(not reading, please use [e-mail] instead)]

mass re-assign.

Comment 5

[Neil Bird]

Used to be that mail I received that Moz determined was junk got moved to Junk
*and* tagged as junk;  with 1.4x it's only being moved, not tagged, so the
mechanism for teaching the filter that it's not junk is questionable as you have
to tell it it *is* junk first ...

Win32, using IMAP.  I'm fairly sure that 1.3 functioned correctly using IMAP,
but I've only recently started using IMAP in lieu of POP so it *may* be that
this was working OK when fetching via POP.

Comment 6

[Daniel Brooks [:db48x]]

You can always right click on the message and choose Mark > As Not Junk before
you move it. That's what I do when it happens. Just remember that you have to
keep marking your new mail that isn't junk as Not Junk in order for it to stay
perfectly trained.

As for the bug, I'm fairly certain that this is because IMAP servers don't keep
the flags when moving messages. According to the mailing list for the IMAP
server I use (bincimap), this is being worked on. Once that's done I expect this
problem to go away for me, which should be a good way to tell if that's the problem.

Comment 7

[Jason M. Abels]

Based on comment #6, it appears the problem is with IMAP, and not with mozilla.

Comment 8

[Thomas Wolf]

I am now running 1.4 (06/24 build) and the problem doesn't appear to exist
anymore: it still moves stuff identified as "Junk" to the local junk folder,
but now in the local Junk folder, all the msgs have the Junk icon set (before,
they didn't.)

Comment 9

[Neil Bird]

Still not working correctly for me - Moz 1.4, Win32 (W2K), IMAP Inbox+Junk. 
Junk's being identified, moved to Junk, but not retaining it's 'Junk' status/icon.

Can't see that it's IMAP, as IIUC the 'junk' etc. flags are stored my Moz. in
the local .msf files, although I guess Moz. /could/ be putting them in some sort
of IMAP user data field and expecting the IMAP server to move that around as well.

Hang on - who closed the bug?

Comment 10

[Jason M. Abels]

Well, the bug definitely shouldn't be *closed*. I marked it invalid, but that
may be a mistake.

Still, we rely on the IMAP server to store flags. It stores the read flag. And
yes, we do store in the .msf file as well (I think!). But, when the mail gets
moved, it's not stored across the move, by either one. 

Comment 11

[Thomas Wolf]

Sorry - I was the one that *closed* the bug - since I no longer have the
problem for which I opened this bug.  I DO now see the Junk flag set
in the Junk folder for messages that were auto-moved from my IMAP server.

tom

Comment 12

[nigel arnot]

To add to the above, am also experiencing this problem, again with IMAP server 
(and junk folder on that server).

Could I suggest as a work-around that ALL mesages in the folder chosen to 
automatically move junk to should be treated as junk, to the extent that the 
button displayed in the big button-bar at the top should be "Not Junk" rather 
than "Junk", regardless of the state of the flag on the message? 

It makes quite a bit of difference for training your filter. When it makes 
mistakes, quite often you want to say "Not Junk" then "Delete" because you've 
read it and it's not for keeping, but you do want to want to retrain your 
filter.

Comment 13

[Vaclav Dvorak]

This seems to be a duplicate of bug 207389, or vice versa. The other one has
more CC's and votes and a better summary, but this one has more comments...
Choosing to dupe this one, but feel free to reverse that. :-)

*** This bug has been marked as a duplicate of 207389 ***