229079 - Junk flag status lost when mail moved into another folder

Status: RESOLVED INVALID

(Thunderbird :: Mail Window Front End, defect)

Description

[Travis Saling]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031119 Firebird/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6b) Gecko/20031119 Firebird/0.7+

After training the junk filters for a while, I decided to start letting
Thunderbird move junk into a new folder. It's quickly become obvious, though,
that when the messages are moved they do not retain their "junk mail" status
setting.

This appears to happen with every message that is moved into the "Junk" folder.

This looks as if it should be a duplicate of #191750 - but that one was marked
as "resolved" on 10/29, so I've opened a new ticket.

Reproducible: Always

Steps to Reproduce:
1. Turn on Thunderbird option to "move incoming messages determined to be junk
mail to...".
2a. Wait for a piece of spam to come in and get identified as junk; OR
2b. Manually mark a piece of mail as junk.
3. View the status of the message in the Junk folder - it will not have the junk
flag set anymore.

Actual Results:  
Mail moved into the junk folder has its junk flag cleared.

Expected Results:  
Mail moved into the junk folder should still have its junk flag set.

Comment 1

[Travis Saling]

Oops, sorry, I forgot to include:

Build is Mozilla Thunderbird 0.4 (20031205), on Mac OS X 10.3.2

Comment 2

[Scott MacGregor]

it's quite possible your imap server does not support custom flags and that's
why this does not work for you. If that's the case, not much we can do for you.

Works here for me on courier, not that you want to hear that :)

Comment 3

[Travis Saling]

Hmmm... I'm at the University of Washington in Seattle, and I'd assume that
we're running the UW IMAPD. If I telnet into port 143 I see this (note that I
can't actually log in without SSL):

* OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS LOGINDISABLED AUTH=GSSAPI]
mailer53.u.washington.edu IMAP4rev1 2001.313-UCS2 at Sat, 20 Dec 2003 22:42:52
-0800 (PST)

I just tried the following. I went to a second computer (Windows this time),
called up Thunderbird and logged into the same account as this Mac is currently
logged into. Then on this Mac I flipped the junk flag on a single message. When
I next hit "get mail" on the Windows computer, the junk flag for that message
flipped. Could that happen if the server didn't support custom flags?

Comment 4

[Scott MacGregor]

no that sounds like it supports custom flags then.

Comment 5

[Travis Saling]

I have found that this bug report is probably invalid. After noting that
Thunderbird handled this circumstance correctly when I used a different IMAP
server, I asked our UW mail gurus about the problem and got the following reply:

--

This problem appears to be an issue with the version of one of the modules
used in the UW mail server. I've included the note from one of the system
administrators about the problem:

-- begin note --

I believe that's a bug in the mbx module.

User defined flags are enumerated in the folder header, it stores
a list of their names.  The order they're stored in turns into an
index number that is used in the message internal headers - when
one of those flags is set or cleared for a particular message, the
bit corresponding to that index number is set or cleared, in the
user defined flags field.

If you have two folders with user defined flags, the odds are not
good that the flags will accidentally happen to be listed in the
same order, because flags are added to the list as required.  It's
not possible to assign some pre-defined order to them precisely
because they're user-defined and hence unpredictable.  Therefore,
in order to preserve the meaning of the flag bits, the transfer
operation must recalculate the index, and of course add any flags
that don't already occur in the destination folder.

The mbx module version we're using doesn't do all that.  FIR does it,
and later versions of MBX may do it.

-- end note --

Comment 6

[Mike Cowperthwaite]

=>Invalid per reporter's comment 5.
Travis Saling, please reopen if you determine there is a problem in TB.