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) {

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

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

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 (sf@roestbak.xs4all.nl) ------------------------------------------ From - Sat Feb 14 00:37:40 2004 X-UIDL: 1076715146.maildrop6.95881 X-Mozilla-Status: 0011 X-Mozilla-Status2: 00000000 Return-Path: <chiba-developer-admin@lists.sourceforge.net> X-XS4ALL-To: <sf@roestbak.xs4all.nl> 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 <sf@roestbak.xs4all.nl>; 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 <sf@roestbak.xs4all.nl>; 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 chiba-developer@lists.sourceforge.net; 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 chiba-developer@lists.sourceforge.net; 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: <402D5E8B.2090803@web.de> From: joern turner <joern.turner@web.de> 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 <mico@pobox.sk> CC: Chiba <chiba-developer@lists.sourceforge.net> Subject: Re: [Chiba-developer] file upload References: <20040213131353.GA13708@mico.pobox.sk> In-Reply-To: <20040213131353.GA13708@mico.pobox.sk> 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: chiba-developer-admin@lists.sourceforge.net Errors-To: chiba-developer-admin@lists.sourceforge.net X-BeenThere: chiba-developer@lists.sourceforge.net X-Mailman-Version: 2.0.9-sf.net Precedence: bulk List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/chiba-developer>, <mailto:chiba-developer-request@lists.sourceforge.net?subject=unsubscribe> List-Id: <chiba-developer.lists.sourceforge.net> List-Post: <mailto:chiba-developer@lists.sourceforge.net> List-Help: <mailto:chiba-developer-request@lists.sourceforge.net?subject=help> List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/chiba-developer>, <mailto:chiba-developer-request@lists.sourceforge.net?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

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

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

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

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

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 'bart@ccmplanet.com'. 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.

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

Filter on "Nobody_NScomTLD_20080620"

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

(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?

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.

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.

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.

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".

Marking fixed.