[Dovecot] Thunderbird or Dovecot bug? (multiple keywords)
Here's a strange one. I have a user who's using Thunderbird 2.0.0 and assigning multiple tags (keywords) to emails, which are getting "lost" (I'll explain) when he leaves the folder and comes back. I can reproduce this on *his* account myself, but cannot reproduce it on *my* account (separate new TBird 2.0.0 profiles on Windows XP).
Use the two TBird default tags 'Important' and 'Work' for all these tests, which it refers to as $Label1 and $Label2 in IMAP-keywords land. If I go into my account, label an email with both tags, it sticks -- I can click on Drafts then back to Inbox, and both tags/keywords still show in the client.
If I go into his account, add the two tags, then click on Drafts and back on Inbox, only the *second* tag (Work, $Label2) shows. If I remove that tag, then the first tag (Important, $Label1) immediately pops up!
On the backend the actual Maildir files match the dovecot-keywords and have the correct letter appended in both cases - so, in his account when the email only shows one tag, the physical mail file has the letters for two tags. So Thunderbird should be showing both tags, like it does in my account where everything is working correctly.
This leads me to believe that the problem has something to do with the difference of dovecot-keywords content, and the interaction TBird has with Dovecot. My account, working correctly, looks like:
dovecot-keywords: 0 $Forwarded 1 $MDNSent 2 $Label2 3 $Label1
file: Maildir/cur/1178712608.H529732P11686.yak.fluid.com:2,RSdc
...which matches, d=$Label1 (Important), c=$Label2 (Work) and TBird is displaying the email as having both tags - all is well and good. Now, his account looks like:
dovecot-keywords: 0 Junk 1 NonJunk 2 $Label4 3 $Label1 4 $Label2 5 $Label3 6 $Label5
file: Maildir/cur/1178728930.P28392Q0M960111.yak.fluid.com:2,RSbde
...again, everything matches on the server; yet, it Thunderbird is only displaying $Label2 (d,3). I also noticed something interesting, even if I have the TB 'Junk Controls' completely disabled on his account, and remove all tags using the menu option, that file still retains the 'b' (NonJunk) tag in the filename:
Maildir/cur/1178728930.P28392Q0M960111.yak.fluid.com:2,RSb
All this long-winded explanation leads me to believe that somehow the difference in dovecot-keywords is causing this problem, but what I can't tell is who's problem it is -- Dovecot, or Thunderbird?
Thoughts welcome, -te
PS: all the normal things tried like deleting the dovecot index files, Thunderbird cache files and profiles, etc.
-- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com
On Wed, 2007-05-09 at 12:01 -0700, Troy Engel wrote:
All this long-winded explanation leads me to believe that somehow the difference in dovecot-keywords is causing this problem, but what I can't tell is who's problem it is -- Dovecot, or Thunderbird?
A lot easier way is to look at the IMAP traffic and see what's different in there. Then you can see if Dovecot is giving wrong replies somewhere or if it's Thunderbird that gets confused from something.
Timo Sirainen wrote:
A lot easier way is to look at the IMAP traffic and see what's different in there. Then you can see if Dovecot is giving wrong replies somewhere or if it's Thunderbird that gets confused from something.
I just used the TB debugging to trap all the IMAP traffic capturing a good session (my account) and the troubled session (his account) using the same WindowsXP 2.0.0 client.
Session: a) add $Label1 b) add $Label2 c) select INBOX.Drafts d) select INBOX e) remove $Label2 f) remove $Label1
Alas, I can't spot where the problem is in the conversation; can I zip up both logs and send to you? (they're pretty large and contain some private info)
-te
-- Troy Engel | Systems Engineer Fluid, Inc | http://www.fluid.com
On Fri, 2007-05-11 at 11:50 -0700, Troy Engel wrote:
Session: a) add $Label1 b) add $Label2 c) select INBOX.Drafts d) select INBOX e) remove $Label2 f) remove $Label1
Alas, I can't spot where the problem is in the conversation; can I zip up both logs and send to you? (they're pretty large and contain some private info)
Looking at the logs, the only difference is that in the working case the $Label2 is returned before $Label1, and in the broken case it's vice versa.
You could try if the attached patch helps, but looks like this is a Thunderbird bug if it relies on the order of the returned keywords.
participants (2)
-
Timo Sirainen
-
Troy Engel