From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523 BuildID: 2002052319 Mozilla seems to be ignoring the content-disposition header on received messages when JPEGs are involved. As covered in bug 55657 and others, this causes Mozilla to wait for the entire message to be downloaded before displaying anything. This can be a pain when someone insists on sending multiple 300 dpi photo scans at you via Outlook Express. Unfortunately, since OE seems to set content-disposition: attachment on the JPEGs, I don't think I can blame MS for it ... Since this bug involves Mozilla ignoring a header in a message, I believe it's a separate issue from 55657, which covers disabling inline attachments. Reproducible: Always Steps to Reproduce: 1. Receive message with large JPEG attachment(s) 2. Open message 3. Wait for everything to be downloaded.

This message also has multipart/alternative sections, if that is helpful.

See bug 98360 also...

I have also observed this behavior on Mozilla 1.0.0 (Gecko/20020609) installed via the Red Hat RPMs, and on the 1.1a Linux Build (Build ID: 2002061108).

I've played with the 'Content-Disposition' header and it seems that Mozilla Mail ignores it completely. It takes only the 'Content-Type' into account and if it is some of 'text/plain', 'text/html', 'image/gif', 'image/jpeg' and so on "basic" types it displays these parts inline no matter if the 'Content-Disposition: attachment'. Types like 'application/octet-stream' are not displayed inline even if 'Content-Disposition: inline'. I suppose if the 'Content-Disposition: inline' but the type could not be handled to be previewed inline to act like attachment, just then. And every 'Content-Disposition: attachment' or unknow value to be treated as attachment. Should someone change the status of this bug to "NEW"?

I have also observed this behaviour in Mozilla 1.3=Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.3) Gecko/20030312. Opening an email with one part being Content-Disposition: attachment Content-Type: text/csv or Content-Type: text/comma-separated-values shows up the whole file inline. The mail is multipart/mixed, the first being multipart/alternative (with text/plain and text/html), ans the second is a csv-file.

So there should be "Do not display inline attachments" (other than the first part) option instead of "Display Attachments Inline" (under the "View" menu) and when this option is not checked only attachments marked "inline" should be displayed. When this option is checked no attachments would be shown inline (after all this is what Bug 55657 was for). If there's an inline part/attachment of PDF (for example) type and plugins are not enabled for Mail & News, such should be treated as "attachment". When plugins are enabled for Mail & News but there's no plug-in for handling PDFs a helper application should popup opening the attachment from/stored in temporary file/place on the disk. The proper handling of multipart MIME messages (there are many other features which would be nice to be handled, like auto-selecting the proper part of a multipart/alternative message with 'Content-Language' set on the different parts, etc.) is very important and such basic functionality meant by the 'Content-Disposition' header should work smoothly and without the current quirks.

Ref: Content-disposition is covered by RFC 2183 (superceding RFC 1806): http://www.faqs.org/rfcs/rfc2183.html Confirming, but reducing severity to Normal. OS, Platform => All. I think Stanimir's idea for changing the menu makes sense.

Clarification to my Comment 4: The line starting with: helper application should popup opening the attachment should read: helper application should popup (automatically when previewing the message) opening the attachment Some additions: The current behavior probably tolerates the old style messages where the attachments are uuencoded in the message body and they have no attributes like 'Content-Disposition'. One possible solution/behavior is to treat the attachments in such messages to have 'Content-Disposition: attachment' always. Of course there could be left the old option "Display Attachments Inline" (in addition to the new proposed one, see my Comment 4) but this one would/should work only for this type of messages (uuencoded) and will uncessary complicate the UI in vafor of some deprected format.

With imap the aggravation is doubled - 1st you have to wait for a long time for the message to display. Then, every attachment is re-downloaded when you use "save" or "save all".

Just today I got 12MB of digital camera images, thunderbird and mailnews were unable to download and display the message in 20 minutes using the company 10Mbps net.access. Web frontend for the mailserver let me download the whole bunch in under a minute.

Olli Männistö, I believe you need to find a different bug. This bug is about a very specific issue, unrelated to re-downloading (bug 46233) or slow downloading.

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

See bug 229075. Maybe the best thing to do with this menu would be to make it a submenu, maybe something like: View Attachments Inline > ( ) All (x) As specified in message ( ) None -------- [x] Images The 'Images' checkbox would allow display of inline image/* types to be suppressed while still allowing text/* and message/rfc822 attachments to be shown inline. (Are there other attachment types that can be displayed natively?)

(In reply to comment #13) > Maybe the best thing to do with this menu would be to make it a submenu, It is better to keep this option simple as it is now (just one). There's only need to correct its behavior and most probably change its label. > The 'Images' checkbox would allow display of inline image/* types to be > suppressed while still allowing text/* and message/rfc822 attachments to be > shown inline. > (Are there other attachment types that can be displayed natively?) The "VCard" is one I've thought of. The preference to "Disable Plug-ins for Mail&News" should be all one may need. All internal types should be shown whenever appropriate and if the option this bug is about become stg like "Don't display multi-parts" - not checked. There may are times when an internally handled type is not appropriate to show/execute, like "text/javascript". JavaScript may be either suppressed - there's already an option, or it could be hardcoded not to execute such most probably unsafe parts. Functionality like "Don't display images", etc. should go with the "View -> Message Body As" options and other places. The thing with not showing inline parts is more about the ability not to fetch the whole message (from an IMAP, for example) to show its body/first part - this is what this bug should focus on, IMHO.

I vote to idea by Mike Cowperthwaite in Comment #13. But I think including all options in View menu is difficult. How about adding "Customize" option to attachment display options like Character Coding? I love current simple flip/flop option too. So my proposal is as follws. (A) View menu structure - View - Attachments - Display all attachments inline if diaplayable, or display all attachments as attachment. (Flip/Flop, Same as current option setting) - Cutomized-option-1 - Cutomized-option-2 | - Cutomized-option-N ==================== - Cutomize ==================== - Other view options (B) Customization panel (Helper Application definition like) Content-Types are specified by user like Helper Application. User option is applied like Message Filter. - if matched, then stop further matching. (Note: # indicates my favarites) 1) text/plain #Always Inline, Always Attachment or Content-Disposition base. 2) text/html Always Inline, #Always Attachment or Content-Disposition base. 3) image/jpeg, image/png Always Inline, Always Attachment or #Content-Disposition base. 4) application/ms-word ### DELETE AND SEND IT BACK TO SENDER NINE TIMES. 5) message/rfc822 #Always Inline, Always Attachment or Content-Disposition base. If inline, Inline or #Attachment for nested message/rfc822 6) multipart/alternative Order of selection - #Normal(last first) or Reversed(first first). Display all of parts in multipart/related or #NOT. 7) text/*, image/*, application/* etc. Always Inline, #Always Attachment or Content-Disposition base. 8) Others Always Inline, #Always Attachment, Content-Disposition base, etc.

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

howdy y'all, [1] my tb info ... Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051201 Thunderbird/1.5 - Build ID: 2005120115 [2] REQUEST = change "Product" from "mozilla application suite" to "core" since th following tbird bug ... - Attachments with "Content-Disposition: attachment" shows automatically https://bugzilla.mozilla.org/show_bug.cgi?id=290019 ... was duped to this one, shouldn't this bug be "core" now? [3] obligatory painfully obvious comment = this problem exists in tb15. take care, lee

for historical reasons, this is done intentionally and has been since Netscape 2.0 and Mozilla 1.0...we display inline the attachments we know how to display unless you turn off view | attachments inline. Perhaps we could add a pref for respecting the content-disposition for all attachment types.

should be marked enhancement, and summary amended to match?

Also, some kind of sane 'max_size' setting, so vCards, and small email signature graphics will display, but large pictures from Aunt Susans last vacation won't.

Bump. It's been 10 years since this was filed, and TB 12.0.1 *still* has this problem. Is this a record? RFC2183 is explicit; see the extracts below. It's plain wrong to automatically display an attachment which is marked 'Content-disposition: attachment'. The user must instead take "some further action". The 'display Attachments Inline' checkbox isn't enough, because (a) it's on by default, and (b) it also applies to attachments which are *intended* to be inline (2.1). Here's why this is a problem. I automatically email out html attachments. These are primarily JavaScript and SVG files, and MUAs can't hope to render them. So, I don't want them to even try, because they'll end up showing some pointless and arbitrary text extracted from some random part of the page. There's a perfect answer to this: a MIME-compliant MUA won't try to render a 'Content-Disposition: attachment'. Outlook gets this right, TB doesn't. ========================================================================= RFC 2183: ---- 2. The Content-Disposition Header Field Content-Disposition is an optional header field. In its absence, the MUA may use whatever presentation method it deems suitable. ---- 2.1 The Inline Disposition Type A bodypart should be marked `inline' if it is intended to be displayed automatically upon display of the message. ---- 2.2 The Attachment Disposition Type Bodyparts can be designated `attachment' to indicate that they are separate from the main body of the mail message, and that their display should not be automatic, but contingent upon some further action of the user. ----