User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8 Build Identifier: 2.0.0.6 A č in the recipient list cuts off recipient name. Reproducible: Always Steps to Reproduce: 1. Add an address book entry like Hans Wuček (name just invented by myself). 2. Compose an e-mail to him. Actual Results: In the message window front end in your outbox, his name is Hans Wuc Expected Results: It should be Hans Wuček

WFM on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007103004 Thunderbird/3.0a1pre ID:2007103004

Testing found that the character encoding may be the issue. -on tb 2.0.0.14 + 3.0a2pre (2008071003) same: When sending alert recommends utf8 instead of western etc stating that will lead to weird chars. *send/recieve in utf8 does go normal !!*send/recieve in western does present Do Show "Hans Wuc" in header while Hans Wuc(ek in thread in your case may be different, but please check the options/character encoding in the compose window. hm. So it is a matter of charset, default or not ...

same as bug 415368, umlauts there ..

and maybe dup 224391 or related what intrigues me is the different wrong representation of the name in header and thread and that other adds in to: where not shown, even not in edit as new, cutting all after the character in discussion. They are present whatsoever in source and show in fwd inline : *fwd inline:(replaced some with "bogus" and "xxx") Subject: test hans Hans Wuc(ek Date: Thu, 10 Jul 2008 20:24:48 +0300 From: Ovidiu Grigorescu <serdan.ro@gmail.com> To: hans Wuc(ek <Hans.Wuček@bogus.ro>, Ovidiu Grigorescu <office@bogus.ro>, xxxxxxx@gmail.com, bogus.ovidiu@gmail.com *view source (replaced some with "bogus" and "xxx") To: =?windows-1252?Q?hans_Wuc=28ek?= <Hans.WuÄek@bogus.ro>, Ovidiu Grigorescu <office@bogus.ro>, xxxxxxx@gmail.com, bogus.ovidiu@gmail.com Subject: test hans Hans =?windows-1252?Q?Wuc=28ek?=

This problem was solved by fix for bug 410333 - will appear in TB 3.0

(In reply to comment #5) > This problem was solved by fix for bug 410333 - will appear in TB 3.0 no, it doesn't unless I am mistaken. bug 410333 is about the message body, isn't it? This bug is about mail headers.

xref bug 318705, possible dupe. It's important to know exactly what characters are in use in the mail, not just how they're displayed. Save the problem email as a .EML file and attach to this bug; pasting text into a response is not reliable. Note that raw non-ASCII characters are ILLEGAL in RFC2822 headers. Ovidiu noted elsewhere that bug 415368 is also similar to this, and that bug notes a similarity to bug 508745.

From mozilla.dev.apps.thunderbird with "Local chars in TB3 header 'to' -- bug ??" I was pointed to this bug. Here some comments after checking the message source, TB/AB and RFC5322: A mail I received has this 'source' items: > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: 8bit > Subject: IT-Mittelstand auf Erholungskurs ... Nokia World 09 ... > To: Günter XXXXX <neandr@gmx.de> The interesting situation is this: - the normal header shows 'GünterXXXXX' (note: no space! like with source) - tooltiptext is only 'G' (truncated before German Umlaut 'ü') - consequently the addressbook entry can't be edited - but (from earlier testing ??) I have an TB/AB entry in 'Collected Addresses' with 'GünterXXXX' and email 'G', deleting that AB entry the message header changes to 'G' only. Basically the received mail has a 'To' item including a non-ASCII char which isn't allowed with RFC definition. So it's not a TB fault not to show that 'local-part' of the mail-address. But somehow TB stores that address to the TB/AB and the next received message will be shown with the (wrong/non-Ascii chars) 'local-part' of the To-address in the message header. Not sure if this bug is the right place to follow up and how the other mentioned bugs relates to this. Seems TB header and TB/AB collecting address needs a further review.

(In reply to comment #0) > Build Identifier: 2.0.0.6 >(snip) > Steps to Reproduce: > 1. Add an address book entry like Hans Wuček (name just invented by myself). > 2. Compose an e-mail to him. > Actual Results: > In the message window front end in your outbox, his name is Hans Wuc It sounds "no dialog to send in UTF-8 or not". This is probably known/already-fixed bug of next. (I can't recall bag number) (Problem-1) If character of out of composing charset is in mail header only, (From:. To:, CC:, .... Probably problem occurred when "Subject: only" case.) dialog of "Send in UTF-8, or Send Anyway" is not diaplyed. Since Tb's action is same as "Send Anyway", header data is corrupted. Bug 318705 pointed in Comment #7 is a variation of phenomena of this (Problem-1). Tb 2.0.0.23 displayed dialog of "Send in UTF-8, or Send Anyway, or Cancel" in next case. Composing charset = iso-8859-1 From: filed = us-ascii only To: filed = Hans Wuček / Hans.Wuček@bogus.ro in addres book Subject: filed = us-ascii only Body text = us-ascii only If "Send Anyway" is replied, Tb 2.0.0.23 generated next header(same as one on comment #4). > To: =?windows-1252?Q?Hans_Wuc=28ek?= <Hans.WuÄek@bogus.ro> (Problem-2) For some peoples, the dialog is annoying, because dialog is frequently displayed if default composing character is not set UTF-8(or appropriate one) even though he receives/replies/forwards mail with characters which is not contained in default composing character he chose. So, "no dialog of Send in UTF-8 or Send Anyway" was requested, and is already landed on Tb trunk, and mail is always sent in UTF-8 without dialog in comment #0 case. It's Bug 410333 pointed in Comment #5. To Florian Effenberger(bug opener): Did you replied "Send Anyway" to dialog? If yes, this bug is INVALID. Dialog was not displayed? If so, it's probably above (Problem-1). Can you produce your problem with newest Tb 2.0.0.23?

(In reply to comment #8) > > Content-Type: text/plain; charset=iso-8859-1 > > To: Günter XXXXX <neandr@gmx.de> This bug is for problem in mail composition by Tb. Your case is problem in display of received mail which is generated by other than Tb. Günter, don't add comment for irrelevant problem, please. Your case is probably Bug 468351(already fixed by Tb3.0b4), because raw binary of non 7bits-us-ascii is seen in Subject: and you use Tb 3. Check with latest nightly before report problem, please.

@9 and @10 comments. > This bug is for problem in mail composition by Tb. Your case is problem in > display of received mail which is generated by other than Tb. Günter, > don't add comment for irrelevant problem, please. Also you are right -- the "cuts off recipient name" has been solved with the other bug 468351 -- your comment sounds a bit rude to me .. also because the deeper problem with the local characters seems to be same here and there.. but maybe you will have a better day the next days .. anyway thanks for pointing to the 'solved' problem description. By the way I worte: > Not sure if this bug is the right place to follow up and how the other > mentioned bugs relates to this. Seems TB header and TB/AB collecting > address needs a further review. The only point is: regardless where local characters are use with the message addressing, we should have them displayed as correct as possible (see also Bug 508745 - 'From' corrupted and 'Reply to' omitted when address contains umlaut) Thanks.

According to comment #11 this issue is solved by bug #468351. Feel free to reopen it if I'm wrong.