User-Agent: Mozilla/4.8 [en] (Windows NT 5.1; U) Build Identifier: Mozilla Thunderbird 0.5 (20040207) In the mail messages overview pane initially no icon is shown when there is an attachment included in the e-mail. Only after selecting the mail message (just click with the mouse on the message once) the attachment-icon appears. This happens when using an IMAP account including messages in the "Local Folders". Reproducible: Always Steps to Reproduce: 1.Open message windows which includes an message with attachment 2 [details] [diff] [review].No attachment icon is shown 3.Click on the message that contains the attachment 4 [details] [diff] [review].The attachment icon is shown Actual Results: Initially no icon was show but it appeared after clicking on the message that included an attachment. Expected Results: Directly show the attachment icon if a mail-message includes an attachment. In the example I already clicked on one mail containting an attachment (as shown by the attachment-icon) after that I clicked on the message above that one and "voila" an other mail with attachement.

See the Mailnews bugs Bug 182720 and Bug 199979. Could be duped???

I am experiencing the same problem on Thunderbird 0.7 on Windows 2000 using pop mail. Email attachment indicator in receive window only appears after the message is highlighted.

This is Seamonkey bug 199979, as noted in comment 1. Maybe it should be duped, I don't know if this could be a Thunderbird-only fix. Confirming for now.

I had the same thing happen on my system using Thunderbird 0.8 on Windows 98SE. It showed up on messages that were imported from Outlook 2000, as well as new ones I sent to myself as a test from another computer.

yes, we have to read the message before we know it has an attachment. That's basically working as designed.

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

If this is working as designed the design is buggy. The attachment flag is not showing the true state of the email then what is the point of having it? At the very least it should show a question mark if it doesn't know if an email has an attachment. Evolution and Squirrelmail don't have this problem so I guess the problem is not with the imap protocol but with the way Thunderbird handles mail. Please fix it in some way that makes sense to users that are not programmers. Please change from WindowsXP to All since this is not an XP specific problem. Isn't the dependency on bug 260669 a mistake. I can't see how that relates to this bug, but I'm not changing it since I don't know enough about it. Someone with a bit more knowledge please check it.

> At the very least it should show a question mark if it > doesn't know if an email has an attachment. Cool idea. Agreed about the bogus dependency, removing.

(In reply to comment #7) > If this is working as designed the design is buggy. > > The attachment flag is not showing the true state of the email then what is the > point of having it? I agree with this analysis. I have Thunderbird on several different computers for grabbing mail from the same account. Often times I will have read the mail from one location, and so I don't "read" the mail from the other computer, I just mark it read. This results in the attachment flag never getting set, and then when I search my emails for "that one email from Fred with an attachment" I can't find it, because it doesn't show the attachment.

i think you should put this bug as "critical", becouse attachment sign this is one of very importatnt mail-descriptors. maybe it's hard for coding, but i think it's worth. it's stupid to say outlook has this option, but many users expect this option by default.

Any news about this issue? It seems to be still present in nightly builds - any chances of this getting fixed in 0.9? This thing the only problem stopping migration of my users from Outlook (and I heard lots of remarks from my colleagues in other organizations about this...)...

we could set the attachment icon on any message with a content type of multipart/mixed, by looking for that header. That will cause the attachment icon to be displayed for any attachment, including v-cards. What do you think, Scott? We could make this behaviour optional, but I'm thinking v-cards are not that common, and most people would probably prefer the false positive...we could clear the attachment flag on messages with v-cards when the user reads the message.

this does the basic work...I could add a hidden pref to control this. I suspect that clicking on a message with a v-card attachment will not clear the attachment flag because I bet we only set that flag, not clear it, but I'll check.

david, I tried that approach already and the noise level was too high. We had to revert it back.

This clears the attachment flag when the user reads a message with just a v-card, and removes the #ifdeffed code from the bayesian spam filter. That code had too many false positives because it got called for multipart alternative messages by libmime, but this patch only checks for multipart mixed.

fixed on trunk and branch.

Bug 259674 is expressly about turning *off* the attachment icons for vCards, which currently is shown once the message has been opened. The patch as described will actually help that problem, even if it first shows an icon for the vCard before the message is opened. It seems currently that the "message has an attachment" status is cached somewhere, like in the .msf -- is that correct?

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

just downloaded and tested http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/ which translates as 0.6+ (20041025) The bug is still in evidence. Any idea guidance as to what I missed would be welcome.

imap needs to get the content-type header by default in order for this to work for imap. Both these fixes will be in the *next* nightly build, *not* the nightly build made before these fixes were checked in.

imap fix checked into branch and trunk.

I am just testing last nightly build (version 0.6+ (20041026)) and it seems that this fix works only partially - for most of the messages (both imported from OE and coming from POP3 server) the paperclip shows properly (for messages which has not been read but have attachment(s), but for others the behaviour is the same - and what is worse, it is not possible now to open the attachment (see attached screenshot). I am almost sure that this is something that has not been happening before, but I am not sure. It might be the result of some other changes, perhaps?

I don't see how this fix could have anything to do with that problem.

Right, it seems that this nightly build has problems with all atachments - I tried opening only these where TB did not show the paperclip in unread message... Sorry for the confusion! There are still however two types of behaviour - some messages got the paperclip icon in unread state, and others show the icon only after reading the message. Perhaps someone will be able to verify this? I am attaching the headers of the message which did not show the paperclip - as far I can tell it is nothing special, but maybe it would help somehow...

just downloaded and tested Thunderbird version 0.6+ (20041026) from http://ftp28f.newaol.com/pub/mozilla.org/thunderbird/nightly/latest-trunk/ sent a new message to a mailbox on a courier-imap server (with an attachment). Paperclip attachment symbol still did not show up until the message had been opened. This bug is not resolved.

the reason it didn't work for that sample message is that the content type is upper case, and I just look for lower case multipart/mixed...

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

tbird version 0.9 (20041103)

Derek, can you attach or e-mail me a protocol log of a session where new imap mail was received with an attachment but the attachment icon didn't display until you clicked on a message. This is working for everyone else that I know of, so your problem sounds like its specific to your setup. http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap

Using TB 0.9 build 20041111 on Win XP SP1, and this bug is back. I received today two emails sent with Incredimail to my POP account, and the paper clip icon did not show any attachment. I clicked on the emails, they had an attachment (some jpg included in the sig), and the paper clip appeared. I thought this bug was fixed, but it seems not...

I installed version 0.9+ (20041113) today and it seems to work here ok.

This question is directed to David B. Did my protocol log of the IMAP session with the courier-IMAP server provide any clues (Additional Comment #32)? Just to add a detail that never got mentioned, the same Tbird client shows the attachment symbol (paperclip) before loading the message when it is dealing with POP mail -- just not for that IMAP server. The attachment symbol does show up after loading the IMAP message. I'm about to build another IMAP server for another client, and if there's something about the configuration of the server that I can adjust to make this work properly, please let me know. The users of this next courier-IMAP server will be using the Mozilla suite, which as of 1.7.3, still seems to have this bug.

Derek, I lost your log - can you resend it? I sent you e-mail to that affect on 11/8 but maybe you don't see non-bug e-mail on that account?

(In reply to comment #35) > POP mail -- just not for that IMAP server. The attachment symbol does show up > after loading the IMAP message. I can't reproduce it with Thunderbird version 0.9+ (20041119) and courier-imap 3.0.8-3 running under Debian Sarge. When I receive a message, I can immediately see the attachment symbol.

For David -- I have sent you under separate cover, to the email address in the link, the log you requested along with a very illuminating (to me) screen shot. From the difference between test #2 and test #1 (in the screen shot not attached here) I have figured out why I seem to be the only one reporting the bug. It is because I am using a digital (x.509) pki certificate to sign my messages. The signed messages do not show the attachment symbol, the unsigned messages do. shall I open another bug?

(In reply to comment #38) > I have figured out why I seem to be the only one reporting the bug. > > It is because I am using a digital (x.509) pki certificate to sign my > messages. The signed messages do not show the attachment symbol, the > unsigned messages do. > > shall I open another bug? Is this bug 243833? See also bug 213051, bug 145180.

I don't think it's any of those bugs, though bug 145180 is related. The issue is that the content type is multipart/signed and we don't treat that as having an attachment (and you'd be unhappy if we did :-) ) I don't see any way to fix this issue - the content type is our best shot at determining from the headers. The content type is the same for a signed message with an attachment as a signed message w/o an attachment and we're back to deciding at message reading time whether the message has an attachment.

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

Is this also considered fixed in trunk? Usually, that is what "FIXED" refers to, but I see this time, it came in with the "fixed-aviary" keyword. Thanks.

(In reply to comment #42) > Is this also considered fixed in trunk? Should be fixed, see bug 199979 comment 21.

I've experienced this bug since Thunderbird v1.0.7. It still occurrs with version 1.6a1 (20060119). My OS is winxp pro x64 (beta). One difference now is that the message needs More than just a clicking, it must be opened Fully for the attachment indicator to appear. Recently I counted twenty-six messages in my in box where this was the case for each of them. Someone important, please reopen this bug.

The fix works well for non-signed messages but fails when a message with attached files is signed e.g. pgp. The little file icon will be displayed first when you open the message. I tested with my Linux CVS trunk build version 1.6a1 (20060114). David, is that a core bug or does it belong to Enigmail? If it's based on core we should reopen or better file a new bug.

I have to revert my last comment. This doesn't only appear for signed messages. Today I received some mail delivery warning messages where this issue can be reproduced at any time. I will attach one of them.

A quick search thru LXR shows that "multipart/report" is not checked for anywhere (altho it's apparently generated as output in a couple places).

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

Tested today, in Thunderbird Version 2.0.0.4 (20070604) this bug is still experienced for signed messages but not for unsigned messages. I am using a digital certificate to sign messages. Should this bug be closed (WONTFIX), after David Bienvenu stated (Comment #40) that there is no way to fix this?

probably should mark it as WONTFIX, per David comment #40

Bryan, comment 41, comment 40

comment 50, comment 40 [can't count, sorry for spam]

The original issue was fixed. For signed messages seems wontfix for technical reasons per comment 40. Closing...

Need to reopen this bug. Im seeing the same issue on TB 3.1.7, on unsigned messages (never tried with signed messages). My original bug 621011 has all the details in it. Im surprised no one else is seeing this. Please let me know what logs you need me to provide (and I'd perhaps need a little help figuring out how to extract those logs).

Can someone please re-open this bug? I am unable to change the status.

(In reply to comment #57) > Can someone please re-open this bug? I am unable to change the status. This bug shouldn't be re-opened, it was originally fixed in the TB 1.0 timeframe and is unlikely to be your issue. I think your bug was incorrectly duped, and I'll reopen in a bit.

You know, I think I still see this from time to time. Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 ID:20120713141924

Still seeing this issue as of 38.2.0

Even worse, asking thunderbird to "repair" the folder, makes all the attachment icons disappear. Please reopen this bug as soon as possible.

(In reply to Worcester12345 from comment #59) > You know, I think I still see this from time to time. (In reply to Sergio Callegari from comment #61) > Please reopen this bug as soon as possible. Bugs which have patches and were fixed a long time ago do not get reopened. Also, commenting in a fixed bug is a recipe for no one noticing your comment. So you want to be in a different bug. For example bug 1177080

But 1177080 looks like the opposite of this one (repairing folder makes spurious attachment icons appear). Hence, opened new bug 1200262