GNOME Bugzilla – Bug 604305
Attachments not properly indicated in message summary
Last modified: 2018-05-04 14:32:10 UTC
As per Milan's comment on IRC: I just received an e-mail with 3 attachements. The message list doesn't show the paper clip. (other emails show as expected). The attachements do show correctly in the actual e-mail. According to Milan: It's either they are inline, or has/has not filename set or some other "heuristic", which I implemented in this couple months ago or some other issue with a "heuristic".. The attachment portion of the e-mails have headers like: --------------090108090908080700050806 Content-Type: application/pdf; name="CoursesByFac.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="CoursesByFac.pdf" or --------------090108090908080700050806 Content-Type: application/pdf; name="CoursesByYear.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="CoursesByYear.pdf" or --------------090108090908080700050806 Content-Type: application/pdf; name="courselevels.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="courselevels.pdf"
Thanks. I see they all are inline, which I thought means is part of the body, thus is not a real attachment. I'll change it most likely today.
So this comes from bug #478239, and the actual behaviour is about Content-Disposition. Eds expects an "attachment" Content-Disposition to mark message as having attachments. I'm extending it to check also for a filename parameter of it. it seems to me that this is the correct thing.
Created attachment 149698 [details] [review] eds patch for evolution-data-server;
Created commit e37b27f in eds master (2.29.4+) The only disadvantage is to refetch the message, as this is done on the first fetch of it.
Off the cuff suggestion: Consider rewriting em_format_is_attachment() as a more generic utility function so that EMFormat and MessageList use the same criteria for determining what is and is not an attachment. I'm not sure what arguments the function should take -- maybe a CamelContentType and optional filename string for starters?
The problem is that message-list cannot determine it for messages which has only summary downloaded. For the proper determination one needs at least a message structure to traverse it and seek for attachments. I know that with a tracker fixes the IMAP provider tries to download also body structure, but if it's really usable for this purpose, and how much it'll help with other providers than IMAP is yet another question. :)
*** Bug 607371 has been marked as a duplicate of this bug. ***