User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.13 (KHTML, like Gecko) Chrome/9.0.597.98 Safari/534.13 Build Identifier: Thunderbird/3.1.7 I have a gmail account. When some e-mail is sent to me with attached file from web e-mail service of mail.bg(www.mail.bg), I receive the message but I don't receive the file. I've tried with Autocad DWG file, RAR archive and jpg picture. It was OK only with the picture. When I open gmail's web client e-mails are OK. The files can be downloaded from there. I've tried other web services(www.abv.bg) and Thunderbird received the same files properly. Reproducible: Always

Can you save one of those messages that don't show with attachments in TB and attached them here using the add an attachment link above ?

(In reply to comment #1) > Can you save one of those messages that don't show with attachments in TB and > attached them here using the add an attachment link above ? I've added a message, screenshot from TB and screenshot from gmail. Hope this helps!

Content-Type: multipart/alternative;boundary="----=_20110223210315_68628" ------=_20110223210315_68628 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A=0A=0Ala ------=_20110223210315_68628 Content-Type: application/x-rar; name="house.s07e13.hdtv.xvid-lol_1(subsunacs.net).rar" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="house.s07e13.hdtv.xvid-lol_1(subsunacs.net).rar" ------=_20110223210315_68628--

With testcase.eml of attachment 515643 [details], the attached .rar file is now correctly displayed in TB, but when trying to double-click, TB shows an error popup: > This attachment appears to be empty. > Please check with the person who sent this. > Often company firewalls or antivirus programs will destroy attachments. But looking at source, the "attachment" is not empty. It doesn't look like a strictly well-formed multipart msg, either, but we should handle this better.

> Bug summary : attached files with emails that are multipart/alternative What do you call by "attached file of multipart/alternative"? Where, by what RFC, is the "attached file of multipart/alternative" defined? Mail structure. Content-Type: multipart/alternative Content-Type: text/plain Content-Type: application/x-rar Sub part is ordered by mail sender's preference in multipart/alternative. Tb is not a mailer who can display application/x-rar as mail body. Tb can show text/plain as mail body. So Tb showed text/plain part. What's wrong in Tb. Note: Following problem is known. If second part is text/Unknown-Mime-Sub-Type, this text/Unknown-Mime-Sub-Type is used as message body by Tb, then garbage is displayed. Becaause Tb is not mailer who shows text/Unknown-Mime-Sub-Type as message body, text/Unknown-Mime-Sub-Type under multipart/alternative should be ignored by Tb. "Quirks like next for malformed mail" is not impossible, if sub part under multipart/alternative is not displayable part for Tb, show this sub part as if attachment in Attachment Pane. (IIRC, bug for this exists. Gmail may have this kind of quirks.) (eg. For other than text/plain and text/html, show as if multipart/mixed) However, this kind of quirks tends to break correct handling of correctly formatted multipart/alternative. An objective of multipart/alternative is: Content-Type: multipart/alternative Image version : Content-Type: image/jpeg Text version : Content-Type: text/plain HTML version : Content-Type: text/html Ecel version : Content-Type: appliction/ms-excel Word version : Content-Type: appliction/ms-word PDF version : Content-Type: appliction/pdf Voice version : Content-Type: appliction/voice If a mailer supports "display PDF as message body", the mailer simply uses it. User of such mailer can enjoy beautiful mail display than HTML. If user loves display by Excel, and if mailer supports "display Excel file as mesage body", user simply request it to the mailer, as done by "View/Message Body As" in Thunderbird. There is no need to show other sub parts because this is multipart/alternative. This kind of malformed mail is generated by casual Web application/Mail application programer in many cases. For this kind of malfored mail, mailnews.display.show_all_body_parts_menu=true is already implemented. I believe that "fixing of such bug in such application" should be requested to mail sender first, if the mail is so important for mail sender and mail recipients.

This message should be multipart/mixed not multipart/alternative. This bug is four years old. We have no resources to fix problems where invalid data is presented.