384.55 KB, text/plain
Created attachment 604551 [details] one of the received messages that causes the problem User Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20100101 Firefox/10.0.2 Build ID: 20120215223356 Steps to reproduce: I received a message supposed to contain a MHT attachment. Looking at the message source with Ctrl-U the attachment was inside the message. Actual results: In the message list no paperclip was displayed and no attachment line was visible under the message preview. This happened not only once, but always with this kind of message, that is a weekly report from Symantec Corporate Antivirus. Every weekly report is not decoded. Expected results: The MHT attachment should have been decoded and the message list should report it with the paperclip icon to the side of the message, and the attachment should have been under the message preview pane.
(In reply to Lorenzo Mau from comment #0) > one of the received messages that causes the problem Folding at mid of name/filename parameter value, mixed used of Space and Tab as folding char, insertion of Tab instead of "fold at space", are seen in header. > [CRLF] = 0x0D0A, [Tab] = 0x09 > Content-Type: application/octet-stream; [CRLF] > [Tab]name="Report riepilogo settimanale esecutivo_9-mar-2012[CRLF] > 23.17.59.mht"[CRLF] > Content-Disposition: attachment; [CRLF] > [Tab]filename="Report riepilogo settimanale esecutivo_9-mar-2012[CRLF] > 23.17.59.mht"[CRLF] This shlould be interpreted like next according to unfolding defined by RFC 5322. > Content-Type: application/octet-stream; [Tab]name="Report riepilogo settimanale esecutivo_9-mar-2012 23.17.59.mht"[CRLF] > Content-Disposition: attachment; [Tab]filename="Report riepilogo settimanale esecutivo_9-mar-2012 23.17.59.mht"[CRLF] Does your problem occur with next header? > Content-Type: application/octet-stream; [CRLF] > [Tab]name="Report riepilogo settimanale esecutivo_9-mar-2012 23.17.59.mht"[CRLF] > Content-Disposition: attachment; [CRLF] > [Tab]filename="Report riepilogo settimanale esecutivo_9-mar-2012 23.17.59.mht"[CRLF] Possibly bug 705431 due to folding at mid of name/filename parameter value. Does your problem occur in Tb 11/12/13(bug 705431 is fixed)? If shown as attachment, what name is shown by Tb?
To check with modified header, do next, please. (1) Save mail as .eml file. (2) Edit .eml file by text editor. (3) Drag&Drop the modified .eml file to thread pane of local mail folder. (import of .eml file by Drag&Drop)
(In reply to WADA from comment #2) > To check with modified header, do next, please. > (1) Save mail as .eml file. > (2) Edit .eml file by text editor. > (3) Drag&Drop the modified .eml file to thread pane of local mail folder. > (import of .eml file by Drag&Drop) I edited the .eml file removing the [CRLF] in the middle of the filename before the " 23.17.59.mht" part. I dragged the message back to TB10 but the attachment is still not displayed. I removed also the other [CRLF] in the "Content-Type:" and "Content-Disposition:" rows just after the semicolon-space chars and dragged the message to TB10 again without success. I removed the [Tab]s also, leaving only a space after the semicolon, with no success. I'll try with TB 11/12/13... just the time to put up a VM to install it.
To speed up things I used a VM with Windows 2000 I already had on my system, I installed TB 11 from the beta channel and dragged the unmodified first message (with all the [CRLF] and [Tab] in place) to the inbox of a dumb account I added, and the attachment is correctly displayed. As I can see from the releases page, the TB11 is going to be released in three days, so I'll wait and see if the update solves the problem. BTW, Thanks for help!
I can confirm that, installing TB10 after removing TB11 on the same Windows 2000 VM, the message causes the same problem: attachment is not displayed.
Component: General → Mail Window Front End
QA Contact: general → front-end
seems to be working fine in trunk builds, which means it should be ok in tb 13, which is going into alpha this week.
my guess is that this is a mime bug, not a front end bug, and might be the mime header parser that lives in necko, not the mailnews/mime code. All the callers that I can see pass in true to MIME_DecodeMimeHeader to eat the continuation characters
With TB11 the attachment is detected, the paperclip appears, but when I try to open the attachment, I receive this error message: "This attachment appears to be empty. Please check with the person who sent this. Often company firewalls or antivirus programs will destroy attachments."
WFM on TB 11.0 as a .eml, IMAP message, and POP3 message.
Not yet fixed in TB 12: same behaviour ad comment #8
confirming comment 8 for TB 12.0.1 / WinXP.
Works now in TB 13.0.1 installed today, confirming comment #6. Fixed!
Attachment #604551 - Attachment mime type: application/octet-stream → text/plain
This bug is for following case. (a) the MHT part is not-referred part under multipart/related => there is no need to show it, according to RFC (b) the not-referred part under multipart/related is application/octet-stream => Tb has some issues in application/octet-stream part handling (c) name/filename parameter is folded at mid of parameter value => This may cause "no name=" or "no filename" condition in Tb Unless Content-Type: attchment is specified, Tb doesn't show this part as if attachment when no name= && no filename=. Any of them can produce phenomenon of known Tb bugs. Each are resolved by different bug in different Tb release. It looks all are resolved by Tb 13.0.1 finally.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: MHT attachment is not decoded → MHT attachment is not decoded (application/octet-stream under multipart/related which is not-referred, and name/file name is folded at mid of parameter value)
Component: Mail Window Front End → MIME
Product: Thunderbird → MailNews Core
QA Contact: front-end → mime
Summary: MHT attachment is not decoded (application/octet-stream under multipart/related which is not-referred, and name/file name is folded at mid of parameter value) → MHT attachment is not decoded (application/octet-stream under multipart/related which is not-referred, and name/filename is folded at mid of parameter value)
(In reply to Lorenzo Mau from comment #8) > With TB11 the attachment is detected, the paperclip appears, but when I try > to open the attachment, I receive this error message: > "This attachment appears to be empty. This is known/outstanding problem after fixing issue (a) and similar one by showing "non-referred part under multipart/related" and "non-text part under multipart/alternative" as if attachmnt. I also couldn't observe problem on test mail of this bug in Tb 13.0.1 on Win-XP. - application/octet-stream under multipart/related is shown as if attachment with name of "Report riepilogo settimanale esecutivo_9-mar-2012 23.17.59.mht" - I could save the ATTACHMENT to local file, and I could open the ATTACHMENT by text editor without problem like "empty attachment" message. This problem looks to have been fixed by Tb 13.0.1. I'm sure that B.M.O bug report exist for any problem obseved by test mail of this bug and that patch for each problem is proposed in such bug. So, it's not WORKSFORME(definition in B.M.O : problem disappeared by unknown patch). However, I think re-finding such bugs and searching patches which fixed problems is useless. Closing as WORKSFORME. Please change if it's wrong or FIXED/VERIFIED is better. By the way, even after issues around wrongly embed part in multipart/related or multipart/alternative is resolved and such part is shown as if attachment at attachment pane(in order to provide a way to save or open by apps), there are two outstanding issues around it. (i) This part is never actual ATTACHMENT of multipart mail. So, Tb currently doesn't include the wrongly embed part upon "Forward in Inline". This is an inconsistency between "attachment pane display by Tb" and "forwarding behavior of Tb" for users. Bug for such "inconsistency" is already opened. (ii) If part has no Content-Disposition: attachment, no name=(Content-Type:), no filename=(Content-Disposition:), the part is currently not shown at atachment pane, even when correctly formed multipart/mixed mail. Please don't open new bug for such known/outstanding issues.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
Whiteboard: [Finally fixed by Tb 13.0.1]
Target Milestone: --- → Thunderbird 13.0
You need to log in before you can comment on or make changes to this bug.