Bug #18906 added smart logic for the case of multiple identities for an account. However, we still have problems when the original message was sent to a mailing list because the to/cc fields do not contain an email address match on one of your identities. We can alleviate this problem for a certain set of conditions by falling back to domain name matches between the mailing list domain and your identity email addresses. This at least helps corporate users who have mailing lists within the same domain as one of their email addresses. Such as superreviewers@mozilla.org and mscott@mozilla.org. Obviously this does not work for all mailing lists because the domains will not always match. But it helps improve this condition a little bit.

i elected to just make a second pass through the identities for the domain based match instead of merging this into the initial pass because the # of identities for an account should be small so the loops are not expensive and I thought it made the code clearer.

> falling back to domain name matches between the mailing list domain > and your identity email addresses. I think you're coding for an edge case here. I don't think that's a good idea. In the vast majority of cases, the mailing list is run by a thrid party and you are just subscribed. E.g. @mozilla.org addresses are more the excpetion than the rule on @mozilla.org mailing lists ;-). Even more so with most other Open Source projects, egroups or whatever. Also, this algorithm will trigger in other cases than mailing lists, which may or may not be wanted. Usually, the email address which is subscribed to the mailing list is hidden in the Received headers somewhere *, unfortuantely that's not strictly formatted. You might want to plaintext-search those headers, if (and only if) you noticed that it's a mailing list post. There are standard headers establishing for mailing lists, e.g. List-Post, and other clients such as mutt use these to offer mailing list specific functions. I don't know the details, but it may be worth checking what these clients do. *Example Received: ... Received: from mozdev.mozdev.org (mozdev.org [167.206.76.23]) by firespit.beonex.com (Postfix) with SMTP id 02F93CC104D3 for <ben.bucksch.news@beonex.com>; Tue, 6 Jan 2004 08:21:32 -0600 (CST) Received: ...

Actually, <sales@example.com>-type addresses are very common in business and are usually not run mailing list software. I just tested my <sales@example.com>-type alias and contrary to my expectation, I didn't get a <ben.bucksch@beonex.com> entry in the Received headers. (Postfix, virtual file) So, your implementation isn't a bad idea, even though it doesn't solve the mailing list problem the majority of cases.

fixed

Filed bug 230247 as followup.

fixed on the M4 branch too.