230230 - Pick identity picker for multiple identities smarter for mailing lists

Status: RESOLVED FIXED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Scott MacGregor]

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 [e-mail]
and [e-mail].

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.

Comment 1

[Scott MacGregor]

Attachment: the fix

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.

Comment 2

[Ben Bucksch (:BenB)]

> 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 <[e-mail]>; Tue,  6 Jan 2004 08:21:32 -0600 (CST)
Received: ...

Comment 3

[Ben Bucksch (:BenB)]

Actually, <[e-mail]>-type addresses are very common in business and are
usually not run mailing list software.
I just tested my <[e-mail]>-type alias and contrary to my expectation,
I didn't get a <[e-mail]> 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.

Comment 4

[Scott MacGregor]

fixed

Comment 5

[Ben Bucksch (:BenB)]

Filed bug 230247 as followup.

Comment 6

[Scott MacGregor]

fixed on the M4 branch too.