Friday, March 30, 2012

winmail.dat can DIAF

pretty much how those couple weeks felt...
Situation:

A user is reporting that when they receive emails from someone, all they see is "winmail.dat".

They've had files resent, but they still shows up like that.

There's a good chance that they only show up as "winmail.dat" when receiving emails from this one user, or maybe a couple.

The problem could even be intermittent, making it extremely difficult to track down.





I recently had the opportunity to run in to this problem. It was only happening to emails sent by one user, except he was upper management, which meant there were many people receiving this strange "winmail.dat" file, and unable to access the attachments he was trying to send them.

I found a few fixes, but after trying them, the problem continued intermittently. The email admin said everything looked fine on the server and passed the issue back to me to resolve. Googling showed the issue should have been resolved by my first attempts, which obviously wasn't the case.


Description:

Microsoft Outlook has a few different ways that email can be composed. Normally, either HTML or Rich Text Format. (RTF)

When an email is written with RTF, there's extra encoding that goes in to it. In this case, attachments are "zipped" up as a file named "winmail.dat".

MOST email servers and clients out there can understand email written in RTF, but some don't. Depending on the server / client architecture, the server and/or the client needs to be able to translate winmail.dat in to the attachments it represents. Being a Microsoft format, your Outlook versions will read them fine, as will larger email solutions like GMail, etc. Most mobile apps don't know what to do with winmail.dat either.

You can look to the following diagram:



Essentially, when a server receives an eMail with an attachment called "winmail.dat" there are a few things that could happen:

  1. The server doesn't understand what "winmail.dat" is.
    This causes "winmail.dat" to be forwarded on to to user when they download the email. 
    1. If the user's email client doesn't know what "winmail.dat" is, they end up with this unknown file attached and must rely on 3rd party programs to unpack the attachments from it.
    2. If the email client is Microsoft / RTF compatible, it'll "unpack" the winmail.dat file in the background and the user just sees the attachments as normal.
    3. Since the server doesn't understand what winmail.dat is, any access through a Web Mail client will also display this "strange" attachment.
  2. The server understands what winmail.dat is.
    ...but still forwards "winmail.dat" to the end user.
    1. The only difference in this scenario, is that since the server understands winmail.dat, access through Web Mail will also provide the user with access to the attachments.
  3. The server understands AND TRANSLATES winmail.dat.
    Pro-actively compensating for clients that don't understand what the winmail.dat attachment is.
    1. This server is the most useful. It'll strip "winmail.dat" and attach the attachments to the email. This allows anything downloading email from it to read all the attachments properly.

However, most people reading this probably don't have access to, or the ability / funding to change the eMail server to make it more Microsoft / Rich Text compliant.

Normal Solutions:

The most common way to fix this is to disable editing email in RTF and instead choose HTML.

1. Global Outlook Format

Outlook 2003:
Tools - Options - Mail Format Tab

  1. Message Format drop-down, choose "HTML"
  2. Internet Format, choose "Convert to HTML format"

pic from SlipStick
Outlook 2010:
File - Options - Mail

  1. Compose messages in "HTML".
  2. Message format, "Convert to HTML format"



This is where most websites covering the issue stopped helping... and in most cases, this is what solves the problem...

2. Override Outlook Format with Contact Properties

Here's where it gets tricky... EVERY contact in an address book has the potential to override the above settings. If Rich Text is set here, then any emails sent to these contacts will be in RTF no matter what you setup as global settings above.

And it gets uglier... got any users with a (near) empty contact list, and just use the auto-fill data Outlook remembers (in the .nk2 file) instead? Any of those could have RTF remembered with it.


Double-click the email in a contact's properties, then:

In 2003, just choose properties.

In 2010, click the unassuming buttons shown left.


To fix this, you have to check that contacts are setup to "Let Outlook decide the best sending format" and convince users to create contacts from all those auto-fill addresses so you can ensure the email properties are setup right.


Forced Solution:

If all else fails, there are a few fixes from Microsoft and a couple registry hacks.

The reg-hacks, I've personally tried, and even forces HTML for a contact that's setup to "Send using Outlook Rich Text Format". Either create  a file with the extension .reg, or create the following DWORDs in your registry. [RUN: regedit.exe - though if I have to tell you how to get to the registry, you probably shouldn't mess around in there]

Microsoft Outlook 2007

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Preferences]
"DisableTNEF"=dword:00000001




Microsoft Outlook 2010

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Preferences]
"DisableTNEF"=dword:00000001


You can also use this Microsoft "FixIt" article to install the reg hacks for you:
http://support.microsoft.com/kb/958012

Now, apparently you might also have to install this Outlook 2007 hotfix package FIRST.
http://support.microsoft.com/kb/957692

As always, reboot after installing this sort of stuff.

No comments:

Post a Comment