Closed Bug 307594 Opened 19 years ago Closed 19 years ago

a space is inserted into an attached file name which doesn't exist in original

Categories

(MailNews Core :: Attachments, defect)

Product:
MailNews Core
Component:
Attachments
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: aoki, Unassigned)

Details

Attachments

(1 file, 1 obsolete file)

Mail folder file for 6 mails(6 cases), Case-3 is added.
6.77 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.10) Gecko/20050717 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.10) Gecko/20050717 Firefox/1.0.6

When I attach a file whose name has odd numbers of ascii character between
Japanese characters, a space is added after the ascii characters and is saved
with a wrong file name. 




Reproducible: Always

Steps to Reproduce:
1.send a mail with an attached file named 'テスト123テスト.txt'(Japanese and
Latin mixed) by a mailer not Thunderbird.
2.receive the mail by Thunderbird.
3.

Actual Results:  
The file name looks 'テスト123 テスト.txt'. A space is inserted after '3'.

Expected Results:  
The file name should be 'テスト123テスト.txt'. No space after '3'.

The plain text of the mail looks like this.

Content-Type: multipart/mixed; boundary=Multipart_Thu_Sep_08_17_13_27_2005

--Multipart_Thu_Sep_08_17_13_27_2005
Content-Type: text/plain; charset=ISO-2022-JP

This is a test.

--Multipart_Thu_Sep_08_17_13_27_2005
Content-Type: application/octet-stream;
	name="=?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=123
	=?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=.txt"
Content-Disposition: attachment;
	filename="=?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=123
	=?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=.txt"
Content-Transfer-Encoding: base64

g2WDWINnlbaPkYLFgreBQg0K
--Multipart_Thu_Sep_08_17_13_27_2005--

I suspect Thunderbird misunderstands two lined name=/filename= fields.
Reporter, does this still happen in Thunderbird 1.5 beta 1 ?
Yes. It still happens with Thunderbird 1.5 Beta1.
The filename is exactly same as 1.0.6.
RFC 2047, "Appendix - changes since RFC 1522" says ;
 ( http://www.faqs.org/rfcs/rfc2047.html )
> + explicitly state that 'encoded-word's are not valid within a
>   'quoted-string'.
And "..." portion of name="..." or filename="..." seems to be a quoted-string.

Aoki san, are you sure that no RFC violation involved in the mail header
produced by your mailer?
(Sorry but I still can't find description on spliting of name or filename
parameter.)

Is an space also added when multiple line Subject:?
 (no quoted-string when Subject:)
> Subject: =?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=123
>          =?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=.txt

Thank you Wada-san (hope this is correct).

You are right that name or filename parameter values are quoted-string
and it seems they violate RFC 2047 appendix statement. But these are
parameter values and are NOT header fields. I couldn't find a RFC which
explains about parameter value format.

I assume parameter values have different format because in RFC2047 they
say,
   An 'encoded-word' may not be more than 75 characters long, including
   'charset', 'encoding', 'encoded-text', and delimiters.  If it is
   desirable to encode more text than will fit in an 'encoded-word' of
   75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
   be used.
but if you send a file with very long name attached by Thunderbird 1.0.6,
the parameter looks like this:

Content-Type: text/plain;
 name="=?ISO-2022-JP?B?GyRCJUYlOSVIJUYlOSVIJUYlOSVIJUYlOSVIJUYlOSVIJUYlOSVIJUYbKEI=?==?ISO-2022-JP?B?GyRCJTklSCVGJTklSCVGJTklSCVGJTklSCVGJTklSCVGJTklSCVGGyhC?\
==?ISO-2022-JP?B?GyRCJTklSCVGJTklSCVGJTklSCVGJTklSCVGJTklSCVGJTklSCVGGyhC?==?ISO-2022-JP?B?GyRCJTklSBsoQjEyMxskQiVGJTklSBsoQi50eHQ=?="
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="=?ISO-2022-JP?B?GyRCJUYlOSVIJUYlOSVIJUYlOSVIJUYlOSVIJUYlOSVIJUYlOSVIJUYbKEI=?==?ISO-2022-JP?B?GyRCJTklSCVGJTklSCVGJTklSCVGJTklSCVGJTklSCVGJTklSCVGG\
yhC?==?ISO-2022-JP?B?GyRCJTklSCVGJTklSCVGJTklSCVGJTklSCVGJTklSCVGJTklSCVGGyhC?==?ISO-2022-JP?B?GyRCJTklSBsoQjEyMxskQiVGJTklSBsoQi50eHQ=?="

Obviously there are more than 75 characters in a line and 'encoded-words' are
inside 'quoted-string'. Other mailers like Outlook Express send name/filename
parameters with encoded-words inside qutoted-string. (Though they put CRLF
to meet 75 characters a line restriction.) 
(In reply to comment #4)

> multiple 'encoded-word's (separated by CRLF SPACE) may be used.
I also think this statement in RFC2047 is the rule for spliting name/filename
parameter.

> Obviously there are more than 75 characters in a line

"more than 75 characters in a line" of a header is not violation of RFC, I believe.
Next in RFC2047 is for length of "An 'encoded-word'".
> An 'encoded-word' may not be more than 75 characters long

RFC2047 says "(separated by CRLF SPACE)".
Does the "SPACE" in this context include TAB character?
(Your data looks to be CRLF+TAB+splitted data)
Can you test when "CRLF" + single space for continuation + no spaces after it?
>Content-Disposition: attachment;[CRLF]
>[TAB]filename="=?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=123[CRLF]
>[A space]=?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=.txt"[CRLF]
(I guess Thunderbird keeps a space for continuation which should be removed...)
Aoki san, attach the test mail to this bug, please.
 - Save the mail as ".eml" file
 - Attach the ".eml" file to this bug with "text/plain",
   by changing extention to ".txt" or specifiyng "text/plain" explicitely. 
   (Mozilla browser displays "message/rfc822" as an mail.)
   (So "text/plain" is better when viewing mail source to analyze problem.)
I'm sorry but I can't attach the mail as a plain text, because I don't want to
expose a personal information in the mail. I already put attachment part of the
mail in my first report.

I also can't test a multiple line with exactly one space test.
I think RFC 822 states that LWSP-chars immediately after CRLF are ignored. 
(Please refer 3.1.1. LONG HEADER FIELD)
(In reply to comment #7)
> I'm sorry but I can't attach the mail as a plain text, because I don't want to
> expose a personal information in the mail.

Do you mean you have no text editor?
Do you mean you have no experience of using text editor?
Please note that ".eml" file(message/rfc822 data) is only a text data.
No need to expose personal information.

I believe problem reporter is better to provide(I think "ought to" though) test
data or test case for problem recreation by other people, and it is whole mail
data in this bug's case, not describing about key data part only.
Read "Bug writing guideline" again, please.


>Do you mean you have no text editor?
I know how to use emacs or ed.
>Do you mean you have no experience of using text editor?
I've been using text editor for a while.
>Please note that ".eml" file(message/rfc822 data) is only a text data.
Yes. I save the mail and looked into the file and found every mail headers
were included. 
>No need to expose personal information.
Sender's mail address is a personal information.

>I believe problem reporter is better to provide(I think "ought to" though) test
>data or test case for problem recreation by other people, and it is whole mail
>data in this bug's case, not describing about key data part only.
I know.

>Read "Bug writing guideline" again, please.
I know. 

I'm looking forward to getting a reply from whoever can solve this problem
from the MIME body header I provided. If no one was there, that's my fault.
Confirmed with Seamonkey/nightly/latest 2005100105(Win-2K).

(Case-1-A) and (Case-1-A) :
  - A space is added after "123" in file name of "Save As" dialog. 
(Case-2-A) and (Case-2-B) :
  - No space is added in file name of "Save As" dialog. 
=> No relation of continuation character, space or TAB, as RFC says.

Possibly one of nexts.
 - If a line ends with ASCII string,
   (1) Thunderbird forgot to remove "SPACE" for continuation.
   (2) Thunderbird add a space after the ending ASCII string as a word separator.
If (2), I don't know what should be, because I don't know about splitting of
'non-encoded-word's.

(Case-1 : First line ends with '123')
(Case-1-A)
>Content-Disposition: attachment;[CRLF]
>[TAB]filename="=?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=123[CRLF]
>[TAB]=?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=.txt"[CRLF]
(Case-1-B)
>Content-Disposition: attachment;[CRLF]
>[TAB]filename="=?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=123[CRLF]
>[A Space]=?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=.txt"[CRLF]

(Case-2 : Ending '123' is removed from Case-1)
(Case-2-A)
>Content-Disposition: attachment;[CRLF]
>[TAB]filename="=?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=[CRLF]
>[TAB]=?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=.txt"[CRLF]
(Case-2-B)
>Content-Disposition: attachment;[CRLF]
>[TAB]filename="=?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=[CRLF]
>[A Space]=?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=.txt"[CRLF]

Changing Product to Core, because not Thunderbird-only problem.
Status: UNCONFIRMED → NEW
Component: General → MailNews: Attachments
Ever confirmed: true
Product: Thunderbird → Core
Version: unspecified → Trunk
(In reply to comment #9)
> >No need to expose personal information.
> Sender's mail address is a personal information.
You can change mail address, server name, mail text, subject etc. very very
easily by text editor before open to public.
Please don't force other people to create test case for problem re-creation. 
Changing "Assigned To:" to default owner.
Assignee: mscott → nobody
QA Contact: general
All you recommended was to save the mail and attach. I didn't think I could change
the saved file by editor as you could say modified file is useless.
Anyway thank you for creating a test case.

>Please don't force other people to create test case for problem re-creation. 
Please don't blame me for what I have not done. I've never forced it.
Attached file Mail Folder file of 4 mails(4 cases) (obsolete) — 
This is copy of Drafts file, which contains 4 mails for 4 test cases.
(1) Save this file in your mail directry.(Say file name of "Test".)
(2) Restart Thunderbird.
(3) Open "Test" folder.
(4) See file name of "Save As" dialog for the attachment.
(In reply to comment #13)
> I didn't think I could change the saved file by editor
Sorry but I misunderstood that you know mail header format well and you know
about Unix mbox format file, because you reached the header correctly, you could
read RFC for mail, and you pointed the problem properly. 
(and becase of 2 words in your mail address - 'labs' and 'fujitsu', probably at
Nakahara :-)

(Case-3) is added.
Test result :  A space was inserted before '123'.

(Case-3 : '123' at line ends in Case-1 is moved to second line)
(Case-3-A)
>Content-Disposition: attachment;[CRLF]
>[TAB]filename="=?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=[CRLF]
>[TAB]123=?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=.txt"[CRLF]
(Case-3-B)
>Content-Disposition: attachment;[CRLF]
>[TAB]filename="=?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=[CRLF]
>[A Space]123=?ISO-2022-JP?B?GyRCJUYlOSVIGyhC?=.txt"[CRLF]
Attachment #198414 - Attachment is obsolete: true
I guess the problem is caused by adding an word separator.
But I can't say "this is bug" because I don't know whether mail header by
Outlook Express contains RFC vilation or not.
Asano san, can you find RFC description on "mixing of encoded-word & plain ASCII
text" and "splitting of it"?
Sorry, Aoki-san. (Asano-san was opener of other bug...)
I think this is a dupe of bug 193439, which is fixed but not on the 1.0 branch.  
Unfortunately, I can't test this due to bug 285073/bug 274264.
(In reply to comment #19)
> I think this is a dupe of bug 193439
Never be a DUP.
This bug(Bug 307594) is problem in interpretation of RFC 2047 style header
generated by Outlook Express (no problem when RFC 2047 style header generated by
Thunderbird.)
Please note that my test case was generated by text editing based on header
attached to comment #0. 

(In reply to comment #20)
> (In reply to comment #19)
> > I think this is a dupe of bug 193439
> Never be a DUP.

You're right; I failed to read the original report closely enough; I thought the 
attachment was generated in TB.

The problem isn't the RFC2047-ness of the header, it's the fact that the header 
was folded (newline inserted) where there wasn't whitespace.  Per the spec:
  http://rfc.net/rfc2822.html#s2.2.3
the leading whitespace at a header fold is not supposed to be removed (and 
therefore, shouldn't have been inserted).  See bug 189431, which complains about 
a space being removed (in an older version of Moz).

xref bug 240924
(In reply to comment #21)
>I thought the attachment was generated in TB.
It's not your fault. I should have remove "Thunderbird" in X-Mailer header.
Very sorry for my confusing test data.
> The problem isn't the RFC2047-ness of the header, it's the fact that
> the header was folded (newline inserted) where there wasn't whitespace.

Thanks for clear description of this bug.
When I wrote comment #3 and refered to Subject: header, I thought about
similarity to problem of TAB in folded Subject: header, but I couldn't think
same phenomenon because I didn't know about folding/unfolding well.

Mike, should this bug be closed as INVALID?
(In reply to comment #23)
> Mike, should this bug be closed as INVALID?

I don't know.  Moz is following the spec here, and I can't think of of a clean 
way to fix this; you can't assume that the whitespace is invalid.  I guess a 
prompt to the user in the case of a header folded in the middle of the data 
would be OK, if a little confusing, but I doubt the folded-ness of the header is 
maintained internally once the message is loaded.

Folded headers have other problems; they can't be properly searched, for 
instance (bug 124641).  I've seen messages submitted where the MIME boundary is 
folded (both with a space-character in the boundary (!) originally, and 
without), causing the message not to be displayed.  Maybe solving those problems 
would provide insight on a better way to approach this one.
Uhm, sounds DelSp=Yes will be required for any header, in addition to DelSp=Yes
for format=flowed... :-)
I think RFC 822 on folding/unfolding should have been "Insert CRLF+WSP(Tab or
space) always/Remove CRLF+WSP always" instead of "Insert CRFL before a
space/Remove CRLF".
If it was, no need of DelSp=Yes for format=flowed and no need of DelSp=Yes for
any header...

Since no RFC violation by Thunderbird as you say(it means RFC violation by
Outlook Express), I think this bug is to be closed as INVALID, although I think
this bug can be kept as "Enhancement" request for torelance even when RFC
violation in received mail.
Mike, what do you think?
Bug 64948 is also an open bug which relates to TAB/Space of folded mail header.
No response for one month by bug opener on the problem since saying "I'm looking forward to getting a reply from whoever can solve this problem" in comment #9...
Aoki san, is it "Fujitsu way"? Or "Lab only way in Fujitsu"? 

I suggest you to close this bug as INVALID.
I've been waiting.
I'd like to close this bug as INVALID. Thank you.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: