151256 - sending attachments NOT as inline

Status: VERIFIED DUPLICATE of bug 66915

(SeaMonkey :: MailNews: Message Display, defect)

Description

[charles allen]

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

Comment 1

[Ben Bucksch (:BenB)]

this is a dup. there's a bug about a way to choose the content-disposition and
other attachment parameters.

Comment 2

[Robert Wall]

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 ***

Comment 3

[Ben Bucksch (:BenB)]

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

Comment 4

[charles allen]

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

Comment 5

[Olga]

Verified dup