User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160604131506 Steps to reproduce: Mail from Verizon phones responding to text messages does not display. Text messages to phonenumber@vzwpix.com or vtext.com are handled properly. When the phone user responds, a message like this is sent from Verizon: Return-Path: <831359xxxx@vzwpix.com> Received: from txslspamp2.vtext.com (txslspamp2.vtext.com [69.78.67.195]) by duke.josephson.com (8.13.8/8.13.8) with ESMTP id u6120J6j017621 for <dlj@josephson.com>; Thu, 30 Jun 2016 19:00:20 -0700 Received: from 39.sub-69-78-81.myvzw.com (HELO m01.vzwpix.com) ([69.78.81.39]) by txslspamp2.vtext.com with SMTP; 01 Jul 2016 02:00:16 +0000 From: 831359xxxx@vzwpix.com To: dlj@josephson.com Subject: Message-ID: <212334098416443817@-212334098416443818> Date: Fri, 1 Jul 2016 02:00:16 +0000 MIME-Version: 1.0 Content-Type: multipart/mixed; type="application/smil"; boundary="__CONTENT_64564_PART_BOUNDARY__33243242__" --__CONTENT_64564_PART_BOUNDARY__33243242__ Content-Type: text/plain; charset=us-ascii Content-ID: <0> Content-Disposition: attachment; filename="text_0.txt" Content-Location: text_0.txt Not hungry --__CONTENT_64564_PART_BOUNDARY__33243242__-- Actual results: Message shows up with no content, is only visible by viewing source. The attachment flag is present but disappears when clicked, and no message (in this case, "Not hungry") is displayed. Expected results: The text attachment should be displayed, either inline or as an attachment.

In case comment #0 shows the full message I can't see a problem. I saved the message from comment #0 and I see "Not hungry". I have "View > Display Attachments Inline" set. As you can see in the message source, the message is badly formatted, the text "No hungry" is included in an attachment.

If you do not have View > Display Attachments Inline set, the attachment should be shown. It is not. The message is indeed badly formatted, but thousands of them come from Verizon that way. I would hope that Mozilla would try to respond more appropriately to badly formatted messages.

You can set preference mailnews.display.show_all_body_parts_menu and then view all body parts via View > Message Body As > All Body Parts. I would hope that Verizon would not send obviously malformed messages. I would also wish you understood that Mozilla has abandoned Thunderbird which is now maintained by a group of unpaid and overworked volunteers who have no time for bugs like this one.

> I would also wish you understood that Mozilla has abandoned Thunderbird which is now maintained by a > group of unpaid and overworked volunteers who have no time for bugs like this one. Got it. Thanks.

I came here from bug #1288335. This is slightly different issue. And I see recent Thunderbird displays the attachment body as message body for this sample. However, in my opinion it should not do this. It should list the attachment on attachments list and optionally display the attachment body inline (as it does for text/plain attachments). It looks like Thunderbird assumes that the first text part of multipart/mixed message is the message body, but if the part contains "Content-Disposition: attachment" it is an invalid assumption.

(In reply to Aleksander Machniak from comment #5) > I came here from bug #1288335. This is slightly different issue. And I see > recent Thunderbird displays the attachment body as message body for this > sample. However, in my opinion it should not do this. It should list the > attachment on attachments list and optionally display the attachment body > inline (as it does for text/plain attachments). > > It looks like Thunderbird assumes that the first text part of > multipart/mixed message is the message body, but if the part contains > "Content-Disposition: attachment" it is an invalid assumption. Thanks, that's right. This behavior started some months ago and was not noted before that. The workaround suggested by Jorg results in any multipart message being presented as attachments.

A more accurate description of the issue is that TB is correctly treating the text portion of such messages as an attachment per the e-mail's content part description, but perhaps it should instead treat it as inline text, even if the user has not selected "View > Display attachments inline." That is how every other mail reader I have used handles these sort of messages: it displays inline the text message sent by Verizon's MMS > e-mail service, and then handles the remaining attachments per whatever image and attachment settings the user has selected. Or, alternatively, on my cell phone using K-9 Mail, where I have selected the option to display the first line or two of each message in my main inbox window, I see the beginning of the text attachment as if it was inline text. (When I open the message, the text is not displayed and is instead presented as an attachment only). I think that this result is almost always the right one from the user's perspective: the actual message should generally be visible as the body of the e-mail, even if it is also treated as an attachment. I imagine a combination of message type = text and size < 200 bytes, or something like that, would do the trick to distinguish between true text files and Verizon packaging text messages as .txt attachments. Here's what a text message content part looks like. --__CONTENT_64564_PART_BOUNDARY__33243242__ Content-Type: text/plain; charset=us-ascii Content-ID: <7> Content-Disposition: attachment; filename="text_7.txt" Content-Location: text_7.txt Very important pictures for you to see. Please advise Jeff --__CONTENT_64564_PART_BOUNDARY__33243242__--