182627 - Message body is not displayed for some messages if view attachments inline is false (name in Content-Type/filename in Content-Disposition for mail-body/mail-body-part forces "attachment" for Tb even though real mail body)

Status: VERIFIED FIXED

(MailNews Core :: MIME, defect)

Description

[[e-mail]]

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

Comment 1

[[e-mail]]

Attachment: Test case

Comment 2

[Jean-Francois Ducarroz]

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

Comment 3

[Mike Cowperthwaite]

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.

Comment 4

[Mike Cowperthwaite]

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.

Comment 5

[Julian Orange]

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

Comment 6

[Jim Longino]

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).

Comment 7

[Mike Cowperthwaite]

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

Comment 8

[Mike Cowperthwaite]

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

Comment 9

[Mike Cowperthwaite]

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

Comment 10

[Mike Cowperthwaite]

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

Comment 11

[Mike Cowperthwaite]

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

Comment 12

[Aaron TEEJAY Trevena]

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: <[e-mail]>
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

Comment 13

[Aaron TEEJAY Trevena]

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

Comment 14

[Mike Cowperthwaite]

(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?

Comment 15

[Aaron TEEJAY Trevena]

(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.

Comment 16

[Aaron TEEJAY Trevena]

Attachment: complex email (html with plain alternative, inline and non-inline attachments)

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

Comment 17

[Aaron TEEJAY Trevena]

(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.

Comment 18

[[e-mail]]

(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.

Comment 19

[Mike Cowperthwaite]

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.

Comment 20

[David :Bienvenu]

Attachment: proposed fix

Comment 21

[Mike Cowperthwaite]

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.

Comment 22

[Mike Cowperthwaite]

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

Comment 23

[Scott MacGregor]

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.

Comment 24

[David :Bienvenu]

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

Comment 25

[Daniel Hoviss]

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

Comment 26

[Viktor Kabelac]

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: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: =?iso-8859-1?Q?R=FCcksendungen?=
Thread-Index: AckokTn1ZiXAwu1BQyKvraA/s70Q8QEXAqvgAXRrMMA=
From: "-cut out-" <[e-mail]>
To: "cut out" <[e-mail]>
Cc: "-cut out-" <[e-mail]>,
	<[e-mail]>

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

Comment 27

[WADA:World Anti-bad-Duping Agency]

(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.

Comment 28

[WADA:World Anti-bad-Duping Agency]

> 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.

Comment 29

[WADA:World Anti-bad-Duping Agency]

Attachment: Test mail(mail folder file) to observe "mail body is not displayed when name/filename is specified"(original report of this bug)

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.

Comment 30

[WADA:World Anti-bad-Duping Agency]

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").

Comment 31

[WADA:World Anti-bad-Duping Agency]

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.

Comment 33

[WADA:World Anti-bad-Duping Agency]

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

Comment 34

[Magnus Melin [:mkmelin]]

Still a problem on trunk.

Comment 36

[WADA:World Anti-bad-Duping Agency]

> 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?

Comment 37

[David :Bienvenu]

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.

Comment 38

[WADA:World Anti-bad-Duping Agency]

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">

Comment 39

[Radomir Zoltowski]

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.

Comment 40

[Radomir Zoltowski]

Attachment: Headers from an affected message body

More messages on request.

Comment 41

[WADA:World Anti-bad-Duping Agency]

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.

Comment 42

[Doug Hockin]

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.

Comment 43

[Phil Lacy]

Attachment: view with patch

(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.

Comment 44

[WADA:World Anti-bad-Duping Agency]

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

Comment 45

[Frank]

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

Comment 46

[timeless]

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

Comment 47

[Jim Avera]

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

Comment 48

[WADA:World Anti-bad-Duping Agency]

(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.

Comment 49

[WADA:World Anti-bad-Duping Agency]

(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.

Comment 50

[David Spector]

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.

Comment 51

[David Spector]

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.

Comment 52

[robert leleu]

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.

Comment 53

[Philippe Lebourg]

I don't know whether the issue was originally fixed but I find myself with the same kind of issue with an up-to-date TB version -as of 2019/06/27-:
when I receive a mail that is (probably) badly formatted, most messages (sorted by date) that came in before that date are not showing the content of their body in the message body pane. This concerns the list of successive messages from that message until ... some date in the past at which the message body show-up is resumed. It looks like it does not depend on the order of operations, sorting key etc. It looks rather like some dimension is read from the faulty message and serves as an index base to determine where to look at things. If the message is faulty, of course, the things go wrong.
Displacing the seemingly faulty message to another folder does not help.