If the message header (wrongly?) contains "Content-disposition: inline;" but you turn off inline attachments then the message body does not display :-(

looks like I don't correclty detect this is the main body part! I'll fix that...

This happens because the Content-Type includes a filename. The Content-Disposition header looks fishy, but doesn't cause the problem. Still present (1.7b); resetting the milestone from 1.3b.

If there is a filename specified in Content-Disposition, but not in Content-Type, then the body is displayed but the attachment panel also lists the body as an attachment. See also bug 229075.

How's progress on this bug? The work around to "view attachments inline" has a nasty side effect. If the reader then prints the email the attchment (viewed inline) is also printed. Julian

This is apparently still present in 1.8a5. I received a message today with the following characteristics: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline The message appeared empty, no indication of any attachments and my "Display attachments inline" was not checked. Once I checked "Display attachments inline", I could see the text and the paperclip appeared on the message envelope (inbox).

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

Attachment 151107 [details] (from the dupe) shows this same problem with: multipart/alternative part1: text/plain part2: text/html, filename="..."

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

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

Excuse the somewhat ungrammatic new summary, but it's more typical to search for "body" than "bodies."

This problem is particularly bad when sending complex multipart emails. This week this bug has cost me at least half a working day trying to work around it, before finding this bug and giving up. I am sending multipart/mixed emails with the content shown below (pdf attachment truncated), and on win xp TB 1.0 no content can be viewed and the attachment cannot be accessed at all unless 'display attachments inline' is ticked. Worse still is that with TB version 1.0.2-1.3.3 (20050513) on RH FC3, even ticking 'show attachments inline' has no effect and the attachment and message are unviewable and unaccessable. Notable differences between the same email created in thunderbird itself (which is handled correctly in both versions on both operating systems) are 1) No encoding set for multipart/mixed and multipart/alternative parts in thunderbird version of email 2) Encoding for text and html is 7 bit in thunderbird version of email 3) Thunderbird email seems to behave correctly in thunderbird Worth noting that the filename is included in the content-disposition of the attached pdf in both versions. Problematic email source : workaround of setting multipart mime parts to 7bit encoding fixes problems with windows version of thunderbird but leaves attached pdf unreadable in linux version. Received: from localhost.localdomain ([192.168.254.10]) by xxxx.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 11:03:31 +0100 Content-Transfer-Encoding: binary Content-Type: multipart/mixed; boundary="----=_NextPart_000_6F74_01C5D884.A1ED7F4A" X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 MIME-Version: 1.0 X-Mailer: MIME::Lite 3.01 (F2.73; T1.15; A1.67; B3.01; Q3.01) Date: Mon, 24 Oct 2005 10:01:04 UT From: <aaron@xxxxx> To: <aaron@xxxxxx> Subject: Test Return-Path: <aaron@xxxxxx> Message-ID: <FSERVERLmmTLBVOdzeZ00000050@xxxxxxx> X-OriginalArrivalTime: 24 Oct 2005 10:03:31.0359 (UTC) FILETIME=[300F62F0:01C5D882] This is a multi-part message in MIME format. ------=_NextPart_000_6F74_01C5D884.A1ED7F4A Content-Transfer-Encoding: binary Content-Type: multipart/alternative; boundary="----=_NextPart_001_6F75_01C5D884.A1ED7F4A" MIME-Version: 1.0 X-Mailer: MIME::Lite 3.01 (F2.73; T1.15; A1.67; B3.01; Q3.01) Date: Mon, 24 Oct 2005 10:01:04 UT ------=_NextPart_001_6F75_01C5D884.A1ED7F4A Content-Disposition: inline Content-Length: 14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" This is a test ------=_NextPart_001_6F75_01C5D884.A1ED7F4A Content-Disposition: inline Content-Length: 23 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" <h1>This is a test</h1> ------=_NextPart_001_6F75_01C5D884.A1ED7F4A-- ------=_NextPart_000_6F74_01C5D884.A1ED7F4A Content-Disposition: attachment; filename="rates.pdf" Content-Transfer-Encoding: base64 Content-Type: application/pdf; name="rates.pdf" JVBERi0xLjMNJeLjz9MNCjE4IDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0v TyAyMSANL0ggWyAxNzk3IDI1MSBdIA0vTCA4NTc5NSANL0UgNzkyMDcgDS9O IDIgDS9UIDg1MzE3IA0+PiANZW5kb2JqDSAgICAgICAgICAgICAgICAgICAg working thunderbird email source : Received: from [10.74.3.2] ([10.74.3.2]) by xxxx with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2005 14:14:29 +0100 Message-ID: <4358E923.4020204@fsite.com> Date: Fri, 21 Oct 2005 14:12:03 +0100 From: aaron trevena <aaron@xxxxxx> User-Agent: Mozilla Thunderbird 1.0.2-1.3.3 (X11/20050513) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aaron Trevena <Aaron@xxxxx> Subject: test with attachments Content-Type: multipart/mixed; boundary="------------000306000806050402010606" Return-Path: aaron@xxxxxxx X-OriginalArrivalTime: 21 Oct 2005 13:14:29.0218 (UTC) FILETIME=[5E3CAC20:01C5D641] This is a multi-part message in MIME format. --------------000306000806050402010606 Content-Type: multipart/alternative; boundary="------------020104020202060200030807" --------------020104020202060200030807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit *some test* HTML --------------020104020202060200030807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> <b>some test</b> HTML <br> </body> </html> --------------020104020202060200030807-- --------------000306000806050402010606 Content-Type: application/pdf; name="codetraits.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="codetraits.pdf" JVBERi0xLjQNJeLjz9MNCjEgMCBvYmoNPDwgDS9UeXBlIC9QYWdlIA0vQ29udGVudHMgMyAw IFIgDS9SZXNvdXJjZXMgMiAwIFIgDS9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0gDS9QYXJl bnQgMTM3IDAgUiANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDS9UaHVt YiAxNjIgMCBSIA0+PiANZW5kb2JqDTIgMCBvYmoNPDwgDS9Gb250IDw8IC9GNTEgNzkgMCBS

workaround in my previous comment seems to work for thunderbird 1.0.7-1.1.fc3 (20050929) on RH FC3

(In reply to comment #12) > I am sending multipart/mixed emails with the content shown below (pdf > attachment truncated), Rather than pasting your message source into a comment, it would be more useful in the future if you would save the message as a .EML file and attach it to the bug. What is this "MIME-lite" and why should we trust it be generating correct source? > on win xp TB 1.0 no content can be viewed and the attachment cannot be > accessed at all unless 'display attachments inline' is ticked. Assuming this is in reference to the MIME-lite-generated message you supplied: I do not see this, TB 1.0.7 and 1.5b2-1006, Win2K. The message text "this is a test" is visible as HTML or as plain, regardless of the setting of Display Attachments Inline. The attachment is visible in the attachment window. It is not shown inline, but inline display of Acrobat files is not supported. > Worse still is that with TB version 1.0.2-1.3.3 (20050513) on RH FC3, even > ticking 'show attachments inline' has no effect and the attachment and message > are unviewable and unaccessable. Maybe; I can't test this. > Notable differences between the same email created in thunderbird itself > (which is handled correctly in both versions on both operating systems) are > 1) No encoding set for multipart/mixed and multipart/alternative parts in > thunderbird version of email > 2) Encoding for text and html is 7 bit in thunderbird version of email In this case, the source Thunderbird generates appears to be correct. Why would you want Content-Transfer-Encoding to be "binary" for a text message? (See RFC 2045 sec 6.2 <http://www.faqs.org/rfcs/rfc2045.html>.) The default value of this header is "7bit" which is correct for the individual readable portions of the message, for the multipart conglomerations, *and* for base64-encoded attachments; binary would only be appropriate for pure binary data that hasn't been transformed by an encoding. That said: in my install, at least, TB has no problems with the "binary" value. > Worth noting that the filename is included in the content-disposition of the > attached pdf in both versions. Well, yes; for an attachment, that is entirely appropriate. Far more noteworthy is that none of the text/ or multipart/ parts has a filename, which means that your symptom, even if there *is* a bug on TB's part, is not the same as this bug. > workaround of setting multipart mime parts to 7bit encoding fixes problems > with windows version of thunderbird but leaves attached pdf unreadable in > linux version. What exactly is meant by this? You're implying here that the Acrobat file *is* readable inline in Thunderbird on Linux -- is that the case? Ever? Can you supply a sample message where this happens?

(In reply to comment #14) > (In reply to comment #12) > What is this "MIME-lite" and why should we trust it be generating correct > source? MIME::Lite is a significant package that is the defacto standard for building MIME messages with Perl. Given the huge ammount of email sent or processed using Perl it is pretty important that a) it is correct and b) thunderbird works with it. > > on win xp TB 1.0 no content can be viewed and the attachment cannot be > > accessed at all unless 'display attachments inline' is ticked. > > Assuming this is in reference to the MIME-lite-generated message you supplied: > I do not see this, TB 1.0.7 and 1.5b2-1006, Win2K. The message text "this is a > test" is visible as HTML or as plain, regardless of the setting of Display > Attachments Inline. The attachment is visible in the attachment window. It is > not shown inline, but inline display of Acrobat files is not supported. That was not a case with the version I had installed - I have upgraded it and I believe the problem was not fixed, the same applies to TB on RH FC3 (both are TB 1.07). When provided with binary encoded MIME Parts no message content is shown at all and no attachments are accessable at all, unless the 'display attachments inline' option is set. It looks to me that in this case TB must be regarding the binary part containing plain text and additional parts as a binary attachment and therefore not displaying it. This behaviour seems quirky at best and certainly contrary to user expectations - if I receive a mixed parts email I expect the mail client to at least provide me with the text part in the main part, rather than nothing at all - gmail, pine, outlook and pretty much every other email client in the world manages this. > > Worse still is that with TB version 1.0.2-1.3.3 (20050513) on RH FC3, even > > ticking 'show attachments inline' has no effect and the attachment and message > > are unviewable and unaccessable. > > Maybe; I can't test this. Fixed in updated version of TB on RHFC3, but still requires workaround. > > Notable differences between the same email created in thunderbird itself > > (which is handled correctly in both versions on both operating systems) are > > 1) No encoding set for multipart/mixed and multipart/alternative parts in > > thunderbird version of email > > 2) Encoding for text and html is 7 bit in thunderbird version of email > > In this case, the source Thunderbird generates appears to be correct. Why > would you want Content-Transfer-Encoding to be "binary" for a text message? > (See > RFC 2045 sec 6.2 <http://www.faqs.org/rfcs/rfc2045.html>.) Because you can and it isn't wrong, default behaviour for MIME::Lite for some reason - I'll email the authors about it as I don't think that is correct nonetheless TB should handle it correctly. > The default value of this header is "7bit" which is correct for the individual > readable portions of the message, for the multipart conglomerations, *and* for > base64-encoded attachments; binary would only be appropriate for pure binary > data that hasn't been transformed by an encoding. > > That said: in my install, at least, TB has no problems with the "binary" value. Thats nice for you :) Sucks for me and anybody else who experiences this problem :( > > Worth noting that the filename is included in the content-disposition of the > > attached pdf in both versions. > > Well, yes; for an attachment, that is entirely appropriate. Far more > noteworthy is that none of the text/ or multipart/ parts has a filename, which > means that your symptom, even if there *is* a bug on TB's part, is not the same > as this bug. A filename isn't required for those IIRC, there is a significant bug in how MIME is handled in TB and the symptoms I have come accross are consistent with those of the original bug added, the original bug may be an edge-case of this one as the further problems I have encountered are broader reaching. > > workaround of setting multipart mime parts to 7bit encoding fixes problems > > with windows version of thunderbird but leaves attached pdf unreadable in > > linux version. > > What exactly is meant by this? You're implying here that the Acrobat file *is* > readable inline in Thunderbird on Linux -- is that the case? Ever? Can you > supply a sample message where this happens? > I meant that in the old version of TB, the attached PDF wasn't readable when saved, this has been fixed in the updated version. Working through this problem further I have found that Thunderbird (latest on windows and linux) cannot handle the email attached correctly and fails to display the inline image inline, even when 'display attachments inline' is set, and when 'display attachments inline' is unset displays no content in the message pane and only 1 of the 2 attachments is shown in the attachments box (it opens correctly). From my experience with it and the other email clients I have been dealing with, TB seems incredibly flakey in how it handles attachments and MIME. Not impressed at all.

This email shows problems in how TB 1.07 handles complex nested MIME

(In reply to comment #16) > Created an attachment (id=200607) [edit] > complex email (html with plain alternative, inline and non-inline attachments) > > This email shows problems in how TB 1.07 handles complex nested MIME > I have just noticed that if the multipart/related MIME Part is binary encoded rather than 7bit then even with 'display attachments inline' nothing is displayed in the latest version (1.07) of TB on both win and linux.

(In reply to comment #17) >the latest version (1.07) of TB 1.07 is the latest release, but 1.5b2 is the latest version.

With the attached mail, I do see the symptom. It is basically same thing as originally described here: the filename on the Content-Type and Content-Disposition headers prevents the HTML message body from being seen. On testing with this, I see that either my comment 4 was mistaken, or the behavior has changed since then. Now (1.0.7 and 1.5b2), a filename on either Content-Type or Content-Disposition causes the message body not to display unless Display Attachments Inline is checked. There's apparently an additional symptom that might warrant its own bug: with this message, selecting "Message Body As Plain" doesn't load the text/plain part but rather loads the HTML part and converts it to plain text. I guess this is either because the entire message is multipart/mixed rather than multipart/alternative, or because the alternative to the text/plain part is multipart/related rather than text/html. The attached message was broken in two ways: first, the fudged cid: link in the HTML message did not match the fudged Content-Id of the image. Second, the images were specified as "application/jpeg" -- Mozilla recognizes "image/jpeg". With those items fixed, both images display as expected (once Display Attachments Inline is checked). The pasted-in message did not have the filenames, and I doubt the bug was actually seen with that particular message.

David, I notice your patch has been checked in. I'm puzzled that it appears to be IMAP-only, as this bug manifests in the POP/Local case as well. But at any rate, it doesn't appear to work: I'm still seeing the message body suppressed with Display Attachment Inline turned off, for messages that specify a filename. TB 1.6a1-0105.

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

Comment on attachment 206280 [details] [diff] [review] proposed fix approving, although mcow says this patch may not be working for him. It still may be the right thing to checkin though.

actually, sorry, my fix has nothing to do with this particular test case, but does fix bugs with this same summary.

For what it's worth, this seems to be a problem that is generated by MAC users, and is reproducable here. I can see only messages that do not contain attachments, and often it is MAC systems that add strange .eml attachments -Daniel

I have just noticed pretty much the same problem today and it seems like it's been around here for 4 years. How come? Or is it a different bug? I am having a multipart message from MS Exchange that has some JPEGs, a text/html part and a text/plain part. If "display attachments inline" is off, there is no trace of a message body displayed, NOR are the text/* attachments offered to be opened as attachments. My previous mailer, TheBat! could do this. Why not Thunderbird? The message goes like this (on request, I can supply the verbatim copy of the message): MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C932C0.B86F55A0" X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: =?iso-8859-1?Q?WG=3A_R=FCcksendungen?= Date: Mon, 20 Oct 2008 16:32:46 +0200 Message-ID: <EDF2A6627CF2004B97FDD0EE61A814C2021F6B1F@groener-ex2.groener.ulm> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?iso-8859-1?Q?R=FCcksendungen?= Thread-Index: AckokTn1ZiXAwu1BQyKvraA/s70Q8QEXAqvgAXRrMMA= From: "-cut out-" <hlienhart@xxxxxx.de> To: "cut out" <cut.out@xyxyxyxyxy.de> Cc: "-cut out-" <slang@xxxxxx.de>, <cut.out@xyxyxyxyxy.de> This is a multi-part message in MIME format. ------_=_NextPart_001_01C932C0.B86F55A0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_002_01C932C0.B86F55A0" ------_=_NextPart_002_01C932C0.B86F55A0 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C932C0.B86F55A0" ------_=_NextPart_003_01C932C0.B86F55A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hallo XXX, ... ------_=_NextPart_003_01C932C0.B86F55A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML xmlns:v =3D "urn:schemas-microsoft-com:vml" xmlns:o =3D=20 "urn:schemas-microsoft-com:office:office" xmlns:w =3D=20 "urn:schemas-microsoft-com:office:word" xmlns:x =3D=20 "urn:schemas-microsoft-com:office:excel" xmlns:p =3D=20 "urn:schemas-microsoft-com:office:powerpoint" xmlns:a =3D=20 "urn:schemas-microsoft-com:office:access" xmlns:dt =3D=20 "uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s =3D=20 "uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs =3D=20 "urn:schemas-microsoft-com:rowset" xmlns:z =3D "#RowsetSchema" xmlns:b = =3D=20 "urn:schemas-microsoft-com:office:publisher" xmlns:ss =3D=20 "urn:schemas-microsoft-com:office:spreadsheet" xmlns:c =3D=20 "urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:oa =3D=20 "urn:schemas-microsoft-com:office:activation" xmlns:html =3D

(In reply to comment #26) Although "mail body is not displayed" is same, this bug's "some messages" is mails which have name(Content-Type:) or filename(Content-Disposition:) parameter in mai body(or mail body part in multipart/mixed etc.) See all comments before your comment and attached test mails, please. In your case, mail structure is as follows. > Content-Type: multipart/mixed; boundary="NextPart_001" > --NextPart_001 > Content-Type: multipart/related; type="multipart/alternative"; boundary="NextPart_002" > --NextPart_002 > Content-Type: multipart/alternative; boundary="--NextPart_003" > --NextPart_003 > Content-Type: text/plain > --NextPart_003 > Content-Type: text/html > --NextPart_003-- > --NextPart_002-- > --NextPart_001-- Because multipart/mixed, first part in it is considered mail body part. In your case, the mail body part is multipart/related. multipart/related is for "HTML source" + "inline data such as image pointed by <img> in HTML". But, there is no start parameter in the multipart/related, and the first part of the multipart/related is multipart/alternative. I don't know whether this structure is proper for "mail body of multipart/related in multipart/mixed" or not. Since Tb looks to render this mail body part when "Display Attachments Inline" is enabled, Tb probably thinks the part is "attachment". It's same phenomenon as this bug - Tb thinks mail body with filename(or name) is "attachment". However, I think cause of your case is different(different code change in different module will be probably required). To Viktor Kabelac: I couldn't find description relates to your case in next document. > https://wiki.mozilla.org/Thunderbird:Fix_some_longstanding_bugs I recommend you to open separate bug with attaching test mail, after search bugzilla.mozilla.org well.

> See all comments before your comment should have been > See all comments before your comment except Comment #12 Viktor Kabelac, Comment #12 is similar case to yours.

Mail folder file contains 6 mails: Mail-1 to mail-3. multipart/mixed case. (1) Subject: Bug-471876-Test-01 : filename in first part (2) Subject: Bug-471876-Test-02 : name in first part (3) Subject: Bug-471876-Test-03 : no name/filename in first part Difference among test mails is header of first part only. All other parts are identical in all three mails. Mail-4 to mail-6. Same case as original report. (4) Subject: Bug-182627-test-case-1 : original-case, name/filename for mail body (5) Subject: Bug-182627-test-case-2 : filename for mail body (6) Subject: Bug-182627-test-case-3 : name for mail body With "Display Attachments Inline"=No, when not multipart, mail body with name or filename is displayed in attachment box. But when multipart/mixed, mail body(first part of multipart/mixed) is not displayed in in attachment box.

Problems observed with test mails by "Display Attachments Inline"=Off; (a) Tb always thinks mail body or part is "attachment", if name or filename is specified in header. (b) Tb doesn't display mail body or part if Tb think it an "attachment", even when data is displayable(text/html, text.plain). It occurs even on mail body of simple mail or mail body of multipart(first part when multipart/mixed) which is displayable(text/html, text/plain). (c) When Tb thinks first part of multipart/mixed(==mail body) is "attachment", Tb doesn't display it in attachment box if the part is displayable type. Tb probably considers it "attachment" at some steps(then not rendered), but as "displayable mail body" at other steps(then not displayed as "attachment").

As Mike Cowperthwaite says in Comment #3, phenomenon of comment #0 is easily observed by follwoing header only(no multipart mail). > Content-Type: text/plain; name="xxx.txt" This bug is probably cause of Bug 477981.

Adding "name & filename" to summary, for ease of search.

Still a problem on trunk.

> Keyword:fixed1.8.1 (set by David on 2006-02-06) Your patch is for multipart/alternative which is irrelevant to original case(comment #0). multipart/alternative case is merely a part of additional comments. It can be said as "same external symptom as this bug" but "completely different probleem from original problem of this bug", although "if Tb considers as attachment, mail body/mail body part is not displayed" is common. And you say next in Comment #24. > actually, sorry, my fix has nothing to do with this particular test case, > but does fix bugs with this same summary. David Bienvenu, Keyword:fixed1.8.1 is too confusing, isn't it?

Sure, I've removed the keyword - I added that so the 1.8.1 drivers would know that the approved patch had landed but they don't care anymore.

Checked with attachment of Comment #29, with Tb 3.0.3. - Simple text/plain mail, with name parameter - Simple text/plain in multipart/mixed mail, with name/filename parameter Mail-body with name and mail-body part in multipart/mixed with name/filename was displayed normally in attachment pane. Behaviour is consistent now for above cases, - displayed as attachment at message display box. - displayed as attachment at attachment box in any cases. as explained in source code. > http://mxr.mozilla.org/comm-central/source/mailnews/mime/src/mimei.cpp#819 > 819 mime_create (const char *content_type, MimeHeaders *hdrs, > 820 MimeDisplayOptions *opts) > 821 { > 822 /* If there is no Content-Disposition header, or if the Content-Disposition > 823 is ``inline'', then we display the part inline (and let mime_find_class() > 824 decide how.) > 825 > 826 If there is any other Content-Disposition (either ``attachment'' or some > 827 disposition that we don't recognise) then we always display the part as > 828 an external link, by using MimeExternalObject to display it. > 829 > 830 But Content-Disposition is ignored for all containers except `message'. > 831 (including multipart/mixed, and multipart/digest.) It's not clear if > 832 this is to spec, but from a usability standpoint, I think it's necessary. > 833 */ "text/xxx part with name/content-disposition/filename in multpart/alternative" case, in which what should be is unclear, is similar issue but different problem is involded. This "similar to but different from this bug" case is being processed by bug 551698. > Content-Disposition: multpart/alternative; boundary="_----------=_1268324732523914" > > --_----------=_1268324732523914 > Content-Disposition: inline; filename="message.html" > Content-Transfer-Encoding: quoted-printable > Content-Type: text/html; name="message.html">

I have been experiencing the same behaviour on all Thunderbirds for the last 10+ years. I don't know if the problem I experience is related to this bug or the mentioned bug 551698. Message body is not displayed when it is a multipart HTML plus a non-displayable attachment, originated from an proprietary application based on PERL. It suggests that the source of problem lies in between PERL and Thunderbird and has been there uncaught for years. I see that this is MIME-tools 5.427 module. Account is an IMAP one connected to MS Exchange. The bit you probably miss is that when I receive the message, it is not being displayed (body is blank, no attachment listed, whatsoever). Status bar tells that the message is being downloaded, but it never finishes. Displaying message in a new window does not work either. Message is still being downloaded. However, when I select 'Edit As New...' the message is successfully downloaded from server and displayed correctly in a new window. Yet, when I close the new 'Edit As New...' message window, the message is *correctly* re-displayed in the main view window, after selecting it again and even after restarting Thunderbird. It clearly indicates, that there is a stale transfer problem from an IMAP server during regular work for main window. 'Edit As New...' function however successds and caches the body correctly for subsequent display requests. It is still connected with 'Content-Disposition: inline' header, but the clue would be to investigate further differences in implementation between main window download and 'Edit As New...' download. For your quick reference, attached are the most important headers which make the difference. Hope it helps.

More messages on request.

Because many mail data for different problem from original problem of comment #0 were pasted to this bug, some comment posters looks to be confused. And, as a result of the confusion, some addtional comments were added for different problem from original problem of comment #0 and mail data for different problem from original problem of comment #0 and comment #1 were pasted again. However, original problem of comment #0 is for attachment 107761 [details] which is attached to comment #1. To avoid further confusions, I paste mail data of attachment 107761 [details] for original problem of this bug's comment #0. Bug summary is mainly for next simplest text/plain mail attached to comment #1. As name/filename is specified, Tb considers mail body text in the simplest text.plain mail as attachment instead of mail body. (Simplest text/plain mail for original problem of comment #0) > Content-type: text/plain; charset=US-ASCII; name="BDY.TXT" > Content-disposition: inline; filename="BDY.TXT" > Content-transfer-encoding: 7bit > > Hi folks. Can any of you play a home game on Monday the 9th of December > against Allenburys? > > Cheers, > > Aaron. (In reply to comment #40) > Headers from an affected message body Radomir Zoltowski, why can your problem be same problem as original problem of comment #0/comment #1? Please note that phenomena of similar external symptom(msg-body/msg-body-part is not displayed as you expected) are not always same problem, as crashes are not always same problem even if "Crash" is common. Your case has next headers. > Content-Type: text/plain; charset="utf-8" > Content-Transfer-Encoding: base64 > Content-Type: text/html; charset="utf-8" > Content-Transfer-Encoding: base64 AFAIR, problem related to base64 encoded mail body existed. Search bugzilla.mozilla.org well for problem relates to base64 encoded mail body via "Advanced Search" of bugzilla.mozilla.org, please.

I have received exactly this kind of email from Delta airlines and have the same problem. If I have "Display attachments inline" unchecked, the message body is completely blank and there is no indication at _all_ that there is an attachment with this email. In general I don't want to show attachments inline and there should be something in the message header area that indicates there are attachments not displayed -- there should be a list of the attachments and I should be able to open them each individually.

(In reply to comment #42) > I have received exactly this kind of email from Delta airlines and have the > same problem. Bug 551698 patch applied renders this view of last sample msg. I think this is what is needed as it shows parts as attachments. If you cc to bug 551698 and watch for check-in and then try a nightly build to confirm then we can dupe this bug.

Checked with next trunk build. > Mozilla/5.0 (Windows NT 5.1; rv:2.0b4pre) Gecko/20100806 Shredder/3.2a1pre Mail body part of name=xxx was shown with View/Display Attachments Inline=Off, although regression of bug 583419 occurs as you know. (1) name=mail.eml in Content-Type of mail body > Content-Type: text/plain; charset="iso-8859-1"; name="mail.eml" (2) name=mail.eml in Content-Type of mail body part of multipart/mixed > Content-Type: multipart/mixed; boundary="Bdy" > --Bdy > Content-Type: text/plain; charset="iso-8859-1"; name="mail.eml" => FIXED/VERIFIED

I'm sorry but I'm not all that tech savvy. It looks like a fix has been found however I can't decipher what I need to do on my end to so I can read my emails. Thx Frank Battelle

wait for the next thunderbird release-- probably 3.3a1 if i'm correctly reading bug 551698

This bug appears to exist in TB 32.0a1 in 2014. So it may have regressed or not been completely fixed. Because this bug report is so long an cluttered, I created a new Bug 1018606 with the current test case

(In reply to Jim Avera from comment #47) > This bug appears to exist in TB 32.0a1 in 2014. So it may have regressed or not been completely fixed. That bug is for following problem, as you correctly stated in bug summary. > HTML attachment is lost/invisible unless Display Attachment Inline is on This bug is for "Message body" or "Messae body part". And, in that bug, "Messae body part" is displayed even though "first part of multipart/mixed"=="Message body part" has name parameter. i.e. This bug doesn't occur in that bug == This bug is already fixed. That bug is absolutely different problem from this bug, even if "something is not displayed if View/Attachments Inline=false is set" part is same. Keep "one prblem per bug", please.

(In reply to Jim Avera from comment #47) Original bug summary by you was pretty confusing and misleading, rather wrong from perspective of mail structure. > HTML attachment is lost/invisible unless Display Attachment Inline is on "What was lost/invisible unless Display Attachment Inline is on" was "Message Body part in multipart/mixed" in your bug 1018606. i.e. This bug 182627 came back after fix verification on 2010-08-07.

Still apparently present 11 years later, in TB 24.6.0. But there are many similar bugs in which message bodies are not displayed, so it is difficult to tell them apart. Menu > View > Display Attachments Inline can be set either way, but no message bodies are shown. I don't know what option I changed to make this happen. TB is so baroque and delicate. But there is nothing better available for Windows 8, so far as I can see.

Problem cause is experimenting with different layouts (Menu > View > Layout > ...) Problem is empty message pane until TB is closed and reopened. Hope this helps someone.

True always for TH 38.8.0 The problematic message, produced by Sbackup (a Linux backup software) is "headed" as Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="sbackup.log" but is in fact UTF-8, and doesn't display any attachment sign. Menu > View > Layout > ... does display the message, and checking the unicode works.