612621 - Any attachment on a message forwarded from Thunderbird 2 to Thunderbird 3 is corrupted on "Save As..."

Status: RESOLVED WORKSFORME

(Thunderbird :: Mail Window Front End, defect)

Description

[David Merrill]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13pre) Gecko/20101103 Lanikai/3.1.7pre

This is true regardless of the file type of the attachment, but does not happen on messages forwarded from Thunderbird 3.

If someone receives a message with an attachment, and (in Thunderbird 2.x) they forward that message to me, I can open the attachment just fine by doubleclicking it, but if I rightclick it and choose "Save As...", the saved file is corrupted such that it cannot be opened.

Reproducible: Always

Steps to Reproduce:
1. From Thunderbird 2, forward to a Thunderbird 3 user a message that includes an attached file.
2. In Thunderbird 3, an "*.eml" attachment appears. Double click to open the forwarded message.
3. In the attachment pane, doubleclick the attachment. If it is openable (e.g., .doc, .pdf), it opens correctly.
4. In the same attachment pane, RIGHTclick the attachment and choose "Save As...", and save the attached file.
5. Open the saved attachment in its associated application.
Actual Results:  
An error occurs. The file cannot be opened, and the error message indicates that the file is corrupted.

Expected Results:  
The file should be openable, as it was on doubleclick.

Comment 1

[David Merrill]

Result of step 4 (attachment saved with "Save As..."), regardless of attachment file type, is a file that contains two HTML ending tags: "</body></html>". This should make the bug much easier to fix.

Comment 2

[Ludovic Hirlimann [:Usul]]

Do you get the same results if you start Thunderbird in -safe-mode (as described at http://support.mozillamessaging.com/en-US/kb/Safe+Mode) ?

Comment 3

[David Merrill]

Yes, same results: the saved file is 18 bytes containing "</body></html>".

Comment 4

[Ludovic Hirlimann [:Usul]]

(In reply to comment #3)
> Yes, same results: the saved file is 18 bytes containing "</body></html>".

Weird I don't get this. Could you install https://addons.mozilla.org/en-US/thunderbird/addon/239387/ run it and give me the prefs that are different on your system ?

Comment 5

[David Merrill]

Now running Miramar Alpha 2 [Mozilla/5.0 (Windows NT 5.1; rv:2.0b10pre) Gecko/20110114 Thunderbird/3.3a2] and getting the same result. Cannot install the about:support 1.0 add-on you requested (not compatible with Miramar). Is there another add-on that will give the same information?

Comment 6

[Jim Porter (:squib)]

Miramar Alpha 2 has about:support built-in, so you don't need to install anything.

Comment 7

[WADA:World Anti-bad-Duping Agency]

David Merrill(bug opener), Tb 3 only problem?
No problem if a mail is forward by Tb 2 and is received/viewed by Tb 2?
How about "a mail is forward by Tb 3 and is received/viewed by Tb 3" in your environment?

As Tb still has bug 559532, attachment handling at standalone window for .eml attachment still has many problems.
(See bugs lited in Dependency tree for meta Bug 269826)
David Merrill, no problem if double click of attachment in attached mail(.eml part, message/rfc822v part)? "Save As" only issue?
(As different code path is used by double-click and context-menu, it can happen)

As seen in bug 580017, some problems can happen if message/rfc822 part(attached mail, .eml) is sent in base64. What headers are used for the attached mail part?
Can you attach mail data which produces your problem?
If yes, save the mail as .eml file, and attach the .eml file to this bug via "Add an attachment" link of this bug(never paste), please.

Comment 8

[David Merrill]

>No problem if a mail is forward by Tb 2 and is received/viewed by Tb 2?
No problem.

>How about "a mail is forward by Tb 3 and is received/viewed by Tb 3" in your
>environment?
Again, no problem.

>no problem if double click of attachment in attached mail(.eml
>part, message/rfc822v part)? "Save As" only issue?
That's correct. Double-click to view is the only way I'm able to save the attachment. "Save As" results in a tiny file, named same as the attachment, that contains only the text "</body></html>".

Comment 9

[David Merrill]

>As seen in bug 580017, some problems can happen if message/rfc822 part(attached
>mail, .eml) is sent in base64. What headers are used for the attached mail
>part?
The initial forwarded message shows an attached .eml file. When I view the source of that initial forwarded message, ALL parts -- including the HTML message part as well as the two file attachments (a PDF and a JPG) -- are base64 encoded. Double-clicking that .eml attachment opens a separate window containing the message and displaying the two attachments. HOWEVER, when I view the source of THAT window, there's NO base64 encoding: in the source, the attachments do not appear to be there at all. What IS there is the following HTML. Note that the following HTML, which references the two attachments, appears AFTER the "</body></html>" that closes the HTML message, and yet repeats that closing code:

</div></body>
</html>
<center><table border><tr><td><div align=right class="headerdisplayname" style="display:inline;">Job Corps MySpace Ad2.pdf</div></td><td><table border=0></table></td></tr></table></center><br><br><fieldset class="mimeAttachmentHeader"><legend class="mimeAttachmentName">JC AD.JPG</legend></fieldset><center><table border><tr><td><div align=right class="headerdisplayname" style="display:inline;">JC AD.JPG</div></td><td><table border=0></table></td></tr></table></center><br>

That is the code that displays what appears to be the two attachments. If I doubleclick one of those "attachments", it will open correctly (and thus is finding and decoding the associated base64 part from the initial forwarded message). But if I "Save As" for either of those "attachments", what's saved for each is an 18-byte file that reads exactly as follows:

</body>
</html>

Comment 10

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #8)
> >No problem if a mail is forward by Tb 2 and is received/viewed by Tb 2?
> No problem.
 >How about "a mail is forward by Tb 3 and is received/viewed by Tb 3" in your
> >environment?
> Again, no problem.

If message/rfc822 part is correctly sent in base64(whole mail data including headers are base64 encoded), bug 580017 occurs, and attached mail can not be viewed by Tb.
Because Tb still has problem of bug 326303, if message/rfc822 part is sent in base64 by Tb(due to mail.file_attach_binary=true, due to mixture of CRLF, LF, CR, ...), Tb shows the message/rfc822 part as attachment but it produces problems in stand alone window which is opened by double-click of the attached message/rfc822 part.

What Content-Transfer-Encoding: is generated for message/rfc822 part by Tb 2?
What Content-Transfer-Encoding: is generated for message/rfc822 part by Tb 3?

For shown message source at stand alone window for message/rfc822 part.

Checked with next mail.
- mail structure :
    multipart/mixed { text/plain, message/rfc822 in text(not base64) }
- attached mail as message/rfc822 :
    multipart/mixed { text/plain, text/plain }
Tb 3.1.7 showed next source at standalone window for the message/rfc822.
> <html>
> <head>
> <title>Text mail with an attachment</title>
> <link rel="important stylesheet" href="chrome://messagebody/skin/messageBody.css">
> </head>
> <body>
> <table border=0 cellspacing=0 cellpadding=0 width="100%" class="header-part1">
> <tr><td><div class="headerdisplayname" style="display:inline;">Subject: </div>Text mail with an attachment</td></tr>
> <tr><td><div class="headerdisplayname" style="display:inline;">From: </div>x x &lt;x1@x.x.x&gt;</td></tr><tr><td><div class="headerdisplayname" style="display:inline;">Date: </div>Fri, 04 Feb 2011 10:45:09 +0900</td></tr>
> </table><table border=0 cellspacing=0 cellpadding=0 width="100%" class="header-part2"><tr><td><div class="headerdisplayname" style="display:inline;">To: </div>z@z.z.z</td></tr></table>
<br>
> 
> <div class="moz-text-plain" wrap=true graphical-quote=true style="font-family: -moz-fixed; font-size: 16px;" lang="ja">
> <pre wrap>
> Mail body text of text mail with an attachment
> </pre></div></body>
> </html>
> <center><table border><tr><td><div align=right class="headerdisplayname" style="display:inline;">z.txt</div></td><td><table border=0></table></td></tr></table></center><br>

You are perhaps seeing next:
(1) Bug 326303 happens on Tb 2.
(2) Due to bug 326303, data in message/rfc822 is corrupted, if sent in base64.
(3) Due to inappropriate handling of the corrupted message/rfc822 part,
    and due to above particularity in stand alone message window for
    message/rfc822 part,
    problems in attachement handling of message/rfc822 part,
    including HTML elements for attachment after </body></html>,
    are exposed to you.
Is message/rfc822 part encoded in base64 by Tb?

Comment 11

[David Merrill]

This bug is moot, mostly because attachments sent from Tb2 to me (w/Tb3) are now saving correctly on "Save As...", and partly because I no longer have access to the original messages on which this bug report was based.

Thank you.