Closed Bug 15577 Opened 21 years ago Closed 21 years ago

Plain text mail attachments come empty

Categories

(MailNews Core :: Backend, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: marina, Assigned: rhp)

Details

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
QA Contact: lchiang → pmock
Marina - is this M10 branch or M11 trunk builds?  I think Kat may have filed
some bugs on this?
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.
Assignee: phil → rhp
Reassign to rhp. Maybe a dup of 15538?
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.
Status: NEW → ASSIGNED
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
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
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
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.