User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20030925 A part of a MIME message (possibly the whole message) described by Content-Disposition: inline; filename="foo" is treated as an attachment. Without filename, everything is ok. Reproducible: Always Steps to Reproduce:

The part with filename `error' should be displayed inline.

I don't think it's a real error, see RFC 2183 <http://www.faqs.org/rfcs/rfc2183.html>, paragraph 2.3 ... But I can understand that you want to give priority to the 'inline' setting.

Hi Jo, thanks for your comment, it made me take a closer look at RFC 2183. It says there: [...] the [filename] parameter may be used on any MIME entity, even `inline' ones. These will not normally be written to files, but the parameter could be used to provide a filename if the receiving user should choose to write the part to a file. I think this is the desired behaviour. Differing bevaviour is of course not a bug, but I see it as a misfeature :-) BTW, I would not have brought this up if I could tell Mutt not to send a filename parameter.

From comment 0: > A part of a MIME message (possibly the whole message) described by > Content-Disposition: inline; filename="foo" > is treated as an attachment. Without filename, everything is ok. This *is* true for the message body; bug 182627. Using Mozilla 1.7b-0406, Win2K, the display of the attached message differs slightly from the report: If View|Display Attachments Inline is set, all four parts of the message are displayed. If it is not set, only the first two (unnamed) parts are displayed. Either way, three parts are shown in the attachment panel: "Part 1.2" "ok" and "error". See bug 147461.

This attachment expands on the original from Carter. There are two messages in this mbox; the first is like Carter's except it provides an initial plain-text message body, then the four text/html attachments. The second message is similar, except that the four attachments are image/gif instead. With Display Attachments Inline set, both messages display all four parts. With Display Attachments Inline turned off, the two *unnamed* text/html parts are still displayed, whereas all four of the image/gif parts are hidden. Carter, any comment? I'm not sure your original reported bug still exists, at least not in the form you attached it.

(In reply to comment #4 and #5) Hi Mike, since I do not see any Carter around, I will answer :-) Thanks for finding the connection with the other reported bug and for mentioning the importance of the presence of a file name there. I cannot comment on 1.7, with 1.6 the behaviour seems to be exactly the same as with 1.5. I had not tried switching on `view attachments inline'. I do think that the situation is clear though: The distinction between an attchment and inline data should be made depending on whether the Content-disposition value is `attachment' or `inline', not depending on the presence of a filename. Indeed the presence of a filename should not make a difference when displaying, it is just a hint of what name to use when saving the part to disk. Greetings, Carsten

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

Filter on "Nobody_NScomTLD_20080620"

with patch to Bug 551698, problem email with fetch by part on and view attmnts inline off. Really not sure if inline means to always be inline or if that is our expectation or what. Anyone up to speed on this bug might look and see if this is ok and now a dupe.

Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="=?KOI8-R?Q?=E2=C1=CC=C1=CE=D3_=EF=EF=EF_=EE=C1=D5=CB=C1-=F3=D7=D1=DA=D8?= =?KOI8-R?Q?_=28=CD=C1=D4=C5=D2=C9=C1=CC=D9_=CB_=D3=CF=D7=C5=D4=D5_?= =?KOI8-R?Q?=C4=C9=D2=C5=CB=D4=CF=D2=CF=D7=29=2Exlsx?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0*=KOI8-R''%E2%C1%CC%C1%CE%D3%20%EF%EF%EF%20%EE%C1%D5%CB%C1%2D%F3; filename*1*=%D7%D1%DA%D8%20%28%CD%C1%D4%C5%D2%C9%C1%CC%D9%20%CB%20%D3%CF; filename*2*=%D7%C5%D4%D5%20%C4%C9%D2%C5%CB%D4%CF%D2%CF%D7%29%2E%78%6C%73; filename*3*=%78 should be so Content-Transfer-Encoding: base64 Content-Disposition: attachment; Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="=?KOI8-R?Q?=E2=C1=CC=C1=CE=D3_=EF=EF=EF_=EE=C1=D5=CB=C1-=F3=D7=D1=DA=D8?= =?KOI8-R?Q?_=28=CD=C1=D4=C5=D2=C9=C1=CC=D9_=CB_=D3=CF=D7=C5=D4=D5_?= =?KOI8-R?Q?=C4=C9=D2=C5=CB=D4=CF=D2=CF=D7=29=2Exlsx?=" filename*0*=KOI8-R''%E2%C1%CC%C1%CE%D3%20%EF%EF%EF%20%EE%C1%D5%CB%C1%2D%F3; filename*1*=%D7%D1%DA%D8%20%28%CD%C1%D4%C5%D2%C9%C1%CC%D9%20%CB%20%D3%CF; filename*2*=%D7%C5%D4%D5%20%C4%C9%D2%C5%CB%D4%CF%D2%CF%D7%29%2E%78%6C%73; filename*3*=%78