844208 - Saving a message/rfc822 attachment decodes its base64 body but preserves its Content-Transfer-Encoding header

Status: RESOLVED WORKSFORME

(Thunderbird :: Untriaged, defect)

Description

[Ilguiz Latypov]

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.

Comment 1

[WADA:World Anti-bad-Duping Agency]

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

Comment 2

[Ilguiz Latypov]

Attachment: A sample container message carrying another message inside

Comment 3

[Ilguiz Latypov]

Attachment: the result of pressing the Save button in the bottom right corner of the body view

Comment 4

[Ilguiz Latypov]

Attachment: the result of pressing "s" against the "message/rfc822" branch in the "v" view of the container in mutt

Comment 5

[Ilguiz Latypov]

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".

Comment 6

[Ilguiz Latypov]

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.

Comment 7

[WADA:World Anti-bad-Duping Agency]

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

Comment 8

[Jonathan Kamens]

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.

Comment 9

[Mark Sapiro]

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.

Comment 10

[Filipus Klutiero]

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

Comment 11

[Wayne Mery (:wsmwk)]

(In reply to Mark Sapiro from comment #9)

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.

(In reply to Jonathan Kamens from comment #8)

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.

JK, do you still see this?

Comment 12

[Mark Sapiro]

I just tested this again with Thunderbird 68.10.0 (64-bit) on Linux, and it seems to be fixed.

Comment 13

[Jonathan Kamens]

I can't imagine that this is still an issue.

Comment 14

[Wayne Mery (:wsmwk)]

=> WFM when we don't know the patch that changed the behavior