Closed
Bug 668259
Opened 13 years ago
Closed 13 years ago
attachments sometimes do not appear in attachment pane
Categories
(Thunderbird :: Message Reader UI, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 602718
People
(Reporter: ash.daminato, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
text/plain
|
Details |
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.
Reporter | ||
Comment 1•13 years ago
|
||
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.
Updated•13 years ago
|
Attachment #542864 -
Attachment mime type: application/octet-stream → text/plain
Updated•13 years ago
|
Blocks: multipartfailtracker
Comment 2•13 years ago
|
||
It seems the issue is that Thunderbird is barfing on multipart/related. Changing that to multipart/mixed makes everything work...
Comment 3•13 years ago
|
||
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.
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).
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•