GNOME Bugzilla – Bug 549592
[tnef attachment decoder] move from experimental to standard?
Last modified: 2021-05-19 11:56:05 UTC
OS: OpenSUSE 11.0 Gnome: 2.22 Evolution: 2.22.1.1 Account type: Gmail IMAP Download mails enabled. I just received one mail stating there's attachment. But I saw only one attachment winmail.dat. I requested sender to send attachment again then she said its already there. So I checked in web mail, there it was showing up pdf attachment. The original mail is attached with private information hidden.
Created attachment 117462 [details] Email having attachment not being detected in evolution.
winmail.dat indicates the attachment was sent from Microsoft Outlook in a proprietary format. As such, special steps are necessary to decode the attachment. Evolution includes a plugin for decoding such attachments, but the plugin is deemed experimental and generally not included or enabled by default in Linux distros. Some distros ship an additional "experimental plugins" package for Evolution that would include it, but I'm not sure if OpenSUSE does.
Shouldn't it be included in mainstream as it is basic requirement for interoperability. We don't know we'll receive mail from which mail client. If web mail can detect it, evolution should also detect it.(no offense, just curious)
I'm not sure why it was determined to be experimental. Maybe it's time to revisit that. Srini, any historical insight here?
Matt, libytnef isn't a most popular lib yet to be included always. Atleast when it was written, we had to search for some rotten lib somewhere.
I see. If the plugin itself is fairly stable, maybe we could tag it as such and build the plugin only if libytnef is detected at configure time. Then distros could choose whether to make libytnef a build requirement. But first I'd have to take a closer look at the plugin to judge whether it's fit to be considered stable.
(In reply to comment #6) > [...] maybe we could tag it as such > and build the plugin only if libytnef is detected at configure time. From configure.in: [...] AC_MSG_CHECKING([for yTNEF]) AC_TRY_COMPILE([#include <stdio.h> #include <ytnef.h>], [TNEFStruct *tnef;], tnef_ok=yes, tnef_ok=no) if test "$tnef_ok" = "yes"; then AC_MSG_RESULT([yes]) TNEF_ATTACHMENTS="tnef-attachments" TNEF_CFLAGS="-DHAVE_YTNEF_H" else AC_TRY_COMPILE([#include <stdio.h> #include <libytnef/ytnef.h>], [TNEFStruct *tnef;], tnef_ok=yes, tnef_ok=no) if test "$tnef_ok" = "yes"; then AC_MSG_RESULT([yes]) TNEF_ATTACHMENTS="tnef-attachments" TNEF_CFLAGS="-DHAVE_LIBYTNEF_YTNEF_H" else AC_MSG_RESULT(no) TNEF_ATTACHMENTS="" TNEF_CFLAGS="" fi fi AC_SUBST(TNEF_CFLAGS) echo "TNEF is "$TNEF_ATTACHMENTS [...] It's been a few months that I fixed an (Fedora specific) issue with this fragment, but isn't that what the current setup does? If I remember correctly the current configure/make system will simply skip the TNEF decoder plugin silently if libytnef isn't detected with this test.
Ah, you're correct. So I guess we just need to review whether the plugin is suitable for tagging as "stable". I myself have no insight here. Srini? We should also add a line item to the configuration summary indicating whether libytnef support (or better, "Outlook Attachment Support") is enabled.
(In reply to comment #8) > So I guess we just need to review whether the plugin is > suitable for tagging as "stable". I myself have no insight here. 0) My limited testcase (about two dozen winmail.dat attachments) was parsed without problems (no crashes or similar surpises). 1) The code does warrant some cleanup. I'm available to discuss the details (but b.g.o. doesn't feel like the right channel to do that). 2) Furthermore, it should be possible to treat winmail.dat attachments transparently in the future (i.e. just parse them and present their content as ordinary MIME parts). There are some problems (such as: how should we treat message text send as an RTF?) but nothing too intimidating. 3) At the moment I can not do 2) or 3). I do hope to be able to do it shortly.
(In reply to comment #9) > 3) At the moment I can not do 2) or 3). I do hope to be able to do it shortly. Your recursion is making my brain hurt. :-P
Is it expected to make it in 2.26?
It would be enabled, if libytnef is available in your distro. I dont think I would request for ext-dep for GNOME for this library.
If I have built evolution from source, do I need to rebuild it after installing that library?
(In reply to comment #13) > If I have built evolution from source, do I need to rebuild it after installing > that library? Yes, if you want to be able to decode TNEF attachments in evolution you have to install libytnef (and possibly something like libytnef-devel, or whatever that is called in OpenSUSE) and then rebuild evolution (and make sure experimental plugins are build too).
Housekeeping: the topic of this bug seems to have become: should the TNEF Attachment Decoder plugin be upgraded from "experimental" (to "standard")? Adjust several fields accordingly.
I think it should be moved to standard.
Any decision so far? We are after 2.29.1 right now, so can be done finally?
The topic came up on our mailing list too. If someone can verify the plugin actually works then I'll promote it to our standard set. I don't have any winmail.dat files handy to test it for myself.
(In reply to comment #18) > The topic came up on our mailing list too. If someone can verify the plugin > actually works then I'll promote it to our standard set. I don't have any > winmail.dat files handy to test it for myself. I have a mail with winmail.dat handy. I can help with testing. BTW I am using evolution from opensuse gnome factory repository. How do I test the plugin in this version?
(In reply to comment #18) > If someone can verify the plugin > actually works then I'll promote it to our standard set. See my comment #9. It used to work (sufficiently) about a year ago. There is another bug where I detailed the current problems with this plugin. Enabling it will probably expose other problems and thus might trigger more feedback, patches, etc. The goal in handling these attachments should be, in my opinion, to parse them, use what is interesting and than entirely hide them from view. (Which could be more trouble than these attachments are actually worth.) Feel free to prod for information me about those strange attachments. > I don't have any > winmail.dat files handy to test it for myself. You might find some of these here in bugzilla or on public mailing list. (Do note that quite a number of these are actually empty and apparently only used by Microsoft Exchange for internal purposes. I don't know. I don't really care.).
Either of you know of any open-source TNEF _encoders_ that we could use to generate our own winmail.dat files or testing? Thought there might be something out there that works kind of like gzip.
(In reply to comment #21) > Either of you know of any open-source TNEF _encoders_ that we could use to > generate our own winmail.dat files or testing? No, sorry. (A quick search on the web, like you probably just did, turned up nothing too.)
(In reply to comment #20) > There is another bug where I detailed the current problems with this plugin. Here I probably was thinking about bug #563579.
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.