User Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20100101 Firefox/7.0.1 Build ID: 20110928224103 Steps to reproduce: 1- I got an message with attachment name contains special czech characters (všb.jpeg) 2 - forward a message Actual results: attachment's name changed to "�" Expected results: atachment's name unchanged. Tested on win, linux. TB version 7 and 10.

(In reply to raal from comment #2) I downloaded your attachment and forwarded it. I didn't get this issue. I can see the attachment name with correct characters both in the sent folder and recipient inbox. I viewed the source of my forwarded e-mail, this is the part where the attachment name is mentioned: Content-Type: image/jpeg; name="=?ISO-8859-2?Q?v=B9b=2Ejpeg?=" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*=iso-8859-2''%76%B9%62%2E%6A%70%65%67 Maybe my configuration allows correct name of attachment to be displayed.

Hello Mashem, the same in my TB - when I open .eml message from hard disk and forward this message, then see no problem. Problem is only when I get message to inbox. I sent to you testing message, please try to forward.

(In reply to raal from comment #4) > Problem is only when I get message to inbox. What is your Folder Properties/General, Default Character Encoding setting? Is "Apply deault to all message ..." checked? How did you open the Forward window? If you open utf-8 mail in message pane(the utf-8 mail is selected at thread pane), and if you execute right-click/Forward of a mail at thread pane without left-click, compose window is opened in utf-8 but binary of original charset is used, then garbled display happens. This is known bug. This is seen at window title(utf-8 is shown because your default character encoding of outgoing message is not utf-8) and at attachment name string of message body in your screen shot. Different issue but same phenomenon is also reported on draft mail to bug 701694. Different charset from original(utf-8) is used in composition window, but conversion from original charset to utf-8 is not done. Similar problem to bug 701694? > Content-Type: image/jpeg; > charset=utf8; > name="=?iso-8859-2?Q?v=B9b=2Ejpeg?=" "charset=utf8; in Content-Type:" may be relevant to "U+FFFD in attachment pane of forward window" in your case.

charset parameter in Content-Type: of attachment part was cause of problem. How Forward is executed was irrelevant. Simplest Forward button of mail is sufficient. (1) Forward => Composition window = utf-8, Attachment's name : in message body : v¹b.txt at attachment box : � > Content-Type: text/plain; charset=utf-8; name="=?iso-8859-2?Q?v=B9b=2Etxt?=" > Content-Disposition: inline; filename="=?iso-8859-2?Q?v=B9b=2Etxt?=" (2) Forward => Composition window = koi8-r, Attachment's name : v╧b.txt > Content-Type: text/plain; charset=koi8-r; name="=?iso-8859-2?Q?v=B9b=2Etxt?=" > Content-Disposition: inline; filename="=?iso-8859-2?Q?v=B9b=2Etxt?=" (3) Forward => Composition window = iso-8859-2, Attachment's name : všb.txt > Content-Type: text/plain; name="=?iso-8859-2?Q?v=B9b=2Etxt?=" > Content-Disposition: inline; filename="=?iso-8859-2?Q?v=B9b=2Etxt?=" Note: Any "αβγ" in attachment part is written in utf-8, so it's shown as garbage when koi8-r case. Perhaps charset of last part is used in composition window opened by Forward, without proper character conversion from original charset, for both message body data and filename parameter in Content-Disposition. So, if the forward mail is sent, next occurs; (1) Some texts in message body is corrupted, and in worst case, almost all message data is corrupted if origial charset or wrongly used charset is special charset like iso-2022-jp. (2) Filename of attachment is altered or garbled.

What is your Folder Properties/General, Default Character Encoding setting? Central european (iso-8859-2) Is "Apply deault to all message ..." checked? No How did you open the Forward window? Button Forward or right-click on message/forward

When Reply, problem of "charset of attachment part is used by composition window" ocurrs too, but problem of "message data is not converted to used charset" doesn't occur. So, "garbled atachment name string in message body" is not observed if Reply.

Regression. tested with old TB 2.0.0.4 - forwarding of "test forwarding message.eml" is correct, attachment name is všb.jpeg

Setting dependecy to bug 716983 for ease of tracking and analysis.

Root cause of "charset is pcked up from last attachment" was resolved by bug 1026989 at last. Some valuable bug reports from users were hidden/lost/ignored by "duping to bug 716983, then duping bug 716983 to other bug". Unfortunately, or fotunately, only "garbled display in Forward Inline case" was resolved by unknown bug while the other bug was being processed, so nothing was resolved by the other bug. Duping this bug to bug 1026989, for ease of tracking, search, understanding current status of problem.

FYI. Patch of bug 1026989, one liner patch, was proposed in the other bug to which bug 716983(and bug 701818 too) had been duped to. The patch was dig out from the other bug by bug 1026989, and long lived "charset is picked up from last attachment" issue has been resolved by bug 1026989. Why such "digging out hidden important patch from the other bug" should be needed in B.M.O?