328266 - Bad "Content-Disposition" or "filename" when attaching files to e-mails

Status: RESOLVED DUPLICATE of bug 65794

(SeaMonkey :: General, defect)

Description

[r.navalinskas]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060222 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060222 SeaMonkey/1.5a

When file is attached to an email, Content-Disposition must be set to "attachment", now it is set to "inline"

Reproducible: Always

Steps to Reproduce:
1. create new message
2. attache a file, let's say some .zip file
3. send a message to anybody, e.g. yourself

Actual Results:  
Attached file is with these parameters:

--------------080707090809030404050002
Content-Type: application/zip;
 name="Reports.zip"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="Reports.zip"

Expected Results:  
Attached files must have these parameters:

--------------080707090809030404050002
Content-Type: application/zip;
 name="Reports.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="Reports.zip"

Comment 1

[zug_treno]

Duplicate of/related to bug 151256 -> Core bug 66915?

Comment 2

[Andrew Schultz]

*** This bug has been marked as a duplicate of 66915 ***

Comment 3

[r.navalinskas]

Can anyone comment on this problem, when it will be fixed ? It is really major problem:

1. If I send attachment to LotusNotes user, he/she sees "awkward" name of the file, such as "aaghfsd.zip" - just because, it is not an "attachment"

2. I used Mozilla/Seamonkey in order to demonstrate to technlogical partners from banking organizations, etc, about how "correctly" email must be formed - I can't anymore

Comment 4

[Andrew Schultz]

Um, why did you reopen this bug?  Is it not a dupe of bug 66915?

Comment 5

[r.navalinskas]

I reopened it because I consider it to be "major" problem, and "bug 66915" treats it only as enhancement. The problematic behaviour exists only for some time, so that means, that was a bug/mistake made and it must be fixed, it is not "new feature".

And for the reasons I described, I consider it as "major".

Comment 6

[Mike Cowperthwaite]

Note that there is a workaround for this problem at the dupe:
bug 65794 comment 11 & 19.

*** This bug has been marked as a duplicate of 65794 ***

Comment 7

[r.navalinskas]

Ok, maybe problem was not in "Content-Disposition", although I'm glad there is workaround about "attachment" thing.

I changes "summary" of this problem, severity to "normal" (maybe I should have left it "major") and I reopen bug as "different" bug:

1. I attach MS Word file (on WindowsXP Pro). 
2. filename contains non-latin characters
3. for some strange reason in "Content-Disposition" there are 2 filenames: filename*0* and filename*1* instead of just 1:

--------------010600090601030002010809
Content-Type: application/msword;
 name*=windows-1257''Tarifin%EBs%20lentel%EBs_060329%20-%20pataisymui.doc
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename*0*=windows-1257''Tarifin%EBs%20lentel%EBs_060329%20-%20pataisymui;
 filename*1*=.doc


Maybe that is the problem why other mailers (such as LotusNotes) see attachment with awkward names, such as "attu1bhs.doc"

And if I am not mistaken, double quotas must surround filename:

Content-Disposition: attachment; filename="MyFileName.doc"

Comment 8

[Mike Cowperthwaite]

This bug, as originally reported, is a dupe.  Do not reopen this bug.  Further, do not change the summary of bugs to some entirely different problem.  Open a second bug, if need be.  In this case, you don't need to open another bug because one is already open for the "problem" you are reporting in comment 7.

In this case, Mozilla is in fact *better* following specs -- specifically, RFC2331 -- than the Microsoft products.  Bug 309566 is about the problem of dealing with Outlook.  Additionally, there are two RFEs open to improve 
handling of this: bug 323388 and bug 323390.

*** This bug has been marked as a duplicate of 65794 ***