Closed Bug 698273 Opened 14 years ago Closed 14 years ago

Attachment not visible

Categories

(Thunderbird :: Message Reader UI, defect)

Product:
Thunderbird
Component:
Message Reader UI
Version:
7 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 674473

People

(Reporter: david, Unassigned)

Details

Attachments

(1 file)

Raw message
21.66 KB, text/plain
Details
Attached file Raw message —
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/14.0.835.202 Safari/535.1 Steps to reproduce: Received an email with both an inline image and an attachment Actual results: You could not tell that the message had an attachment nor get at it. The paper clip was not shown in the Inbox, and there was no attachment list at the end of the message either in the preview pane or if the message was opened in its own window. Expected results: The attachment should be there. Note: I checked the same message in both Outlook (2000) and GMail (in Chrome FWIW), and both correctly see the attachment as expected. The message is generated by PhpMailer (http://phpmailer.worxware.com/index.php ) version 5.1. I have a certain degree of control over the email, so I tired (a) removing the inline image - the attachment DOES then show up (but this is not a satisfactory solution) (b) reversing the order of the inline image and the attachment. The attachment does NOT then show up. The raw message from my Inbox is attached. You can see that the attachment is in there (Lorem.txt)
Mail structure. > Content-Type: multipart/related; type="text/html"; boundary="b1_4478ad2b56a8002986ca07f18a261587" > --b1_4478ad2b56a8002986ca07f18a261587 > Content-Type: multipart/alternative; boundary="b2_4478ad2b56a8002986ca07f18a261587" > --b2_4478ad2b56a8002986ca07f18a261587 > Content-Type: text/plain; charset = "UTF-8" > (snip) > --b2_4478ad2b56a8002986ca07f18a261587 > Content-Type: text/html; charset = "UTF-8" > <html> > <img src='cid:_logo' ... /> > </html> > --b2_4478ad2b56a8002986ca07f18a261587-- > --b1_4478ad2b56a8002986ca07f18a261587 > Content-Type: text/plain; name="Lorem.txt" > Content-Transfer-Encoding: base64 > (snip) > --b1_4478ad2b56a8002986ca07f18a261587 > Content-Type: application/octet-stream; name="logoemail.png" > Content-ID: <_logo> > (snip) > --b1_4478ad2b56a8002986ca07f18a261587-- Dup of 692040. To bug opener: What is difference of your request from that bug? > Note: I checked the same message in both Outlook (2000) and GMail (in Chrome FWIW), > and both correctly see the attachment as expected. What is base of your "correctly"? Please distingush "correctness based on RFC" and "display as you want or expectation by developer of mail application which mail sender uses, who generated malformed mail if based on RFC for multipart/related". Gmail and Chrome looks to have quirks for malformed mail generated by Outlook and/or by mail applications based on Outlook's bad behvior on mail structure(if based on RFC), or by mail applications who never respects RFC.
Hey, I'm just trying to be helpful in reporting a bug here. No need to reply so aggressively. Correctly means "works as sender intended". 692040 seems to be about inline images, not attachments. The one it references 674473, with reams of arguments, does however, seem to be the same. From that, I gather that Outlook sends mails with this structure as well. So your attitude seems to be that it is more important to stick to the letter of the spec than to handle as intended emails from the most widely used email client in the world and which are also read properly by every other email client I have tried. That's just crazy. And it is entirely reasonable to assume that an email which displays as intended in other email clients but not in Thunderbird is a bug in Thunderbird, not everyone else's! Even if MS fixed Outlook tomorrow, there would be millions of old versions still sending out "incorrect" messages for years to come (and already in people's mailboxes). This needs a pragmatic solution not a pedantic head-in-the-sand attitude! I will mark this as a duplicate of 674473 if the system lets me.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
URL pointed in bug 674473 comment #20 by Joe Sabash is forum thread for discussion on the problem. > http://groups.google.com/group/mozilla.dev.apps.thunderbird/browse_thread/thread/c130fc04bf6c0d2e# I'm absolutely in favor of next in top of the thread by thread opener. > In the short term, we may want to consider backing out bug 351224 and friends, > since detaching multipart/related parts is much less important than > being able to see parts from (admittedly malformed) messages. Patch for bug 351224 is correct sort-out and clean-up of Tb's code(very confusing though, because the patch was proposed in inappropriate bug 351224), even though start of great patch creation work was not-so-important phenomenon reported to bug 351224 comment #0. However, patch for bug 351224(and succesors of it) should be limited to trunk builds only, once bug 674473 is found. I believe it shouldn't be landed on release build, until bug 674473 will be correctly fixed.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: