228980 - Identity selection based on recipients should be more correct (identity matching should not be partial match)

Status: RESOLVED FIXED

(MailNews Core :: Composition, defect)

Description

[Ben Bucksch (:BenB)]

Based on bug 18906 comment 26 by beinvenu:
"The searching of the hint string for the email address is just a string search
- that's good enough for now but it would be more correct to parse out the
addresses and compare that way, so that a@b won't match freda@bc"

Relevant code:
      var hdr =
messenger.messageServiceFromURI(messageUri).messageURIToMsgHdr(messageUri);
      var hintForIdentity = hdr.recipients + hdr.ccList;
[...]
      if (optionalHint.search(tempID.email) >= 0) {

Comment 1

[Scott MacGregor]

It turns out, this really isn't a big deal because it can only happen if you
have several identities for the SAME account in which one identity address
encompasses another. 

Marking future

Comment 2

[eberry]

I would appreciate some sort of domain comparison fallback such that if I
receive a message addressed to [e-mail] and reply the default identify
would be [e-mail] if I don't have a [e-mail] identity defined.  I'm not
sure how well that would work for others, but it would help me.

Comment 3

[Ronald van Kuijk]

The selection of the right identity is a 'problem' for me (and others I think)
when mailinlists are used. The headers below do not result in selecting the
right identity though the right address is in there ([e-mail])

------------------------------------------

From - Sat Feb 14 00:37:40 2004
X-UIDL: 1076715146.maildrop6.95881
X-Mozilla-Status: 0011
X-Mozilla-Status2: 00000000
Return-Path: <[e-mail]>
X-XS4ALL-To: <[e-mail]>
Received: from mxzilla3.xs4all.nl (mxzilla3.xs4all.nl [194.109.24.203])
	by maildrop6.xs4all.nl (8.12.9/8.12.6) with ESMTP id i1DNWQwQ095878
	for <[e-mail]>; Sat, 14 Feb 2004 00:32:26 +0100 (CET)
Received: from sc8-sf-list1.sourceforge.net (lists.sourceforge.net [66.35.250.206])
	by mxzilla3.xs4all.nl (8.12.10/8.12.10) with ESMTP id i1DNWPjT019006
	for <[e-mail]>; Sat, 14 Feb 2004 00:32:25 +0100 (CET)
Received: from localhost ([127.0.0.1] helo=projects.sourceforge.net)
	by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30)
	id 1Armou-0008LS-KU; Fri, 13 Feb 2004 15:34:04 -0800
Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11]
helo=sc8-sf-mx1.sourceforge.net)
	by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30)
	id 1Armoq-0008JD-1g
	for [e-mail]; Fri, 13 Feb 2004 15:34:00 -0800
Received: from natsmtp00.rzone.de ([81.169.145.165] helo=natsmtp00.webmailer.de)
	by sc8-sf-mx1.sourceforge.net with esmtp (Exim 4.30)
	id 1Armmq-0003bq-Su
	for [e-mail]; Fri, 13 Feb 2004 15:31:57 -0800
Received: from web.de (pD9E792BC.dip0.t-ipconnect.de [217.231.146.188])
	by post.webmailer.de (8.12.10/8.12.10) with ESMTP id i1DNVsrH021017;
	Sat, 14 Feb 2004 00:31:54 +0100 (MET)
Message-ID: <[e-mail]>
From: joern turner <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Mikula <[e-mail]>
CC: Chiba <[e-mail]>
Subject: Re: [Chiba-developer] file upload
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	Report problems to http://sf.net/tracker/?func=add&group_id=1&atid=200001
	0.0 HTML_MESSAGE           BODY: HTML included in message
Sender: [e-mail]
Errors-To: [e-mail]
X-BeenThere: [e-mail]
X-Mailman-Version: 2.0.9-sf.net
Precedence: bulk
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/chiba-developer>,
	<mailto:[e-mail]?subject=unsubscribe>
List-Id: <chiba-developer.lists.sourceforge.net>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/chiba-developer>,
	<mailto:[e-mail]?subject=subscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum=chiba-developer>
X-Original-Date: Sat, 14 Feb 2004 00:32:27 +0100
Date: Sat, 14 Feb 2004 00:32:27 +0100
X-UIDL: 1076715146.maildrop6.95881

Comment 4

[Ronald van Kuijk]

Sorry for the short comment in the previous one, I pressed commit to soon. 

I think multiple identies are used with mailinglists alot, especially for people
with 'catchall' pop/imap accounts, it is realy handy to have a selection of the
right identiy based on more than the recipients and cclist. These two should
ofcourse have preference over other fields, but the 'received' header with a
from in there should be checked to I think. Therefor I think that for
multiple-identies to really work this should be changed and not be a minor issue

Comment 5

[R.K.Aa.]

*** Bug 207040 has been marked as a duplicate of this bug. ***

Comment 6

[Zeiram]

Regarding Comment #3 and Comment #4, the behaviour for mailing-lists is adressed
in another bug. See bug 230247.

Comment 7

[benjymous]

I use yahoogroups a lot and have the email addresses there sent to a different
alias to my main account (although my main pop3 account is a catchall)

e.g.   yahoo list mail gets delivered to lists@mydomain
which is caught in user@mydomain's mailbox

Currently, when I reply, it doesn't automatically pick the lists identity
(although I can manually select it from the from: dropdown)

I think the problem is that only a subset of the possible fields that contain
the recepient's address are being checked (since a mailing list will often have
the to: addr set as the mailing list itself, and BCC the subscribers)

In the case of yahoogroups, the "Envelope-to:" header contains the real
subscriber's address in most cases, or sometimes the "Delivered-to:" header

Comment 8

[Bart Kuik]

For me it should be much easier if there was an option 'attach identity' with
the filter rules. Everything that has @ccmplanet.com in the 'to', 'from' or
'cc', or has 'ccmplanet' in the subject or body schould be placed in one folder,
and should be replied from '[e-mail]'. The first steps are handled by
the filters, the last step is always a manual step, and should imho also be
automated by the filters.

Comment 9

[(not reading, please use [e-mail] instead)]

sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.

Comment 10

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 11

[Magnus Melin [:mkmelin]]

FWIF, the original issue in this bug was fixed in bug 397975.

Comment 12

[WADA:World Anti-bad-Duping Agency]

(In reply to Ben Bucksch (:BenB) from comment #0)
> "The searching of the hint string for the email address is just a string search
> - that's good enough for now but it would be more correct to parse out the
> addresses and compare that way, so that a@b won't match freda@bc"
> Relevant code:
>       var hdr =
> messenger.messageServiceFromURI(messageUri).messageURIToMsgHdr(messageUri);
>       var hintForIdentity = hdr.recipients + hdr.ccList;
> [...]
>       if (optionalHint.search(tempID.email) >= 0) {

Why bug for specific issue like above can be meta bug at B.M.O.?

Comparison of mail addresses in message headers and Identity's mail address has recently improved by bug 397975.　 
Ben Bucksch(bug opener), is change by bug 397975 sufficient for this bug's issue?

Comment 13

[Ben Bucksch (:BenB)]

I can't really tell whether bug 397975  fixes my comment 0.

Note that Karsten Düsterloh has morphed this bug into a meta-bug in 2005, but I didn't mean it to be one when I filed it 2005. Now it is a meta-bug, so let's leave it at that.

Comment 14

[WADA:World Anti-bad-Duping Agency]

FYI.
For original comment #0.
Fix by bug 397975 was;
(1) Change Hint string to "comma separated mail addresses(may be enclosed in <>)".
(2) Comparison like next.
> +  // If we have more than one identity and a hint to help us pick one.
> +  if (identityCount > 1 && optionalHint) {
> +    // Normalize case on the optional hint to improve our chances of
> +    // finding a match.
> +    optionalHint = optionalHint.toLowerCase();
> +    let hints = optionalHint.toLowerCase().split(",");
> +    for (let i = 0 ; i < hints.length; i++) {
> +      for each (let identity in fixIterator(identities,
> +                  Components.interfaces.nsIMsgIdentity)) {
> +        if (!identity.email)
> +          continue;
> +        if (hints[i].trim() == identity.email.toLowerCase() ||
> +            hints[i].indexOf("<" + identity.email.toLowerCase() + ">") != -1)
> +          return identity;
>        }
>      }
>    }
After it, as Magnus Melin says, a@b won't match freda@bc(comment #0) and xyz@bc won't match freada@bc(bug 397975) any more.

Comment 15

[WADA:World Anti-bad-Duping Agency]

What had been done by patch for bug 397975 is following in bug 18906 comment #26.
> but it would be more correct to parse out the addresses and compare that way,
> so that a@b won't match freda@bc
This bug looks for me first bug report of problem what was fixed by patch for bug 397975.

Comment 16

[WADA:World Anti-bad-Duping Agency]

Changing back this bug to non-meta bug, and move bugs in Depends on: field to actual meta bug 699681 for ease of knowing changes around identity picking and for ease of sorting out of repeatedly opened bugs for "From: in Reply/Forward is wrong".

Comment 17

[Magnus Melin [:mkmelin]]

Marking fixed.