1803170 - Attached message (base64 encoded, content-type: text/plain, without .eml extension) not opened as an email. Changing content-type to message/rfc822 opens attachment as blank message in TB; saved attachment has 0 bytes (but 2.4 KB in attachment pane)

Status: RESOLVED WORKSFORME

(MailNews Core :: MIME, defect)

Description

[graham]

Attachment: Screenshot_2022-11-2.png

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:107.0) Gecko/20100101 Firefox/107.0

Steps to reproduce:

Received email sent from another computer using Thunderbird 102. The email contained a forwarded email as an attachment.
On choosing Open (the attachment), Thunderbird reports it is a "Python File (no console)" noting it's from my imap server and suggests opening it in my text editor (Xed). Doing so shows the message source text.
Trying again to open the attachment but changing the suggested application to 'thunderbird' results in opening an empty "Write" email window which shows a pre-attached attachment with the same name as the original email attachment but with a '-1' added to the end of the filename and noting the attachment is zero bytes.

Actual results:

As noted above - either got message source displayed in text editor, or a weird mis-set-up 'Write' email window. (see attached PNG screenshot)

Expected results:

When choosing to open the the attachment, previous behaviour was to simply open the email attachment and display it in a normal received-email window.

I have found a workaround which involves exporting the email and editing the message source:
Export the email using Save As and save as an .eml file in a local directory/folder.
Open the .eml file in a text editor and add .eml to both the attachment name,
i.e. Content-Type: text/plain; charset=UTF-8; name="<name>.eml"
and to the attachment filename,
i.e. Content-Disposition: attachment; filename="<filename>.eml"
Doing that results in Thunderbird opening the email attachment as would be expected given that 'thunderbird' is the chosen application to open the attachment.

Incidentally, when looking at the message source for emails that suffer this problem and comparing them to emails that, in the past, did NOT suffer this problem, there was one commonality. The forwarded email attachment within problem received emails is encoded as base64. The forwarded email attachment within previous (no problems) received emails is NOT encoded as base64.
Whether this is related to the cause of the problem - I don't know but thought it worth mentioning.

Comment 1

[Magnus Melin [:mkmelin]]

Please attach a sample as .eml

Comment 2

[graham]

Attachment: Test email for FW attachment - Graham Smith <[e-mail]> - 2022-11-29 2341.eml

Comment 3

[graham]

Attachment: Fwd: Test email for FW attachment - Sue Smith <[e-mail]> - 2022-11-29 2343.eml

Comment 4

[graham]

Here is a .eml file being an email from my desktop PC to Sue's desktop PC. Then the second .eml file is Sue's forwarding of my original email back to me. Upon receipt, I can not open the attachment email in the way I would expect.
As noted before, we are both using Thunderbird 102 on Linux Mint machines.
As noted before I can workaround the problem by editing the message source to add ".eml" to the filename of the attachment. However, we can not use the Thunderbird setting "add extension to filename" as our email provider, like most others, rejects emails with ".eml" attachments resulting in message undelivered problems.

Comment 5

[Thomas D. (:thomas8)]

Well, there's several things going on here. Tested on TB 102.5.1, Win10.

The attached message has the following features:

• base64 encoded
• content-type: text/plain
• no .eml extension

So afasics there's absolutely nothing in that attachment which would enable Thunderbird to know that this is a message, short of parsing the actual content of the attachment (for which the cost/benefit ratio doesn't look right at all).
So it's not surprising at all that Thunderbird proposes to open that message as a text file, because that's what it is from all the looks of it.

However, I'm surprised about the following: After changing the content-type of the attached message to message/rfc822 (but still without .eml extension):

• Thunderbird will open the attached message (ok)
• But the message will appear blank
• And saving the attached message (which is shown as 2.4 KB in the UI) results in 0 bytes file.

The last two look like a bug to me - Magnus, would you agree?
If yes, probably best filed as a new bug (I can do that) if there isn't one already.

Comment 6

[Thomas D. (:thomas8)]

Graham, are you saying that attached messages which neither had content-type: message/rfc822 nor .eml extension were opened directly from attachment pane by earlier versions of Thunderbird? If yes, were those attached messages also base64 encoded?

Comment 7

[graham]

Yes, previous behaviour was to open forwarded emails as a normal email window displayed as expected. And, yes, those attachments were not flagged as message/rfc822 nor had .emo extensions. No they were NOT base64 encoded. It looks like Thunderbird did not encode forwarded email attachments as base64 but instead sent as original content unencoded.

Comment 8

[Magnus Melin [:mkmelin]]

The attached .eml saves just fine for me on trunk.
When tb forwards as attachment is should set the right content type though, and apparently we don't.

Comment 9

[graham]

Hi, do we know if anything is happening about this bug?
Its status is unconfirmed - whereas it is, in fact, confirmed. It impacts on many users. It's clearly a flaw in the process of encoding and tagging an email to be forwarded.
Needs fixing.

Comment 10

[graham]

Above still applies. Why is nothing being done about this?? It is a critical flaw.

Comment 11

[graham]

Attachment: Test email for FW attachment - Graham Smith <[e-mail]> - 2022-11-29 2341.eml

Comment 12

[graham]

Attachment: Fwd: Test email for FW attachment - Sue Smith <[e-mail]> - 2022-11-29 2343.eml

Comment 13

[graham]

Attachment: Fwd: Test email for FW attachment (add eml extn) - Sue Smith <[e-mail]> - 2022-11-29 2343.eml

Comment 14

[graham]

Attachment: Fwd: Test email for FW attachment (mod CT) - Sue Smith <[e-mail]> - 2022-11-29 2343.eml

Comment 15

[graham]

Attachment: Fwd: Test email for FW attachment (mod CT and eml) - Sue Smith <[e-mail]> - 2022-11-29 2343.eml

Comment 16

[graham]

Attachment: Fwd: Test email for FW attachment (mod CT decodeb64) - Sue Smith <[e-mail]> - 2022-11-29 2343.eml

Comment 17

[graham]

I stumbled upon an oddity workaround and done some further tests (running 115). The results point to the cause of the problem being the code that TB runs when user do the following:

1. Have Settings > Composition > 'Forward messages:' set to As Attachment; and have NOT ticked option to add extension to filename.
   (the latter because the majority of mail servers block emails with attachments that have .eml extensions )
2. Use any "normal" method to forward an email to a recipient: - e.g. select email, right click, choose 'Forward'; or open email, click the 'Forward' toolbar button, or use menu Message > Forward (Ctrl+L)
3. Fill in the forwarding email details and send.
   The code TB then uses encodes the attached email in base 64 AND states that the attachment is "Content-Type: text/plain".

The problems are:

1. TB marking the attachment as "Content-Type: text/plain" is just plain WRONG!
2. TB cannot open and decode an base 64 attachment marked as "Content-Type: text/plain" unless the filename has an extension - a situation that is not helped by many mail servers blocking many extensions.
3. TB fails to do ANYTHING with the attachment if it is encoded base 64 AND it's Content-Type is marked as "Content-Type: message/rfc822" - irrespective of whether the filename has an extension or not.

The workaround oddity is that the following approach a) doesn't send a base 64 encoded attachment, b) correctly marks the Content-Type, c) results in an email attachment that is correctly handled even thought it DOES NOT have an extension added to the filename. Steps are:

1. Use any "normal" method to forward an email to a recipient (as noted above).
2. Remove the attachment from the created forwarding email (right click and choose Remove Attachment)
3. Select the email that one is forwarding and drag it to the created forwarding email window/tab - the Add As Attachment feature kicks in... use that as normal.
4. Send the forwarding email to the recipient.
   The result works because it does three things:
5. It does NOT encode the attachment in base 64 - attaches in plain text
6. It correctly marks the attachment as "Content-Type: message/rfc822"
7. Doesn't add a filename extension that will cause a picky mail server to block the email because of filename extensions.

So, the fix options are to reprogram TB so that:

• TB does NOT mark attached emails as "Content-Type: text/plain" (this one is a must-do)
• TB doesn't try to encode normally forwarded emails in base 64, or
• enable TB to decode and correctly handle base 64 "Content-Type: message/rfc822" attachments
  (the above two options depend on attitudes to security - even tho' base 64 encoding isn't really secure at all)

Basically, it's just a big tidy up of the mess created by the coders of the above processes. I will attach copies of email files that can be used to test the flaws and possible corrections. The 'subject' bit in brackets hints at the differences between the same email with relevant mods.

Comment 18

[Wayne Mery (:wsmwk)]

Do you still see this issue when using 140.x ?

Comment 19

[graham]

No. Seems to be fixed. Also tried sending from an installation of 142.x to installation of 128.x - attachment opened fine and sent somehting back from 128.x to 142.x - attachment opened fine.

Comment 20

[Wayne Mery (:wsmwk)]

Thanks for the update