GNOME Bugzilla – Bug 563579
[tnef attachment decoder] Should handle winmail.dat attachments transparently
Last modified: 2021-05-19 11:56:50 UTC
Hi Windows converted using Evolution, instead of Outlook. However my customers remain Outlook users and I cannot read their winmail.dat attached file even with plugin seemingly active. Please advise fix? Distribution: Ubuntu 8.10 (intrepid) Gnome Release: 2.24.1 2008-10-24 (Ubuntu) BugBuddy Version: 2.24.1
Thanks for taking the time to report this bug. This bug report isn't very useful because it doesn't describe the bug well. If you have time and can still reproduce the bug, please read http://bugzilla.gnome.org/bug-HOWTO.html and add a more useful description to this bug.
Hi If I understood your suggestion how to: The application Evolution is not functioning properly. On a desktop, specifically a laptop Toshiba Tecra M2. When I received an email from an Outlook user, I get an winmail.dat file attachment that I cannot read. Double click on the attachment or right click it gets your the text editor - neither of which opens the file. Therefore this part of the Evolution program does not work. Other information: - Evolution 2.24.2 - Gnome - you already have it This is the case even though - libytnef0 - evolution-plugins-experimental - tnef plugin are all active and running from what I can, per review in Evolution and Sypnatic. So what's next?
0) TNEF / winmail.dat support is far from perfect. 1) Basically all information that is hidden in the winmail.dat attchment and that evolution can handle should be displayed as another attachment (could be any type of file: .doc. .pdf, .vcf). Some winmail.dat files (also) contain that text of the message in HTML and/or Rich Text Format: evolution cannot yet handle those additional versions of the message text. (I guess some winmail.dat files might not even contain that and would than be basically useless for evolution. They seem to serve some Outlook/Exchange internal purpose too.) 2) It is my feeling (I may have mentioned this in another bug, but I couldn't find it) that evolution should retrieve and display all usable information from winmail.dat files in an appropriate way and than just hide those winmail.dat attachments in the UI (as they than serve no purpose any more). 3) Still, if you find winmail.dat attachments that you suspect should be handled better by evolution please analyse them (sourceforge.net has two standalone TNEF parsers at least) and report the detailed problem (perhaps in another bug) 4) Update the summary to reflect the problem as I see it. Related housekeeping. (Might check for duplicates of this bug too.)
*** Bug 552894 has been marked as a duplicate of this bug. ***
Just to check, are you using gmail IMAP to receive your mail? The reason I ask is that there is a known gmail IMAP bug that scrambles the winmail.dat in such a way that evolution doesn't process it properly. There is a fix. google camel_imap_braindamaged. If not, nevermind. :)
(In reply to comment #5) > There is a fix. google camel_imap_braindamaged. That would be bug #517440 (but there's nothing in this report that makes me think the reporter ran into that problem).
(In reply to comment #3) > 1) Basically all information that is hidden in the winmail.dat attchment and > that evolution can handle should be displayed as another attachment [...] > > 2) It is my feeling [...] that evolution should retrieve and display all usable > information from winmail.dat files in an appropriate way and than just hide > those winmail.dat attachments in the UI [...]. 0) My limited experience with winmail.dat attachments (50+ messages) tells me these messages have this form: multipart/mixed text/plain application/ms-tnef 1) Currently the plugin transform this into: multipart/mixed text/plain application/ms-tnef [enclosed/files...] 2) I've finally managed to hack this plugin so it can transform these messages into this: multipart/mixed multipart/alternative text/plain [text/html] [enclosed/files...] Basically that is: hide the winmail.dat file entirely; if the winmail.dat has a text/html copy of the text/plain part, move it up one level; and show the attachments enclosed in the winmail.dat, if any. 3) winmail.dat is complicated (eg, it might also have an application/rtf version of the text/plain part, which means gmime or libabiword might be needed to display these). It is unlikely that evolution will ever support it entirely (even taken into account that some stuff seems to be solely MS Exchange internal features). But we could try to do only the straightforward parts. 4) How would the other developers like this hack (for 2.28 currently) get added to their workload?
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new bug report ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.