Open Bug 77811 Opened 23 years ago Updated 1 year ago

Inline viewer for Microsoft proprietary mail formats (ms-tnef, etc.) ["winmail.dat"]

Categories

(MailNews Core :: MIME, enhancement)

Product:
MailNews Core
Component:
MIME
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: baffoni, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug,
URL
)

Details

(Whiteboard: [workaround: comment 170,173][read comment 158 before replying])

Attachments

(2 files)

Message with a tnef attachment
142.05 KB, text/plain
Details
Microsoft's description of the TNEF format
82.93 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details 
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.
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Inline viewer for Microsoft proprietary mail formats (ms-tnef, etc.) → [RFE] Inline viewer for Microsoft proprietary mail formats (ms-tnef, etc.)
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.
Status: NEW → ASSIGNED
Whiteboard: outlook express
Target Milestone: --- → Future
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
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
Attachment #91136 - Attachment mime type: message/rfc822 → text/plain
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 ...
Summary: [RFE] Inline viewer for Microsoft proprietary mail formats (ms-tnef, etc.) → Inline viewer for Microsoft proprietary mail formats (ms-tnef, etc.)
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.
Whiteboard: outlook express → parity-oe
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.
OS: Windows NT → All
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. :(
Product: MailNews → Core
*** 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
Summary: Inline viewer for Microsoft proprietary mail formats (ms-tnef, etc.) → Inline viewer for Microsoft proprietary mail formats (ms-tnef, etc.) ["winmail.dat"]
*** 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.
Assignee: ducarroz → sspitzer
Status: ASSIGNED → NEW
QA Contact: esther
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.
Flags: blocking-aviary2.0?
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.
http://tud.at/php/tnef/index.php
is a front end for
http://sourceforge.net/projects/tnef/

additional link:
http://www.dominodude.com/personal/tmk/blog.nsf/d6plinks/TKEN-65ZJR3

may be it is able to rewrite this liberary in javascript or include in the source tree.
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.
Flags: blocking-thunderbird2?
Flags: blocking-thunderbird2? → blocking-thunderbird2-
Any particular reason this isn't wanted in the next release?
Assignee: sspitzer → nobody
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. )-:
Blocks: 360980
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 aronrubin@gmail.com . 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.
QA Contact: mime
Target Milestone: Future → ---
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?
Flags: blocking-thunderbird3?
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.
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
@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 2.0.0.14 (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 2.0.0.14 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! :)
Product: Core → MailNews Core
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...
Whiteboard: parity-oe → parity-oe [penelope_wants]
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!
Whiteboard: parity-oe [penelope_wants] → [penelope_wants]
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...
Is there an error in bugzilla? Is comment history is not showing up for people? 

Recap
I made a addon named LookOut that grabs sub-attachments and other data from TNEF (commonly named winmail.dat) attachments INLINE. It works well for attachments and ok for a subset of calendaring and contact data. The calendaring and contact data appear as iCalendar and vCard attachments.
The manner in which the LookOut front end operates is a unfortunate result of Mozilla Mail+News architecture (Thunderbird). The architecture does not allow javascript access to create a inline mime level content type handler that could produce new mime parts. Instead LookOut is forced to intercept and hijack UI interactions and alter the attachments list. It is that same Mozilla Mail+News architecture that in my opinion creates a high barrier to creating a module which actually speaks Exchanges wire protocol.

Microsoft
There are various problems with Exchange and Outlook but first some background. TNEF is a quasi competitor to MIME. The idea is break a message into parts an allow these parts to have metadata associated with them. There is nothing I see in TNEF that could not be directly expressed in MIME.

Configuration of the Exchange server is not as simple of a matter as one might think. If TNEF is disabled the metadata will simply not be transmitted. You can ask newer versions of Exchange to send iCalendar and vCard instead of MAPI properties in TNEF. It is unclear to me at this time whether those are treated as second class citizens.

Aron
(In reply to comment #114)
> The architecture does not allow
> javascript access to create a inline mime level content type handler that could
> produce new mime parts. Instead LookOut is forced to intercept and hijack UI
> interactions and alter the attachments list.
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?
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 :)
Depends on: 446321
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:1.9.2.16pre) 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:1.9.2.19pre) 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.
(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).
Whiteboard: [penelope_wants] → [penelope_wants][read comment 158 before replying]
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.
Flags: blocking-thunderbird3-
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.
I'd like to "vote" for this one but haven't found the feature.
Whiteboard: [penelope_wants][read comment 158 before replying] → [workaround: comment 170,173][read comment 158 before replying]
read comment, not a solution and I believe the original bug intention was for TB to include a way of managing winmail.dat files, not to implement an Add-On. There were other add-ons and they died, nothing ensures us the next update of TB will stop the add-on from working.
There is one, very special thing about this that must be noted. We all use TB (there are four installs all in Windows 7 x64, updated, etc) One sender may send an e-mail from Outlook, and two receivers here, one can see the attachments and the other can't (sees a winmail.dat file instead) that does not always happen but it does less often.
See Also: → 325606

What's the plan for this after the death of old TB addons? This is still a commonly used thing in corporate/government e-mail.

(In reply to khagaroth from comment #184)

What's the plan for this after the death of old TB addons? This is still a commonly used thing in corporate/government e-mail.

Office 365.

(In reply to khagaroth from comment #184)

What's the plan for this after the death of old TB addons? This is still a commonly used thing in corporate/government e-mail.

Ideally, the sender would be skilled enough not to send a proprietary formatted email out on the internet with a silly expectation that everyone uses Microsoft Outlook. But you are right, it would be silly to expect organisations with professional IT departments to actually know what they were doing. Better the open-source community adapt to professional sending malformed mail, and that is what is happening.

So for now https://addons.thunderbird.net/en-US/thunderbird/addon/lookout-fix-version
Then they are looking to the future https://github.com/TB-throwback/LookOut-fix-version/issues/53

But they may not have to as according to the Thunderbird road map, this bug for 78 perhaps. http://lists.thunderbird.net/pipermail/maildev_lists.thunderbird.net/2019-November/002024.html

Regarding the comment "Ideally, the sender would be skilled enough not to send a proprietary formatted email", I just have to ask: what world do you live in? This bug was opened 19 years ago. REPEAT 19 years ago! If a format has been active and alive for 19 years it has long since passed the threshold to being a defacto standard even if it's not an official one. To live in an ivory tower and ignore that fact means you are alienating a large group of potential users of your product.

Do you really believe the average e-mail user has any idea what TNEF is or that it is a proprietary format? All they know is they get e-mails from some of their friends and cannot see all of the contents and have no idea why.

I'm a developer and I tried to use TB about 10 years ago and this was a show stopper for me because I just want to read my e-mail and have it work for all formats. I tried lookout at the time and it did not work or did not work right, and there were posts stating (I think) that it was no longer being maintained.

(In reply to PK from comment #187)

I'm a developer

Are you offering to assist in the development of this feature?

No. The only reason I mentioned being a developer is that developers are usually more tolerant of software that might not just work out of the box. They are willing to fiddle with it if necessary. The average consumer is not, or has no idea how to.

If the comment I was responding to had been "we don't have any developers interested in working on this" or "the TNEF format is a closely guarded secret and reverse engineering TNEF formatted e-mails will only give partial solutions" or other comments of that nature I would have thought that was a reasonable response and not said anything.

The reason I responded was because the original comment seemed arrogant and attitudes like that will prevent more mainstream adoption (assuming that is one of the goals of the thunderbird project).

Like I said, I had tried to adopt TB about 10 years ago (plus or minus) and have since moved on. Ten years ago my answer might have been different, but not now. I've stayed subscribed to this thread since then more for idle curiosity then anything else.

(In reply to PK from comment #189)

No. The only reason I mentioned being a developer is that developers are usually more tolerant of software that might not just work out of the box. They are willing to fiddle with it if necessary. The average consumer is not, or has no idea how to.

If the comment I was responding to had been "we don't have any developers interested in working on this" or "the TNEF format is a closely guarded secret and reverse engineering TNEF formatted e-mails will only give partial solutions" or other comments of that nature I would have thought that was a reasonable response and not said anything.

The reason I responded was because the original comment seemed arrogant and attitudes like that will prevent more mainstream adoption (assuming that is one of the goals of the thunderbird project).

Like I said, I had tried to adopt TB about 10 years ago (plus or minus) and have since moved on. Ten years ago my answer might have been different, but not now. I've stayed subscribed to this thread since then more for idle curiosity then anything else.

Maybe.... maybe with the cloud e-mail (office 365) the old Exchange/Outlook users may be migrated to a new platform and we stop seeing this. Your comment is right, I can't assume anything but that the developers are linux people that only consumes and relates to other linux people and they do not work with/collaborate with private companies that employ Exhange/Outlook. I did all the time and it was a pain to unpack winmail.dat files, that fortunately, 19 years later are still coming but less and less or LookOut Fix is doing it's job.

Hello, I'm currently maintaining lookout (fix version). Development is slow as I don't have as much time to work on the breaking changes in TB.

Unfortunately I've seen tnef files from office 365 accounts. Also there has been an uptick in tnef emails (at least in my industry) due to several large organisations upgrading from old windows servers. With many people either using google apps or outlook, many systems administratior simply don't know they have not configured their servers correctly.

You know if you have recieved a modern tnef email as it has the body in the tnef as .html rather than .rtf

Several administrators have stated it's not their problem to fix, hence why I originally started maintaining the addon.

Thunderbird would benefit greatly if the client could decode the format natively, as lets face it the lookout addon is janky and not to mention it has been 19 years. It is time to accept tnef format emails are here to stay

(In reply to dugite-code from comment #191)

Hello, I'm currently maintaining lookout (fix version). Development is slow as I don't have as much time to work on the breaking changes in TB.

Unfortunately I've seen tnef files from office 365 accounts. Also there has been an uptick in tnef emails (at least in my industry) due to several large organisations upgrading from old windows servers. With many people either using google apps or outlook, many systems administratior simply don't know they have not configured their servers correctly.

You know if you have recieved a modern tnef email as it has the body in the tnef as .html rather than .rtf

Several administrators have stated it's not their problem to fix, hence why I originally started maintaining the addon.

Thunderbird would benefit greatly if the client could decode the format natively, as lets face it the lookout addon is janky and not to mention it has been 19 years. It is time to accept tnef format emails are here to stay

Can you start transitioning the addon into the Thunderbird code itself? Maybe break it into pieces, and start stripping the pieces out of the addon and into Thunderbird? Is there anyone on here who can and will help him to do this? Thanks so much.

The tnef parser is already split off from the rest of the addon, however I believe the java based jtenf would be a better reference as it's had more development, lookout is just getting maintenance patches

Can those just go right into Thunderbird instead?

When I first commented on this bug in 2006, my manager at the time was an extreme Microsoft zealot who thought everyone should use Windows and Outlook, and that any platform that couldn't handle Outlook's "standard" format was brain-damaged by definition, and that the only solution worth considering was to abandon broken toys like Thunderbird (and Linux!) and use Outlook.

That was years ago, thankfully, and that particular manager moved on, and I eventually stopped seeing TNEF-formatted e-mail entirely.

And I retired a couple of months ago, so I really don't need to worry about the issue anymore. :-)

But if people are still seeing TNEF in their incoming e-mail, and if it's not feasible for them to get the senders to stop doing this, then I hope the Lookout extension can continue to be available.

TNEF unfortunately is still very prevalent in small to large business who use exchange server. It seems as if this is one of those things that will not die in the past.

It looks like someone from the Thunderbird team would have to integrate the function from the add-on to Thunderbird itself, as the maintainer is not working on the webextension currently.

Because TNEF only shows an attachment in Thunderbird, I cannot fully recommend it to my peers, or install it for people I know because this is a huge incompatibility issue that breaks emails from certain senders. In all my years of using Thunderbird, this is the only issue I've run in to.

It would be beneficial to all users. This is indeed much needed and increase compatibility/interoperability of Thunderbird. Without it currently, it makes TB looks like having a "bug" and not working properly!

Especially considering a solution already exists, why not to convert the existing plugin into an experiment (shall be trivial for the dev team) and pre-load it in TB like lightning before? That would be the quickest way to do before slowly integrating it to Core later on.

This bug has quite a large vote number so obviously something people need/want!

(In reply to Rich Wales from comment #195)

When I first commented on this bug in 2006,
...
But if people are still seeing TNEF in their incoming e-mail, and if it's not feasible for them to get the senders to stop doing this, then I hope the Lookout extension can continue to be available.

The "Lookout" extension is no longer supported.

This has been working for a long LONG time with the Lookout extension. That is no longer a solution (no longer compatible), so this bug needs to get fixed ASAP.

Thank you.

(In reply to Worcester12345 from comment #199)

Just had a user complaint about this. Saying the sender claims we are the only ones having this problem. It turns out we are also one of the only recipients using Thunderbird. This is sealing the fate for Thunderbird to go away sooner rather than later. I'm sure this is the same for thousands or more users of this program. As of right now, there is no workaround for this user, other than Outlook (or Office365). Please help, time is critical.

If you go to the lookout Github page there is a beta release available: https://github.com/TB-throwback/LookOut-fix-version/releases/tag/v3.0.00b1 The reason I haven't released it is I'm missing the version checking for backwards compatibility and I am missing event invite sample for testing

(In reply to dugite-code from comment #200)

(In reply to Worcester12345 from comment #199)

Just had a user complaint about this. Saying the sender claims we are the only ones having this problem. It turns out we are also one of the only recipients using Thunderbird. This is sealing the fate for Thunderbird to go away sooner rather than later. I'm sure this is the same for thousands or more users of this program. As of right now, there is no workaround for this user, other than Outlook (or Office365). Please help, time is critical.

If you go to the lookout Github page there is a beta release available: https://github.com/TB-throwback/LookOut-fix-version/releases/tag/v3.0.00b1 The reason I haven't released it is I'm missing the version checking for backwards compatibility and I am missing event invite sample for testing

This is to go with the 78.3.2 64-bit version. Is it compatible with that?

Any chance you can help write a patch to put this code into Thunderbird itself?

Thanks.

(In reply to Worcester12345 from comment #201)

Any chance you can help write a patch to put this code into Thunderbird itself?
Thanks.

Even if it is just a couple little patches, to make it closer. Break them into separate bugs to accomplish each task. This will get us ALL closer to having a functioning email client.

Thanks so much.

Yes that is for TB 78.x.

Unfortunately I am only the current maintainer and have only been working on keeping the existing code running with the various Thunderbird changes, I'm not actually hugely familiar with the actual de-coding side of the addon. Also there has been more work done in other libraries such as jtenf that need to be considered by anyone doing work in this space. Someone more experienced with the Thunderbird code would be better suited to tackle this issue.

As I said, even small bugs to chip away at the edges of this would be helpful. That way, it is less for an addon to do, and less to keep up in the long run.

Hello,
I've been struggling with this problem too since the upgrade to TB 78.x.

After some googling I've found a nice solution to this problem for my employer (I'm a Linux network admin) > server side tnef (winmail.dat) extraction/decoding with mimedefang + libconvert-tnef-perl + libfile-libmagic-perl.

As my post is OT, I will not go into details here... but can share my solution if there is interest.

@dugite-code
Many thanks for your efforts. Your addon served me well since I send our Exchange 2013 server more than 2 years ago into hell.

@ TB devs
TB is missing a lot of important features, but it's still the BEST solution on earth if you migrate from Exchange server.
I do appreciate your changes/improvements even when they break things at the beginning.
TB is getting better and better with every major release... Many thanks to you.

Regards
Darius

(In reply to d.spitznagel from comment #205)

As my post is OT, I will not go into details here... but can share my solution if there is interest.

Darius, I think it would be great if you could share the solution.

(In reply to Saulius Gurklys from comment #206)

(In reply to d.spitznagel from comment #205)

As my post is OT, I will not go into details here... but can share my solution if there is interest.

Darius, I think it would be great if you could share the solution.

You can find my text-based howto here...
https://www.goodbytez.de/howtos/mimedefang

(In reply to d.spitznagel from comment #207)

..
You can find my text-based howto here...
https://www.goodbytez.de/howtos/mimedefang

Thank you!

Today I discovered, that a "special" email with a winmail.dat attachment crashed my defang (convert tnef to mine only) implementation!
Disabling defang on server side let the mail pass through.
With our webmail interface I was able to read the mail. It has its own inline tnef viewer and showed me 4 attachments with 0 bytes in size.

Please implement tnef inline viewer capabilities ASAP!
I realy don't understand why webclients can do that but TB not:(

Please fix that!

Kind regards
Darius

(In reply to d.spitznagel from comment #209)

With extensive help from John Bieling the Add-on Lookout (Fix Version) has been updated to work for TB78.

The Thunderbird devs are well aware that this issue needs investigating as can be seen on this roadmap for TB78+ in 2021

(In reply to Worcester12345 from comment #211)

(In reply to dugite-code from comment #210)

(In reply to d.spitznagel from comment #209)
...
The Thunderbird devs are well aware that this issue needs investigating as can be seen on this roadmap for TB78+ in 2021

I hope someone can back this up by giving this a top priority. Right now is has NO priority!

Thanks.

Please read https://bugzilla.mozilla.org/page.cgi?id=etiquette.html Advocacy is not needed in this bug report - so comments are now limited.

Restrict Comments: true
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: