501872 - attached file name in Japanese from Thunderbird couldn't be decoded correctly by OSX Mail

Status: RESOLVED INVALID

(Thunderbird :: Message Compose Window, defect)

Description

[bugzilla]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; ja-JP-mac; rv:1.9.0.11) Gecko/2009060214 Firefox/3.0.11
Build Identifier: 2.0.0.22 (20090605)

when sending mail with attached file from Thunderbird, if the file name containing Japanese characters (double byte), Apple's OSX Mail often failed to retrieve correct file name. Very short name (less than 5 double byte characters) is OK, but longer one would fail.


Reproducible: Always

Steps to Reproduce:
1.create (any type of) file with name "０１２３４５６７８９０１２３４５６７８９０.rtf". any file name is OK, but should be longer than 6 double byte characters.
2.create new mail message with the file above attached.
3.send it to some mail account.
4.receive the mail by Apple's Mail (version 3.6 (935/935.3), but all versions will get the same result, as far as I know)
5.check the attached file's file name.

Actual Results:  
０１２３４５6#7#8#9#0#1#2#3#4#5#6#7#8#9#0.rtf

Expected Results:  
０１２３４５６７８９０１２３４５６７８９０.rtf

thunderbird encode attached file name to

 filename*0*=ISO-2022-JP''%1B%24%42%23%30%23%31%23%32%23%33%23%34%23%35%23;
 filename*1*=%36%23%37%23%38%23%39%23%30%23%31%23%32%23%33%23%34%23%35%23;
 filename*2*=%36%23%37%23%38%23%39%23%30%1B%28%42%2E%72%74%66

while ISO-2022-JP described in RFC2237, 1554, 1468 clearly requires "double-byte-seq" (%1B%24%42) for each lines.

other major mail softwares (MS Outlook 12.0, Windows Eudora Version 6.2J rev4.2) doesn't have this problem.

Comment 1

[Masatoshi Kimura [:emk]]

(In reply to comment #0)
> while ISO-2022-JP described in RFC2237, 1554, 1468 clearly requires
> "double-byte-seq" (%1B%24%42) for each lines.
All of them don't consider the RFC2231-folded parameter. According to RFC 1468bis (which unfortunately did not become RFC for some unknown reason):
http://tools.ietf.org/html/draft-yamamoto-charset-iso-2022-jp-02
> Both "extended-value" and "extended-other-values" need not to be
> self-composite since they are to be concatenated first when
> received.  That is, they can contain any portion of ISO-2022-JP
> string which may or may not end with ASCII.
So I believe this is Mail.app's fault.
> other major mail softwares (MS Outlook 12.0, Windows Eudora Version 6.2J
> rev4.2) doesn't have this problem.
They don't use RFC2231 param folding.

Comment 2

[bugzilla]

Refering RFC2237, 1554, and 1468 is misleading. sorry.

I personally agree that RFC2231 folded parameter should be treated "concatenate all, then decode" manner. But because of it is a compatibility issue between two softwares, saying "the other side should work on it since it is their fault" would not improve the situation, and result is not good for both side.

 (and draft-yamamoto-charset-iso-2022-jp-02 is not RFC, we cannot use it as a reason "why you should do it". sigh...)

I appreciate someone confirm the situation and think whether Thunderbird side would do something on the issue, even if it is Apple's fault.

Comment 3

[Wayne Mery (:wsmwk)]

(In reply to bugzilla from comment #2)
> Refering RFC2237, 1554, and 1468 is misleading. sorry.
> 
> I personally agree that RFC2231 folded parameter should be treated
> "concatenate all, then decode" manner. But because of it is a compatibility
> issue between two softwares, saying "the other side should work on it since
> it is their fault" would not improve the situation, and result is not good
> for both side.
> 
>  (and draft-yamamoto-charset-iso-2022-jp-02 is not RFC, we cannot use it as
> a reason "why you should do it". sigh...)
> 
> I appreciate someone confirm the situation and think whether Thunderbird
> side would do something on the issue, even if it is Apple's fault.

Comment 4

[Wayne Mery (:wsmwk)]

Does it still reproduce?

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to bugzilla from comment #2)

....
I appreciate someone confirm the situation and think whether Thunderbird
side would do something on the issue, even if it is Apple's fault.

Jorg may know something about this, or know someone who knows something :)

(reporter's BMO account is disabled)

Comment 6

[Jorg K (CEST = GMT+2)]

Not relevant any more, we always use UTF-8 now:
https://searchfox.org/comm-central/search?q=LegacyParmFolding&case=false&regexp=false&path=
Implemented in bug 1532668.

Not sure how to best close it. Had it been filed today, it would be invalid. Open to better suggestions.