User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 When composing a message and entering recipients, TB suggests them from the address book. If multiple people have the same name (e.g. mayer, mueller, smith) as part of either the email address or the last/first name, TB always suggests the same address as recipient. Often, the first recipient in the suggestion list is not the recipient you want to use. To fasten the workflow, I propose a simple method which solves the problem: The address book saves the frequency of message exchange to a particular email and makes recipient suggestions based on this data. For example: -I have two ppl. with the same last name in my address book. -First, a data value "number of message exchange" is 0. -If I continue to email those people, the value increases based on HOW OFTEN I email a specific person. -If I compose a new email, the suggestion algorithms suggests the address I wrote MOST messages to. Benefit: Time-saving message composing and suggestion parameters based on statistical evaluation of user behavior. Please integrate this. It should not be too difficult. Reproducible: Always Steps to Reproduce: 1. Write an email to a person. 2. Have two persons with e.g. same last name in AB Actual Results: Wrong person gets suggested first to the "TO" field. Expected Results: The person with the highest number of messages composed to gets suggested first None. All OS.

The local address books already do this - OS X and LDAP address books don't.

(In reply to comment #1) > The local address books already do this - OS X and LDAP address books don't. Since what (dev-)version?

It does not work with 3.1.8...

See Bug 1058583 "Address Book Popularity Index needs to age", for a restatement of the address book recency and frequency issues, and resolves related issues and bugs looking at autocomplete sorting. This new bug focuses on Aging the Address Book counts (what has been incorrectly identified as a "PopularityIndex", rather than establishing and managing data about recency and frequency. It turns a count into a workable "PopularityIndex" -- Aging an address book count reflects both recency and frequency.

This bug was invalid for local ABs because frequency aka popularityIndex is already implemented (albeit insufficiently). So what remains to be done here (per Mark's comment 1) is to implement some similar algorithm for OS X and LDAP ABs. Morphing accordingly and confirming to keep on radar.

Seems like thisis reasonably close to bug 543114 to be a duplicate

(In reply to Wayne Mery (:wsmwk) from comment #6) > Seems like thisis reasonably close to bug 543114 to be a duplicate Yep, thanks!