I occaisionally get email from people using MS Outlook/OE that have attachments that are not recognized by Netscape Communicator/Mozilla that are of MIME type MS-TNEF (there are others, but I can't think of them right now). I would like to request the added feature of having a filter that recognizes Microsoft proprietary format and either converts them to html or, better, lets you interact with them as normal mail (RFC822) MSG attachments.
May I suggest that someone looks into http://world.std.com/~damned/software.html It is a package that will decode TNEF attachments. I haven't tried it myself but the author claims that ------------ TNEF is mainly tested and used on GNU/Linux and CYGWIN systems. It 'should' work on other UNIX and UNIX-like systems. ------------ and license is GPL.
Is this feature being worked on ? I receive more and more files with this kind of attachments and this results for me in a dataloss since I can't access the attachments.
Can you attach to this bug report a sample message. Thanks
Created attachment 91136 [details] Message with a tnef attachment There is a jpeg image atached in this message (bresiltu.jpg, 97990 B) , I cannot read it with Mozilla. I saved the message as an eml file from Mozille Mail
I found an interesting article about tnef: http://agamemnon.ucs.ed.ac.uk/faq/mstnef.html
There's also another free app, Fentun that deals with these. The website is http://www.fentun.com/ and the FAQ details where to find the technical details of the format. This format, Transport Neutral Encapsulation Format, is so non-standard that even Outlook Express can't handle it, only Outlook. Given that Mozilla is about standards-compliance I think this bug should be marked WONTFIX, after all we don't support other non-standard stuff, do we?
As a matter of fact, that is what "quirks" mode is all about - supporting non-standards without handling standard material in a non-standard way; I don't see this a much different. By viewing non-standard formats (but not _sending_ in those formats) is not a whole lot different than supporting plugins. I guess you could argue that this should be handled by a plugin though ...
We experience this a lot here, having techies who use Mozilla and non-techies who use Outlook as a stand-alone MUA using SMTP and POP/IMAP without MS-Exchange. If Outlook is used with Exchange Server (the more common scenario), then the two Microsoft products use a proprietary binary wire protocol, and the Exchange Server does the attachment packaging, and will use MIME to talk to the outside world over SMTP. Some additional details which may be useful, based on our experience with the version of Outlook from Office 2000 for Windows. 1. When Outlook generates TNEF attachments, and sends without an MS-Exchange sevrer, the format is actually the attachment encapsulated in TNEF, which is in turn encapsulated in MIME. The outer MIME encapsulation file is always called "winmail.dat" 2. In the TNEF mode, Outlook will not send MIME multipart/alternative for the email message, but will instead put the formatted version of the content inside the TNEF file; the outer MIME email is text/plain only. 3. There is no obvious menu option in Outlook to control whether it uses TNEF or MIME for attachments; however there is a menu option to control the format of the email body, and if this is set to HTML then Outlook will use MIME, if it is set to RTF it will use TNEF. 4. There is a separate option for the format to send Outlook calendar entries in - the two choices are (a) TNEF and (b) ICAL packed as a MIME attachment. This option defaults to TNEF. 5. If Outlook is sending a calendar entry / meeting invitation *and* an attachment in the same message, it will always use TNEF regardless of the above two settings. My suggestion for this feature: a. Although it is supporting a format which is not public standard, it would be highly useful to users of Mozilla, and for that reason I think it would be worth doing, in the same way that OpenOffice supports MS-Word files - it's pragmatism. b. There are multiple open source projects that could supply example code, such as those mentioned above c. I think the easiest UI to do would be to allow double clicking the winmail.dat attachment to pull up another window (c.f. the Download Manager for visual layout) with a contents list for the TNEF, which could then handle individual attachments. AFAIK TNEF does not provide data types for attachments, so this window in turn would have to support dispatching helper apps and plugins by filename extension. d. For later versions it might be possible to consider (i) unpacking the RTF for the formatted version of an email body from a TNEF file and displaying it in line in the mail viewer, and (ii) inlining the TNEF unpacking so its contents end up in the initial attachment list. Of course, c. above could be done as a standalone helper application, but it would be nice if it was integrated with and could take advantage of Mozilla's MIME type manager.
Surely this is more than an enhancement... it really is a pain in the but because a good portion of users out there use M$... and M$ Outlook.
Even though this problem is introduced by M$ Outlook, this really should be classified as an OS independant bug... as it exists when I use my MacOSX or IRIX browser.
Squirrelmail has a tnef viewer plugin, you click the winmail.dat file and it opens a window showing the contents. We use mozilla corporate wide, and trying to get users to run a command line TNEF tool is not an option. So it would be nice to incorporate a TNEF "viewer" into mozilla or possibly a mozdev plugin, that opens the TNEF file and lets you extract from it. I was looking into a nice windows based TNEF extracter to try and associate .dat files with it, then when they click it it would open up and they can see the files and open them from there, but I didn't find anything intuitive engough, I was hoping for soemthing like a winzip interface.
Just a note... attachments encoded in this fashion by Outlook don't always show up as WINMAIL.DAT in the attachments list. A recent message received had, as it's final portion of MIME sections: Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 This showed up as "Part 1.2" in the attachments list. The mailer in the header was: X-Mailer: Internet Mail Service (5.5.2653.19) I also agree that this should be changed to OS: All as all versions of Mozilla will encounter problems with this type of attachment and would benefit from better handling of it.
In my opinion, there should be either an extension or it should be default behaviour. I prefer the default behaviour. In the meanwhile: I downloaded fentun and changed the following in my Thunderbird mimeTypes.rdf file: <RDF:Description about="urn:mimetype:externalApplication:application/ms-tnef" NC:path="C:\opt\fentun\fentun.exe" NC:prettyName="Fentun (ms-tnef)" /> On double clicking the attachment ("Part 1.2") in my case, it opens fentun showing the list of files inside the attachment, allowing to save.
I also vote for this bug to be fixed. The ideas mentioned below (using the download manager as a layout, etc) are all good ideas. I would actually be quite happy to use an external helper application, if I could only find one that offered sufficient options of what to do with the files.
Additional to the attachments saved in the winmail.dat it can also contain invitations messages from a exchange server calendar. Outlook displays a button so that you can accept or deny an invitation to a meeting. If you use exchanges calendar you have to use outlook or otherwise you cannot accept/deny an invitaion to a meeting (or so I was told). It would be really helpfull if there is an extension to mozilla/thunderbird that extracts the calendar informations from the winmail.dat and display some buttons to accept and deny an invitation. The ytnef project on sf.net has extracted already the information from the winmail.dat. (see http://ytnef.sf.net) Currently I have to switch from my beloved mozilla to outlook. :(
*** Bug 279279 has been marked as a duplicate of this bug. ***
This item appears to have been in bugzilla for some time. Is there any real chance of this feature making it into Thunderbird? I guess I didn't realize how much mail and from how many different organizations arrived at my company in ms-tnef. We have been trying to deal with this by employing a perl script that is distributed with Anomy Sanitizer. (Pretty Good) However, sometimes these "dat" files still slip through. Except for the tnef issue our attempt to switch to Thunderbird has gone well. However, this issue appears to be serious enough that we may have to switch back to MS-Products. If possible we'd like to stay with Mozilla as we see it as very large part of our overall plan to eventually move off from the MS platform on the desktop. (Non-MS apps first then ditch Windows) The solution of changing the outlook settings of our customers dosen't seem feasable. In one case we recieved a very unfriendly message from the tech support group of one of our larger customers for even suggesting that one of their users change settings. [wrapped in a winmail.dat, of course...uuugh.] There is no priority or target milestone listed for this issue. Does this mean this item will simply not be addressed?
*** Bug 266088 has been marked as a duplicate of this bug. ***
*** Bug 282822 has been marked as a duplicate of this bug. ***
Some bugs were duped against Bug 173693 which is for wontfixing this. offline tool for windows http://www.magicwinmail.net/wmparser/index.php http://www.magicwinmail.net/wmparser/bin/wmparser.zip online decoding http://www.magicwinmail.net/wmparser/olparser.php
*** Bug 283191 has been marked as a duplicate of this bug. ***
*** Bug 291773 has been marked as a duplicate of this bug. ***
I believe that the owner of the bug, Ducarroz, is not actually active anymore on the Mozilla project, and his bugs should be reaffected. I think this should logically be WONTFIX, as the scope is more adequate for an extension than in the core of Thunderbird. But given the significant community interest for this bug, I seems more adequate to first reassign it to the module owner to let him decide. For those who need a workaround, reread comment 14.
Re #24, I do think this ought to be in the core, rather than an extension. Attachments are a fundamental part of what a mail client does, and tnef is in many cases a de-facto standard. Extensions are for optional extras, but almost everyone is going to need tnef support.
(In reply to comment #23) > *** Bug 291773 has been marked as a duplicate of this bug. *** I think it isn't a duplicate of this bug, because I have the bug only by automatically forwarding mails. (created by an Outlook rule) If I send a mail from the same server (with the same Outlook version) to my home mail account with attachment it's allright.
I tried to the solution in comment 14 and restarted thunderbird (1.0.6 on Win32), but when I double-click on attachments with MIME type application/ms-tnef I still get the "Open With/Save to Disk" popup. does anyone else have this working in TB 1.0.6?
I was just helping someone with this today and discovered this bug. It is still not working in an hourly Thunderbird build from this morning.
it is even worse if you got a mail where the sender using outlook pasted images in his HTML mail and expects you to know which image goes where in the mail. You get (after working with an external program from thunderbird) a bunch of images in a directory and his mail with empty spaces where he pasted images, and you must put the puzzle together. I found that fentun.exe does not open all the tnef attachments. on windows I found only two reliable solutions to open such attachments: * http://tud.at/php/tnef/index.php (great for privacy, send your files unencrypted on internet. plus this site was down for a while) * compiling from source the UNIX tnef command-line program under cygwin. that's what I use now. not really user-friendly. franckly, this is barring completely using thunderbird in any serious corporate setting except if you REALLY REALLY want to use it. Outlook is here, I wish it wasn't, many people do, but it's life. this feature is needed and an extension is not enough. it must be standard. people expect to be able to read their mails, that's what a mail client is for. they don't want to install an extension (maybe not available in all the thunderbird languages) that won't offer viewing images copy-pasted in HTML mails just because the sender used outlook.
Just to add to this issue, this is a pain for most installs out there. It really is stopping thunderbird adoption. I think Microsoft know this and it is a deliberate part of their strategy. If you can, I would make this an unpleasant but necessary priority. BTW Thunderbird is most excellent, we always try to install it at all sites but the winmail.dat issue has come back to haunt us.
Any particular reason this isn't wanted in the next release?
11 years ago
Does Outlook 2003 still do this, or is it mainly Outlook 2000?
Yes. Outlook 2003 still can generate in mstnef. These types of messages seem to get much worse to untangle when the message has been forwarded around from MS-Outlook to MS-Outlook client then finally copied to a Thunderbird client.
Hello, According to me, Ignoring the file of this bug is not a good idea as it may causes loss of data (ie the attachments). The support of the winmail.dat is a major showstopper to the adoption of thunderbird in corporate environnement where Outlook is used. If the thunderbird users can't see the attachments of their fellows using Outlook, you can bet that TB will have a hard time proving itself as a successfull replacement of outlook express and/or outlook. Just my two cents. Keep up the good work, gent's Bertrand
Hello, According to me, Ignoring the file of this bug is not a good idea as it may causes loss of data (ie the attachments). The support of the winmail.dat is a major showstopper to the adoption of thunderbird in corporate environnement where Outlook is used. If the thunderbird users can't see the attachments of their fellows using Outlook, you can bet that TB will have a hard time proving itself as a successfull replacement of outlook express and/or outlook. I think that the support of the TNEF should be in the core of TB. I do agree this is not the most elegant, but most of the user expect to have a fully functionnal outlook express replacement (and more of course) right out of the box. TB is a great piece of software and it would be very sad to have to go back to ms mail client just because winmail.dat is not handled. Just my two cents. Keep up the good work, gent's Bertrand
*** Bug 331461 has been marked as a duplicate of this bug. ***
Fixing this bug is REALLY IMPORTANT; I think it should be a blocking bug for the next major release of Thunderbird. http://www.kelv.net/linuxbusiness.html highlights this bug as one of the key reasons people can't use OSS systems in general. And just look at the other comments: "major showstopper", completely [barring using thunderbird in any serious corporate setting", "this issue appears to be serious enough that we may have to switch back to MS-Products". There is NO POINT to an email client that can't receive email. Yes, it's not a standard format, but Mozilla supports lots of other odd extensions that aren't official standards; this is a de facto standard, and there's no licensing reason to NOT support it.
+1 for anything that gets this into the next release. Is there anyone who is monitoring this bug that has the authority/ability to change the priority and resolve this issue? Maybe the bug hasn't been addressed for 5 years because it isn't on anyone's radar screen.
(In reply to comment #39) > +1 for anything that gets this into the next release. Is there anyone who is > monitoring this bug that has the authority/ability to change the priority and > resolve this issue? > > Maybe the bug hasn't been addressed for 5 years because it isn't on anyone's > radar screen. > I note from the CC list hat several people CC'd here are serious moz types, so can I assume do something. My guess is the problem is two-fold: 1) No-one is currently listed as the owner of this bug. So someone with code experience is going to have to volunteer to sort it out. 2) The priority very much depends on your own working experience. I have only every received a couple of winmail.dat-containing e-mails, so to me it is not a problem. On the other hand, some people are I guess plagued by this the whole time.
I've posted a short "how-to" guide for those dealing with the problem today here: <a href="http://www.dwheeler.com/essays/microsoft-outlook-tnef.html"> http://www.dwheeler.com/essays/microsoft-outlook-tnef.html</a> - but it would be MUCH better if Thunderbird had built-in DIRECT support for opening/handling this format.
I thinks it's a good idea to make tnef decoder in core but we must alert users that TNEF is non-standard and with TB decode only partialy this format To help, MS senders can read http://support.microsoft.com/kb/290809
(In reply to comment #42) > I thinks it's a good idea to make tnef decoder in core but we must alert users > that TNEF is non-standard and with TB decode only partialy this format > > To help, MS senders can read http://support.microsoft.com/kb/290809 > I tried, but it gets cut off in Firefox. )-:
I see a lot of yays and nays about whether this is acceptable as an extension. Would it be sufficient to provide it as an extension first? If the extension becomes popular enough, it could be used as a means show the developers that it is a needed function in the core. It would become much easier for them to justify spending their time on it. If this is an acceptable plan of attack, I will see if I can write an extension for this.
An extension would be a great step forward on this issue.
"Alerting" Outlook users that TNEF is non-standard isn't going to accomplish a thing. Corporate environments are, I'm afraid, far more likely to consider Outlook's (mis)behaviour to be "standard" by definition and will simply tune out any appeal to RFC's, etc. -- just as we've already seen happen regarding IE vs. other browsers. Since TNEF-encoded attachments display fine in Outlook, users of that software are simply not going to understand why there's a problem; far more likely to happen would be a corporate directive banning "non-standard" (i.e., non-Microsoft) mail software within the company in question. People who want to promote Thunderbird -- or simply to be able to use it themselves -- in an environment where others are using Outlook really MUST have an easy way to handle TNEF data.
Just today got a new twist on this. I got a bunch of pictures from a comcast account and about 7 pictures all showed up as one winmail.dat file. I forwarded the email over to a yahoo account, and was able to individually download and therefore view these pictures there. There is no way I could do this in the latest thunderbird 2.0 beta nightly build. Something needs to be done here.
Please fix this... It is driving me nuts... its seems the majority of the professional world is using outlook, and i keep getting winmail.dat... SUX Thank you to whomever takes the lead on this project
For those not willing to wait for native TNEF handling have a look at EolSoft's WinMail Opener. http://www.eolsoft.com/freeware/winmail_opener/ Seems to work for me. Simply associate .dat files with it and off you go.
If this can't be fixed for 2.0 final, can we get a flag to mark it to block for 2.1 or 2.5 or whatever the next version is? Thank you.
I'm new to Thunderbird, but I feel annoyed by this "situation" on winmail.dat. T-bird being such a great program, should have already solved this problem. Otherwise, I have reached the top with T_bird !!!!
I have added my vote to get this in the Thunderbird core. The reason is that users trying to switch to Thunderbird from Outlook using something like an IMAP intermediate will find many messages populated with winmail.dat. Not having this feature is a blocker to entry. The various .dat associaters work, but are much less convenient than inline handling.
I am heavily disappointed of the discussion. 6-year neglect of user needs provokes major doubt in the management of the project. It is a definite blocker to invest resources in promotion of the Thunderbird.
Tomorrow will be the 6th birthday of this feature request, still unassigned.
There IS a Thunderbird extension that does this, "LookOut". Home page at: http://lookout.mozdev.org/ and download location at: https://addons.mozilla.org/en-US/thunderbird/addon/4433 This capability really should be built-in, though. What's the point of an email reader that can't read an attachment format that's widely sent? Yes, tnef is stupid, but uuencoding has its own bain dramage, and Tbird handles that well enough. Let's remove the blockers from widespread adoption.
Perhaps the extension author would be interested in working with us to incorporate his code into Thunderbird? Can the code be licensed suitably, e.g., MPL?
Well, it is part of "mozdev", so isn't that sort of directly related to Mozilla Corp anyhow? In any event, the email address from the extension's page is firstname.lastname@example.org . I suggest a developer contact him and ask. Looking forward to the answer/progress.
Ok, I'm here. I thought I did put this under the tri-license. I would like to help any way I can. The real problem with the extension is that the TB/MailNews API is not clean when it comes to attachments. I had to do ugly hacking which is partly modeled on enigmail. If I could focus on the TNEF decoding and someone else who was more intimate with MailNews worked the UI side I think we could make an excellent TB and SB extension or internal. By the way I have also spoke with legal at Lockheed Martin, which funded the initial version, and the MPL is fine. Aron
By the way I see no good reason to not have TNEF decoding available. The program should be designed around the user. If a user needs to decode some miscellaneous format so be it. I am not so sure that it should be internal though. If that is really the case then Mozilla should have en/decoders for many other things as well. And yes I feel dirty after dealing with this ignorantly conceived format. Aron
Aron, I'd be happy to work with you on this.
Please note that bug #360980 has been assigned to the Penelope team. Make sure you are not working on two separate solutions.
That looks much more narrow in scope and further behind. There is no indication of any progress on TNEF in penelope or how that will flow back to MailNews. LookOut is meant to be a TNEF decoder. TNEF encapsulates all sorts of metadata, most notably RTF messages, attachments, contact info and calendar/event data. Microsoft just entirely ignored MIME, vCard, and iCal. Aron
(In reply to comment #47) > Just today got a new twist on this. I got a bunch of pictures from a comcast > account and about 7 pictures all showed up as one winmail.dat file. I forwarded > the email over to a yahoo account, and was able to individually download and > therefore view these pictures there. There is no way I could do this in the > latest thunderbird 2.0 beta nightly build. Something needs to be done here. Just hit the same thing again today with the nightly 2.0.x branch of Thunderbird. Forwarded the attachment to yahoo mail just fine, and opened fine once in yahoo mail. (In reply to comment #59) > By the way I see no good reason to not have TNEF decoding available. The > program should be designed around the user. If a user needs to decode some > miscellaneous format so be it. I am not so sure that it should be internal > though. If that is really the case then Mozilla should have en/decoders for > many other things as well. ... Aron, thanks for coming here and offering your help on this bug. I hope a resolution is reached soon. I think various formats should be supported also, and as the need (demand) arises, new bugs can be added to deal with those additional formats. This particular format is so pervasive, though, that it really does need to be in the base program. Thanks for your work on this matter.
I know this is a little late to be updating comment #6, but the link in #6 (that is, http://agamemnon.ucs.ed.ac.uk/faq/mstnef.html ) seems to be broken, and the new URL is / probably should be [something like] http://www.is.ed.ac.uk/itus/sce/email/mstnef.html (can someone cause this to be displayed in or near #6?) (& maybe with a "strike-through" font for the old URL?) ...just my 0.02, Mike Schwartz
By the way, I submitted a new version of LookOut on the July 5. It has been stuck in review but they will theoretically approve it at some point. It makes you wonder how many other add-ons that people need are stuck in the queue collecting dust.
New version of the LookOut extension put into AMO for review. This one fixes a metadata reading bug and added RTF decoding/decompression. It would be nice if the RTF could be viewed inline but at least it is accessible. RTF and HTML body text (as opposed to an explicit attachment) will now show as body_part_#.rtf or body_part_#.html. Until the AMO folks get around to it you will find the LookOut 1.2 xpi in the AMO sandbox. Enjoy, Aron
If anyone is still out there I have yet another version stuck in the AMO sandbox. I should be renamed the AMO tar pit. I am also half way done the code to interpret MAPI appointment data as ical data.
A couple more details for anyone interested. The next version will hopefully allow TB users to move a little closer to integration with Exchange without Outlook or Evolution Exchange Connector. It reads a number of additional MAPI properties including the calendaring data. I will need some advice on how to best display the non-calendaring data. Most of it does not look useful but I'm sure there are people who would disagree.
I would also like to add my vote to make this part of the core. The reasoning being that the use of this not-standard microsoft extension is so widespread as to be a defacto-standard. This coupled with the fact that the average non-technical person is going to give up way before they get to the point of trying to install add-ins. Chances are good they have no idea what an add-in is. Thunderbird should be usable for them "out of the box" without having to customize it with addons. I also think it is totally unrealistic (as suggested in some of the older posts) to tell senders to "stop using TNEF." Most of the people I get attachments from would have no idea how or any inclination to learn how to do this. Other people (most with outlook that someone else setup) have no problems reading their e-mail, so why should they have to put out effort just for me?
Aron has made a good add-on. +1 vote for making this part of the core. I see that the bug is assigned to 'Nobody'. Does this mean nobody at Mozilla is monitoring this issue? Is it considered unusual (or significant) that a bug has consistent activity an no fix going on 7 years?
This is the biggest problem that I have with using Thunderbird. I need to work with attachments from an exchange server, and at least download them. I have to use an add-on (LookOut) to even see that the attachments exist, and often I can only see the first attachment of several. I do NOT have to have a MS-whatever compatible viewer to see powerpoint or whatever. Although both have their place, being able to relate to the common or widespread use in the industry is far more important to the users than strict adherence to documents or technical specifications.
This one is close to blocking tb3, but I need to get a better feel for some of the logistical/license issues before I could mark it blocking-tb3.
@Steve Burns Do you have the "only one attachment" problem with LookOut 1.2.2?
Correct, I still have a multiple attachment problem with the latest versions. Let me give you a few additional details. Thunderbird version 126.96.36.199 (20080421) LookOut 1.2.2 The bottom pane often shows three entries: Part 1.2 body_part_0.rtf AttachmentOneOfMany.xxx The first attachment will display and save and work correctly, but all other attachments are not shown. I am grateful that I can see the first attachment. I have noticed that lots of multiple attachments show OK when "Part 1.2" and "body_part_0.rtf" is NOT present (sender is not using MSOutlook, I think). When multiple attachments showed up correctly, the "Content-Type" was NOT "application/ms-tnef". The email header refers to "Microsoft Exchange V6.5". The bug that is supposed to be discussed here is for Thunderbird, not LookOut, and/so if more details are needed I would be happy to take the LookOut bug discussion to a different forum or off-list as needed. ----- MSExchange and MSOutlook are so pervasive in our culture that I think there is a lot of value for Thunderbird to natively handle the MS formats in a graceful way, without needing the extra step of adding an Add-on. Especially if we want to help people find their way out of the tunnel.
Ok I have fixed the multiple attachment issue. I had been reusing the file attribute data structure without clearing some of the fields. I also fixed a couple of other issues. I merged in my latest MAPI to VCal code as well. That code is largely un-exercised. Does anyone have an email with appointment data that I could test with? Aron
Thank you but I check my home account with GMail. Can you save the message as an EML so can be sure to have a copy not preprocessed by Google. Attach the EML file. I then open that in TB. Aron
I have posted the new version to the project site. I will submit this to AMO as soon as I get a little more testing done. http://lookout.mozdev.org Aron
To Aron: Using LookOut v1.2.3, all I get from the mail are two files: - winmail.dat - body_part_0.rtf The mail was sent using Outlook 2007 and Thunderbird 188.8.131.52 is the client who received the mail (actually, it's an invitation for a meeting, not a real mail) Is it possible to fix this and to have such accepted/rejected buttons just like in outlook? To Mozilla's staff: Guys, more than 100 people demand this functionality and it's such a pain to use Outlook just for these damn winmail.dat-things as Thunderbird can't handle it.. :( - So _please_, give us this functionality!
Yes please open the email in Thunderbird and File->Save As->File then send the file to me. I am still processing all the test data to finish the meeting module. Mozilla has taken an active interest in incorporating LookOut's capabilities. Additionally Lightning may provide further calendering functionality. I am trying to feed that with the MAPI decoding in LookOut. Thank you, Aron
You've got GMail! :D And I'm _so glad_ that Mozilla cares that much about its users! :)
I use a helper app for winmail.dat (TNEF) files. It's named "fentun". It works in SeaMonkey, too. Get it free at http://www.fentun.com/
I used to use Fentun, but it stopped working reliably in XP. I now use WinmailOpener, mapped to .dat files. Still a bandaid solution, but better than nothing.
Michael, Can i have the link to winmailopener. I would love to test this on unix if possible since i cant decode the message either.
After looking at the links provided for extensions/apps to handle TNEF files all state support in TB2.
.. which anybody who has Office 2007's Outlook can proof to be false, i.e. the latest TB2 isn't able to handle TNEF files, nor to handle attached images correctly (they're displayed inline, regardless if originally attached or indeed added inline)! As soon as TNEF- and/or HTML- content is/are involved, there's a "PartX.Y"-textfile being shown as an attachment and TNEF-related mails are handled completely wrong..
Here is the link to winmail opener: http://www.eolsoft.com/freeware/winmail_opener/ . However, this is ONLY for windows. Per the FAQ on EOLsoft, there is a mac TNEF decoder at http://www.joshjacob.com/macdev/tnef/index.html, but again, this appears to be a Mac-only application, not specifically for UNIX. If you can get either one to part with the TNEF decoding code, you might be able to port it into Tbird, but I'm doubting it as at least joshjacob requests a donation for the app.
Aron, was just wondering if you have made any progress on this?
I have made a lot of progress with LookOut itself. For LookOut as an add-on I have two attachment decode bugs left that seem to relate to non-english setups. One of them seems to be an issue saving files if the file name includes certain unicode characters. Reading through some Win32 docs I am starting to suspect that may be because filenames need to use UTF16 instead of UTF8, however, the Moz IO code should abstract that. None of the reporters of that issue have given me any test data. The other issue is for some non-english language packs people observe no virtual attachments. For that one I have received some test data but no information about what appears in the "Error Console". I have a lot more work to do on the calendaring and contact code but it seems work reasonably at the moment.
Oh, sorry, my other problem is that it has taken over two months to get a version approved through addons.mozilla.org
Since I'm from Germany and currently writing from my work-machine which has Outlook 2008 installed, just let me know if I can be of _any_ help! :) I'm creating invitations or whatever you need just to get this bug solved, because it's the main (only?) reason for most of my colleagues to prefer Outlook over Thunderbird..
Ensure you have LookOut 1.2.6 downloaded from the "experimental" area of AMO because they have not approved it yet. In order to have problems you *may* have to be using the non-english language specific Thunderbird download. I think that means they do not ship the english language pack with the installer but I am not sure. Also the attachment file names must have some characters in it that are outside ASCII (7-bit). They may have to be well outside ASCII. By the way your appointment example, "bla", is very useful. If you or anyone else wanted to supply more elaborate MAPI meeting invites, attendee change notifications, project notifications, etc. I would be grateful.
Hmm.. Mine were sent directly to your mail-address and because there's private data within those .eml-files, I sent them to your mail-address once again..
Aron: I talked to the product manager for AMO a bit yesterday, and it sounds like we still have some kinks to work out of that system; sorry for the long delay. I'll start up an email conversation with him, you, and a few others shortly...
Any news on this bug? Yes, I hate this TNEF format too, but I need it for my daily work. LookOut works quite good so far. If Firefox includes some of the IE Quirks Mode, then why can't Thunderbird have support for TNEF?
BTW: Evolution supports TNEF attachments, even though its support is not perfect. https://bugzilla.gnome.org/show_bug.cgi?id=271398 https://bugzilla.gnome.org/show_bug.cgi?id=563579 KDE's Kmail supports them too (but I can't say how good that support is)
In addition, I have no option but to use Msoft Mail simply because other mail clients does not support TNEF. This is very unfortunate and limits the options greatly in terms of what to use for communication. It is not a matter on my side being able to access the mail, it is an issue that my recipient does not understand the attachment that cannot be opened. It is a skill thing which unfortunately limits the use of anything other than Msoft Mail Clients.
There is a way to accomplish this on Windows: 1. Download the free Winmail Opener program http://www.eolsoft.com/freeware/winmail_opener/ (I simply extracted the .exe installer to a folder, then put that on a shared location, so all of our users can make use of it without me having to install it on on everyones PC) 2. Install the 'OpenAttachmentByExtension' extension http://nic-nac-project.org/~kaosmos/index-en.html#openattach 3. Restart TB then go into the options for the extension and add the dat extension with a pointer to the wmo application. Done... you can now open winmail.dat files to read the message and/or extract the attachments (if there are any).
This don't work with 3.0.1 version...
Charles, you seem to forget what's this bug all about: _inline_ viewing, not using _any_ third-party tools and not to only view the contents of the DAT-file! Additionally, Comment #49 already lists that tool for usage which makes me wonder why you wanted to post it again.. Personally, I don't care about the DAT-format - I just want this bug to be fixed and to answer invitation- and voting-mails as I can do with Outlook 2007!
(In reply to comment #105) > This don't work with 3.0.1 version... Does for me - I just tested again to make sure. > Charles, you seem to forget what's this bug all about: _inline_ viewing, True... so sue me for trying to help with a workaround. > Additionally, Comment #49 already lists that tool for usage which makes > me wonder why you wanted to post it again.. I didn't read every single comment before posting, and I missed it - so sue me. And besides, my explanation is a bit more detailed, > Personally, I don't care about the DAT-format - I just want this bug to be > fixed and to answer invitation- and voting-mails as I can do with Outlook > 2007! Yeah, there are a *lot* of 'bugs' in TB I'd like to see fixed... this one is pretty low on it though.
(In reply to comment #107) > True... so sue me for trying to help with a workaround. Excuse me, I did _not_ want to sound arrogant or like "Stop that, because it doesn't help!" - it may help, but doesn't fix the bug and I assume(d), using workarounds makes people lazier with regards to solving bugs.. You know "With FOO it works, so BAR as a fix isn't really urgent" - especially, if you take into account that this bug exists for over 9 years without a final solution.. > I didn't read every single comment before posting, and I missed it - so sue me. > And besides, my explanation is a bit more detailed, Again, I'm sorry for not honoring your contribution enough. > Yeah, there are a *lot* of 'bugs' in TB I'd like to see fixed... this one is > pretty low on it though. Not IMHO - AFAICT, this is one of the most missing features that make CEOs preferring Outlook over Thunderbird!
Charles, have you ever received a meeting invitation inside a winmail.dat, that you wanted to accept and import into Lightning? With an arsenal of extensions and additional applications it is possible (at least importing, not sure about accepting), but really it needs to be integrated.
No, those aren't important to me, which is why I said it was low on *my* list of bugs that need fixing... That said I do understand the need for those who rely heavily on calendaring and interaction with Outlook users, and agree it would be nice to add this capability. But the fact is, there is a simple fix on the Exchange server side, so you should be pushing for the moron windows admins on their side to fix it, because it is broken for everyone outside their exchange environment that doesn't use Outlook.
Could you explain what needs to be fixed on the Exchange-side?
Exchange does not have to be part of the equation, standalone Outlook can cause the same problem.
(In reply to comment #111) > Could you explain what needs to be fixed on the Exchange-side? and > Exchange does not have to be part of the equation, standalone Outlook can > cause the same problem. Both true. Here is an email template I created a long time ago to explain the problem to problem senders, and the different ways of resolving it (on either the Exchange Server side (for everyone in the company), or on the Outlook side individually, if the exchange admin won't cooperate: "Fyi, we are receiving all of your emails with one or more 'winmail.dat' files as an attachment. This is a known issue with Microsoft Outlook and Exchange Server that causes non-Exchange recipients of your emails to get these attachments. It isn't a problem if you aren't including any actual attachments (like PDF or Word/Excel files) - but if you do, these won't be readable by our Sales Reps (without my having to decode them individually with a special tool). Here is a Microsoft Tech Document outlining the issue, including different ways to resolve it: http://support.microsoft.com/kb/149203 Please forward this to your IT person. If they choose not to implement the change at the server level, then they should be able to help you configure your Outlook to not send these to the MBI addresses in your address book." Hope that helps...
Regarding priority: This single bug is why I cannot use Thunderbird and why I use and require my staff to use Outlook. My boss requires me to send pleasingly-formatted email that is compatible with whatever Outlook configuration we have running on the IT server. I tried LookOut and other workarounds but nothing worked well enough, and I lost the battle here. There were other compatibility problems with numbering and bulleted formets, but this attachment bug was the biggie. - A former Thunderbird user
We (IT staff) put our collective feet down against using Outlook in the organization and wouldn't budge. What we have now is the majority of users (approximately 100 in total) using Thunderbird 2 (! Still waiting for Lightning 1.0). The rest are using/complaining about IceWarp Webmail, with a handful of holdouts still using Outlook. This was only possible by using Aron's extension. In fact, what we use is LookOut with extensive modifications that might be difficult to integrate back into the trunk; Aron, you might remember that conversation some time ago. We've also locked down and disabled HTML composition in Email, but that's another subject. The only way to "beat" Outlook is by evening the playfield; do your best to trick Outlook into using web standards against its will, and do your best to convince Thunderbird that it needs to be compatible with Outlook anyway. At the least, this bug can make the latter happen.
I'm taking the risk of becoming very unpopular here, but I don't think it is something we need to "fight" outlook to change. This is how outlook is, and as much as we don't like it Outlook is still the most used enterprise email client out there - Thunderbird should be able to communicate (receive and send emails) with outlook properly either with built-in support, or an official plugin.
(In reply to comment #115) > What do you mean by "the architecture"? Is this just about making a certain > function scriptable? Did you file a bug about making that happen? My impressions are a bit old here (about a year) so bare with me a little. In general terms as you get toward the back end of mail operation abstraction and hook points fall away precipitously. Where libmime should just be concerned with containers and leafs, it is instead a direct implementation of MIME protocol intermixed with specific handlers. Everything is crammed in there - protocol, security, display. It is absolutely chaotic. I did file a bug report [bug 446321]. It was more narrowly focused then asking for rearchitecting libmime and IMAP :)
Could use the "helpwanted" keyword.
I first started looking at this bug 2 1/2 years ago. Back then it was a blocker preventing me from switching from Outlook 2000 to Thunderbird. I have finally given up and purchased copies of office 2010. When I see comments like "you should be pushing for the moron windows admins on their side to fix it, because it is broken for everyone outside their exchange environment that doesn't use Outlook.", it is disheartening that some of the people posting about this problem just don't get it. My company has over 100,000 employees worldwide and an entire division that does IT. Do you really think you are going to be able to tell them all to change what they do? The average user won't even have access to those level of admins. All they can do is contact the help desk people who certainly aren't going to be able to do anything or even care about doing anything. Ya coulda been a contender ...
It is actually quite entertaining for how many years I've been following this bug; even more so, since by now I'm using Outlook 2010 (their IMAP support with version 2010 did really improve, their .pst-storage format is still rubbish though)... that, and I would've gladly donated whatever amount it required for this to be implemented. But then again, that's not how opensource works I guess... if nobody is interested, throwing money at it seldom helps. It's been a nice time with Netscape Mail&News and after Mozilla with Thunderbird then though! ... another few users lost.
Still getting unusable winmail.dat on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) Gecko/20110307 Lightning/1.0b2 Lanikai/3.1.10pre
Happy birthday to you! Ten great years for this bug report, and it doesn't look a day older. Is this a record?
The least it could do is to open up Outlook Express when you try to open the attachment. I just got bit by this again today. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11pre) Gecko/20110622 Lightning/1.0b2 Lanikai/3.1.12pre
(In reply to comment #129) Unfortunately, there are two problem with that approach. Well, at least two anyway. 1) I have seen Outlook Express have exactly the same problem with TNEF (ie "winmail.dat") attachments. TNEF attachments are created by Outlook, not Outlook Express. 2) That workaround pre-supposes that a) you're running on Windows; and b) that Outlook Express is actually installed. MS in their infinite wisdom (!!) have rebranded Outlook Express as "Windows Mail" or "Live Mail" or some such name. Regardless of the name, it's not available in a Linux or Mac OS X flavour. No, unfortunately the only answer (apart from getting people to not use Microsoft Outlook in its default proprietary mode) is to actually have Thunderbird intelligently "unwrap" the TNEF attachment, and then re-present the various sections as MIME attachments to the email. Whether the unwrapping should be done "on-the-fly" (ie when viewing/forwarding/replying to the email), or as a permanent change (ie as the email is being initially received into the mailstore) is open to debate. My personal preference would be the permanent rewrite of the incoming message so that the TNEF encapsulated attachment(s) are broken out into their constituent elements and then stored as separate attachments to the message, and the TNEF "winmail.dat" envelope is silently dropped. oF course, that's my preference.
(In reply to comment #130) > My personal preference would be the permanent rewrite of the incoming > message so that the TNEF encapsulated attachment(s) are broken out into > their constituent elements and then stored as separate attachments to the > message, and the TNEF "winmail.dat" envelope is silently dropped. oF course, > that's my preference. Although totally off-topic for this bug, the most excellent anti-spam proxy ASSP has a plug-in that does precisely that (uses the perl TNEF convert plugin). I haven't used it (yet) myself, so can't vouch for it personally, but I'm told it works as advertised.
Over 10 years on this bug! I'm going to give http://outgoing.mozilla.org/v1/ec8ec54ef337ef240f0c5afde1e7c31daec4fd2a/http%3A//lookout.mozdev.org a try.
(In reply to Scott Marshall from comment #130) > My personal preference would be the permanent rewrite of the incoming > message so that the TNEF encapsulated attachment(s) are broken out into > their constituent elements and then stored as separate attachments to the > message, and the TNEF "winmail.dat" envelope is silently dropped. oF course, > that's my preference. Agreed. I cant receive ANY files from exchange server (hotmail and lot of my costumers) after update to thunderbird 6 as Lookout extension stop working. As TNFE is used for all Exchange Mail Server and clients using Outlook can use it to, I think this bug should be correctec ASAP.
This should not be "new", but should be "fixed" with "Aron Rubin" as the resolver. I'm running TB 8.0 from PortableApps, and LookOut 1.2.13 from AMO. * winmail.dat is automagically expanded into multiple attachments. * ICS files from within show up in my Lightning calendar. Future enhancements (additional tickets) could be: * Help on Options for the plugin. * Move this to the formal code tree so it's maintained for new versions. * View RTF in-line (different plugin/scope, maybe RTF-to-HTML)
I'd love to get a working LookOut for TB 10 so I can see if it still works in there. There was oddness with some file before I started working in Aurora channel (couldn't see .ics files with or without lightning for launching external calendar, etc.).
I have just completed testing TNEF with Thunderbird 9.0.1 and Lookout 1.2.13 against Windows Live Mail 2011 and it has to be said TB+Lookout works much better as WLM2011 loses font formatting and attachments! However Lookout is listing winmail.dat as an attachment and the formatted message can only be seen in body_part_0.rtf, I am sure it used to hide these and display the rtf directly in the TB message window. Anyway, given this issue has been open for over 10 years then I think it should either be closed and marked "will not fix" (which is really what the current status is!) or preferably TB should be fixed making TB the best mail client (or making it better really). Sure we could continue with TB+Lookout but that is far from ideal.
This really needs to get fixed. I have used Thunderbird for several years, and lack of support for Winmail.dat and calendar invitations containing attachments from outlook is the only major problem I have seen. Having said that this is a HUGE problem. Corporate clients do not care about RFCs or standards. For them Outlook is the standard, and they expect their contractors to be able to work with all mail that they send, including meeting invitations with attachments. Lack of this capability forces me to maintain a separate outlook client. Thunderbird will never be the best mail and calendar client available, while this problem remains unresolved. Closing it and marking it "will not fix" is just a way of putting one's head in the sand. Outlook is going to be around for another 20 years, and this application needs to work with outlook mail seamlessly.
Rob - while this is undoubtedly true, open source only works when people volunteer resources. If you don't have coding expertise to fix this, how about offering a bounty to see it fixed? This may incentivise someone to take on what is clearly a difficult problem to resolve. If I was still using Thunderbird, I would contribute to a bounty (but I now primarily use Mac OS X mail).
There are a lot of people who agree with you Rob, and we all wait with baited breath for your patches that make Thunderbird magically work seamlessly with Outlook. :)
Why should effort be applied to implement a feature that currently exists only in Microsoft products? There are plenty of existing actual discrepancies in Thunderbird that need to be fixed. Bugzilla provides a "vote" capability, but only to vote in favor of a change. If there were a capability to vote against a change, I would vote against this non-enhancement.
(In reply to David E. Ross from comment #141) Some people want to be Microsoft bashers, other people live (whether they like it or not) in a world where Microsoft has an appreciable part of the market and the remainder has to be compatible with it. The problem isn't as apparent as it was when this bug was created, because Microsoft has also moved to support internet standards and mail with TNEF attachments is now only sent by users who have made configuration changes, but it still is a nuisance sometimes. There is an extension that handles the problem, only it sometimes does not work (because of changes in Thunderbird? because there are bugs in it? I don't know for sure) Maybe it would be sufficient when the extension would be adopted as a standard one and maintained when changes are made.
(In reply to David E. Ross from comment #141) > Why should effort be applied to implement a feature that currently exists > only in Microsoft products? There are plenty of existing actual > discrepancies in Thunderbird that need to be fixed. > > Bugzilla provides a "vote" capability, but only to vote in favor of a > change. If there were a capability to vote against a change, I would vote > against this non-enhancement. Because Microsoft has a huge market share. That makes MS a standards definition, even if we don't like it. Interoperability, or "working" is what matters, not "being right".
(In reply to David E. Ross from comment #141) > Why should effort be applied to implement a feature that currently exists > only in Microsoft products? There are plenty of existing actual > discrepancies in Thunderbird that need to be fixed. The current guidelines for MIME is to support the MIME specifications as well as any deviation from the specifications where the intent is clear and where there is compelling evidence that it is common enough to warrant special-casing. TNEF decoding does qualify under these guidelines, at least to me, but the current architecture is not capable of gracefully supporting it: I would probably not accept the current LookOut add-on to be checked into the tree under its current state.
(In reply to David E. Ross from comment #141) Same reason as something like LibreOffice allows for opening and saving DOC files. If this is not available - TB will only stay a niche program. It would be one of the major requirements to eat into OL's market share (there are others but this is something which is simply impossible to live without). To get everyone working with TB would mean that those early adopters need to "live" inside a M$ dominated environment. Only once enough (say around 50%) of all users are using TB (or some other standards compliant client) would it be possible to drop support for such proprietary format. For the time being, TB users have to not even notice that the emails they've received originated from OL. There should be no reason for a TB-user to think: "What am I going to do in this case?" It should simply work as any other email/invite works. Even stating that they should install an add-on would alienate nearly every single non-tech-savvy user. So with this attitude towards this one single bug/non-bug (whatever you want to call it) you've just doomed TB to never be used by the general email sender / receiver. And thus it will never reach any form of decent market share, so it could just as well die in such case. TB need to create TNEF attachments, OL (at least since 2003) can read normal mime types - so that shouldn't be a problem. It's just that TB needs to be able to read the contents of a TNEF correctly and be able to work with OL invites to add to a calendar and reply accept/decline/tentative/etc.
I completely agree with irneb. I don't know why TNEF reading capability is not included already in Thunderbird. It must not be so difficult (compared to other features implemented in TB), and it's the major (if not the only) drawback of TB, considering that almost 100% of business users use Outlook.
At present the LookOut addon seems to work for TNEF attachments. Though calendar invites only work 1/3rd way (they're displayed as an invite, but neither are they added to a calendar, nor is there a way of accepting). BTW, should this bug not be applied to the official LookOut addon? http://lookout.mozdev.org/ At least then there is some possibility of someone actually doing something about the bug instead of simply stating: "I would vote against this non-enhancement".
(In reply to irneb from comment #145) > (In reply to David E. Ross from comment #141) > Same reason as something like LibreOffice allows for opening and saving DOC > files. If this is not available - TB will only stay a niche program. > > It would be one of the major requirements to eat into OL's market share > (there are others but this is something which is simply impossible to live > without). To get everyone working with TB would mean that those early > adopters need to "live" inside a M$ dominated environment. Only once enough > (say around 50%) of all users are using TB (or some other standards > compliant client) would it be possible to drop support for such proprietary > format. For the time being, TB users have to not even notice that the emails > they've received originated from OL. There should be no reason for a TB-user > to think: "What am I going to do in this case?" It should simply work as any > other email/invite works. > > Even stating that they should install an add-on would alienate nearly every > single non-tech-savvy user. So with this attitude towards this one single > bug/non-bug (whatever you want to call it) you've just doomed TB to never be > used by the general email sender / receiver. And thus it will never reach > any form of decent market share, so it could just as well die in such case. > > TB need to create TNEF attachments, OL (at least since 2003) can read normal > mime types - so that shouldn't be a problem. It's just that TB needs to be > able to read the contents of a TNEF correctly and be able to work with OL > invites to add to a calendar and reply accept/decline/tentative/etc. Well stated irneb. I completely agree... Now how to get it fixed? Is there a MIME structure defined for TNEF? Is the TNEF structure well understood or published? The first step to action is understanding...
(In reply to irneb from comment #147) > BTW, should this bug not be applied to the official LookOut addon? > http://lookout.mozdev.org/ No, for the reasons you stated in response #145. In order for TB to win market share, the functionality needs to be seamlessly integrated in TB.
(In reply to Richard Seegmiller from comment #148) > Is the TNEF structure well understood or published? [MS-OXTNEF]: Transport Neutral Encapsulation Format (TNEF) Data Algorithm Online: http://msdn.microsoft.com/en-us/library/cc425498%28v=exchg.80%29.aspx PDF: http://download.microsoft.com/download/5/D/D/5DD33FDF-91F5-496D-9884-0A0B0EE698BB/%5BMS-OXTNEF%5D.pdf ZIP: http://download.microsoft.com/download/5/D/D/5DD33FDF-91F5-496D-9884-0A0B0EE698BB/Exchange_Protocols.zip When asked at MozCamp, one TB developer said about LookOut: "This is a very piece of hack, I don't even want to talk about it". Go figure TNEF attitude yourself... Great that Aron Rubin made LookOut, hope this will be updated for new TB versions. This saves a day in mixed TB, Outlook environment.
Look, everyone, it is just this simple: Do not use TB, since TB (community) doesn't want to allow this tool to work in the mainstream, they want it to remain "their" tech-geekie "gem" that everyone else in the world is too ignorant to use... I tried for months to get this to work in the environment I MUST work in, one where all associates send Outlook attachments. Period. After informing my superior I couldn't open his attachment, he basically told me that I could either stop playing with **** tools or get a contract elsewhere... if I continued to attempt to use TB, and burn business work cycles trying to do so, I would lose my job. Quite simple. Look at the history: it was opened NEARLY TWELVE(12) Y_E_A_R_S AGO! The "Community" is set in cement. I've enjoyed this thread, laughing at the wasted time arguing a moot point. a decade ago TB had a chance; now, due to these types of obstinance in the face of real-world influences on THE USERS, TB is a flyspeck and shrinking. G'day and Merry Christmas.
(In reply to Richard Seegmiller from comment #148) > Well stated irneb. I completely agree... Now how to get it fixed? > > Is there a MIME structure defined for TNEF? Is the TNEF structure well > understood or published? > > The first step to action is understanding... The problem is not to get a TNEF unpacker. There are many. The problem appears to be to get it integrated into Thunderbird/Seamonkey. Either built into the program or as a distributed plugin that comes with and is updated with every release (there are distributed plugins at least with Seamonkey, I don't know about Thunderbird) The issue appears to be an anti-Microsoft attitude. It is by Microsoft so it must be bad and we must stay away from it. However, the majority of businesses selected Microsoft and a small fraction of those users are sending TNEF mail. (thankfully it is no longer the default) I start to wonder why Mozilla releases for the Windows platform at all. After all, that is by Microsoft as well and it does not adhere to many open standards.
IMHO the problem is that Mozilla has no actual interest in Thunderbird, nor in business environments. It's evident from how they decided twice in the last years to "give away" the Thunderbird development (previously to the "Mozilla Messaging" team, then to the community) and how they decided to change the release policy to the foolish "rapid release" one (for both TB and Firefox), just to follow the fashion trend. When I read the Thunderbird development is of no interest for Mozilla because there is little space for innovation I feel very sad. There would be a lot of areas in which innovation would be very welcome (instead of just keeping to change the interface by moving tool bars up and down): better integration with Microsoft technologies is one of them (see this bug, or the support for Exchange as a mail and calendar server... there are working extensions out there, so it IS possible to add such kind of support), better integration with SPAM recognition technologies and automatic mail classification would be another (POPfile is amazing.. having that technology built in Thunderbird would be great), smarter ideas for e-mail archiving and backup would be another, and so on. It's a pity.
Just figured why LookOut didn't work with invites :0 ... I didn't have a calendar set as the default for that particular account. And a correction to a typo in my comment #145: > TB need to create TNEF attachments, ... It should read: TB need *NOT* create TNEF attachments, ... Lysdexia-R-I :) As for it being an addon ... I suppose it's possible to package a TB with the needed addons. E.g. a business edition with Exchange-like connection, LookOut, VCS, Quote&Reply formatting to comply with the non-standard-MS prefixing, etc. pre-installed. Much like Zimbra Desktop ... just more of the other addons too. That way you could circumvent the die-hards who simply WILL NOT even hear anything about those de-facto non-standards. Might open up some other "editions" too, e.g. with the new datastore backend it might even be possible to write an addon to use something like WebDav to enable collaborative sharing of files. Or even just allow editing of LDAP contacts directly inside TB! Call it something like an "enterprise" edition. But I fear that Mozzila's never going to hear something like that. Look how long people have been asking to have Lightning installed by default!
+1 to fix this.
I just installed "Lookout" extension/addon in Thunderbird 17.0.4 , and it seemed to make things work, at least until the next Thunderbird update breaks something again. This is NOT the way to run a product.
This bug is not a bug for your gripes about Thunderbird development or Lookout in general. Unless you are actively working on implementing adding support for TNEF to Thunderbird, please do not comment on this bug. All your comments will be doing is dissuading others from implementing this feature. As one of the owners of the relevant parts of the code base, I will assure that implementing support for TNEF is a desirable goal. However, there are significant technical hurdles that need to be overcome before support is possible (the approach that the Lookout extension uses is not suitable for integration into core Thunderbird code).
Wow, a maintainer confirms interest not less than 12 years after the feature request. Despite, it is still assigned to nobody.
(In reply to Joshua Cranmer [:jcranmer] from comment #158) > This bug is not a bug for your gripes about Thunderbird development or > Lookout in general. Unless you are actively working on implementing adding > support for TNEF to Thunderbird, please do not comment on this bug. All your > comments will be doing is dissuading others from implementing this feature. > > As one of the owners of the relevant parts of the code base, I will assure > that implementing support for TNEF is a desirable goal. However, there are > significant technical hurdles that need to be overcome before support is > possible (the approach that the Lookout extension uses is not suitable for > integration into core Thunderbird code). I thought bugs are where "testers" can provide feedback to "developers", and people can share ideas to solve a problem. Right now, there is an immense problem in the business world, and I was providing feedback that the functionality in Lookout solves this problem, at least for now. If nothing else, it confirms the current version of the extension works with the current version of the software, and accomplishes its goal. I hope this helps in the symbiotic relationship "developers" and "testers" have with one another.
(In reply to Joshua Cranmer [:jcranmer] from comment #158) > This bug is not a bug for your gripes about Thunderbird development or > Lookout in general. Unless you are actively working on implementing adding > support for TNEF to Thunderbird, please do not comment on this bug. All your > comments will be doing is dissuading others from implementing this feature. > > As one of the owners of the relevant parts of the code base, I will assure > that implementing support for TNEF is a desirable goal. However, there are > significant technical hurdles that need to be overcome before support is > possible (the approach that the Lookout extension uses is not suitable for > integration into core Thunderbird code). Joshua, Thank you for chiming in on this subject. I appreciate your efforts on this code base. What types of issues to you see (the technical hurdles): - the lack of documentation of the TNEF implementation? - competing priorities? - ? Thanks for your efforts on this. Part of me would like to see most of the above comments deleted since many of them do not add value to the technical issue at hand...on the other hand...I understand and appreciate the community's frustration...
(In reply to Ale Mand from comment #159) > Wow, a maintainer confirms interest not less than 12 years after the feature > request. > Despite, it is still assigned to nobody. I said it was desirable. I did not say that the current all-volunteer development staff has enough bandwidth to implement this feature right now. (In reply to Richard Seegmiller from comment #161) > What types of issues to you see (the technical hurdles): > - the lack of documentation of the TNEF implementation? > - competing priorities? > - ? The inflexibility posed by our current MIME decoding architecture. In particular, it is impossible under the current architecture to properly handle IMAP parts-on-demand or delete/detach attachment functionality. My JSMime work will have this flexibility built into it, but that is at least a year away from being ready.
(In reply to Joshua Cranmer [:jcranmer] from comment #162) > The inflexibility posed by our current MIME decoding architecture. In > particular, it is impossible under the current architecture to properly > handle IMAP parts-on-demand or delete/detach attachment functionality. My > JSMime work will have this flexibility built into it, but that is at least a > year away from being ready. I see... It even appears that MS had trouble with this for a time in Exchange Server 2007: http://support.microsoft.com/kb/944153 Has nobody else in the Internet community done any kind of work on this that could be leveraged? I saw some effort at http://www.alfresco.com/node/2296?utm_expid=11184972-4 (an open source cloud based document management company). In particular, there were some references to this as an issue: https://issues.alfresco.com/jira/browse/ALF-7522?page=com.atlassian.jira.plugin.system.issuetabpanels:changehistory-tabpanel I don't know much about this code base...other than it appears to be open source. It popped up in my search on the subject: imap tnef
I've created an Issue at Freedomsponsors for this: http://www.freedomsponsors.org/core/issue/472/inline-viewer-for-microsoft-proprietary-mail-formats-ms-tnef-etc-winmaildat Please consider throwing some money in. Whoever fixes this bug then gets a nice bounty.
Given the advancement (or absence of it) in TB development, and the failure to keep the pace of competitors, I've given up TB, converted my archives to Outlook 2013, and unsubscribing this bug.
Same for me. Migration to Outlook/Exchange will be next week. Hooray!
Given the shortage of resources and given that there is an add-on that does the job (https://addons.mozilla.org/en-GB/thunderbird/addon/lookout/), I don't think that Thunderbird will provide the functionality any time soon. Unless, of course, the author of the add-on (see comment #58) were to incorporate it into Thunderbird, which would be most welcome.
There is a fork of LookOut - LookOut+: https://addons.mozilla.org/en-GB/thunderbird/addon/lookout-1/ It has some bug fixes.
Still "testing" Thunderbird, now on 38.3.0. Confirming this bug still exists.
Sure. There is an add-on to deliver this functionality, see comment #169 and comment #170. Repeating from comment #169: I don't think that Thunderbird will provide the functionality any time soon. Unless, of course, the author of the add-on were to incorporate it into Thunderbird, which would be most welcome.
Here is the repository for the LookOut+ addon: https://github.com/AKMergl/LookOut I would assume any experienced developer should be able to integrate that into Thunderbird. I'm afraid I have no experience in this field myself though...
Just rephrasing comment #172: The understaffed, overworked and unpaid team of volunteers staffing Thunderbird positively has no time for this. If there is an add-on that does the job, great. Please contact the add-on author and ask him whether he is prepared to integrate his add-on into TB.
I understand that. I just added that link in case a random developer ends up here and feels like integrating it :)
(In reply to Jorg K (GMT+2) from comment #174) > Just rephrasing comment #172: > The understaffed, overworked and unpaid team of volunteers staffing > Thunderbird positively has no time for this. If there is an add-on that does > the job, great. Please contact the add-on author and ask him whether he is > prepared to integrate his add-on into TB. That would be great, and is the reason this basic functionality should be BUILT-IN. It needs to be a part of the basic program, and would be EASIER to manage if it were built-in.