Solved

Office 365 TNEF / Winmail.dat issue when sending attachments to external users

Posted on 2013-02-07
7
2,955 Views
Last Modified: 2013-03-06
My company is using Exchange 2010 through Office 365 as our e-mail platform.  From time to time users will complain that when they send a message containing an attachment to an external user that user will receive the attachment as a winmail.dat file which they cannot open.

From my research, I understand that this is because Exchange is sending the message in TNEF format which other mail clients do not understand.

I know that I have the option of telling Exchange to never send messages to remote domains in TNEF format, however before I do that I want to better understand the implications of doing so.

From http://support.microsoft.com/default.aspx?scid=KB;en-us;q241538:

TNEF encoded attachments are used to send:
The formatted text version of the message (font information, colors, and such)
OLE objects (embedded pictures, embedded Office documents, and such)
Special Outlook features (custom forms, voting buttons, meeting requests, and such)
Regular file attachments that were added to the original message

Does this mean that if I globally disable TNEF for all remote domains that mail will be sent as plain text only (i.e. no text formatting, images in signatures, etc)?  Also, does it mean we would not be able to send Outlook calendar invites to 3rd parties?

I have seen differing opinions on this.

As far as mail formatting, some claim that disabling TNEF will cause messages to be sent as plain text while others claim that they will be sent as HTML.

I am looking for some references that better explain the ramifications of disabling TNEF.
0
Comment
Question by:FWeston
  • 4
  • 3
7 Comments
 
LVL 18

Accepted Solution

by:
Richard Daneke earned 500 total points
ID: 38867080
One can use PowerShell to turn the conversion off for specific domains or for specific email addresses.  Messages sent are not converted, so one would expect anecdotal experiences.

However, text messages remain text messages, rtf messages remain rtf messages, and html messages remain html messages.  Format of the message is controlled in a format ribbon group on the message itself.

TNEF encoded attachments are used to send:

The formatted text version of the message (font information, colors, and such)
This is okay.  No problem, here, the recipient gets the messages in sent format.  Does not apply to messages in text format

OLE objects (embedded pictures, embedded Office documents, and such)
Potential problem when the recipient's email system has problems opening embedded objects

Special Outlook features (custom forms, voting buttons, meeting requests, and such)
Potential problem when the recipient's email system has problems opening special Outlook forms in something other than Outlook


Regular file attachments that were added to the original message
This is okay.  No problem, here, the recipient gets the messages with attachment.  Attachment in original file type.
0
 
LVL 3

Author Comment

by:FWeston
ID: 38868176
If I wanted to test this by adding a domain to the list of remote domains to never send TNEF encoded messages to, how can I check on the receiving side if the message came in as TNEF or not?
0
 
LVL 18

Expert Comment

by:Richard Daneke
ID: 38870613
Do you have someone with an earthlink or mindspring account?  

If you have a domain that receives the .dat,  one could send a test message.  Confirm the conversion to TNEF.    Run the PowerShell script, and send the same test.

I mention mindspring since this past week, I had the situation come up and resolved with a mindspring account.
0
Don't lose your head updating email signatures!

Do your end users still have the wrong email signature? Do email signature updates bore you or fill you with a sense of dread? You can make this a whole lot easier on yourself by trusting an Exclaimer email signature management solution. Over 50 million users do...so should you!

 
LVL 3

Author Comment

by:FWeston
ID: 38877184
No I do not know anyone with one of those accounts.

Rather than verify this solves the problem for those folks that are receiving the message as winmail.dat, what I am more interested in verifying is that making this change does not impact everyone else.

So for instance, I can send messages to myself at Gmail and they come through fine right now.  After I make the change, I want to send a test message to myself and verify it still comes through fine, but I would also like to have a way to verify that the change has taken effect and the message was not received as TNEF.
0
 
LVL 18

Expert Comment

by:Richard Daneke
ID: 38877365
If your Gmail is working, you do not need to change anything relative to gmail.   The powershell script is specific to domains, not ALL domains.  

So, one would specifiy the domain that is having a problem.  Outlook then, no longer converts the messages.
0
 
LVL 3

Author Comment

by:FWeston
ID: 38877384
Right, but going back to my original question about setting the default setting for all domains to never convert to TNEF.  From what I gather, that is the only option I have which will make this problem go away forever.

Before I do that, I want to verify that doing this is not going to break things.

So, I'm using Gmail as an example of something that works perfectly right now, and that I also want to work after I switch the default setting to "never convert to TNEF".

So the way I propose to test that is to set the setting for gmail.com to "never convert to TNEF", then send an e-mail to gmail.com and verify it comes through properly.  That's fine, but what I'm asking is after I do that, how can I verify that the setting took effect and the message I receive at gmail.com was not received in TNEF format?
0
 
LVL 18

Expert Comment

by:Richard Daneke
ID: 38877546
Message encoding details are stored in message headers.  One could look there.

When you do decide to make changes, let me refer you to this specifc page on Office365 and TNEF.  You could set your test to an email address, a domain, or system-wide.

http://help.outlook.com/en-us/140/gg263346.aspx

This explains several options in the settings within Office365 and online Exchange.  

If your outside mail client is handling a TNEF encoded message, I think it would be safe to assume it can handle a non-TNEF encoded message.

As a matter of policy, one could:
force default message format to plain text (not encoding any messages in text format),
set TNEF encoding to false - (not encoding any messages),
set TNEF encoding to false for specific individuals
set TNEF encoding to false for specific domains
0

Featured Post

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Find out what Office 365 Transport Rules are, how they work and their limitations managing Office 365 signatures.
This is my first article on Expert Exchange on the Manual Method of Exporting Office 365 Mailboxes to PST format by using the eDiscovery mechanism of Office. Hope you will enjoy the article.
To show how to create a transport rule in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Mail Flow >> Rules tab.:  To cr…
The video tutorial explains the basics of the Exchange server Database Availability groups. The components of this video include: 1. Automatic Failover 2. Failover Clustering 3. Active Manager

932 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

19 Experts available now in Live!

Get 1:1 Help Now