668259 - attachments sometimes do not appear in attachment pane

Status: RESOLVED DUPLICATE of bug 602718

(Thunderbird :: Message Reader UI, defect)

Description

[ash.daminato]

Attachment: FW fax from 5066226329.eml

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0
Build ID: 20110615151330

Steps to reproduce:

I upgraded from Thunderbird 3.1 to 5.0. We receive faxes as email attachments from a 3rd party provider. Our receptionist sorts and forwards or prints the attachment to the correct party using Microsoft Outlook.

I saved the email as a file and opened it with thunderbird 3.1 and 5.0


Actual results:

Thunderbird 5.0 does not indicate that there is an attachment in the e-mail. Thunderbird 3.1 did indicate there was an attachment.


Expected results:

Thunderbird 5.0 should indicate that there is an attachement.

Comment 1

[ash.daminato]

I tested this with Thunderbird 5.0 on Windows 7 Professional 64-bit and Thunderid 5.0 Beta 2 on Ubuntu 11.04 64-bit.

Comment 2

[Jim Porter (:squib)]

It seems the issue is that Thunderbird is barfing on multipart/related. Changing that to multipart/mixed makes everything work...

Comment 3

[Jim Porter (:squib)]

Ah, it's not "barfing" exactly; the message is malformed. MIME multipart/related containers aren't supposed to be used to store attachments at all. Wikipedia's summary is pretty good here: "A multipart/related is used to indicate that message parts should not be considered individually but rather as parts of an aggregate whole."

This is problematic in the attached email for a couple reasons: first, the structure looks like this:

* multipart/related
  * multipart/alternative
    * text/plain
    * text/html
  * image/tiff

That's wrong, since multipart/related wouldn't make sense for a text/plain object: plain text isn't a compound object (but HTML, for example, is). It's also bad because even in the HTML object, there's no reference to the related image/tiff part, which defeats the purpose of using multipart/related.

It's probably not super-helpful to you, but the "correct" way to fix this would be for the 3rd party provider to use MIME subtypes properly and switch from multipart/related to multipart/mixed.

In the end, this is probably a dupe of bug 602718.

Comment 4

[rsx11m]

I agree, the message is technically invalid as there is no reference whatsoever to "cid:1" in the message body, thus it is malformed (notwithstanding the fact that Thunderbird wouldn't be able to display the TIFF image inline, yet another reason to make multipart/related items accessible as proposed in bug 602718).