GNOME Bugzilla – Bug 700778
Correct TNEF mime type definition typo
Last modified: 2017-11-14 15:28:12 UTC
Hello, today I have received an e-mail with an attached winmail.dat (the first time in my life, I believe), but evolution was unable to open that attachment. The corresponding module is installed, though: $ ls /usr/lib/evolution/3.8/modules/module-tnef-attachment.so /usr/lib/evolution/3.8/modules/module-tnef-attachment.so All this on current Debian testing/unstable with Evolution packages taken from the experimental branch: $ dpkg -l \*evolution\* | grep ^ii | awk '{print $2 " " $3}' evolution 3.8.2-1 evolution-common 3.8.2-1 evolution-data-server 3.8.2-1 evolution-data-server-common 3.8.2-1 evolution-plugins 3.8.2-1 evolution-webcal 2.32.0-2+b1 libevolution 3.8.2-1 Cheers, - Fabian
Is that winmail.dat something you could attach here or email me privately? I don't think I even have access to a winmail.date file to test with.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!
My bad. I should have mentioned the reporter emailed me the sample file privately, I just haven't made time to investigate further. I'm told libytnef is dead upstream and riddled with security holes, so I'm wondering if we should even keep this feature.
I can confirm this bug is still valid. I've also filled a bugs in Ubuntu GNOME project: https://bugs.launchpad.net/ubuntu-gnome/+bug/1390466 So, when receiving an email from user using outlook, the attached files are grouped all in one tnef file, as one part of a multipart email. The content-type of this part of the email is as below: Content-Type: application/ms-tnef; name="winmail.dat" Old version of evolution decode correctly this kind of email up to version 3.4.0 of evolution when TNEF attachement are handled bu evolution plug-ins. At this time, the TNEF plugin handle those two mime types : - "application/ms-tnef" and - "application/vnd.ms-tnef". Since this commit, for evolution 3.5, https://git.gnome.org/browse/evolution/commit/?id=931191474643164e96b5778c790e42cca517e729, the mime_type handled by the TNEF module are : - "application/ms-tnefl" and - "application/vnd.ms-tnef". There is an additionnal letter 'l' that prevent this module from working correctly!!! This typo is also in lastest code from git (master branch): https://git.gnome.org/browse/evolution/tree/modules/tnef-attachment/e-mail-parser-tnef-attachment.c#n74 After patched the binary file directly with the following command, it's work again!!! $ sudo sed -i 's#application/ms-tnefl#application/ms-tnef\x00#' /usr/lib/evolution/3.10/modules/module-tnef-attachment.so
Created attachment 290181 [details] [review] Fix of typo in handled mime types
Does this bug need to be cloned for other (lastest) version of evolution ? I have this bug with Evolution 3.10 in Ubuntu 14.14 (with Gnome3-team PPA).
(In reply to comment #5) > Created an attachment (id=290181) [details] [review] > Fix of typo in handled mime types Awesome, thank you!
Thanks for the patch. Such things are pretty hard to find. I pushed your change into current sources: Created commit a425b43 in evo master (3.13.8+) [1] Created commit 06f5517 in evo evolution-3-12 (3.12.9+) [1] https://git.gnome.org/browse/evolution/commit/?id=a425b43
This week, this bug (or a similar?) has bitten me again! I've got another e-mail with an attachment called "winmail.dat" (now, the second time in my entire life) which Evolution refuses to open. The actual error message is: " Could not open "winmail.dat" No application is registered as handling this file " These are the relevant Debian packages I have installed on my system: $ dpkg -l '*evolution*' | awk '/^ii/{print $2 " " $3}' evolution 3.26.2-1 evolution-common 3.26.2-1 evolution-data-server 3.26.2.1-1 evolution-data-server-common 3.26.2.1-1 evolution-plugin-bogofilter 3.26.2-1 evolution-plugin-pstimport 3.26.2-1 evolution-plugins 3.26.2-1 evolution-plugins-experimental 3.26.2-1 libevolution 3.26.2-1 libreoffice-evolution 1:5.4.2-3 The corresponding plugin is also installed: $ dpkg -L libevolution | grep tnef /usr/lib/evolution/modules/module-tnef-attachment.so And the mime-type of the attachment is also properly detected: $ file --mime-type winmail.dat winmail.dat: application/vnd.ms-tnef If prefered, I can send the winmail.dat attachment as a signed mail to one of the Evolution developers. Best regards, - Fabian
(In reply to Fabian Greffrath from comment #9) > This week, this bug (or a similar?) has bitten me again! Why change the status to VERIFIED OBSOLETE, then?
(In reply to Fabian Greffrath from comment #9) > $ file --mime-type winmail.dat > winmail.dat: application/vnd.ms-tnef It rather depends what Content-Type header the attachment has, than what some command line utility thinks about it. What are your installed *tnef* ('*' as a wildcard here) packages, please? Feel free to send the whole message to my bugzilla email, just reference this bug in the subject, thus I'd not overlook it in my spam folder. I'd prefer whole message, to have it as a reproducer (you can drag&drop it from the message list into the composer attachment area at the bottom), rather than the winmail.dat file itself, I suppose the main (private) content of the message is in the winmail.dat file anyway. I promise to use it for testing purposes only and I won't share it in public with anyone. I've a GPG key too, for the same address, with ID F3C36A0D, which you can use to encrypt the message (signing it won't hide the content for others on the route).
I forgot to ask, did you receive the message to an IMAP, POP3, EWS,... account?
(In reply to Alexandre Franke from comment #10) > Why change the status to VERIFIED OBSOLETE, then? Oops, sorry, I never meant to change the bug status, just leave a comment here. (In reply to Milan Crha from comment #11) > It rather depends what Content-Type header the attachment has, than what > some command line utility thinks about it. It was just to show that the file in question is really a TNEF attachment and not just some random blob of that specific name. > What are your installed *tnef* ('*' as a wildcard here) packages, please? libytnef0:amd64 1.9.2-2 > Feel free to send the whole message to my bugzilla email, just reference > this bug in the subject, thus I'd not overlook it in my spam folder. I'd Just done so, thanks! > key too, for the same address, with ID F3C36A0D, which you can use to > encrypt the message (signing it won't hide the content for others on the > route). Yep, I meant to encrypt the mail. ;) (In reply to Milan Crha from comment #12) > I forgot to ask, did you receive the message to an IMAP, POP3, EWS,... > account? It's an IMAP account using Evolution's imapx backend and dovecot-common 1:1.2.15-7+deb6u1 on the server side.
Thanks for the test message, it helped. I've been able to reproduce it, and to be honest, it was a matter of "luck" to have shown the attachments extracted from the TNEF file. It didn't have anything to do with the initial issue (thus, next time, open a new bug report, please, especially after such long time). I made some changes which helped me to make the code more reliable. I also found an issue with one attachment missing (an image in this case), which I fixed as well. Created commit 83290ed9ec in evo master (3.27.3+) Created commit 3868229047 in evo gnome-3-26 (3.26.3+)
Thank you for fixing this issue! > thus, next time, open a new bug report, please, especially after such long time Will do next time, I promise. ;) > I made some changes which helped me to make the code more reliable I guess the main fix is the change to empe_tnef_attachment_parse(), right?
(In reply to Fabian Greffrath from comment #15) > I guess the main fix is the change to empe_tnef_attachment_parse(), right? Well, it was supposed to be, as it seemed to me that the file in the background wasn't written completely to the disk, thus libytnef failed to process it properly, but I wasn't able to make it work consistently with those changes. Then I made all those functions static, which fixes any clashing with anything outside, and then it begun to work as expected. There will be a little follow-up in the code, the code has compiler warnings with the latest libytnef, which I'll fix soon.