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

RESOLVED DUPLICATE of bug 65794

Status

SeaMonkey
General
RESOLVED DUPLICATE of bug 65794
12 years ago
12 years ago

People

(Reporter: r.navalinskas, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
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

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

Comment 2

12 years ago

*** This bug has been marked as a duplicate of 66915 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 3

12 years ago
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
(Reporter)

Updated

12 years ago
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---

Comment 4

12 years ago
Um, why did you reopen this bug?  Is it not a dupe of bug 66915?
(Reporter)

Comment 5

12 years ago
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

12 years ago
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 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → DUPLICATE
(Reporter)

Comment 7

12 years ago
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"
Severity: major → normal
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Summary: Bad "Content-Disposition" when attaching files to e-mails → Bad "Content-Disposition" or "filename" when attaching files to e-mails

Comment 8

12 years ago
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 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.