User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: version 1.0 (20041206) Only seen this once. This spam e-mail contained an attached jpeg which displayed in the body pane; preferences were set to plain text only. In both version 1.0 (20041206) under Windows XP and version 1.0 (20041221) under Linux. Display Attachments Inline was turned on. The body pane would be empty and the typical <hr>-like seperator between body and attachments was absent. I was able to rip out the entire message using mutt and have attached it below. The headers under both Thunderbird builds would stop after "X-SPAM-LEVEL", but the mutt excavation shows much more was contained in the mail. Reproducible: Always

The MIME structure of this document is: Top: multipart/alternative Part 1: multipart/alternative Part 1.1: text/plain Part 1.2: text/html <- this appears to be text for fooling spam filters Part 2: image/jpeg <- this is the ad This structure is legal, and Mozilla is doing the expected thing with it: it displays the last part in the structure which it is capable of displaying. I tried fudging the message to this: Top: multipart/alternative Part 1: text/plain Part 2: image/jpeg and still could not get the text/plain portion to take precedence over the image portion. Also, fwiw, this message exhibits the same symptom as bug 234980. xref bug 130119.

Our m/a decoder (mailnews/mime/src/mimemalt.cpp, IIRC) is very stupid: it just skips some *known* unwanted mimetypes (esp. HTML) and hopes that the rest is plaintext. (It wasn't me, although CVS blames me! ;-) ) <http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/mimemalt.cpp#226>

> It wasn't me (Actually, I don't know anymore)

While looking at bug 61815, I restructured the message that was there to follow what might be a sensible MIME arrangement: Top: multipart/alternative Part 1: text/plain Part 2: multipart/related Part 2.1: text/html Part 2.2: image/gif This displays the HTML part correctly, when that's selected. When as-Plain is selected, the message body is blank, but should be "testing". I'm not sure if this symptom is basically the same as this bug or not. (There may be an error in this attachment, I edited it by hand.)

*** Bug 276899 has been marked as a duplicate of this bug. ***

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

Nick this might have been fixed by bug 351224. Could you take a few minutes and download the latest nightly ( http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/ ), backup your profile and test and let us know if this is fixed or not ?

I found the same issue. Thunderbird 24.2.0 displays only the image part for message with following structure: - multipart/alternative - text/plain - image/gif "Message Body As" setting is irrelevant, i.e. does not change the behaviour. What's more, the message contains: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 Which might mean that Thunderbird also creates such "stupid" messages. I call it "stupid" because making an image/gif part alternative doesn't have much sense to me. Of course, it might have been broken by some server mail content filter that I'm not aware.

I don't think TB sent this out. I've never seen this, and I can't imagine nor find such code. From superficial code inspection, there seems to be only one place that sets multipart: http://mxr.mozilla.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js#2636 http://mxr.mozilla.org/comm-central/source/mailnews/compose/src/nsMsgSend.cpp#698

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.

With TB 49 (2016-05-17) the HTML part of attachment 172454 [details] is displayed, same for attachment 175206 [details]. Attachment 172454 [details] has a bad MIME structure. Attachment 175206 [details] is fine. That the text/plain part isn't displayed (comment #5) is covered by bug 253830.