95266 - Message body should be displayed as "message body" instead of "part 1.1" in the attachments panel

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Jeff Tsai]

o Send yourself a message with one or more attachments.
o Receive and view the message.
o Notice that the message body is displayed as "Part 1.1".
o It would be nice to displayed as "message body" intsead of techy mime "Part 
1.1"

Comment 1

[Jeff Tsai]

Similarly, a forwarded message should be displayed as "forwarded message" 
instead of "Part 1.2" in the attachments pane.

Comment 2

[[e-mail] (gone - use [e-mail] instead)]

Agreed, marking new.

Comment 3

[scottputterman]

reassigning to ducarroz

Comment 4

[Jean-Francois Ducarroz]

Jeff, what do you means exaclty by "Send yourself a message with one or more
attachments"? Are you creating a new message, addind attachment and then send it
or are you forwarding a message that already comtains attachment?

Comment 5

[Jeff Tsai]

Either way will do. I just don't like to see the attachment panel says "Part
1.1, Part 1.2 ...." It's sort of techie terms. Not good of the general users.

Comment 6

[Jean-Francois Ducarroz]

we put part n.m only when the part doesn't have a name. Sure, we can try to be
smarter and figure out a better name depending of the situation...

Comment 7

[Jeff Tsai]

Now I sort of remember what I did for Netscape 3.0 and 4.0 when forwarding a
email message I added the "name=forward.msg" as one of the parameter for
"Content-Type:" mail header. I also added the "filename=forward.msg" as one of
the parameter for "Content-Disposition:". That's where you play the trick. So,
when generating the final RFC822 mime message before going to the wire you try
your best to figure out what name should be displayed to the user and set it
over there.

Comment 8

[Jean-Francois Ducarroz]

Thanks for the tip. In my recent change in attachment handling, I now put the
subject of the message as filename when we send it if I remember right.

Comment 9

[[e-mail]]

There is at least one other scenario that this occurs in.
I imported an Outlook mailbox and some messages came across with no message body
ie nothing could be seen in the preview pane or when opened. There messages had
attachments called "Part 1.1" which had to be saved and opened with some other
application (ie a text viewer). It turns out that the Part 1.1 attachment is the
message body.
This may or may not be related to this bug but the imported messages should show
the original message body and not be turned into an attachment.

It is difficult to extract the mail message source from Outlook to send to you.
The headers look like (not sure if it is complete or not)
Received: from bmarks ([1.3.1.13])
	by blackhole.solnet.com.au (8.11.3/8.11.3) with SMTP id g45NaGP27281
	for <[e-mail]>; Mon, 6 May 2002 09:36:16 +1000 (EST)
From: "Brian Marks" <[e-mail]>
To: "Matthew Jurgens" <[e-mail]>
Subject: FW: SolNet Melbourne & IBM
Date: Mon, 6 May 2002 09:31:32 +1000
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0056_01C1F4E0.CF38EAB0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
Status:   

Comment 10

[Garth Wallace]

Correcting grammar in summary

Comment 11

[Ralph]

I have some mails, which cam across from an outlook import and which show the
part 1.1. effect.

I played around with it, forwarded the mail, edited the mail etc. What it comes
down to is the following difference in the header lines:

The messy imported mail has the following line:

Content-Transfer-Encoding: 8bit

while the ok-Version has:

content-class: urn:content-classes:message
Content-Transfer-Encoding: quoted-printable

Beyond that, for German Umlauts, the non-ok-version has the translated Version
like m=FCssen  ( =FC stands for German Umlaut-u ), while the ok-Version shows a
source with correctly shown Umlauts.

Bottom line is, that part 1.1 is shown as long as the message body is considered
 to be an 8 bit content, while a quoted-printable content is shown as inline
message body. 

Comment 12

[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 199298.

Comment 13

[Mike Cowperthwaite]

Jeff Tsai (if you're still reading this) -- messages created by Mozilla with 
attachments no longer show *anything* for the message body in the attachment 
window.  I think this bug can be safely WFM'd.  If I'm mistaken, please reopen.

The issue about "Part 1.1" showing up in mails from Outlook is bug 155537, I 
think.  In that case, the problem is the body part of the message having a blank 
Content-Type.