548730 - "mail.strictly_mime.parm_folding" function of Thunderbird 3 does not work correctly

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[TKN]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Build Identifier: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.8)  Gecko/20100216 Thunderbird/3.0.2

"mail.strictly_mime.parm_folding" function of Thunderbird 3
does not work correctly.

Please confirm the following source of mail data in "Actual Results".

I specify "0" for "mail.strictly_mime.parm_folding" of both tb2 and tb3.

In my recognition, value of param folding table is as follows;
  name encoding  filename encoding  RFC 2047 encoded values are split?
0  RFC 2047      RFC 2047           N
1  RFC 2047      RFC 2047           Y
2  RFC 2231      RFC 2231           N/A
3  RFC 2047      RFC 2231           N
4  RFC 2047      RFC 2231           Y


Reproducible: Always

Steps to Reproduce:
Specify "0" for "mail.strictly_mime.parm_folding"
Actual Results:  
In tb3 case, RFC 2047 encoded values are split as follows;

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv:1.9.1.7)
Gecko/20100111 Thunderbird/3.0.1

This is a multi-part message in MIME format.
--------------030109010506040706080808
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

test

--------------030109010506040706080808
Content-Type: application/msword;
name="=?ISO-2022-JP?B?VGh1bmRlcmJpcmQzXxskQiVGJTklSE1RJUklLSVlJWElcyVIGyhCLnJ0Zg==?="
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename*0*=ISO-2022-JP''%54%68%75%6E%64%65%72%62%69%72%64%33%5F%1B%24%42;
filename*1*=%25%46%25%39%25%48%4D%51%25%49%25%2D%25%65%25%61%25%73%25%48;
filename*2*=%1B%28%42%2E%72%74%66

Expected Results:  
In tb2 case, RFC 2047 encoded values are not split as follows;
############################Thunderbird/2.0.0.23###########################

User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)

This is a multi-part message in MIME format.
--------------010208010105070908050704
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

test

--------------010208010105070908050704
Content-Type: application/msword;
name="=?ISO-2022-JP?B?VGh1bmRlcmJpcmQzXxskQiVGJTklSE1RJUklLSVlJWElcyVIGyhCLnJ0Zg==?="
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="=?ISO-2022-JP?B?VGh1bmRlcmJpcmQzXxskQiVGJTklSE1RJUklLSVlJWElcyVIGyhCLnJ0Zg==?="

Comment 1

[Masatoshi Kimura [:emk]]

In Tb3, "mail.strictly_mime.parm_folding" does no longer affect Content-Disposition header.

Comment 2

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #0)
> does not work correctly.
> (snip)

What is your base of "not correctly"?

AFAIK, rough history is:
(1) Bug 193439 : Implemented RFC2231 encoding for filename.
                 mail.strictly_mime.parm_folding=2 was added.
(2) Bug 309566 : Modified for not-rfc2231-compliant mail clients.
                 mail.strictly_mime.parm_folding=3/4 were added.
(3) After that, Bug 486682 was found.
    So, 3/4 were merged to 0/1, and meaning/behaviour of 0/1 were changed.

(current meaning)
> http://mxr.mozilla.org/comm-central/source/mailnews/mailnews.js#191
> 191 // 0/1 (name param is encoded in a legacy way), 2(RFC 2231 only)
> 192 // 0 the name param is never separated to multiple lines.
> 193 pref("mail.strictly_mime.parm_folding",     1);

> In my recognition, value of param folding table is as follows;
>  name encoding  filename encoding  RFC 2047 encoded values are split?
> 0  RFC 2047      RFC 2047           N
> 1  RFC 2047      RFC 2047           Y
> 2  RFC 2231      RFC 2231           N/A
> 3  RFC 2047      RFC 2231           N
> 4  RFC 2047      RFC 2231           Y

Based on test results with Tb 2? If so, see patch of Bug 486682, please.
> diff --git a/mailnews/mailnews.js b/mailnews/mailnews.js
> -// 0/1 (RFC 2047), 2(RFC 2231), 3/4(RFC 2231, but name param is encoded by RFC 2047)
> -// 0/3 the name param is never separated to multiple lines.
> -pref("mail.strictly_mime.parm_folding",     3);
> +// 0/1 (name param is encoded in a legacy way), 2(RFC 2231 only)
> +// 0 the name param is never separated to multiple lines.
> +pref("mail.strictly_mime.parm_folding",     1);
3/4 were merged to 0/1, and meaning of 0/1 was changed.

Comment 3

[TKN]

(In reply to comment #1)
> In Tb3, "mail.strictly_mime.parm_folding" does no longer affect
> Content-Disposition header.

I can have a proper understanding of "mail.strictly_mime.parm_folding" in tb3.
Thank you.

Comment 4

[TKN]

(In reply to comment #2)
I asked it about "mail.strictly_mime.parm_folding" of tb3 on a premise that tb2 was right.
I can have a proper understanding of "mail.strictly_mime.parm_folding" in tb3.
Thank you.

Comment 5

[he110w0r1d1413]

So how to control the behavior of filename header? Anything new setting?