Last Comment Bug 323318 - [RFC 2231] when the attachment file name is separated, should append semi-colon(';')
: [RFC 2231] when the attachment file name is separated, should append semi-col...
Status: RESOLVED FIXED
Mozilla Japan wants to fix on 1.8 bra...
: fixed1.8.1, intl, verified1.8.0.2
Product: MailNews Core
Classification: Components
Component: Attachments (show other bugs)
: Trunk
: All All
: P1 major with 1 vote (vote)
: mozilla1.8.1
Assigned To: Masayuki Nakano [:masayuki] (Mozilla Japan)
:
:
Mentors:
: 330664 (view as bug list)
Depends on:
Blocks: 193439
  Show dependency treegraph
 
Reported: 2006-01-13 10:12 PST by OBATA Akio
Modified: 2008-07-31 01:21 PDT (History)
8 users (show)
mscott: blocking‑thunderbird2+
dveditz: blocking1.8.0.1-
dveditz: blocking1.8.0.2+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Patch rv1.0 (1.07 KB, patch)
2006-01-13 21:21 PST, Masayuki Nakano [:masayuki] (Mozilla Japan)
jshin1987: review+
mozilla: superreview+
dveditz: approval1.8.0.1-
mscott: approval1.8.0.2+
mscott: approval1.8.1+
Details | Diff | Splinter Review

Description OBATA Akio 2006-01-13 10:12:06 PST
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Build Identifier: Thunderbird 1.5 (Windows/20051201)

In Content-Disposition header, filename prameter is invalid.
regular-parameter is OK, but extended-parameter is no good.
(semicolon is missing)

So, even if using rfc2231-compliant MUA, filename could'nt be recognized correctly.


Reproducible: Always

Steps to Reproduce:
1. Start to write message
2. Attach file whth long, non-ASCII(ex. japanese, ISO-2022-JP) name. 
3. Send message

Actual Results:  
 Content-Disposition: attachment;
  filename*0*=ISO-2022-JP''XXXXXXXXXXXXXX
  filename*1*=ZZZZZZZZZZZZZZZZZZZZZZZZZZZ 


Expected Results:  
 Content-Disposition: attachment;
  filename*0*=ISO-2022-JP''XXXXXXXXXXXXXX;
  filename*1*=ZZZZZZZZZZZZZZZZZZZZZZZZZZZ 


RFC2183 says, all parameter=value in Content-Disposition must be separated with ";".

In rfc2231, section 4.1, example: 
   Content-Type: application/x-stuff
    title*0*=us-ascii'en'This%20is%20even%20more%20
    title*1*=%2A%2A%2Afun%2A%2A%2A%20
    title*2="isn't it!"
This is wrong (author also say).
Comment 1 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-01-13 10:35:45 PST
jshin:

Could you check this?
Comment 2 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-01-13 19:13:07 PST
I don't know this report is correct or is not so, and I don't confirm this, but if this is correct, this should block next release.
Comment 3 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-01-13 20:12:09 PST
I confirmed this bug.
Comment 4 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-01-13 21:21:25 PST
Created attachment 208456 [details] [diff] [review]
Patch rv1.0

This creates following header when I attached "あいうえおあいうえおあいうえおあいうえお.png"

Content-Type: image/png;
 name*0*=ISO-2022-JP''%1B%24B%24%22%24%24%24%26%24%28%24*%24%22%24%24%24%26;
 name*1*=%24%28%24*%24%22%24%24%24%26%24%28%24*%24%22%24%24%24%26%24%28;
 name*2*=%24*%1B%28B.png
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename*0*=ISO-2022-JP''%1B%24B%24%22%24%24%24%26%24%28%24*%24%22%24%24;
 filename*1*=%24%26%24%28%24*%24%22%24%24%24%26%24%28%24*%24%22%24%24%24;
 filename*2*=%26%24%28%24*%1B%28B.png
Comment 5 Jungshik Shin 2006-01-14 14:11:44 PST
Comment on attachment 208456 [details] [diff] [review]
Patch rv1.0

Thanks for the patch. 

asking for sr and a 1.8.1 at the same time because it's a trivial fix but kinda important in making TB fully compliant to the standard. 

I'm not sure which branch (1.8.0.1 or 1.8.0.2) I have to get an approval for to get this patch reflected in the next point release of TB (1.5.1?) It'd be nice if it's also approved for whichever branch it may be.
Comment 6 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-01-14 19:15:33 PST
Comment on attachment 208456 [details] [diff] [review]
Patch rv1.0

Some Japanese MUAs support rfc2231. But some MUAs cannot process current header. It's critical. I think we should fix this in 1.8.0.x too.
Comment 7 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-01-15 08:41:33 PST
Thank you David and Jungshik for your r+sr.

Checked-in to Trunk.

-> FIXED
Comment 8 Daniel Veditz [:dveditz] 2006-01-19 12:05:43 PST
Thunderbird is going to sync up on 1.8.0.2
Comment 9 Daniel Veditz [:dveditz] 2006-01-19 12:06:24 PST
Comment on attachment 208456 [details] [diff] [review]
Patch rv1.0

Moving patch request to 1.8.0.2, too late for 1.8.0.1
Comment 10 Chris Beard 2006-01-19 16:47:40 PST
Just to underline previous comments, this is a significant bug that affects builds for the region and therefore *must* be fixed as soon as possible.  Let's ensure that it gets into the next stability and security update of Thunderbird.
Comment 11 Scott MacGregor 2006-01-20 17:32:39 PST
This was caused by Bug 193439

Until a fix is released, can't users turn that off via the mail.strictly_mime_parm_folding pref?
Comment 12 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-01-20 20:19:04 PST
Yes. But the buggy mode is used by *default setting*. This gives damage for our marketing. In Japan, many light users doesn't change settings in many applications. And this bug makes trouble on *non-Tunderbird MUA*. So, many Tb users might not know this problem is existing. This is the betrayal to our product users.
Comment 13 Scott MacGregor 2006-01-24 09:19:52 PST
Comment on attachment 208456 [details] [diff] [review]
Patch rv1.0

this has been baking long enough on the trunk, I think it's safe to put on the 1.8.1 branch for Thunderbird 2.

I believe the 1.8.0.x tree is still closed for the Firefox release. Once the tree opens (which should be soon) I'll plus this for the branch too.
Comment 14 Scott MacGregor 2006-01-25 11:58:57 PST
I landed this on the 1.8.1 branch for thunderbird 2.
Comment 15 Masayuki Nakano [:masayuki] (Mozilla Japan) 2006-01-25 12:01:10 PST
Oops. Thank you for your check-in.
Comment 16 Scott MacGregor 2006-01-31 11:58:46 PST
Comment on attachment 208456 [details] [diff] [review]
Patch rv1.0

approving.
Comment 17 Scott MacGregor 2006-01-31 12:00:01 PST
i fixed this on the 1.8.0.x branch.
Comment 18 Magnus Melin 2006-03-16 02:36:30 PST
*** Bug 330664 has been marked as a duplicate of this bug. ***
Comment 19 Mike Baikov 2006-06-22 00:32:25 PDT
In Thunderbird 1.5.x change format of attachments:

some old programs (like thebat! 1.4x) don't understand attachments like:

Content-Type: application/msword;
 name*0*=UTF-8''%D0%98%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%86%D0%B8%D1;
 name*1*=%8F%20%D0%BF%D0%BE%20%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B5%20%D1;
 name*2*=%81%20%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%BE%D0;
 name*3*=%B9%20SuperMac.doc
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename*0*=UTF-8''%D0%98%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BA%D1%86%D0%B8;
 filename*1*=%D1%8F%20%D0%BF%D0%BE%20%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%B5;
 filename*2*=%20%D1%81%20%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC;
 filename*3*=%D0%BE%D0%B9%20SuperMac.doc


It understand old (1.0.x thunderbird) format only:

Content-Type: application/msword;
 name="=?KOI8-R?Q?=E9=CE=D3=D4=D2=D5=CB=C3=C9=D1_=D0=CF_=D2=C1=C2=CF=D4=C5_?==?KOI8-R?Q?=D3_=D0=D2=CF=C7=D2=C1=CD=CD=CF=CA_SuperMac=2Edoc?="
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="=?KOI8-R?Q?=E9=CE=D3=D4=D2=D5=CB=C3=C9=D1_=D0=CF_=D2=C1=C2=CF=D4=C5_?==?KOI8-R?Q?=D3_=D0=D2=CF=C7=D2=C1=CD=CD=CF=CA_SuperMac=2Edoc?="


What's to do? How to change new format to old format in fresh thunderbird 1.5.x?
Comment 20 Mike Baikov 2006-06-22 00:34:08 PDT
(In reply to comment #19)
> 
> 
> What's to do? How to change new format to old format in fresh thunderbird
> 1.5.x?
> 

Additional. New format viewing all attachments as messages.wiz files :-(

Note You need to log in before you can comment on or make changes to this bug.