User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160608193719 Steps to reproduce: I have a message with following structure: Content-Type: multipart/mixed; boundary="=_8695d27360e27439ab27176a84c4a1c3" Content-Transfer-Encoding: base64 Content-Type: text/plain; name=file1.txt Content-Disposition: attachment; filename=file1.txt; size=4704207 Content-Transfer-Encoding: base64 Content-Type: text/plain; name=file2.txt Content-Disposition: attachment; filename=file2.txt; size=47042 i.e. it's a message with no body and two text/plain attachments. Now, there is a couple of issues with this message: 1. The first attachment is displayed as body, not as the inline attachment, i.e. there's no hr line with attachment name. BTW, because the attachment is quite big it makes message openning quite slow. 2. The first attachment is not listed on attachments list - e.g. can't be saved to disk, opened, detached, deleted, etc. 3. While Reply handles this correctly (body is empty), Forward will put the first attachment body in the reply body and not on attachments list. It is slow again (even kills my Thunderbird sometimes).
Can you attach such a message, please. See also bug 1283731 where someone complained that malformed messages from Verizon phones were not handled well. In general, Thunderbird is now maintained by a group of unpaid and overworked volunteers who have very little time for bugs like this one, that is improve the tolerance of the system towards invalid data. To improve access to the various parts, set preference mailnews.display.show_all_body_parts_menu and then select View > Message Body As > All Message Parts. That should enable you to save the first attachment.
Severity: normal → enhancement
Summary: Handling of message with no body but text/plain attachments → Improve handling of message with no body but text/plain attachments
Here's the simplified message source: Message-ID: <firstname.lastname@example.org> Date: Thu, 21 Jul 2016 19:57:13 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------1E7502FF12C01C55224E99A4" This is a multi-part message in MIME format. --------------1E7502FF12C01C55224E99A4 Content-Type: text/plain; charset=UTF-8; name="attachment1 [details] [diff] [review].txt" Content-Disposition: attachment; filename="attachment1 [details] [diff] [review].txt" attachment1 [details] [diff] [review] body --------------1E7502FF12C01C55224E99A4 Content-Type: text/plain; charset=UTF-8; name="attachment2 [details] [diff] [review].txt" Content-Disposition: attachment; filename="attachment2 [details] [diff] [review].txt" attachment2 [details] [diff] [review] body --------------1E7502FF12C01C55224E99A4--
"show_all_body_parts=true" indeed adds the missing file to the attachments list. However, does not fix all issues here and I'm pretty sure this case should not require any additional configuration. I also added a comment in bug 1283731 which should not be closed as wontfix, imho.
(In reply to Aleksander Machniak from comment #3) > I also added a comment in > bug 1283731 which should not be closed as wontfix, imho. The reporter closed it.
duplicate of another recently handled bug? (you have a much better handle on these than me)
I don't see it as a duplicate. There is bug 1411185 where there is no body but only an attachment. That bug is about saving the attachment.
You need to log in before you can comment on or make changes to this bug.