Closed Bug 1100973 Opened 10 years ago Closed 3 years ago

When "Message-ID" custom header is set, subject is shown empty in message list and new mail alert popup

Categories

(Thunderbird :: Message Reader UI, defect)

31 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: peci1, Unassigned)

References

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141106120505

Steps to reproduce:

When I add "Message-ID: " to mailnews.customHeaders, some new emails (not all!) show empty subjects in the message list and in the new mail alert popup. If the subject starts with Re: or Fwd:, then only these prefixes are shown and the rest of the subject is left out. In the message view (the pane displaying the contents of the message), the subject is shown correctly.

I use some filters (none of which uses Message-ID) to sort mail into folders, and this bug only occurs in some of the target folders.

Repairing the affected folders helps for old messages, but new messages are still affected. This also means there is no problem with the source of the messages being crippled, because redownloading and reconstructing the messages again helps.

I haven't observed this behavior in TB 17. This is why I stayed for long with 17, and today I decided to find the culprit in 31. When I remove Message-ID from custom headers, new mails start behaving normally, whereas old mails don't change (if they had empty subject, they still have it). When I look in the message store folder, the file containing all mail in a folder contains both good and bad emails. However, the corresponding MSF file only contains subjects of good emails (I just did a string search).
IMAP? POP3?

If the mail is copied to local mail folder, is the mail shown as exected?
   Create a new folder, call FolderX, under Local Folders, copy the mail to FolderX, Repaair Folder of FolderX.

If IMAP, do you see problem when the mail is copied?
   Create a new folder, call FolderX, under the IMAP account, copy the mail to FolderX, Repaair Folder of FolderX.

An example email.
(i) Length of the Message-iD: is 82 bytes(including [CRLF]=0x0D0A). This is relevant? 
> <------------------------------------------------------------------------------------------- 80 bytes ---->
> Message-ID: <CALtTQa6J54dHW50pPiKwLBwZu84rDEYs1QC+jJ7PLCUoMi-PYg@mail.gmail.com>[CRLF]
> Subject: test21[CRLF]
(ii) Subject: is header just after Message-Id:. Is this common in mails problem occurs?
      Subject: header is eaten up by Tb 31?

If imap, message header is selectively requested by Tb.
  uid fetch xx body.peek[ headers(subject from ... message-id ...) ]
When "headers" is requested, server doesn't always return message header data as-is. Gmail IMAP is an example.
If header data returned to "body.peek[ headers(subject from ... message-id ...) ]" is different from header data returned to "body.peek[]", this kind of phenoenon occurs.
   When Subject: is encoded in special charseta and special char is contained, Gmail IMAP returned wrongly interpreted subject text
   as Subject: header data, so, subject shown at Thread pane != Subject in message header pane(from body.peek[] data), happened.
If imap, get imap log and check server response to "body.peek[ headers(subject from ... message-id ...) ]", please.
FYI.
https://tools.ietf.org/html/rfc5322#section-2.1.1
   two length limit in mail : 78 chars excluding CRLF, and 1000 chars including CRLF
I only use IMAP for my accounts in TB.

Unfortunately, as I've found the workaround (to delete Message-ID custom header from prefs.js), I was able to update all my TB installations and repair the folders in them. After doing that, I'm no longer able to reproduce this issue even when adding Message-ID again to prefs.js. 

So it seems that removing that custom header and repairing folders is a way to fix this problem. I don't know why.

If you've still been interested in an IMAP log, I can send you one where I operated with mails and folders that would surely suffer from this bug if it weren't fixed by the above workaround.
(In reply to Martin Pecka from comment #4)

"No custome header of Message-ID, re-fetch header" can produce one of next:
(1-a) No Messsage-ID in BODY.PEEK[ heaader.fields( Subject ...)], then bug of imap server won't occur.
(2-b) No Messsage-ID in BODY.PEEK[ heaader.fields( Subject ...)], so Messsage-ID heder, then bug of Tb won't occur.
"Re-addinf custome header of Message-ID after it, then re-fetch header" can produce one of next:
(2-a) Position of Messsage-ID in BODY.PEEK[ header.fields( Subject ... Messsage-ID)] is altered, then bug of imap server won't occur.
(2-b) Position of Messsage-ID in BODY.PEEK[ header.fields( Subject ... Messsage-ID)] is altered,
         so order of returned header is changed, then bug of Tb won't occur.

There is no need to send imap log. "Check log when problem ocurred using Text Editor by yourself" is sufficient.
(i)   If correct Subject: header data is retunrned to BODY.PEEK[ header.fields( ... Subject Messsage-ID Received ...)], Tb's bug.
(ii)  If wrong Subject: header data is retunrned to BODY.PEEK[ header.fields( ... Subject Messsage-ID Received ...)], Server's bug.
See Also: → 1323503

(In reply to Martin Pecka from comment #4)

repair the folders in them. After doing that, I'm no longer able to
reproduce this issue even when adding Message-ID again to prefs.js.

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → INVALID

(In reply to Alfred Peters from comment #6)

I'm sorry, but the part you quoted and probably took as a reason to close the issue is taken out of context. Just a sentence earlier I said it is only fixed because I applied a workaround (unsetting Message-ID from custom headers). So the issue should not be marked INVALID just based on this.

So you still see this on an actual TB? Then feel free to reopen the bug.

JFTR:

  • The Message-ID of your example itself is absolute OK
  • I have set Message-ID set in that pref since long time, I use an IMAP account with many folders and have never seen this bug till today.
    Though I don't use GMail and move-filter only for testing purposes.
  • On the other hand, today I did some quick tests with an GMail account and still can't reproduce.

I've re-added Message-ID to that setting to test whether this bug is still there. If it happens again, I'll reopen.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: