User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 Build Identifier: 2.0.0.19 (20081209) Often I receive e-mails without attachments which are shown with a paperclip symbol, .i.e. as "message with attachment", anyway in the message list pane, until I actually click on and display them. Then Thunderbird notices that there is no attachment at all and the paperclip symbol goes away. I would expect the symbol not to appear at all. Those messages with false paperclip symbols seem to have in common that they are of MIME Type "multipart/mixed", even though they contain just one part. BTW, I really searched the database for this error because I believe somebody else must have noticed it before. Unfortunately I found no corresponding ticket. So if this is a duplicate, please flag it accordingly. Thanks. Reproducible: Always Steps to Reproduce: Receive incoming e-mail without attachments, but of type multipart/mixed, which looks like this in source code: From - Tue Feb 17 15:14:25 2009 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 X-Mozilla-Keys: Return-Path: <foo@bar.de> X-Original-To: foo@bar.de Delivered-To: blah@bar.de Message-Id: <0000000.mmailer000000000@fritz.box> From: "Sender" <baz@bar.de> To: <foo@bar.de>, Date: Tue, 17 Feb 2009 10:48:42 +0100 Subject: My subject Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------=_Boundary._0000000.mmailer.fritz.box0000000000" X-KasLoop: blahblah This is a multi-part message in MIME format. --------=_Boundary._0000000.mmailer.fritz.box0000000000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 QW5ydWYgYW4gZnJlZW5ldA0KDQoxNy4wMi4wOSAxMDo0ODozNw0K Actual Results: Paperclip symbol is displayed which then vanishes after reading the message Expected Results: No paperclip

multipart/mixed usually do have attachments, no? xref bug 241203

That's bug 274156, but was marked fixed. Has this been reverted somewhere?

@Magnus: No, bug 241203 describes the opposite behaviour of icons *not* being displayed even though there is an attachment. @rsx11m: I have no idea how this was supposed to be fixed. As a matter of fact, the error happens. Obviously during mail download only top level headers are checked, at least this is what I assume, not having looked into the code. Thus, only the first occurrence of "multipart/mixed" is registered and consequently an attachment icon is displayed. Later during full e-mail parsing (i.e. when the user actually displays the message), Thunderbird notices that the multipart actually only contains one part or maybe two parts (ASCII + HTML), but nor "real" attachment. In this case the icon goes away, now correctly showing the status "no attachment". My question/wish would be to verify the MIME message structure right during download, so the correct icon is (not) displayed right from the start. Would this slow down Thunderbird or is it feasible?

There have been quite a few changes to msgHdrViewOverlay.js since that patch was checked in (revision 1.41), and my question was actually more for Magnus than yourself. The issue is that on initial examination of the message, only the top-level headers are apparently looked at (which is the normal behavior for IMAP, and there is an option to download headers only for POP accounts). At this point, it likely isn't known how many MIME parts are actually in the message. Thus, the full message would need to be parsed already (or the body structure requested in the IMAP case) when new mail is received.

So it is exactly like I assumed. So maybe we need a case distinction: a) If only top-level headers are downloaded at a certain time, assume that a multipart message has attachments. -> display icon b) As soon as the full message or at least the message's full (nested) MIME structure is downloaded, analyse it and update the icon accordingly, i.e. right during download, not just when the message is displayed or marked as read. Probably it would be a good idea to make (b) configurable via a documented option in the UI or at least via an about:config toggle. The default for full parsing during download can be "off", if it is expensive CPU-wise, otherwise I would be happy with the default "on", too. As long as I can activate this feature in any sensible way I will be content.

(In reply to comment #2) > That's bug 274156, but was marked fixed. Has this been reverted somewhere? Don't know, but indeed that bug looks very similar...

I just noticed something else: The problem is not restricted to inbound messages. Whenever I send a plain text message with an automatic VCF attachment - a feature provided by Thunderbird itself - messages in the "Sent" folder are displayed with paperclip symbols until I actually open and read them. Usually I do not do that with outbound messages, but I have to do it in order to make the paparclip go away. A sample message is structured like this: ... User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 ... Content-Type: multipart/mixed; boundary="------------030704030402030207060104" This is a multi-part message in MIME format. --------------030704030402030207060104 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ... --------------030704030402030207060104 Content-Type: text/x-vcard; charset=utf-8; name="MyCard.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="MyCard.vcf" ... --------------030704030402030207060104--

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1pre) Gecko/20090525 Lightning/1.0pre Shredder/3.0b3pre This annoying behavior is present in Thunderbird 3 beta.

Aurimas (or reporter) can attach here a complete mail sample?

I know this regressed since tb2 (i think at least going back to last spring). Don't think we actually have a bug open for it, so confirming.

I highly doubt this regressed - we've always treated multipart/mixed as having attachment until we find out differently.

You're right.

I see this on Mac, not Win-specific as per the bug report. Also, it has always been the case as long as I remember. With regard to Comment 12, not sure why it takes a click on the message to "find out differently"? (but then again I'm not a programmer :-) ) It is more than an annoyance to not be able to distinguish multi-part msgs from true attachments when reviewing newly received mail. It looks like 1/2 the people who write to me (many of my friends and colleagues use Apple Mail which only does plain or multi-part) have sent me attachments and I must click on every paper-clipped msg in the list to see whether anything is really attached to any of them.

The bug is still here in TB17.0.3. Some messages get the paperclip icon in the mail list after I do 'Repair folder'. If I select those messages (click on them in the list) - the paperclip icon disappears. Imagine that you have thousands emails marked as "has attachment" so you have to click on each of them just to be sure.

(In reply to David :Bienvenu from comment #12) > we've always treated multipart/mixed as > having attachment until we find out differently. That appears to be the case still.