GNOME Bugzilla – Bug 767807
Inline non-text/image attachments hidden in message list
Last modified: 2016-10-20 12:11:59 UTC
Created attachment 329986 [details] sample of NO CLIP at NOTIFICATION as we could see in my image there is attachment in the email from sender, but it was not marked in the notification clip. and some of which emails without attachment are marked in notification clip there is attachment/ but on the other hand, some most of them are marked with clip correctly.
Thanks for reporting this. (How is this a critical issue? Lowering severity.) Which exact types of attachments is this about? What account type is this about? Could you provide a public testcase to allow others to reproduce?
Thanks for a bug report. Whether the message contains an attachment or not is usually determined from the message structure. A test message, stripped of private information, would be very helpful. To give some hints, it's impossible to detect whether any message has an attachment when it's an encrypted message (without asking for the password for the private key to decrypt the message).
(In reply to André Klapper from comment #1) > Thanks for reporting this. > > (How is this a critical issue? Lowering severity.) > > Which exact types of attachments is this about? What account type is this > about? > > Could you provide a public testcase to allow others to reproduce? 1. Critical? Well it not suppose to work like this So now my user has to click on every email to ensure that the email is either contain or not containing attachment. 2. Any attachment regardless of spreadsheet or pdf or image It's just happen randomly 3. Unable to reproduce as we do not know what went wrong It's just happen randomly in random email Within my attachment pix, in fact there are few emails that is not showing attachment notice correctly. But only present 1 2 with attachment but was not shown with paper clip 1 without attachment but was shown with paper clip Email account type server: IMAP
(In reply to Milan Crha from comment #2) > Thanks for a bug report. Whether the message contains an attachment or not > is usually determined from the message structure. A test message, stripped > of private information, would be very helpful. To give some hints, it's > impossible to detect whether any message has an attachment when it's an > encrypted message (without asking for the password for the private key to > decrypt the message). I am also experiencing this bug, how could I provide my "test message, stripped of private information"? At the moment, I have two "buggy" messages: - Both belong to the same IMAP account; - One contains a PDF file, the other one contains a PDF file and a ".dat" file, shown in preview pane as a HTML attachment; - None of them is encrypted. Running Evo 3.20.5
Right-click the message in the message list, Save as mbox..., then open the file and remove from there anything what would be private. You can also delete most of the PDF file content, which will make it invalid, but it's okay, because validity of the attachment doesn't influence the decision whether the message contains an attachment of not. On the other hand, the message structure itself does influence it. If you are unsure, feel free to send me the messages as zipped attachments to my bugzilla email, only reference this bug report in the subject, otherwise I could overlook it in my spam folder.
(In reply to Milan Crha from comment #5) > If you are unsure, feel free to > send me the messages as zipped attachments to my bugzilla email, only > reference this bug report in the subject, otherwise I could overlook it in > my spam folder. Milan, I sent you the messages privately on 2016-10-18 08:01:22.
(In reply to Andrea Vai from comment #6) > Milan, I sent you the messages privately on 2016-10-18 08:01:22. Yup, confirming, I have it here, I just didn't get to it yet. I'm sorry of not letting you know earlier. I didn't open the message yet, thus it's still unread, and it shows the attachment icon (IMAP account), but it doesn't mean much, as it has a .zip attachment. I extracted both messages and imported them into an On This Computer folder, and both has missing the attachment icon. Both messages have the "attachment" declared as: Content-Disposition: inline; filename="some.pdf" Content-Type: application/pdf; name="some.pdf" Content-Transfer-Encoding: base64 The problem is that "inline" in the Content-Disposition [1]. It's meant to show the part immediately, to not present is as an attachment. The change for bug #749108 seem to change the behaviour. [1] https://tools.ietf.org/html/rfc2183.html
I made the change to cover what the Apple Mail does (from the mails I received from Andrea: X-Mailer: Apple Mail (2.1085) Mime-Version: 1.0 (Apple Message framework v1085) and X-Mailer: Apple Mail (2.3124) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) ), the changed algorithm now checks also for the Content-Type, and when it is not text/*, nor image/*, then it simply ignores the "inline" Content-Disposition and marks the message as with an attachment. To have this in work, you should re-download message summary for the particular folder, because it works for newly received/recognized messages only. Created commit 9d35ee8 in eds master (3.23.1+) Created commit 1e42b34 in eds gnome-3-22 (3.22.2+)