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

UNCONFIRMED
Unassigned

Status

Thunderbird
Message Reader UI
UNCONFIRMED
3 years ago
11 months ago

People

(Reporter: Martin Pecka, Unassigned)

Tracking

31 Branch
x86_64
Windows 7

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
Created attachment 8524636 [details]
An example email whose subject disappears when "Message-ID" custom header is set. When I download such email without the "Message-ID" header in customHeaders, It shows up well.

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).
(Reporter)

Updated

3 years ago
Duplicate of this bug: 918074
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
(Reporter)

Comment 4

3 years ago
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.

Updated

11 months ago
See Also: → bug 1323503
You need to log in before you can comment on or make changes to this bug.