User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Build Identifier: version 1.5.0.8 (20061025) At one point on 2006/Nov/09 ThunderBird informed me that a new e-mail had been received. The mail folder in the tree showed 1 new e-mail, but no new mail could be found inside the actual folder's messages list. Normally I blame the Mail Summary File, delete it, and be on my happy way - but that did not fix anything. After hours of poking at things, it appears that the issue is related to the "Message-Id" and "References" mail headers. Specifically, if they are the same value and the mail does not appear first in the mailbox file, the message is not displayed in the list. Just to re-iterate, this is not about the message itself not displaying - I can't even get that far because the message is never shown in the messages list. Reproducible: Always Steps to Reproduce: Create a mailbox file with the following fairly minimal content in the Profile mail folder, start Thunderbird, and see if the message "Exhibit B" is displayed in the messages list. Here it is not. ===== From sales@example.com Wed Nov 08 22:18:06 2006 Message-Id: <200611082118.kA8LI6WP044656@example.com> References: <200611082118.kA8LI6WP044656@example.com> Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain MIME-Version: 1.0 Date: Wed, 8 Nov 2006 21:18:06 UT From: sales@example.com To: john.doe@example.com Cc: example@example.com Subject: Exhibit B Exhibit B ===== Actual Results: The second message, "Exhibit B", is never shown in the messages list. Expected Results: I would expect "Exhibit B" to show up so I can actually read my e-mail :) Removing the "Message-Id" header solves the issue. Removing the "References" header does not solve the issue. Modifying the value of the "Message-Id" header solves the issue. Modifying the value of the "References" header solves the issue. Modifying the values of both the "Message-Id" and "References" headers to both have the same, albeit a different from original, value does not solve the issue. Although there is no actual data loss (unless you compact the folders), for all intents and purposes the casual user may effectively not be 'getting' their e-mail. So I'm setting the Severity to Major, even if for myself it is rather more of a Critical level.

Correction to mailbox file - paste error - my apologies ===== From sales@example.com Wed Nov 08 22:18:06 2006 Message-Id: <200611082118.kA8LI6WP044656@example.com> Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain MIME-Version: 1.0 Date: Wed, 8 Nov 2006 21:18:06 UT From: sales@example.com To: john.doe@example.com Subject: Exhibit A Exhibit A From sales@example.com Wed Nov 08 22:18:06 2006 Message-Id: <200611082118.kA8LI6WP044656@example.com> References: <200611082118.kA8LI6WP044656@example.com> Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain MIME-Version: 1.0 Date: Wed, 8 Nov 2006 21:18:06 UT From: sales@example.com To: john.doe@example.com Subject: Exhibit B Exhibit B ===== Further information: If you swap Exhibit A and Exhibit B in the mailbox file, both messages display just fine.

I can generally reproduce this (with TB 2b1-1109, SM 1.5a-0925), except: (In reply to comment #0) > Removing the "References" header does not solve the issue. This does cause both messages to be listed for me; are you sure you rebuilt the .MSF properly when testing this case? What program generated the original faulty message?

The original 'faulty message' (could you explain what is faulty about it?) is generated by the Cerberus Helpdesk software; Cerberus Helpdesk v. 2.7.0 (beta) I can confirm that removing the "References" header in my example -does- actually cause both messages to be displayed. The original mailbox file must have had another instance of such a mail message in it that was causing my earlier test result. Thanks for confirming

(In reply to comment #3) > (could you explain what is faulty about it?) A message shouldn't be referencing itself -- the reference header should contain the id of the message being responded to.

somehow I suspected that was what you meant. I'll talk to our IT dept about that bit. That said, I take it this shouldn't be causing thunderbird to flake out? ( I can see how it might if it was a threaded view, if threaded views take advantage of those headers. )

For what it's worth - this seems to just be an issue recently. I have e-mails that have this malformation dating back years. I can't say 100% for sure, but I only noticed this issue after the semi-automatic update to Thunderbird 1.5.0.8

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