Mozilla currently creates attachments of type application/octet-stream regardless of the settings in Internet Config or Mozilla preferences. Mozilla should set the proper MIME type of an outgoing attachment by matching its Mac file type to a MIME type via Internet Config. See bug 5721.

I found out some more after looking at my sent mail: As late as 20010129 Mozilla assigned correct MIME types (e.g. application/pdf) to attachments in outgoing messages. Sometime between then and 20010208 Mac Mozilla started using appledouble on outgoing attachments. The attached file within the appledouble wrapper is set to application/octet-stream even for known file types. This is a pretty serious problem for Mac users sending files to users on non-Mac platforms or to users of clients that don't support appledouble. Steps to reproduce (tried with 2001022808): Mail a file attachment to yourself of a known file type (e.g. PDF, which should be application/pdf). Open the message from your Inbox and select View -> Message Source. Expected: Content-Type of attachment should be the file's correct MIME type (e.g. application/pdf) Actual: Content-Type of attachment is application/octet-stream See also bug 70218, "ability to turn off appledouble in outgoing attachments"

This worked in Mac Mozilla 0.7 (before Mozilla did appledouble encoding).

that's a known issue that we still need to finish to implement. Thank for the remaining and filling this bug. Nominating nsbeta1

marking nsbeta1+ and moving to mozilla0.9

I have a fix for that, patches coming soon...

a comment in the second patch says "hust" when it means "just". Also, you should check for a null _retval (i.e., NS_ENSURE_ARG(_retval) in the first patch. If you make those changes, sr=bienvenu

Fixed and checked in

Using builds 2001-05-02 on mac os8.6, when I send a msg with an attached .pdf file the source shows it's Content type as application/pdf. Note: I wanted to see the problem to verify I tested it correctly, so I went back to 6.01 and sent a .pdf attachment and that showed the correct Content type. Since the bug was logged on 2-28 I went back to a 2-15 build sent a .pdf and sure enough the source code showed as: Content-Type: application/octet-stream; name="ReadMe.pdf" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="ReadMe.pdf" I will verfiy this as fixed based on the product is correct with the steps on 2-28. If there is something else I should have done to verify this please let me know.