133638 - Corrupt Microsoft Word .doc file attachments sent by Linux Mozilla 0.9.9

Status: VERIFIED INVALID

(MailNews Core :: Attachments, defect, P1)

Description

[Steven Augart]

I sent a .doc file as an attachment to an email message I composed with the
Linux Mozilla build 0.9.9.  The .doc file was not encoded correctly and arrived
corrupted.  

I can send that .doc file via a Win32 0.9.9 build and it is properly encoded.

The email message containing the corrupted version of the file encoded it as:
 Content-Type: cmd_delete;
  name="augart-resume.doc"
 Content-Transfer-Encoding: quoted-printable
 Content-Disposition: inline;
  filename="augart-resume.doc"

The email message that contained an accurately encoded version of the file
encoded it as:
 Content-Type: application/msword;
  name="augart-resume.doc"
 Content-Transfer-Encoding: base64
 Content-Disposition: inline;
  filename="augart-resume.doc"

I will attach files demonstrating the problem.

Comment 1

[Steven Augart]

Attachment: Email message sent using Linux Mozilla 0.9.9; includes corrupt attachment.

Comment 2

[Steven Augart]

Attachment: An email message composed witn Windows Mozilla 0.9.9, contains the properly encoded attachment

Comment 3

[Steven Augart]

Attachment: The .doc file after quoted-printable by Linux Mozilla 0.9.9. It is *almost* correct, as you can see.

Comment 4

[Steven Augart]

Attachment: The attached .doc file, correctly reconstructed after Windows Mozilla 0.9.9's base64 encoding.

Comment 5

[Steven Augart]

Attachment: The original file, uncorrupted before transmission. Use this as a test case if you think you've fixed the bug.

Comment 6

[Steven Augart]

This bug does not appear in Linux builds of Netscape communicator 4.79.

Comment 7

[Vadim Berezniker]

Is this reproducible?
If I send the document, it arrives properly encoded.

Comment 8

[Boris Zbarsky [:bzbarsky]]

This is almost certainly dependent on the exact MIME setup on the machine in
question....

Comment 9

[scottputterman]

reassigning to ducarroz.  Can anyone reproduce this?

Comment 10

[Jean-Francois Ducarroz]

Right, looks should be dependent on the MIME type configuration on the machine.
However, the fact the content-type get set to cmd_delete make me think that we
are using an uninitialized string with result in random/bogus value!

Comment 11

[Jean-Francois Ducarroz]

Reporter, how do you attach the document? please give us the exact steps. Thanks

Comment 12

[Jean-Francois Ducarroz]

Reporter, in the preference panel "Navigator/Helper Applications", do you have
any entry named cmd_delete or something related to .doc document?

Comment 13

[Steven Augart]

Jean-François du Carroz:  In reply to your question about Navigator/Helper
Applications, YES.  I have an entry for cmd_delete and an entry for
application/msword files ending in (.doc).

.doc files are handled by ``Save to disk''.

MIME type cmd_delete, with the extension doc, is handled by soffice (Sun's Star
Office).

Comment 14

[Steven Augart]

Jean-François du Carroz: This is in reply to your question about
exactly how I attach the document.

1) get into mail-news with Control-2.
2) Click on the Compose icon on the toolbar.
3) Clikc on To field.  Type address of recipient
4) Click on Subject: field  Type the subject.
5) Left-click on the blank window captioned `Attachments', at the right-
hand side of the header fields.
6) Horizontally zoom the file window, since it always pops up too small for me     
    to read the whole name of a long file :( )  I do this using the window     
    manager.
7) left-click on the name of the file I want.
8) Left-click on Open
9) left-click on the Send icon on the toolbar.

Comment 15

[Jean-Francois Ducarroz]

I don't understand how come you get an entry for cmd_delete in the application
helper but that seems a bogus entry for me. Deleting that entry should solve the
problem!

Comment 16

[Steven Augart]

Ok.  I have removed the evil cmd_entry in my Preferences > Navigator >
Helper Applications window.  MS-Word files are now sent encoded as
base 64.  Which works.  The file made it in and out correctly.

I now see two problems: 

1) How did the cmd_entry get into the preferences in the first place?
   I did tell Mozilla once, in response to a download prompt, to use
   soffice to open Microsoft Word documents.  But I certainly never
   gave those documents a mime type.  Perhaps cmd_entry was a bogus
   mime type used by the remote server?

   In an attempt to answer this, I deleted the other .doc entry in my
   helper applications association list and tried to download a .doc
   file again from the web.  This time around, mozilla just asked me
   where I wanted to save the file.  Perhaps mozilla has some memory
   that it should save .doc files, even though I told it to forget
   about them?

2) Why did Mozilla use an information-losing encoding like
   quoted-printable to encode the file?  I assume that the problem
   happens because in quoted-printable, it's presumably ok to add line
   breaks (for wrapping) and to translate the ends of lines back and
   forth between CR-LF and LF.

   (I haven't checked the RFC, though, so I could be wrong about
   this).  At any rate, I think Mozilla should not mess around using
   quoted-printable with any files that contain any non-printing
   characters.  If there are a few tiny uses of odd characters, sure.
   Go ahead and quoted-printable them.  But if using quoted-printable
   means that over 50% of the file has to be quoted, there is
   certainly something wrong with the choice of encoding, and the
   chances of things surviving unscathed are not good.

As I finish typing this, I've gotten a reply from Jean-François
suggesting that I nuke the cmd_delete entry from my helper
applications list.  I guess great minds think alike :).

Comment 17

[Jean-Francois Ducarroz]

Steve, I don't have an answer for your question #1 but if you are ever able to
reproduce it, please file a new bug for it.

The problem #2 is a side effect of the first problem, we failed to choose the
correct encoding when having a bogus content-type. I'll file a new bug for that.

But for what concern this bug, I'll mark it as invalid.

Thanks Steve for your help.

Comment 18

[Steven Augart]

Attachment: testcase3.WEIRD

Try sending an email message with this as an attachment.

Comment 19

[Steven Augart]

Attachment: testcase3.WEIRD after it's been through mozilla's quoted-printable encoding and decoding

You'll note that here the byte whose decimal value is 13 (015, ^M, <CR>)
has been converted into a 10 (012, ^J, <NL>, standard Unix line terminator).

Comment 20

[Steven Augart]

I'm a bit uncomfortable with the classification system we're using.
By marking this bug as INVALID, we end up creating the illusory impression
that the bug report was bogus or not worth paying attention to.

Yet in fact, we learned from it that something is indeed wrong.  Something is
wrong with how we choose encodings for attachments with content-types about
which Mozilla has no special knowledge.

I'd argue for a REMIND, to become a FIXED when your fix goes in.

Here's another manifestation of the bug that gave me some food for thought.

I created a file called testcase3.WEIRD.  The idea here is that we hope Mozilla
has never seen a .WEIRD file extension.

Its contents are the byte stream ^A^B^C^M^N^O^P^Q^R^S^T^U^V^W

I attached it to an email message.  Mozilla decided it was text/plain, and
turned the ^M into a <CR><LF> for SMTP.  When I received it the <CR><LF> was
saved as my system's usual end-of-line character (<LF>).

What this means effectively is that Mozilla will corrupt arbitrary binary
files sent as attachments.

Comment 21

[Jean-Francois Ducarroz]

Steve, the real problem is the bogus mime type in the pref you have. We use the
correct encoding based on the bogus mime type. Once you correct that bogus mime
type, everything is fine. That why I have marked this bug invalid and asked you
to open a new one for the bogus mime type which is a totally different problem!

This bug is invalid!

Comment 22

[Trix Supremo]

verified invalid

Comment 23

[Steven Augart]

Jean-François:  In comment # 17, you write:
  The problem #2 is a side effect of the first problem, we failed to choose the
  correct encoding when having a bogus content-type. I'll file a new bug for that.

and then in comment # 21 you write:
  That why I have marked this bug invalid and asked you
  to open a new one for the bogus mime type which is a totally different problem!

When I read comment #21 the first time (back in 2002 when you wrote it) I
overlooked that you were asking me to open a new bug report for the bogus mime
type.  (Hysteresis from comment #17.)  Did you ever open a report for that, or
should I file one?  Or should I append comments to one of the bugs I've found
that sounds like it might be the bogus mime type problem (Bug # 170939,  Bug #
157219) ?

I searched bugzilla and have not found a report filed in the past year for this.



(Bug #172760 has some conceptual similarities, and might be worth looking at by
whoever handles this one.)