76323 - MIME "multipart/related" attachments don't show up

Status: VERIFIED WORKSFORME

(MailNews Core :: MIME, defect, P2)

Description

[Ewald Beekman]

This is part of an email header sent by outlook, it seems mozilla can't handle
this because the gif image contained in one of the body parts doesn't show.
Also there is no paperclip button to indicate mozilla actually detected any
attachments. When i change the Content-Type to "multipart/mixed" and delete the
type="text/plain" everything works fine again.
Tested with mozilla 0.8.1 on a PC

MIME-Version: 1.0                                                               
Content-Type: multipart/related;                                                
        type="text/plain";                                                      
        boundary="----=_NextPart_000_0039_01C0C72E.CA7F7E70"                    
X-Priority: 3                                                                   
X-MSMail-Priority: Normal                                                       
X-Mailer: Microsoft Outlook Express 5.50.4133.2400                              
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400

==This is what the body looks like:
This is a multi-part message in MIME format.

------=_NextPart_000_0039_01C0C72E.CA7F7E70
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit




------=_NextPart_000_0039_01C0C72E.CA7F7E70
Content-Type: image/gif;
        name="dilbert2091369010417.gif"
Content-Transfer-Encoding: base64
Content-Location:
http://www.dilbert.com/comics/dilbert/archive/images/dilbert2091369010417.gif

R0lGODdhWALVAKIAAP///9vb27a2tpKSkm1tbUlJSSQkJAAAACwAAAAAWALVAEAD/wi63P4wykmr
vTjrzbv/YCiOZGmeaKpGwnEEayzPsVs0Qs60L+3/wI5LQDEciMGkogATDRbHAmFAOBQMhOy02Qhk
etc. etc.

Comment 1

[Boris Zbarsky [:bzbarsky]]

what happens if you remove the type="" but leave the multipart/related?

Comment 2

[Boris Zbarsky [:bzbarsky]]

comments from reporter:

The attachment still doesn't show, anyway i beleive the type="" is
mandatory according to the rfc (2387).

Comment 3

[scottputterman]

Does this work now?  It could be
http://bugzilla.mozilla.org/show_bug.cgi?id=75457 which was fixed after you
filed this bug.

Comment 4

[Ewald Beekman]

Attachment: multipart/related mail message with GIF image

Comment 5

[Ewald Beekman]

It makes no difference whether the message is on the IMAP server in a
folder or in one of the local folders.
I made an attachment of the email which caused the problem so you
can see for yourself

Comment 6

[scottputterman]

I can reproduce it with this message too. It works fine in OE but doesn't work
in NS4.7 or current builds.  When you sent this message from OE did you just
attach an image?

Comment 7

[Ewald Beekman]

I got the email from somebody else, he told me that he created it by dropping
the image in the message pane. That would explain for the empty body part. The
reason for making it multipart/related instead of multipart/mixed is unclear to
me.

Comment 8

[scottputterman]

Esther, could you or someone in QA see how easy this is to reproduce.  I tried
this with Outlook Express and wasn't able to reproduce.  I got multipart/mixed.
 If this isn't easily reproduceable then we can push off for a bit.

Comment 9

[scottputterman]

moving to mozilla0.9.2

Comment 10

[Jean-Francois Ducarroz]

What outlook does seems wrong! it send a message as multipart/related. The 
message contains two part but they are not related! By that I means the first 
part should have a link to the second part. It's not the case. That's why we are 
not showing the image! However, if the content type was multipart/mixed, that 
would work.

Comment 11

[Dave Gileadi]

Attachment: I've received several e-mails that do not contain "multipart/related" where an attachment doesn't show up. It seems to happen when someone attaches an e-mail that contains the attachment.

Comment 12

[scottputterman]

I'm moving to the future milestone.  As ducarroz says, it looks like this should
have been sent multipart/mixed.  If we can find more examples of how this gets
created as multipart/related we should reconsider doing this earlier.  Dave, as
for your message, I think that might be related to some of the comments in 74649
(though this might be a separate bug altogether.  I'll update the bug to look at
your attachment)

Comment 13

[Jean-Marc Desperrier]

I'd like the target milestone to be changed to something much nearer.

This situation is no difficult to reproduce, I encounter it very regularly when
receiving email from Outlook users.

I have a coworker who uses PINE, and he has no difficulty seing the attachments
in this messages I can't read with Mozilla.

I think that multipart/related could be handled about the same as
multipart/mixed, and the attachment displayed in the attachement panel, so the
bug should be easy to solve (just paste in the multipart/mixed code-behaviour).
Outlook seems to handle multipart/related messages this way.

Here are the headers of the message I just received with this problem.

X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Received: by carbone.certplus.com 
	id <[e-mail]>; Tue, 10 Jul 2001 11:02:34 +0200
MIME-Version: 1.0
Content-Type: multipart/related;
	boundary="----_=_NextPart_001_01C1091F.0F4F9256";
	type="text/html"
Content-Class: urn:content-classes:message
Subject: =?iso-8859-1?Q?TR=3A_FLASH_=3A_ZZZ_restructure_ses_activit=E9s?=
Date: Tue, 10 Jul 2001 11:01:24 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: =?iso-8859-1?Q?FLASH_=3A_ZZZ_restructure_ses_activit=E9s?=
Thread-Index: AcEJGu+lMgIvcMECTAub77khOtXeTAAA/6eA
From: "R P" <[e-mail]>
To: "T C" <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C1091F.0F4F9256
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">


</HTML>
------_=_NextPart_001_01C1091F.0F4F9256
Content-Type: application/pdf;
	name="COM_Flash_10_07_01.pdf";
	x-mac-type=50444620;
	x-mac-creator=4341524F
Content-Transfer-Encoding: base64
Content-ID: <a05100301b77079a2205d@[192.168.1.6].0.0>
Content-Description: COM_Flash_10_07_01.pdf
Content-Disposition: attachment;
	filename="COM_Flash_10_07_01.pdf"
Content-Location: 1_multipart%3F2_COM_Flash_10_07_01.pdf

JVBERi0xLjIgDSXi48/TIA0xMCAwIG9iag08PA0vTGVuZ3RoIDExIDAgUg0vRmlsdGVyIC9GbGF0

By the way, I encountered another problem, trying to select the last lines in
the "view source" panel for this message crashes Mozilla every time.
I don't have time now to test if this happens with other builds/messages.

Comment 14

[scottputterman]

Can you send me a message ([e-mail]) that exhibits this behavior? 
Karne, can you reproduce this with Outlook and an Exchange server?

Comment 15

[Karen Huang]

Build 07-10-03-0.9.2
Yes. Used above Jean's message headers and testing on Outlook:
At least Outlook did handle the second attached message's header.
Please see the following attached screen shot.

Comment 16

[Karen Huang]

Attachment: attach the screen shot when testing on Outlook

Comment 17

[scottputterman]

Karen, can you reproduce this with a message of your own, just by composing it
in Outlook and sending it?

Comment 18

[Karen Huang]

I cannot reproduce this problem either, I got multipart/mixed too....
I am wondering to know how to get the "multipart/related" attachments for just 
composing/sending in Outlook?

Comment 19

[Karen Huang]

Ccing Jean-Marc who mentioned that she encountered it very regularly when
receiving email from Outlook.

Jean-Marc, can you send the message to me ([e-mail])that exhibits this 
behavior? 

Comment 20

[Jean-Marc Desperrier]

Attachment: Other mail message of type content/related

Comment 21

[Jean-Marc Desperrier]

> Ccing Jean-Marc who mentioned that she encountered it very regularly when
I'm a "he".

I received once again an email of this kind. 
It doesn't happen that often after all.
The email I received was a forward with outlook of an original message that
itself already had the "multipart/related" type. 
Attachment 53745 [details] is that original message. 
I don't know how it was created, so I can't describe how to reproduce this with
Outlook.

I've checked that when the same person who forwarded me that message forwards me
a multipart/mixed message with attachements, I have no problems.When opening
attachment 53745 [details] with Outlook Express, it's attachment is accessible.

Comment 22

[odi]

The target milestone should be changed to 1.0.
This is a major problem that affects interoperatablity with Outlook. If
Mozilla's Mail Client can not read Outlook Email this is *really* severe!
I am using Mozilla in a mixed Outlook(Win) / Entourage(Mac) environment at work
and I always have problems with those attachments. If this is not going to be
fixed I have to change back to (hated) Outlook.

Comment 23

[Jean-Francois Ducarroz]

Fix for bug 109249 will fix this "problem"

Comment 24

[Phil Anderton]

Does Mozilla claim to be able to handle multipart/related? If not, see rfc2387:

"User agents that do not recognize Multipart/Related shall, in
accordance with [MIME], treat the entire entity as Multipart/Mixed."

Comment 25

[Jean-Francois Ducarroz]

Again, Mozilla correctly interpret multipart/related. The problem here is that
MS Outlook uses multipart/related when the part are not related!! it should use
instead multipart/mixed. Anyway, since a while now, we are showing lost related
parts as attachment.

Using a recent build (Mozilla RC2, Win2K), this is working fine for me.

Comment 26

[Phil Anderton]

Attachment: Very simple multipart/related message

Comment 27

[Phil Anderton]

Attachment: Same message with multipart/mixed

Maybe I've misunderstood something. Take a look at my attachments - the "same"
content displays differently.

Comment 28

[Jean-Francois Ducarroz]

I explain:

1) multipart/mixed
The message contains a main body and several other part with are represented as
attachment or inline. Mozilla automatically display part inline when possible
(text/*, image/jpeg)

2) multipart/related
The message contains a main body which link to other related part. Tipically an
html message body with an embedded image. If in case of multipart/related, a
part is not related to the main body, we consider it as a lost part and show it
as attachment (despite this is not a valid message format).

You 2 test cases show exactly that!

Comment 29

[Trix Supremo]

verified wfm