145150 - importing Outlook email with header Content-Type: application/ms-tnef

Status: RESOLVED FIXED

(MailNews Core :: Import, defect)

Description

[C Cavello]

When importing certain email messages from MS Outlook (2000), no text is
displayed in the message body, but all emails have an attachment called
"attachment".  If user performs "view source" on the message everything is there OK.

According to Cavin Song in bug 58206 comment #30:
The problem (ie, body text is stored in an attachment) is caused by the 
following message header:

  Content-Type: application/ms-tnef

It basically says that the body text is an application of type 'ms-tnef' even 
though the body text is really just plain text.  For this reason mozilla makes 
the body text a separate file so that you can launch it or save it to local 
disk. It's not possible to display application type of data in the message 
window. If I remove the above header or change it to "Content-Type: text/plain" 
from the imported message the message is displayed correctly. 
---

More notes:

http://agamemnon.ucs.ed.ac.uk/faq/mstnef.html
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q241538

The above web sites give more information on "application/ms-tnef".

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

This bug will become more visible with the patch for bug 58206 being approved
for the branch.  The 1.0.1 drivers would appreciate some investigation being
done on this bug.

Comment 2

[Cavin Song]

The 2nd link (provided by reporter) to the TNEF info says:

When a message containing TNEF information is received by a mail client that 
does not understand TNEF, there are three common results: 

1. The plain text version of the message is received and it contains an 
attachment named Winmail.dat. The Winmail.dat attachment does not contain any 
useful information when opened since it is in the special TNEF format. 

2. The plain text version of the message is received and it contains an 
attachment with a generic name such as ATT00008.dat or ATT00005.eml. In this 
case the client is unable to recognize the TNEF part of the message, and is 
unable to recognize the Winmail.dat file name, so it creates a file name to hold 
the TNEF information. 

3. The plain text version of the message is received and the client ignores the 
Winmail.dat attachment. This is the behavior found in Microsoft Outlook Express. 
Outlook Express does not understand TNEF, but it does know to ignore TNEF 
information. The result is a plain text message.

So I think we can chose to implement option #3 to ignore the Winmail.dat 
attachment mainly because we don't retrieve it via MAPI interface anyway. I'll 
verify this in the code later. In this case I think we only need to change 
"Content-Type:" header from "application/ms-tnef" to  "plain/text", which is 
easy to do.

But I would like to have more test msgs to make sure that the fix is going to 
work for all cases, for example, outlook msgs with multiple attachments, single 
attachment, no attachment, etc.

Reporter, can you provide me with another test .pst file which contains various 
types of msgs? Thanks.

Comment 3

[Cavin Song]

Attachment: Proposed patch, v1

Map "Content-Type: application/ms-tnef" to "Content-Type: text/plain" so the
body text can be displayed normally (instead of in an attachment).

Comment 4

[Cavin Song]

I tested this patch against reporter's test Outlook msgs he sent me and the 
imported msgs all look fine.

Comment 5

[Jean-Francois Ducarroz]

Comment on attachment 85673 [details] [diff] [review]
Proposed patch, v1

Why not just look for "content-type: application/ms-tnef". I am worry that you
will detect the second string without witout being part of the content-type.
Imagine I have a message like that:

...
content-type: text/plain
subject: what is "application/ms-tnef"?
...

Comment 6

[Cavin Song]

The patch does exactly that because it checks both content type and value (the
header is already parsed out into two fields). I have to do this check here
since this is the place where the code writes out data to the output file.

Comment 7

[Jean-Francois Ducarroz]

Does header contains only one line of header or it could contains several lines?

Comment 8

[Cavin Song]

It gets one header (like Date:, Subject:, etc) at a time in this function and
GetHeaderValue() retrieves the value associated with the header.

Comment 9

[Jean-Francois Ducarroz]

Comment on attachment 85673 [details] [diff] [review]
Proposed patch, v1

R=ducarroz

Comment 10

[David :Bienvenu]

Comment on attachment 85673 [details] [diff] [review]
Proposed patch, v1

sr=bienvenu

Comment 11

[Cavin Song]

Fix checked into trunk.

Comment 12

[Cavin Song]

Reporter, can you try tomorrow's build and see if the fix works for you ok (ie,
all your messages)? Thanks.

Comment 13

[C Cavello]

Tested fix with trunk build 2002053104 (win32).  Those troublesome messages no
longer show up as attachments.  I see the messages in the message body.

I can see reasons for converting RTF (Rich Text Format) messages into plain
text, but why are the HTML messages in my *.pst converted into plain text?  Is
there a requirements document defining how true to the original you want the
import to be?  This may be a (not-yet-filed?) separate bug, "import email from
Outlook converts HTML to plain text".

Comment 14

[Cavin Song]

I'm not sure if there is any header in the msg indicating that a given msg
contains html text. If so then we can map "application/tnef" to "text/html".
I'll investigate. Does any of your test msgs contain html text?

Comment 15

[Cavin Song]

When I forward a test msgs with HTML body text from reporter to my own mail
account, Outlook generates an alternate body part which contains all the HTML
tags from the original msgs, and as a result, I知 able to see the original
format (fonts, sizes and colors) of the body text. In other words, Outlook
creates a msg whose content type is 'multipart/alternative' and with two body
parts: one plain text and one HTML version of the original body text. 

I think Outlook understands that no one is going to understand winmail.dat
format so it provides an alternate way for other mail clients to display HTML
text if the clients know how to handle HTML pages. So unless we understand how
to interpret info in winmail.dat (like Outlook does) I don't think the issue of
"missing HTML info in msg body" is going to be resolved. See
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q241538 for details on
the type of info that may be carried/contained in winmail.dat.