GNOME Bugzilla – Bug 796136
[IMAPx] Guess message info's attachment flag more accurately
Last modified: 2018-06-13 10:02:36 UTC
I have received a message with attachments, but the message list doesn't show the clip icon. The message is in an IMAP folder, and if I move/copy it to another IMAP folder, the icon does not appear. On the other hand, if I move/copy it to a local folder, the icon appears. If I copy/move it from the local folder back to an IMAP folder, the icon does not disappear. Running evolution 3.26.6 on Fedora 27 (3.26.6-1.fc27) See the related discussion starting at https://mail.gnome.org/archives/evolution-list/2018-May/msg00023.html
Thanks for a bug report. For what I had on my mind with respect of this is that the IMAP allows to get message structure only, without actual body, using the FETCH BODYSTRUCTURE. It is not used currently, but it can be and with its help it's possible to guess whether the message contains any attachments more accurately. It returns this for your test message (new-lines added for (partial) readability only): > A00132 UID FETCH 61:* (UID FLAGS BODYSTRUCTURE) > * 57 FETCH (UID 60 MODSEQ (7932231) FLAGS () BODYSTRUCTURE > (("TEXT" "PLAIN" ("CHARSET" "utf-8") NIL NIL "QUOTED-PRINTABLE" 39 1 NIL NIL NIL) > (("TEXT" "HTML" ("CHARSET" "utf-8") NIL NIL "QUOTED-PRINTABLE" 36 1 NIL NIL NIL) > ("APPLICATION" "OCTET-STREAM" ("NAME" "....xls") NIL NIL "BASE64" 21 NIL ("ATTACHMENT" ("FILENAME" "....xls")) NIL) > ("TEXT" "HTML" ("CHARSET" "us-ascii") NIL NIL "7BIT" 215 5 NIL NIL NIL) > ("APPLICATION" "VND.OPENXMLFORMATS-OFFICEDOCUMENT.WORDPROCESSINGML.DOCUMENT" ("NAME" "....docx") NIL NIL "BASE64" 21 NIL ("ATTACHMENT" ("FILENAME" "....docx")) NIL) > ("TEXT" "HTML" ("CHARSET" "us-ascii") NIL NIL "7BIT" 215 5 NIL NIL NIL) > ("APPLICATION" "VND.OPENXMLFORMATS-OFFICEDOCUMENT.WORDPROCESSINGML.DOCUMENT" ("NAME" "....docx") NIL NIL "BASE64" 21 NIL ("ATTACHMENT" ("FILENAME" "....docx")) NIL) > ("TEXT" "HTML" ("CHARSET" "us-ascii") NIL NIL "QUOTED-PRINTABLE" 2278 46 NIL NIL NIL) > "MIXED" ("BOUNDARY" "Apple-Mail=_4E79C80B-0558-4103-9A6C-D4AFF3A4190D") NIL NIL) > "ALTERNATIVE" ("BOUNDARY" "Apple-Mail=_216CC5B4-7F6B-43E4-90A2-F5C5DD35CB01") NIL NIL) > ) > A00132 OK Success The response format is described here: https://tools.ietf.org/html/rfc3501#section-7.4.2
I made it work with the BODYSTRUCTURE, the parser had been already there (in IMAPx), but it was not used. This change required an ABI change as well, thus I bumped soname version for libcamel, which means it cannot go to the stable. The attachment guess is that accurate (with the BODYSTRUCTURE), that I even can remove the attachment icon for multipart/mixed when there is no real attachment available (the multipart/mixed is a quick guess that the message contains an attachment in other parts of the code which is shared by all providers). I also set whether the message contains calendar invitation/attachment now, when the body structure is known. The change doesn't influence existing messages, only those newly received. I also didn't change copy/move within the server, that relies on the values in the local summary too. Created commit b78936dd1 in eds master (3.29.3+)
And a follow up work within https://gitlab.gnome.org/GNOME/evolution-data-server/issues/6