User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0 Build ID: 20110615151330 Steps to reproduce: I opened my spam folder. I saw a mail, which has a name in the "From"-column, that I know (I also have an address book entry to this name, but without an eMail address). This name was not shown in the from-field of the preview. The name also doesn't occur in the message source. Actual results: There is a name shown in the "From"-column, which is not part of the source. Expected results: "From" of message list and message preview should be the same. No values should appear that aren't part of the source. As this a spam mail, some users give more credibility, if they "know" the sender...

Does rebuilding the index for the folder that contains the email helps ?

No, it doesn't.

I'm guessing this has to do with the fact that the email address is non-ASCII and the display name lookup from bug 243631 is barfing on that, but I'm not totally sure.

(In reply to comment #4) > I'm guessing this has to do with the fact that the email address is > non-ASCII and the display name lookup from bug 243631 is barfing on that, > but I'm not totally sure. I have the same problem in some newsgroups and in all cases the email adresses in the From column contains non-ASCII characters.

I just noticed three things: 1. You can simply find this kind of mail by sorting by "From", because the mails get really sorted by the alias in the Source (in my example "Dr. Friedelinde.Friederike", so it will appear at "D") but as stated before in the overview you see the entry of your address book. So these eMails seem to be sorted in the wrong way. 2. Today the exact mail I mentioned before, has a different "From", also from my address book. 3. Both entries of the address book are entries without an email address. Perhaps this helps, perhaps it's just coincidence.

Bug confirmed when an user with domain @Fjørndættehotmail.com (a mangled version of adress obfucation was seen by several thunderbird5-users with a "faked" name taken from their adressbook. When the sender removed the non-ascii characters, to @Fjrndttehotmail.com, the sender name appeared correctly. See for instance Message-ID: <4e30703b$0$311$14726298@news.sunsite.dk> from dk.edb.internet.software.mail+news where thunderbird5 does not show my name as sender.

If you uncheck "Show only display name for people in my address book" the right sender name is shown. You find it here: Tools > Options > Advanced > click the Read and display tab. But still this must be a bug.

Confirming this, since I see it too. It appears to pick up the first contact in the address book that matches the substring before the first Unicode character, e.g. Bärb@example.com would use the display name from Bob@nowhere.com in the address book.

WADA, this bug and bug 672966 aren't actually dependent on one another (though they're both the result of the same change). This is an actual bug, in that we don't handle Unicode properly when looking for a contact in the address book. Bug 672966 is just an issue with user confusion, which can hopefully be helped with some documentation.

(In reply to Jim Porter (:squib) from comment #10) > It appears to pick up the first contact > in the address book that matches the substring before the first Unicode > character I cannot see this connection here. It is always the same contact from the address book. But in my case the from header contains no email address, but only a name with a non-ASCII character. I made some tests: »From: Big Bad Spammer« → TB shows “Big Bad Spammer” »From: Big Bäd Spammer« → TB shows contact form the address book »From: Big Bäd Spammer a@b.invalid« → TB shows contact from the address book »From: Big Bäd Spammer <a@b.invalid>« → TB shows “Big B�d Spammer”

This is a two part fix: 1) In nsAbMDBDirectory we now check to see if the email address has been truncated after conversion of utf-8 to utf-16, if so, there's probably been an error, so return the fact (we already check the email address isn't empty at the start of the function). 2) In the DB view, use the decoded form of the from field message header rather than the encoded form. This means we get a proper utf-8 value passed to GetCardForEmailAddress and we display the right thing in the thread list.

Comment on attachment 587443 [details] [diff] [review] The fix this looks good - I'll try to test it later.

Comment on attachment 587443 [details] [diff] [review] The fix Checked into trunk: http://hg.mozilla.org/comm-central/rev/4a3f5d039f95

Checked into branches: http://hg.mozilla.org/releases/comm-aurora/rev/2f1c07cca30f http://hg.mozilla.org/releases/comm-beta/rev/f80720b2f49c