Using mozilla 1.0 mailnews, when I SEND attachments they always seem to show up inline. I expect them to NOT be inline by default! Possibly you could have a limited set of exceptions such as file type GIF, JPEG, and other images. But I would argue against even that. I think all attachments should not be inline by default. The problem is when I send a large attachment such as a TEX file it shows up in the body of the message of my recipient. That is not what I want. I think most users would agree. Attachments should NOT be inline by default. Some popular email applications (Eudora for one) do not give an option to save an inline attachment which happens to be a text file. My TEX files fall into that category, as would RTF and many others. When they get this message, they have to cut and paste the relevant part of the message body into another file. Big hassle for them. Even worse, I can find no GUI way to override this behavior. Am I missing something? Thanks to parish_AT_ntlworld.com on in the mozilla newsgroups I found the setting to add to prefs.js to make attchments be sent NOT inline. That is: user_pref("mail.content_disposition_type", 1); It is going to be a pain for me to modify all my users' prefs.js file to include this special setting. Before you mark this as a duplicate of bug #55657, that bug is talking about disabling the display of inline attachments for receiving mail. I'm trying to send email without inline attachments. Finally, you may need to know about my test case: User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1a) Gecko/20020606
this is a dup. there's a bug about a way to choose the content-disposition and other attachment parameters.
I've marked this as a duplicate of bug 66915(UI for changing content-disposition of outgoing attachments), you may also be interested in bug 65794(Some attachments get Content-Disposition: inline (incorrect)). *** This bug has been marked as a duplicate of 66915 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
> Some popular email applications (Eudora for one) do not give an option to save > an inline attachment which happens to be a text file. That's a bug in Eudora. Qualcomm blames this on Mozilla, and so do its users, but IMO it's wrong. If we send as normal attachment, there is no way in other client to view the msg inline. Sending as inline attachment is (or should be) a way to make the file both viewable inline and savable. IMO.
>Qualcomm blames this on Mozilla, and so do its users, I think most users expect attachments to NOT be inline in the first place IMO. It is the unusual inability to send a "normal" attachment by Mozilla that shows up this problem in Eudora and other mail clients. If mozilla sent a "normal" attachment there would be no problem. >If we send as normal attachment, there is no way in other client to view the msg inline. Yes, and that's the way it's supposed to be IMO. The other client can always view the message, just not the attachment. 99% of the attachments I send or receive I do NOT want to view in my mail client. >Sending as inline attachment is (or should be) a way to make the file both >viewable inline and savable. IMO. Well, that's your opinion. But in the real world, it isn't. Besides, even if I could save an inline attachment in Eudora, I don't want to see them inline anyway! Having HTML or MS Word .DOC attachments automatically open can be a security problem as well. My point: Sending "normal" attachments should be the default behaviour out of the box. Failing that, there should be a way in the GUI to send a "normal" attachment.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.