199298 - Import from Outlook moves msg body to Part 1.1 attachment

Status: RESOLVED FIXED

(MailNews Core :: Import, defect)

Description

[Sam Hulick]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030325
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030325

When importing mail from Outlook, many e-mails have their message bodies moved
to an attachment called Part 1.1.  This "Part 1.1" bug only seems to occur when
importing mail.  When receiving new mail from a mail server, I never get this,
even if the e-mail is sent from Outlook using RTF format.  If RTF is used, I get
winmail.dat which is expected.

NOTE: This is not a dupe of bug 95266 as that user claims that receiving emails
via a server results in Part 1.1 attachment.  This no longer occurs AFAIK

Reproducible: Always

Steps to Reproduce:
1. Import mail from Outlook
2. Check various messages


Actual Results:  
Some have the body as Part 1.1 attachment

Expected Results:  
The message body should be there as expected

Comment 1

[Roberto Salomon]

I observe the same behavior on several recent e-mails. All "blank" e-mails have
attachments (both binary and text). Another common trait is that the message
headers have spaces missing on the boundary entry

Subject: test
Content-Type: multipart/mixed;
boundary="------------010803060701040404050108"

Manually editing the message in the inbox file to include a space before
boundary= results in the content being displayed. The attachment however is
shown as "Part 1.1".

Inspection of the entry shows that both name and filename are also missing a
space before the entry.

--------------010803060701040404050108
Content-Type: application/zip;
name="boot.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="boot.zip"

Manually inserting a space before name and filename corrects the problem.

Apparently there is a bug on the mail parser that requires a space to be present
before certain entries. This may be related to bug 95266.

Comment 2

[Mike Cowperthwaite]

Sam Hulick -- is this a dupe of bug 155537?
This would happen for messages with their own attachments, and the main body of 
the mail would have a blank   Content-type:   header.  See also bug 210606.

(Roberto Salomon, clearly that does not apply to your posted example.)

Comment 3

[Mike Cowperthwaite]

Roberto Salomon, see bug 166646.

Comment 4

[Mike Cowperthwaite]

In email, Roberto Salomon indicated that the messages he saw with the improperly 
"folded" headers might have been the result of a buggy antivirus scan on the 
part of his ISP.  He agreed that the fragment in comment 1 is unrelated to this 
bug.

This bug should be about the problem with Mozilla's Import-from-Outlook function 
(if that's in fact what's going on) which may be causing the Content-Type header 
of the body part of a multipart message to be blank.  The symptom of Mozilla 
displaying such a message with the body as an uinterpretable "Part 1.1" 
attachment is bug 155537.

To determine whether in fact there is a problem with Import-from-Outlook, some 
test data is necessary.  Ideally, this would be achieved as follows (copied from 
bug 210606 comment 10):
  Create a message in Outlook with a (small!) attachment.
  Send it to an account that is read by Outlook and an account that is
    read by Mozilla.
  Save the message from Outlook into a .EML (or .MSG or whatever Outlook uses)
  Save the message read by Mozilla into a .EML
  Import the Outlook folder into Mozilla, then save the message AGAIN 
    into a .EML.

Attach the three .EML files to this bug; that would be the evidence required to 
confirm it.  (I may be able to do this myself later this week.)

Comment 5

[Mike Cowperthwaite]

Following up on comment 4: I attempted to perform the test listed, but on the 
system I could use where Outlook was installed, I could not install Mozilla 
because I did not have full privileges.

I discovered, however, that Outlook (I'm not sure which version I was looking 
at) does not have (or has well hidden) a feature for saving or printing the full 
source of the message as text, or even of viewing the complete headers; it can 
be saved as a .MSG file, but this is a binary mangle of the original message.

Outlook experts, please correct me with better information if I'm wrong there.

Comment 6

[Peter Kirk]

(In reply to comment #5)
...
> I discovered, however, that Outlook (I'm not sure which version I was looking 
> at) does not have (or has well hidden) a feature for saving or printing the full 
> source of the message as text, or even of viewing the complete headers; it can 
> be saved as a .MSG file, but this is a binary mangle of the original message.
> 
> Outlook experts, please correct me with better information if I'm wrong there.

From memory of when I was using Outlook 2002: there is no way of viewing the
complete source, but there is (somewhere under Properties I think) a way of
viewing headers. The .MSG and .PST files do include the main part of a message
as plain text, but BEWARE! this has been converted to CP1252 or probably the
system code page, and so has lost informmation about any other characters
(although this information must be stored in some coded form in the .PST file.

Comment 7

[David :Bienvenu]

Attachment: proposed fix

this fixes that bug, and a problem importing attachments with outlook 2003

Comment 8

[Scott MacGregor]

Comment on attachment 164650 [details] [diff] [review]
proposed fix

so glad this was you and not me :)

Comment 9

[David :Bienvenu]

*** Bug 250878 has been marked as a duplicate of this bug. ***

Comment 10

[Serge Gautherie (:sgautherie)]

(In reply to comment #7)
> Created an attachment (id=164650) [edit]
> proposed fix

|tPath| was removed, but the following line update was missed:
{{
617         MAPI_TRACE1( "~~ERROR~~ OpenStreamOnFile failed - temp path:
%s\r\n", tPath);
}}

Can you fix this too ?

Comment 11

[Serge Gautherie (:sgautherie)]

(In reply to comment #10)

3 years later ... I filed bug 199298.