600499 - Bad Content-Disposition MIME header when filename is too long

Status: RESOLVED DUPLICATE of bug 309566

(MailNews Core :: MIME, defect)

Description

[Ian Eiloart]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_4; en-gb) AppleWebKit/533.18.1 (KHTML, like Gecko) Version/5.0.2 Safari/533.18.5
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4

When sending an attachment with a file name longer than 52 characters, the Content-Disposition filename in the MIME header for that attachment is broken. It appears like this when 53 characters, for example:

Content-Disposition: attachment;
 filename*0="Faculty List for Heads of School attachment12345 [details].log"

The full MIME header for this attachment looks like this:
Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0";
 name="Faculty List for Heads of School attachment123456 [details] [diff] [review]6.log"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="Faculty List for Heads of School attachment123456 [details] [diff] [review]6.log"

And, we can see that the filename is correctly represented in the Content-Type header.

And for longer file names, like this:
Content-Disposition: attachment;
 filename*0="Faculty List for Heads of School attachment to 1234567890.lo";
 filename*1="g"

And so on. The correct representation would look like this:

Content-Disposition: attachment;
 filename="Faculty List for Heads of School attachment1234 [details].log"

Or, like this:

Content-Disposition: attachment;
 filename="Faculty List for Heads of School attachment12345 [details]Faculty List for Heads of School attachment1234 [details].log";

The latter example is from Mulberry, and no wrapping occurs in the file name.


Reproducible: Always

Steps to Reproduce:
1. Create a file with a file name longer than 52 characters
2. Attach it to a message in Thunderbird.
3. Send the message, and examine the raw content (for example, in Mulberry MUA).

Actual Results:  
The filename in the Content-Disposition MIME header for the attachment is incorrectly represented, like this for example:


Content-Disposition: attachment;
 filename*0="Faculty List for Heads of School attachment to 1234567890.lo";
 filename*1="g"


Expected Results:  
The filename in the Content-Disposition MIME header for the attachment is correctly represented, like this for example:


Content-Disposition: attachment;
 filename="Faculty List for Heads of School attachment12345 [details]Faculty List for Heads of School attachment1234 [details].log";


The problem is serious, because Mailman (2.1.6 and earlier) reacts badly when it sees this error. For lists which permit plain text digests, Mailman can't construct the digest. Until the offending message is removed from the list queue, Mailman won't send any more messages to that list.

I have observed this bug in Thunderbird 2.0.0.23 and 2.0.0.24 for Windows, and reproduced the behaviour in Thunderbird 3.1.4 for Windows, 3.0.1 for OSX and 3.1.4 for OSX.

Comment 1

[WADA:World Anti-bad-Duping Agency]

Same problem as Bug 309566? Read next, please.
> bug 348821
> http://tools.ietf.org/html/rfc2231
>   3. Parameter Value Continuations

Comment 2

[Ludovic Hirlimann [:Usul]]

Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.