15577 - Plain text mail attachments come empty

Status: VERIFIED FIXED

(MailNews Core :: Backend, defect, P3)

Description

[marina]

Sent from 5.0 plain text attachments are coming with an empty body.
Steps to reproduce:
-open new mail;
-click attach icon and attach local file(plain text);
-send it and get it;
//note: even though the attachment is mentionned you do not see one, body is
blank

Comment 1

[lchiang]

Marina - is this M10 branch or M11 trunk builds?  I think Kat may have filed
some bugs on this?

Comment 2

[Katsuhiko Momoi]

This problem is observed with 10/3/99 Win32 M10 candidate build.
I don't think I have filed any similar bug on this problem. This
seems like something which should go to rhp.

Actually the problem is that when 5.0 sends out plain text attachment,
it creates the following type of headers for the multipart attachment.

----
Content-Type: multipart/mixed;
 boundary="------------020908070601040906050707"

This is a multi-part message in MIME format.
--------------020908070601040906050707
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

plain text NS home page

-- This message was sent by Messenger 5.0
--------------020908070601040906050707
Content-Type: application/octet-stream;
 name="home_netscape_com.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="home_netscape_com.txt"
...
...

------------------------------------------

Note the "application/octet-stream" which prevents 5.0 from showing
this inline. It seems that we don't have a way to display this type
of attachment in 5.0 right now even though the attachment icon is
visible and shows that there is an attachment.

In contrast, if we send the same .txt file with 4.7, we get the following:

--------------------------------
.....
.....
--------------8975A9AB49880AE2ABFFC25A
Content-Type: text/plain; charset=iso-8859-1;
 name="home_netscape_com.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
 filename="home_netscape_com.txt"
.....
.....
--------------------------------

So we should do probably 2 things:

1. Generate the headers like 4.7 as we send out plain text attachments,
   not "application/octet stream".
2. Have the attachment link be active and do something like prompt
    to save when this type of headers are present. Currently the
    attachment link does nothing.

Note that "Save attachment" button does work and you can save such
files.

Comment 3

[Phil Peterson]

Reassign to rhp. Maybe a dup of 15538?

Comment 4

[Katsuhiko Momoi]

No, this is not related or duplicate of Bug 15538 in which
no mail goes out and the app hangs if there is HTML attachment.
This one goes out but with inappropriate headers for
the multipart.

Comment 5

[rhp (gone)]

I'd love to know what the heck is changing around here to make stuff that
worked 6 weeks ago before my sabbatical started all of the sudden break.
I'll look into this after I look at the other 50 things that also don't seem to
work anymore....

Boy am I glad I came back...grrrr....

- rhp

Comment 6

[rhp (gone)]

I just checked in a fix for a problem with Plain text mail compose and I've
tested several text attachments and they are all working for me.

- rhp

Comment 7

[marina]

it is not empty any more but has an i18n problem described in # 15766. This bug
was entered for the empty body and i guess i can mark it verified. The other
problem has already a bug report so will be taking care of. Verifying with
1999-10-13-M11 build