156349 - Microsoft Word/Excel files corrupted during a MIME transfer

Status: RESOLVED WORKSFORME

(MailNews Core :: MIME, defect)

Description

[Phil Irwin]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529
BuildID:    2002052918

Microsoft Word, and Excel files get corrupted at some point during a MIME
transfer.  If I attach a word or excel file and send it to myself, then save it
to a file, A binary diff says the two files are different and Word cannot open
the transferred file whereas it can open the originally attached file.  

I am 90% sure the problem is on the encoding side because people using Eudora
and other mailers cannot open the attached file either.

Another thing that is odd is they get wrong MIME type.  Here's an example:

Content-Type: type=type=application/ms-powerpoint;
 name="homesetcheck.doc"
Content-Disposition: inline;
 filename="homesetcheck.doc"

But still, the contents of the file itself should not change through the transfer.

Reproducible: Always
Steps to Reproduce:
1. Attach Word/Excel file to an Email
2. "Send"
3. Pick up mail on the other end and save attachment
4 [details] [diff] [review]. Do a diff on the two files and try to open the saved one in Word/Excel

Actual Results:  An error to the effect of "Make sure this file has a .DOC
extension" is presented

Expected Results:  The attached file and the transferred/saved file should be
identical.

I can Email you the particular file(s) if you would like to see if the problem
is reproduced on your end.  [e-mail]

Comment 1

[Phil Irwin]

Attachment: This is the original microsoft document that was attached. It can be opened in Microsoft Word

If the same encoding problem exists on this form, we're outta luck

Comment 2

[Phil Irwin]

Attachment: File after going though Mozilla's MIME encoder/decoder

I downloaded the last attachment myself and it seems to be fine, so this web
page's encoder does not exhibit the same problem that I am seeing in the
Mozilla Mailer.

Comment 3

[Jean-Francois Ducarroz]

The problem comes from the content-type used during the file transfert which is
not correct. We already have a bug on that issue open I thing. cc'ing sspitzer

Comment 4

[R.K.Aa.]

similar: bug 125603, bug 133638

Comment 5

[Jean-Marc Desperrier]

I can not open in word the second attachment, and binary comparison shows some
0a replaced by 0d inside it.

Can you include the whole original email in . eml as an attachment ? (do
File/Save As/File to get it).

Comment 6

[Rick Bilonick]

I am having the same problem with 1.0.1 after installing a newer RPM (on a RH
8.0 Linux Intel PC). If I send an MS Word .doc and an MS Excel .xls file, the
Excel file either can.t be opened or opens with all blank sheets (the sheet
names are visible but they are all blank contents). This happens also as a test
when I send the files to myself. The MS Word file is perfectly fine. I have
discovered that if I zip the Excel file, send it to myself, and then unzip it,
the Excel file opens normally and is not corrupted.

Comment 7

[Jeff Condron]

I hope this isn't a duplicate, I think my first entry didn't make it...

I had the same problem (appilication/msword documents were encoded using
quoted-printable). I am running Netscape 7.1 on Red Hat Linux 8.0.

I found a news posting on de.comp.standards which was entitled:
   MIME/quoted printable/base64
(you can search for it on groups.google.com)

This article I believe stated that adding:

   user_pref("mail.file_attach_binary", true);

to your prefs.js would fix this problem. 

I closed netscape, added this line to prefs.js, and restarted, and now my word
documents are readable.

I am not sure exactly what the news post said, since it is in German, and I
don't read it. Someone who can read it may be able to shed more light on the
whys and wherefores.

One useful document might be what user_prefs are available, and what each does
(at least a summary).

Comment 8

[Moritz Strübe]

Reporter: Is this still open???

Comment 9

[Simon Waldman]

The same, or something very similar, is still happening on 1.7 linux (20040616).
A word attachment gets given 

Content-Type: multipart/appledouble;
 name="smallcv.doc"
Content-Disposition: inline;
 filename="smallcv.doc"
Content-Transfer-Encoding: 7bit

Which is presumably wrong - 7bit seems unlikely. Certainly recipients using a
variety of mail clients are unable to read it. When the message is received by
Moz, no attachment is visible except through viewing the message source.

I'm happy to provide any other info requested to help in fixing this - it's a
major problem for those few of us who are using Moz on linux to send .doc files.

Comment 10

[Mike Cowperthwaite]

Phil Irwin: can you at all reproduce the original report?  I am particularly 
curious whether you still see the   Content-Type: type=type=...   bogusness.

Is the mail going thru an MS Exchange server?  IMAP or MS-mail?

Is the copy of the message in your Sent folder also corrupt?


I suspect the multipart/appledouble issue is a separate problem, but the 
questions above still pertain.  See bug 236239. 

Comment 11

[Mike Cowperthwaite]

From reporter via email
=========
(In reply to comment #10)
> Phil Irwin: can you at all reproduce the original report?  I am particularly
> curious whether you still see the   Content-Type: type=type=...   bogusness.

No, but it is funny that it is a ".doc" file and I see:

  Content-Type: type=application/ms-powerpoint; name="InstTiminig.doc"
  Content-Transfer-Encoding: quoted-printable
  Content-Disposition: inline; filename="InstTiminig.doc"


> Is the mail going thru an MS Exchange server?  IMAP or MS-mail?

It happens with both IMAP and POP.


> Is the copy of the message in your Sent folder also corrupt?

Yes, it passes diff with the one received on the other end.  And they both
fail diff with the original.  I cannot open either one of them with MS product
or OpenOffice.
================

Hmm.  Are the attachments still getting corrupted, tho?  That's kind of the 
whole point of this bug, isn't it?


> No, but it is funny that it is a ".doc" file and I see:

I'm not sure whether you thought all those headers were particularly off.
The Content-Type does look incorrect.  When Mozilla is attaching a file, I 
believe it determines the type by looking for the extension in the Helper 
Applications preferences; if it's there, it will use the associated type.

Under Windows (as a backup?) it (may?) also look in the registry's HKCR branch 
for the extension, and use the content-type value from there.  I would check 
both of these to see how .doc is listed.

The other possibly suspicious header is
  Content-Transfer-Encoding: quoted-printable

Why q-p, rather than Base64, is being used, I have no idea.

Comment 12

[simon annear]

Marking as worksforme (diff gives identical files)

tested using attachment 1 [details] [diff] [review] and Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b)
Gecko/20050302 on Linux (SUN JavaDesktop R2) sending through Sun Msging Server

Also - no issues with mime types:

Content-Type: application/msword;
 name="homesetcheck.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="homesetcheck.doc"