Solved

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

Posted on 2013-02-07
7
2,926 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

Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

Join & Write a Comment

Exchange server is not supported in any cloud-hosted platform (other than Azure with Azure Premium Storage).
Follow this checklist to learn more about the 15 things you should never include in an email signature from personal quotes, animated gifs and out-of-date marketing content.
This Experts Exchange video Micro Tutorial shows how to tell Microsoft Office that a word is NOT spelled correctly. Microsoft Office has a built-in, main dictionary that is shared by Office apps, including Excel, Outlook, PowerPoint, and Word. When …
how to add IIS SMTP to handle application/Scanner relays into office 365.

747 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

12 Experts available now in Live!

Get 1:1 Help Now