User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release) Build ID: 20140428193603 Steps to reproduce: The attachment in emails from Interactive Brokers is completely invislble - neither displayed inline or as a save-able attachment. If View->Display Attachment Inline is on, then the attachment becomes visible. This sounds exactly like a supposedly-longago-fixed bug 182627 from 2002. The messages (sample attached) looks like this: multipart/mixed first part has Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename=xxx (the html attachment which vanishes when displayed) second part Is a *nested* multipart/alternative first (nested) part is text/plain second (nested) part is text/html (this is displayed) STEPS TO REPRODUCE: 1. Download the attached "SanitizedBrokerStatement.eml" 2. In TB, File->Open Saved Email and browse to the file 3. Set View->DisplayAttachmentsInline off Actual results: When View->Display Attachments Inline is off, the attachment completely vanishes. It can not be saved or opened. Expected results: The attachment should appear as an attachment which can be saved or opened.

Content-Type: multipart/mixed --level1 Content-type: text/html; name="...", Content-Disposition: attachment; filename="..." --level1 Content-type: multipart/alternative --level2 Content-type: text/plain (no name, no Content-Disposition:, no content in original mail) --level2 Content-type: text/html (no name, no Content-Disposition:)

> Bug summary : HTML attachment is lost/invisible unless Display Attachment Inline is on Which part do you call "HTML attachment"? Following part? > Content-Type: multipart/mixed > --level1 > Content-type: text/html; name="...", Content-Disposition: attachment; filename="..." From perspected of semantics of content data, this is attached file. However, this part is "Message Body part in multipart/mixed" from perspective of mail structure. Mail application perhaps plased "message body of multipart/alterntive" and "text/html file for attachement" in reversed order. Both bug 182627 and bug 583419 are observed on test mail in Tb 24.5.0. "Message Body part under multipart/mixed" is displayed only when View/Display Attachments Inline=true. "Text attachment part under multipart/mixed" is always displayed in inline, if no name/no filename. These are also seen in Tb trunk nightly. Both are regressed at same time?

Anyway, report about "reversed order in multipart/mixed" and "no content in text/plain part under multipart/alternative" to mail sender. Request mail sender to send "attchment file as attachment instead of message body".

Bug 182627 was fixed by Bug 551698. As written in Whiteboard: of Bug 551698, and as seen in patch for Bug 551698, patch of Bug 551698 expects "land patch for Bug 583419 first, land patch for Bug 551698 second". However, actual sequence was "land patch for Bug 551698 first, land patch for Bug 583419 second". > http://hg.mozilla.org/comm-central/log/9bd77606066e/mailnews/mime/src/mimei.cpp Patch for Bug 583419 was perhaps written based on source code before patch for Bug 551698 is landed. i.e. Change by Bug 551698(fixed Bug 182627) was backed out by Bug 583419. We perhaps checked fixing of Bug 182627 between "patch for Bug 551698" and "patch for Bug 583419".

Phil Lacy, what should we do?

> Anyway, report about "reversed order in multipart/mixed" and "no content in text/plain part under > multipart/alternative" to mail sender. Request mail sender to send "attchment file as > attachment instead of message body". I will try (again) to communicate with the message source (Interactive Brokers) about how their emails are structured. Question: How exactly should they send "attchment file as attachment instead of message body"? They are already tagging the attachment with "Content-Disposition: attachment; filename=xxx", what else is needed?

(In reply to Jim Avera from comment #6) > Question: How exactly should they send "attchment file as attachment instead of message body"? > They are already tagging the attachment with "Content-Disposition: attachment; filename=xxx", what else is needed? Ask them to put "multipart/alternative part first" and "text/html part with attachment/filename second" under multipart/mixed, if "text/html part with attachment/filename" is attachment file. Rule of multipart/mixed is "show each part in order placed under multipart/mixed with respecting Content-Disposition" only. So, the mail is never RFC violation". And, following expectation is valid : - first part is shown as attachment in attachment pane accoring to Content-Disposition: attachment. - second part is shown in inline according to default of Content-Disposition: inline However, "Content-Disposition: attachment or inline" is merely "sender's want". It's never "have to be shown in inline or as attatchment". It's up to mailer or user. As you already know, Tb has "Display Attachments Inline" mode. This is expliciit request of "ignore Content-Disposition: attachment" by you. There is no concept of "message body" nor "attachment" in multipart/mixed. However, historical reason, "first part under multipart" == "text/plain or text/html which is message body if no attached file and mail is sent in text/plain or text/html mail". And, if "file attachment" is needed, almost all mailer's behavior was "put the 'message bofy' at top of multipart/mixed" and "put additional 'attachment files' after it under multipart/mixed". This is what I called "message body in multipart/mixed". And, in many mailers including Thunderbird, name/filename is set when file is attached to a mail. So, historical reasons, Tb used internal rule of "attachment = non-displayable part, or part which has name/file name if displayable part". This bug is obviously Tb's bug, because rule of multipart/mixed is "show each part in order placed under multipart/mixed with respecting Content-Disposition" only. However, for historical reasons, many mailers including Thunderbird still consider "first part in multipart/mixed is equivallent to 'message body' of non-multipart text/plain or text/html mail".

I have been away from my developing tools for very long time but will look at this not sure if i can do much on my iPad. I was hoping the jsmime completed by jcranmer would take over the backend to mime. I posted a question to bug 959309

i pinpointed the bug to a single line Content-Type: multipart/mixed; vs. Content-Type: multipart/alternative; the email is sent from a python code, and the attachment is visible both cases on gmail webclient. Content-Type: multipart/alternative; --> not showing attachment vs. Content-Type: multipart/mixed; --> does show attachment example eml file: not showing attachment: http://pastebin.com/33cvj9Pi showing attachment: http://pastebin.com/yjbgVK6w

(In reply to Phil Lacy from comment #8) > I posted a question to bug 959309 Setting dependency to that bug for ease of tracking, problem aanalysis, and fixing this bug.

(In reply to Shula Amokshim from comment #9) > example eml file: > not showing attachment: http://pastebin.com/33cvj9Pi This bug is obviously for specific case which is written in comment #1. Please never add comment on your irrelevant case to this bug, merely by same multipart/alternative is involved in both your case and this bug.

(In reply to WADA from comment #10) > (In reply to Phil Lacy from comment #8) > > I posted a question to bug 959309 > > Setting dependency to that bug for ease of tracking, problem aanalysis, and > fixing this bug. That's not a useful dependency for tracking.