GNOME Bugzilla – Bug 478239
attachment icon is shown for messages that contain no attachment
Last modified: 2009-04-27 09:44:34 UTC
I will attach a sample message that appears with a "paperclip" icon in my inbox, although it contains no attachments (that I can see, at least). Happens with a lot of mails I receive from my mailing list.
Created attachment 95827 [details] sample message
technically, it does have an attachment... the mailing-list footer. your mailing-list software is adding its footer as attachments to mixed-text-html messages (which is arguably better than munging the text in the body)
Technically maybe. In practice, the user does not care about a mailing list footer. He wants a visual indication only if there is an *actionable* attachment. In that case, only display the icon if there is an attachment that is actionable on top of the mailing list header.
We have a downstream bug for this too. https://bugzilla.redhat.com/show_bug.cgi?id=280801 Also see bug #481437.
It's similar "issue" as with bug #313225. The approach to traverse message body and decide if we have or have not attachment based on available parts should work well for local stores, but for imap or other remote stores, it just doesn't work. I can imagine one "solution", updating state of the attachment in time of downloading message. It will show attachment icon when added message to the summary, but first time after read/download that message, it will update summary with more accurate information. It's not a real fix, but I'm not aware of any proper solution for that.
srag, as we discussed on IRC yesterday, I tried with CAMEL_DEBUG=all, with one folder containing exactly two messages, one with ics attachment (no attachment icon) and one multipart/mixed, where I can see the attachment icon, but no attachment action button. I deleted my summary information from ~/.evolution/mail/imap/... and run Evolution to create this summary. I can see on the console that it downloads only basic headers of the message from the IMAP, not the structure of the message (any information on other parts of the message). For me, the headers are "Return-Path:, Date:, From:, To:, Message-ID:, Subject:, MIME-Version:, Content-Type: and boundary=". I also briefly looked to IMAP RFCs, and it doesn't seem to have there any such option to retrieve also message structure, which makes sense, somehow. Thus I think there is no better "solution" for remote storages than the post-download update of the summary. It can be either "do not mark as with attachment until you know there are any" or "unmark attachment flag if you realize there is no real attachment", even the second is a bit better, from my point of view.
The second option seems fine to me. Unmark it automatically when you later see that there are no attachments.
*** Bug 481437 has been marked as a duplicate of this bug. ***
Created attachment 132345 [details] [review] proposed eds patch for evolution-data-server; I hoped it'll be possible to do this on one place, but it turned out that it's provider-specific issue. I didn't change all the providers, only some local and IMAP, because GW seems to handle this itself, same as eex and ema. It also seems the local providers adds messages to cache only through 'append' function, thus there I fix the item there, with IMAP it's a different thing. With this patch, say on IMAP, you get marked message as with attachment when multipart/mixed, but as soon as the message is requested, it checks whether there is any real attachment, and if not, then the flag is cleared (noticed some minor painting issue). 'inline'-s are not treated as attachments.
Seems fine to me.
Created commit 3562520 in master.