145291 - Microsoft Word attachments don't appear for recipient

Status: VERIFIED FIXED

(MailNews Core :: Attachments, defect)

Description

[David Mischel]

When a MacOS X client composes email with two Word attachments, the recipient
does not see any attachments at all when the message is read. The attaching
client creates an "appledouble" attachment which contains the two attached
files, each of which is of type "application/binary." 

Even after naming the files to attach with a .doc extension, associating it with
the "application/msword" MIME type,and configuring both the sender and recipient
to use Word to handle .doc types the recipient does not see any attachments at all.

We have seen this with 0.9.9 milestone, RC1 and RC2 on Mac OS X.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Could you attach the source of the email in question to this bug using
http://bugzilla.mozilla.org/attachment.cgi?bugid=145291&action=enter ?

Comment 2

[David Mischel]

Attachment: This file was created using "Save as..." on a test message.

This sample of a message whose attachments Mozilla on OS X could not read is
attached per a request by [e-mail].

Comment 3

[Boris Zbarsky [:bzbarsky]]

Mail from David:

I see I didn't specify that the inability to see the attachments is only 
when the recipient is on a Mac OS X system. Windows users see the 
attachments just fine. The bug is when sender and recipient are on Mac 
OS X. We are not testing on OS 9 or less.

Adding pp keyword...

Comment 4

[Jean-Francois Ducarroz]

reassign to myself.

Comment 5

[Jean-Francois Ducarroz]

Works fine for me using Netscape 7.0PR1 on Mac OSX, I am reading the test
message from a pop account and both attachment are showing up. I can open those
attachments without trouble.

Reporter, are you using pop or imap?

Comment 6

[Jean-Francois Ducarroz]

I am able to reproduce this problem on IMAP, looks like the IMAP protocole
doesn't correctly feed the appledouble part to mime!

The current workaround is to move/copy the message to a local folder, from there
you will be able to see the attachment.

This is a dataloss as the user cannot see the attachmens and probably isn't even
award of it. Nominating nsbeta1

Comment 7

[scottputterman]

marking nsbeta1+ [adt2 rtm] per mail triage.

Comment 8

[Jean-Francois Ducarroz]

The problem does not occurs if you send only one apple double attachment. But it
would appends if you send one MSWord attachment and signed the message (which
generate an extra part at the end of the message).

Comment 9

[Jean-Francois Ducarroz]

Here is the problem:

In mimemoz2.cpp, function BuildAttachmentList, we check is an appledouble
multipart has 2 children before accepting it. We do that to rule out potential
bogus appledouble attachment.

In nsIMAPBodyShell.cpp, function nsIMAPBodypartMultipart::ShouldFetchInline, we
accept to generate appledouble content only if the datafork of the attachment
can be displayed inline. This is Mac only. This code is trigger only when doing
part on demand.

Therefore, when we have a message big enough (case with 2 attachments but not
with only one), IMAP will do part on demand and not generate the content of the
appledouble part. Therefore mime wont be able to see it's children and will rule
out it's an invalid attachment and ignore it.

The easy way to fix it would be to remove the test for children in mime or at
least when we detect we are processing a truncated imap message. That would work
 most of the time but it's possible (and I have seen) that the header of the
multipart/appledouble body does not contains the name of the attachment (which
is in one of the children) and therefore we won't be able to correctly named the
attachment in the message display!

The real solution would be to fix the IMAP code to not truncated the whole
appledouble part content but rather the content of its both children.

Comment 10

[Jean-Francois Ducarroz]

Attachment: Proposed fix, v1

I have removed the optimization in IMAP which was preventing to generated the
children headers of a multipart/appledouble attachment when doing part on
demande. Now, we cut only the content of the children (if they cannot be
displayed inline). This is what we are already doing on other platforms. I have
tested the patch carrefully with several case of appledouble attachments
(inline or not).

Comment 11

[David :Bienvenu]

Comment on attachment 87994 [details] [diff] [review]
Proposed fix, v1

sr=bienvenu

Comment 12

[Cavin Song]

Comment on attachment 87994 [details] [diff] [review]
Proposed fix, v1

r=cavin.

Comment 13

[Jean-Francois Ducarroz]

Fixed in trunk.

This is a safe fix we should really take for the branch

Comment 14

[scottputterman]

Trix, could you verify this on the trunk?

Comment 15

[scottputterman]

What mail client generated this email?  Will most email clients generate a mail
with 2 attachments such that this problem won't occur?

Comment 16

[Jean-Francois Ducarroz]

Scott, the problem occurs when we have message with an apple double attachment
and the message is big enouh to force IMAP do to part on demand. This is not
related to  any particular mail client.

Comment 17

[Paul Wyskoczka]

Adding adt1.0.1+ on behalf of the adt for checkin to the 1.0 branch.  Please get
drivers approval before checking in. When you check this into the branch, please
change the mozilla1.0.1+ keyword to fixed1.0.1

Comment 18

[Judson Valeski]

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+"
keyword and add the "fixed1.0.1" keyword.

Comment 19

[Jean-Francois Ducarroz]

fix checked in the branch

Comment 20

[Trix Supremo]

verified on branch 2002071005-1.0, changing keyword to verified1.0.1