Changes have been made in Git (FRAMEWORK_5_1):

commit 732af34b223439cc3df5e2aea01bea012ef231b4
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Fri Dec 20 19:48:34 2013 -0500

     Add support for parsing TNEF data when possible.

     Bug: 12882

     Conflicts:
             framework/ActiveSync/lib/Horde/ActiveSync/Imap/Message.php

  .../lib/Horde/ActiveSync/Imap/Message.php          |   78 +++++++++++++------
  1 files changed, 53 insertions(+), 25 deletions(-)

http://git.horde.org/horde-git/-/commit/732af34b223439cc3df5e2aea01bea012ef231b4

Initial support done. Now parses out the same data IMP is able to. 
Will send the raw .dat attachment if it contains no parse-able data.

Changes have been made in Git (master):

commit 217780c1175ff415a7c6981ab6952fa6441462e4
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Fri Dec 20 19:48:34 2013 -0500

     Add support for parsing TNEF data when possible.

     Bug: 12882

  .../lib/Horde/ActiveSync/Imap/Message.php          |  114 
+++++++++++++++-----
  1 files changed, 88 insertions(+), 26 deletions(-)

http://git.horde.org/horde-git/-/commit/217780c1175ff415a7c6981ab6952fa6441462e4

Agreed. That's why I'd still include the *.dat file if we couldn't 
parse it, or if it's a meeting response etc...

I'd prefer to not have to resort to third party applications to view 
an attachment on the client that the user is used to being able to see 
as-is using IMP.

Not sure if it's only the easy way out ;)

We could let Outlook 2013 also handle the meeting response in the 
winmail.dat file.
Parsing on the horde side might potentially break some Outlook 
specific extra information in there.

Yeah, that's the easy way out ;)

I'd like to parse out the attachment data from the TNEF file when 
possible and add them as "normal" attachments. Of course, I'll only do 
this for non-cryptographically signed messages. I'll have to 
investigate if we should strip the *.dat file when we are able to 
extract the attachments since this would needlessly increase bandwidth 
usage.

I remembered what the problem was originally for me - it was when 
dealing with meeting request responses - which are also sometimes 
bundled in the TNEF data. Our library didn't include support for 
extracting the data and quite honestly it looked like more work than 
it was worth to implement it on my own time :)

Here's a tested and working patch.

Outlook 2013 handles winmail.dat attachments without the blink of an eye.

Indeed. Good point :)

I would consider this an enhancement, not a bug.

Another point to pass on the original winmail.dat attachment:
Outlook 2013 accessing it via ActiveSync will probably be able to handle it.

That needs testing though (which I would volunteer to do once we have 
a "fix").

I remember having issues with this when developing the code and not 
being able to decode them. I *think* it was when forwarding emails 
though, and involved the entire message body. I hid the attachment 
since there was nothing we could do with it on the client side in the 
clients I tested.

I will take a look at this again, as it relates to attachments and 
"unhide" the attachment.

Hi,

when one receives a message from an Outlook user in rich-text-format 
(RTF), all attachments are stored in a "winmail.dat" TNEF container.

IMP automatically decodes this container and shows the contained files 
while hiding the original winmail.dat attachment.

ActiveSync hides the winmail.dat file completely and does not show any 
attachment.
Attached you'll find an example message with a winmail.dat file.

We should either a) use the same decoder as IMP and show the 
attachments or b) show the winmail.dat file to the user.

In my particular case the user complained he can't see the winmail.dat 
file. Back when using Exchange+ActiveSync, he was able to open 
winmail.dat files using an app on his iOS device.

Cheers,
Thomas