User Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.12) Gecko/20100101 Firefox/10.0.12 Iceweasel/10.0.12 Build ID: 20130108232239 Steps to reproduce: In my Icedove 10.0.12 on Debian unstable I see the text of a text/plain base64 message/rfc822 attachment below the main part. But saving the attachment copies its base64-decoded content without deleting the base64 header. <Subject>.eml: ============================ ... Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ... <Base64-decoded plain text body> ============================ Actual results: This results in seeing garbage on attempt to open the saved attachment. Expected results: If saving the attachment must involve base64-decoding its body (why?), the decoding procedure should remove the Content-Transfer-Encoding header from the saved copy.

(In reply to Ilguiz Latypov from comment #0) > I see the text of a text/plain base64 message/rfc822 attachment below the main part. > <Subject>.eml: > ============================ > ... > Content-Type: text/plain; charset="utf-8" > Content-Transfer-Encoding: base64 > ... > > <Base64-decoded plain text body> > ============================ How can the "Content-Type: text/plain;" part be a "message/rfc822 attachment" part? Mail like following? multipart/mixed text/plain; or text/html; message/rfc822 (data of this message/rfc822 part) Subject: ... Content-Type: multipart/... Content-Type: text/... (data of this text/... part) <Subject>.eml: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 (data of this text/..., base64 part) <Base64-decoded plain text body> If so, which part did you save as file? If message/rfc822 part of above mail structure is saved as .eml file, any line(data of attachd mail) under the messae/rfc822 part(==attached mail) has to be saved as-is. Anyway, can you show us actual mail data structure first? Save the mail to .eml file, Edit the .eml file by Text Editor, Because data in each part is not needed unless base64 decoded data will be needed for analysis, remove data lines under each part, remove/replace private information such as mail addrss, Save tthe modified .eml, then attach the mail structure data(.eml file) to this bug(never paste long dat to bug, please)

I agree with WADA. The container message has multiple parts one of which has the message/rfc822 type. The attachment within the container message did not have parts in my case and carried a type text/plain. I am adding the following files to this ticket: * the sample container message "container-message", * the result of saving the attachment by pressing the Save button in the bottom right corner of the message body view in Icedove, "This is it.eml", * the result of saving the attachment by pressing "s" on the message/rfc822 branch in the structure shown my mutt after pressing "v", "cut-on-reply-foo".

Why did this receive a resolution? My agreement with the guess on the structure of the message did not imply that I stopped observing the issue.

(In reply to Ilguiz Latypov from comment #6) > Why did this receive a resolution? Sorry, I misunderstood source by mutt was by Tb. Different from bug 326303, but similar bad handling of "message/rfc822 with base64" looks involved. For base64 decoded message body text of saved eml. file, even though Content-Trasnfer-Encoding:base64. It may be a regression by "base64 decode of message bofy for message filter". Problem of "if a text mail is base64 encoded, body filter can't find string in message body" occurred, so "decode message body" logic is added to steps before message filter. Such change may produce this bug.

I'm seeing this too. The result of the bug is that the saved attachment is corrupt, since its header claims that the body is encoded in base64 when in fact it isn't.

See my commnent at <https://bugzilla.mozilla.org/show_bug.cgi?id=425455#c20>. It appears that this is the same underlying bug as bug 425455.

This happened to me on Thunderbird 45.1 on Windows 10. It caused me to upload corrupted mails to ticket #1282244.