User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release) Build ID: 20131205075310 Steps to reproduce: Receive messages normally. View message list. Attachment icons (paper clip) in Attachments column not displayed beside some (not all) messages that I know contain attachments. Click on message in list to select/focus a message. After clicking once, attachment icon is displayed. This happens to a significant portion (about half?) of all messages I receive that contain attachments. Other messages display the attachment icon normally, automatically upon receiving message without selecting the message. This has been occurring for as long as I can remember, at least in the last several versions of Thunderbird (possibly as far back as TB 17). Actual results: Attachment icon not automatically displayed in Attachments column in message list window for some messages that contain attachments, until message is selected. Expected results: Attachment icons should appear automatically in Attachments column upon receipt of incoming messages containing attachments.

I can definitely confirm this behavior, which appears especially with messages moved into another folder. Even if the message correctly displayed attachments before the move, it never does after the move. To have the Attachments columns correctly populated it is necessary to load the message (either in the preview pane or in a separate window).

Also seeing this bug in 38.4.0, for unsigned IMAP messages. One very annoying effect is that searching for messages with attachments will only find messages that have been opened before.

I saw this behavior in Thunderbird 45.1.0 with DMARC Rua Reports from google (not from yahoo, Microsoft or other senders). The difference I noticed between the messages is that Google does not send any text with their mails. The message structure looks like this: From: noreply-dmarc-support@google.com To: [...] Content-Type: application/zip; name="google.com![...].zip" Content-Disposition: attachment; filename="google.com![...].zip" Content-Transfer-Encoding: base64 [base64 encoded attachement follows] Microsoft and yahoo, for example, use "normal" Content-Type: multipart/mixed; instead with MIME boundaries in their DMARC reports. With their mails, Thunderbird directly notices that the mail contains an attachment. For Content-Type: application/zip; as used by Google, Thunderbird notices the attachment when opening the message.

This is still a problem in 45.5.0. I don't understand why this bug is still classified "unconfirmed" ??

This mystery is already known phenomenon and bug for it already exists, as indicated by "dupeme" in Whiteboard field of this bug. I don't remember bug number. As stated by bugzilla_mozilla@mail.christosoft.de in comment #4, following occurs. When new mail is fetched, if Content-type:multipart/mixed, Thunderbird shows "attachment icon", because sub part called "Attachment"(attached file) can be contained under multipart/mixed only, even though Content-Disposition:attachment can be set in any sub part under multipart/related and multipart/altertnative. When mail is opened by user, structure/content of mail is analyzed Thunderbird in order to display mail content to user. So following can occur when not-well-formed mail or malformed mail. (a) If no attached file in multipart/mixed(mail body part only), attachment icon perhaps disappears. (b) When non-used part by HTML exists in multipart/related, Thunderbird shows it as-if attachment, in order to provide a way to save data of such malformed part as "file on HDD". In this case, IIRC, Thunderbird shows "attachment icon" because something is shown in attachment box, despite that "real/actual attached file under multipart/mixed" doesn't exist in the mail. From perspective of "correctness" or "consistency", "attachment icon" shouldn't be shown at Thread pane when (b), because "real/actual attached file under multipart/mixed" never exists in the mail. "An element shown in attachment box by (b)" is merely element shown as-if attachment to provide "Save As" interface to user.

@WADA: that sounds like the opposite of what's happening (attachment icon displayed when it SHOULDN'T be) -- this bug is about "attachment icon NOT displayed when it should be"

(In reply to Konstantin Svist from comment #7) > @WADA: that sounds like the opposite of what's happening (attachment icon displayed when it SHOULDN'T be) > -- this bug is about "attachment icon NOT displayed when it should be" Have you read my comment on (b)? (1) Because mail is not multipart/mixed, "attachment icon" is not shown at Thread pane. (ii) When mail is viewed, if mail is malformed mail and non-used part under multipart/related exists, Thunderbird shows the sub part of malformed mail as-if attachment in Attchment box. This is never "correct/valid/actual attached file to mail". At this step (ii), what is "Should be"? Current Thunderbird behavior: When (ii) occurred on malformed mail, show "attachment icon" of Thrread pane. You say : If (ii) happens on malformed mail, "attachment icon" of Thread pane should be shown at step (i). I say : When (ii) happened on malformed mail, "attachment icon" of Thread pane shouldn't be shown at step (ii), because it's never "correct/valid/actual attached file to mail".

My bug 1166067 was merged into this one; please take a look at attachment 8607220 [details] -- there are 2 REAL attachments in the message but no attachment icon displayed

Note: currently on Tb 45.4.0 and that same message is still displayed the same way (without an icon) and does not show up when filtered by Custom Views -> Has Attachments The message source structure: From - Sun May 3 12:28:24 2015 ... Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-8--745298500 ... X-Mailer: Apple Mail (2.1085) --Apple-Mail-8--745298500 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 ... <<<MESSAGE BODY>>> ... --Apple-Mail-8--745298500 Content-Type: multipart/mixed; boundary=Apple-Mail-9--745298500 --Apple-Mail-9--745298500 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii <html><head></head><body[...] --Apple-Mail-9--745298500 Content-Disposition: inline; filename="2015-02-01 [***] Minutes.pdf" Content-Type: application/pdf; x-mac-type=50444620; x-mac-creator=4D535744; x-unix-mode=0644; name="2015-02-01 [***] Minutes.pdf" Content-Transfer-Encoding: base64 <<<BASE-64 CONTENT>>> ... <<<2nd pdf attachent>>> ... --Apple-Mail-9--745298500 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 <html><head></head><body [...] ... <<<more content (quoted replies?)>>>

> Content-Type: multipart/alternative; boundary=Apple-Mail-8--745298500 > --Apple-Mail-8--745298500 > Content-Type: text/plain; charset=windows-1252 > --Apple-Mail-8--745298500 > Content-Type: multipart/mixed; boundary=Apple-Mail-9--745298500 > --Apple-Mail-9--745298500 > Content-Type: text/html; charset=us-ascii > --Apple-Mail-9--745298500 > Content-Disposition: inline; filename="2015-02-01 [***] Minutes.pdf" > Content-Type: application/pdf; > --Apple-Mail-9--745298500 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/html; charset=windows-1252 It looks for me following. 1. multipart/alternative => text/plain is used as "message body part under multipart/alternative". And, multipart/mixed under multipart/alternative != usable part such as text/plain, text/html under multipart/alternative. So, it should be completely ignored, because text/plain part is already chosen in multipart/alternative. 2. However, it's multipart/mixed, then "application/pdf part under multipart/mixed under multipart/alternative" is shown as-if attachment at attachment box, because it's non-used/non-displayable sub part. If such PDF part is shown as-if attachment, I believe text/html part also should be shown as-if attachment. Or, "text/html part under the multipart/mixed under multipart/alternative" was used by Thunderbird as "message body" when "View/Message As/Original HTML"? Anyway, it's never real attachment because mail is multipart/alternative mail.

(In reply to Konstantin Svist from comment #9) > My bug 1166067 was merged into this one; I think duping was bad and wrong, because your case was: (a) subpart of malformed mail is shown as-if attachment in Attachment box when mail is viewed. (b) "attaxchment icon" is not shown at Thread pane when the mailformed mail is viewed. (b) is apparently different from this bug.

thanks for un-merging