Community Discussions and Support
OT: winmail.dat problem - a blast from the past

[quote user="Thomas R. Stephenson"]

Did you note in the kb article that it says if you set some of the outlook only options it will drop back to TNEF no matter what the setting are in the user setup.

 [/quote]

Yes. These are just standard html formatted mails, some with attachments, no voting or meeting requests or any other OL only "features".

Have even checked through every contact, as mail format can be set on a per contact basis as well.

The frustrating thing is that there is no discernable pattern.[:@]

[quote user="Thomas R. Stephenson"]<p>Did you note in the kb article that it says if you set some of the outlook only options it will drop back to TNEF no matter what the setting are in the user setup.</p><p> [/quote]</p><p>Yes. These are just standard html formatted mails, some with attachments, no voting or meeting requests or any other OL only "features".</p><p>Have even checked through every contact, as mail format can be set on a per contact basis as well.</p><p>The frustrating thing is that there is no discernable pattern.[:@] </p>

Hi All,

I'm reasonably certain that this problem has nothing to do with Mercury but hopefully nevertheles someone can shed light on it.

One of my customers has just started emailing their invoices. Its working fine other than a few customers who don't see the attachments.

They email back to say where's the attachments, the accounts lady goes to her Outlook 2003 Sent Items and resends the email and now the customer can see the attachments...

When the customer looks at the headers, the "bad" email contains this

------=_NextPart_000_0093_01CA5E06.E7FA0F60

Content-Type: application/ms-tnef;

   name="winmail.dat"

Content-Transfer-Encoding: base64

Content-Disposition: attachment;

   filename="winmail.dat"

 

And the "good" email contains this:

 

------=_NextPart_000_015D_01CA5E1A.D97DEE70

Content-Type: application/pdf;

   name="49844.pdf"

Content-Transfer-Encoding: base64

Content-Disposition: attachment;

   filename="49844.pdf"

 

The email is generated by an accounts system that transfers it to Outlook's Outbox using MAPI from where it is sent (via Mercury).

 

What I don't understand is why the second email (produced by finding in Sent Items, then Resend Email) is different. And I think understanding that is the key to fixing it.

 

Any ideas?

Cheers, Gordon

<P>Hi All,</P> <P>I'm reasonably certain that this problem has nothing to do with Mercury but hopefully nevertheles someone can shed light on it.</P> <P>One of my customers has just started emailing their invoices. Its working fine other than a few customers who don't see the attachments.</P> <P>They email back to say where's the attachments, the accounts lady goes to her Outlook 2003 Sent Items and resends the email and now the customer can see the attachments...</P> <P>When the customer looks at the headers, the "bad" email contains this</P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas>------=_NextPart_000_0093_01CA5E06.E7FA0F60</FONT></P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas>Content-Type: application/ms-tnef;</FONT></P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas><SPAN style="mso-spacerun: yes">   </SPAN>name="winmail.dat"</FONT></P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas>Content-Transfer-Encoding: base64</FONT></P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas>Content-Disposition: attachment;</FONT></P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas><SPAN style="mso-spacerun: yes"> </SPAN><SPAN style="mso-tab-count: 1">  </SPAN>filename="winmail.dat"</FONT></P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas></FONT> </P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas>And the "good" email contains this:</FONT></P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas></FONT> </P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas>------=_NextPart_000_015D_01CA5E1A.D97DEE70</FONT></P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas>Content-Type: application/pdf;</FONT></P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas> <SPAN style="mso-tab-count: 1">  </SPAN>name="49844.pdf"</FONT></P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas>Content-Transfer-Encoding: base64</FONT></P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas>Content-Disposition: attachment;</FONT></P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas><SPAN style="mso-tab-count: 1">   </SPAN>filename="49844.pdf"</FONT></P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas></FONT> </P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas>The email is generated by an accounts system that transfers it to Outlook's Outbox using MAPI from where it is sent (via Mercury).</FONT></P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas></FONT> </P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas>What I don't understand is why the second email (produced by finding in Sent Items, then Resend Email) is different. And I think understanding that is the key to fixing it.</FONT></P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas></FONT> </P> <P style="MARGIN: 0cm 0cm 0pt" class=MsoPlainText><FONT size=3 face=Consolas>Any ideas?</FONT></P> <P mce_keep="true">Cheers, Gordon</P>

When the customer looks at the headers, the "bad" email contains this

------=_NextPart_000_0093_01CA5E06.E7FA0F60

Content-Type: application/ms-tnef;

   name="winmail.dat"

Content-Transfer-Encoding: base64

Content-Disposition: attachment;

   filename="winmail.dat"

The Outlook user should verify that they never send using Outlook Rich Text format.  In Outlook 2002 this is set in Tools | Options | Mail format | Internet format.  They should select "Convert to HTML format" and check the top box to ensure the graphics go with the message.  This should produce a HTML message that all can read.  I ass-u-me that other versions of outlook do this in a similar manner.

 

<blockquote><p>When the customer looks at the headers, the "bad" email contains this</p><p style="margin: 0cm 0cm 0pt;" class="MsoPlainText"><font face="Consolas" size="3">------=_NextPart_000_0093_01CA5E06.E7FA0F60</font></p><p style="margin: 0cm 0cm 0pt;" class="MsoPlainText"><font face="Consolas" size="3">Content-Type: application/ms-tnef;</font></p><p style="margin: 0cm 0cm 0pt;" class="MsoPlainText"><font face="Consolas" size="3"><span style="">   </span>name="winmail.dat"</font></p><p style="margin: 0cm 0cm 0pt;" class="MsoPlainText"><font face="Consolas" size="3">Content-Transfer-Encoding: base64</font></p><p style="margin: 0cm 0cm 0pt;" class="MsoPlainText"><font face="Consolas" size="3">Content-Disposition: attachment;</font></p><p style="margin: 0cm 0cm 0pt;" class="MsoPlainText"><font face="Consolas" size="3"><span style=""> </span><span style="">  </span>filename="winmail.dat"</font></p></blockquote><p style="margin: 0cm 0cm 0pt;" class="MsoPlainText">The Outlook user should verify that they never send using Outlook Rich Text format.  In Outlook 2002 this is set in Tools | Options | Mail format | Internet format.  They should select "Convert to HTML format" and check the top box to ensure the graphics go with the message.  This should produce a HTML message that all can read.  I ass-u-me that other versions of outlook do this in a similar manner. </p><p style="margin: 0cm 0cm 0pt;" class="MsoPlainText"> </p>

Hi Thomas,

Well thats exactly what I thought this problem was about. But in this case I know Outlook is set to send in html and the same Outlook sent both messages. The difference being that the first one came from the accounts system to Outlook then was sent and the second one came from Sent Items in Outlook and was resent. I would have thought they would be pretty much identical but it seems not.

I've only at the moment seem the headers from the message as received by the customer. I'll compare the pair from the sent messages archive this evening.

Cheers, Gordon

<P>Hi Thomas,</P> <P>Well thats exactly what I thought this problem was about. But in this case I know Outlook is set to send in html and the same Outlook sent both messages. The difference being that the first one came from the accounts system to Outlook then was sent and the second one came from Sent Items in Outlook and was resent. I would have thought they would be pretty much identical but it seems not.</P> <P>I've only at the moment seem the headers from the message as received by the customer. I'll compare the pair from the sent messages archive this evening.</P> <P>Cheers, Gordon</P>

Outlook 2007 seems to do this randomly for one of my users. Everything is set for HTML only (also tried plain text) but every so often these #$%^$ TNEF messages get generated for no apparent reason.

Been at this on and off for 6 months, IMHO Outlook is broken and should not be used for email (that needs to be read by standards compliant clients anyway).

<p>Outlook 2007 seems to do this randomly for one of my users. Everything is set for HTML only (also tried plain text) but every so often these #$%^$ TNEF messages get generated for no apparent reason.</p><p>Been at this on and off for 6 months, IMHO Outlook is broken and should not be used for email (that needs to be read by standards compliant clients anyway). </p>

[quote user="dilberts_left_nut"]IMHO Outlook is broken and should not be used for email (that needs to be read by standards compliant clients anyway).
[/quote]

IMHO also - I think it's Outlook that's responsible for a recent spate of emails sent to a group of recipients but with no To, cc or bcc headers - which means, at best, that the receiving system can't put it in the right mailbox, and at worst that it gets spam-binned.

Sorry - O/T from even the O/T thread !

<p>[quote user="dilberts_left_nut"]IMHO Outlook is broken and should not be used for email (that needs to be read by standards compliant clients anyway). [/quote]</p><p>IMHO also - I think it's Outlook that's responsible for a recent spate of emails sent to a group of recipients but with no To, cc or bcc headers - which means, at best, that the receiving system can't put it in the right mailbox, and at worst that it gets spam-binned.</p><p>Sorry - O/T from even the O/T thread ! </p>


http://support.microsoft.com/kb/290809/

Good grief, they almost make the send of mail using TNEF a good thing.  ;-( Seems like it would have been a lot easier for them to have just used HTML instead of TNEF for their special functions.

 

<blockquote>http://support.microsoft.com/kb/290809/ </blockquote><p>Good grief, they almost make the send of mail using TNEF a good thing.  ;-( Seems like it would have been a lot easier for them to have just used HTML instead of TNEF for their special functions.</p><p> </p>

[quote user="ldsandon"]http://support.microsoft.com/kb/290809/[/quote]

Been there, done that.

OL2k7 still sends TNEF sporadically.

<p>[quote user="ldsandon"]http://support.microsoft.com/kb/290809/[/quote]</p><p>Been there, done that.</p><p>OL2k7 still sends TNEF sporadically. </p>

http://support.microsoft.com/kb/290809/

Been there, done that.

OL2k7 still sends TNEF sporadically.

Did you note in the kb article that it says if you set some of the outlook only options it will drop back to TNEF no matter what the setting are in the user setup.

 

<blockquote><blockquote><div>http://support.microsoft.com/kb/290809/</div></blockquote><p>Been there, done that.</p></blockquote><blockquote>OL2k7 still sends TNEF sporadically. </blockquote><p>Did you note in the kb article that it says if you set some of the outlook only options it will drop back to TNEF no matter what the setting are in the user setup.</p><p> </p>

I've run into this problem as well, and some of our staff are reluctant to tell the customer the problem is on their end with their Outlook config. So we just us the Winmail Reader to open and read the winmaiil.dat file.  It works pretty good, and I don't have to hear our staff whine about "why aren't we just using (Outhouse) Outlook instead of Pegasus?". 

I've run into this problem as well, and some of our staff are reluctant to tell the customer the problem is on their end with their Outlook config. So we just us the Winmail Reader to open and read the winmaiil.dat file.  It works pretty good, and I don't have to hear our staff whine about "why aren't we just using (Outhouse) Outlook instead of Pegasus?". 
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft