User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3b) Gecko/20030103 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3b) Gecko/20030103 when creating a filter, allow a filter rule based on "To or CC" to look in an address book. if i get mail that has a To: or CC: to someone i know that is from someone that i don't keep in my address book, but has been BCC:ed to me, i'd like to be able to recognize it. similarly, if i get spam that is addressed to a bunch of people on the to: or cc: list, i'd like to be able to add those addresses to a "xref spam addresses" address book, and then have future filtering check that address book; i find that spam often contains a similar group of addresses which could help block a good amount of spam i see. Reproducible: Always Steps to Reproduce: 1. 2. 3.

*** This bug has been marked as a duplicate of 162789 ***

jruderman, are you certain this is a duplicate. i looked at 162789, and it appears to be for a bug for looking for the sender in a chosen address book. that already works for me, though i understand that there are other minor issues regarding the rules file that have that bug left marked as open. the issue of this bug about the ability to allow items in the "To or CC" field to also be searched in the Address book of choice. i.e. a separate field. this is not an option when "To or CC" is chosen. i'm going to re-open this for now, but if you are absolutely certain that the work being done on 162789 is going to address the ability for having other items searched in the address books, then re-resolve it.

You're right, this isn't a dup. Sorry.

mass re-assign.

When this is done, I'd like to ask that "Address book" be generalized to all using LDAP address books as well as locally stored address books. In a corporate environment, being able to filter based upon presence in the corporate LDAP server would be very useful.

I think this would be more useful to users than one might initially think-- here's a common case (an actual one for me, as well) illustrating how useful this feature would be: Our business works with several clients. I've created an address book for each client listing the e-mail addresses of all of our contacts there. I've got a filter that sorts incoming mail into folders for each client if it was sent by someone in that client's address book. Fine and dandy-- but it's MUCH harder for me to filter the outbound e-mails (on which I am CC'd) from co-workers TO those companies into the company's folder. Being able to say "filter into this folder if any of the recipients is in a given address book" would make life much, much easier. As it stands, all of our outbound mail ends up in my "general office" folder and has to be hand sorted into the company folders or the thread-view in the folder is missing items. I also BCC myself on all outbound mails so both back-and-forth will show up in the threads. I currently have to hand-move these messages as well. Given that the filter based on the FROM being in an address book is implemented, adding the feature for TO/CC shouldn't be too hard, should it? Is it simple enough for an outside party like myself to implement and submit as a patch?

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

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

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

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

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

Is this ever going to be fixed, or is this really a WONTFIX (and run Thunderbird)? It's been over 2 years since this bug was filed, and there seems to be no progress being made on it.

Well... technically it's not a *bug*, you see. It's more of a feature request. A patently obvious, supremely useful, and probably not very hard to implement feature (though I would have to delve into the source code to make that call). Just allow filters to be placed on the 'Sent' folder as well as the 'Inbox', so I can filter mail by who it's TO when I send it as well as who it's FROM when I receive it. It doesn't work this way in Thunderbird, either. In Thunderbird, they do have seperate filter settings for different points in the mail tree hierarchy (i.e. 'Local Folders' can have different settings from 'mymailaccount'), but it doesn't allow you to assign filters to specific folders, such as 'Sent'. Only the inboxes of the respective seperate mail accounts are allowed to be filtered. So, I still track down and drag messages from 'Sent' to 'BBE/Sent' manually about once a day. Obviously the logic is there to highlight and activate menus, and behave differently according to what part of the tree is highlighted, but perhaps the filter stuff is all one big, fat, ugly kludge, and hardwired to 'Sent'.

> Just allow filters to be placed on the 'Sent' folder as well as the 'Inbox', so Which has NOTHING to do with this bug whatsoever. This is about using the TO field to filter INCOMING mail against an address book, - so that mail sent to a valid address can be received and not treated as spam (or alternatively, mail to known bad addresses can be marked as spam).

Hmm. I thought I had mentioned this in 248983, and never wrote up this seperate suggestion. So much for relying my memory. Can't imagine it hasn't been suggested about a million times by now.

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

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

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

Hoorrrraaaayyyyyyyyyy Completes 5 years. Even President's tennure expires in this time. I propose to close this bug/issue/enhancement/new feature

(In reply to comment #19) > Hoorrrraaaayyyyyyyyyy > > Completes 5 years. Even President's tennure expires in this time. > > I propose to close this bug/issue/enhancement/new feature please no. as the original submitter, i would still like to see it "fixed" (i.e. implemnted). if closing it and forcing me to open a duplicate bug will get it done sooner, then close it, and i'll open a new one. but it seems popular enough. there have been 7 bugs marked duplicate; one would think that is a cry for the feature from the masses.

I'd love to see this in the product too. It would make my life much simpler. My case is that I have owned a domain name for a long time and have many usernames that have either leaked onto spam lists or that have been created by spammers and have been picked up by other spammers. Whether its a bug or a feature, 5 years doesn't say much for the engineering process.

I'd like to have this fixed too. I mass-imported about 14000 mails from my old mail program and now I want to filter them in various folders. Unfortunately, I can't filter according to presence of address from To: field in an addressbook. I guess all three "To:", "Cc:" and "To or Cc:" should benefit of added email filtering using list from addressbook

Since I learned enough about the mail filters to accomplish my goals in bug 414179, I looked around for some other similar bugs I could fix and found this one. The main issue, beyond simply turning on the feature, was figuring out the purpose of code that only executed if filter was Sender and one of the AB checks. Was that Sender check critical for some reason? I finally convinced myself that the Sender check was simply a literal conversion of the older SenderInAB filter type rather than some critical issue. This patch works, but I want to test it a little more before asking for a review.

Comment on attachment 313285 [details] [diff] [review] Add To, ToOrCC, and CC to Ab filter checks OK I'm happy with this patch, requesting review.

You're a gentleman and a scholar, my friend.

Bravo Bravo. You don't know how much of my pain has been reduced. I never knew my earlier comment was motivating. But really thanks a ton. Waiting when it gets to production.

Well, it missed 2.0.0.14 .....

(In reply to comment #27) > Well, it missed 2.0.0.14 ..... > Virtually no feature changes are being added to the 2.0.0.x series. The patch if for trunk.

After 5 years, you think someone might be embarrassed enough to make an exception - As simple enough a change that this is... What is this Microsoft? Can someone make this happen? Is this something that someone who's too old to code can cobble into an existing client?

(In reply to comment #29) > After 5 years, you think someone might be embarrassed enough to make an > exception - As simple enough a change that this is... What is this Microsoft? No. The 2.0.0.x series is for security and stability fixes only. We don't allow other changes to ensure compatibility with extensions, so that we don't get regressions and break what users do, and for a variety of other reasons.

Comment on attachment 313285 [details] [diff] [review] Add To, ToOrCC, and CC to Ab filter checks So in general this looks reasonable. However there's a problem in mailWidgets.xml I think: 1) Open up Filter dialog, select the first column as "To". 2) Then select the second column as either is or isn't in address book. 3) Third column is displayed correctly. 4) Now select CC or "To or CC" in the first column 5) Third column reverts to a text box.

OK I see that problem, so I'll look into it. Also I want to submit a unit test for at least the backend features in my next patch. I'm also going to block this bug on bug 432812 which we need for unit test.

This patch includes the fix for the issue in bug 434493 comment 6, as well as unit tests. There's also the issue left hanging of whether to implement a set of unit test unload functions as proposed in bug 434810 - though this patch should work regardless. The issue in comment 32 is addressed by forcing the widget to use the default settings when the attribute is changed. This could also affect other uses of the widget - but I don't think anyone really intended to preserve settings when the attribute was changed.

Oops, left in some junk from initial testing and previous bug in the unit tests. Removed the junk.

Comment on attachment 322344 [details] [diff] [review] Removed some leftovers >Index: mailnews/base/search/src/nsMsgSearchSession.cpp This bit is no longer needed. >Index: mailnews/base/search/src/nsMsgSearchTerm.cpp >- if (m_attribute == nsMsgSearchAttrib::Sender && >- (m_operator == nsMsgSearchOp::IsInAB || >+ if ((m_operator == nsMsgSearchOp::IsInAB || > m_operator == nsMsgSearchOp::IsntInAB)) You don't need the extra pair of ( ) around this. >- if (m_attribute == nsMsgSearchAttrib::Sender && >- (m_operator == nsMsgSearchOp::IsInAB || >+ if ((m_operator == nsMsgSearchOp::IsInAB || > m_operator == nsMsgSearchOp::IsntInAB)) ditto. Index: mailnews/base/test/unit/test_bug187768.js Maybe test_searchToCc.js or something? >+const Cc = Components.classes; >+const Ci = Components.interfaces; These are now global. >+var have_434810 = false; Obviously we need to remove these bits now and just get 434810 committed before these. >+ OnStopCopy: function(aStatus) >+ { >+ var fileName = Files.shift(); >+ if (fileName) >+ { var file = do_get_file(fileName); >+ copyService.CopyFileMessage(file, inboxFolder, null, false, 0, >+ copyListener, null); The var needs to be on a new line. >+// Runs at completion of copy >+function afterOnStopCopy() >+{ >+ testAbSearch(); >+ return true; >+} Any particular reason not to just call testAbSearch()? You also don't need the return true here. >+// Test that validity table for scope aScope has Available and Enabled set >+// to aValue for operator aOp and attribute aAttrib >+function testValidity(aScope, aOp, aAttrib, aValue) Didn't I see this in a patch I reviewed the other day? Is it worth sharing some of these functions in a common script? r=me with the comments fixed.

Fixed Standard8's issues, generally updated unit test to the most recent standards. Carrying over r, asking for sr.

I forgot to add that attachment 325639 [details] [diff] [review] was tested with attachment 324903 [details] [diff] [review] from bug 436630 backed out, as that patch broke the ability to define message searches.

Comment on attachment 325639 [details] [diff] [review] Fixed Standard8's nits this looks ok, but I'm curious if the tests work on the mac...

Standard8 tried this on his Mac, and it passed unit tests. So I'm requesting checkin.

(In reply to comment #38) > (From update of attachment 325639 [details] [diff] [review]) > this looks ok, but I'm curious if the tests work on the mac... > Yep these work fine in both debug and opt builds on mac.

Checking in mailnews/base/resources/content/mailWidgets.xml; /cvsroot/mozilla/mailnews/base/resources/content/mailWidgets.xml,v <-- mailWidgets.xml new revision: 1.128; previous revision: 1.127 done Checking in mailnews/base/search/src/nsMsgImapSearch.cpp; /cvsroot/mozilla/mailnews/base/search/src/nsMsgImapSearch.cpp,v <-- nsMsgImapSearch.cpp new revision: 1.54; previous revision: 1.53 done Checking in mailnews/base/search/src/nsMsgSearchTerm.cpp; /cvsroot/mozilla/mailnews/base/search/src/nsMsgSearchTerm.cpp,v <-- nsMsgSearchTerm.cpp new revision: 1.161; previous revision: 1.160 done RCS file: /cvsroot/mozilla/mailnews/base/test/unit/test_searchAddressInAb.js,v done Checking in mailnews/base/test/unit/test_searchAddressInAb.js; /cvsroot/mozilla/mailnews/base/test/unit/test_searchAddressInAb.js,v <-- test_searchAddressInAb.js initial revision: 1.1 done RCS file: /cvsroot/mozilla/mailnews/test/data/bugmail2,v done Checking in mailnews/test/data/bugmail2; /cvsroot/mozilla/mailnews/test/data/bugmail2,v <-- bugmail2 initial revision: 1.1 done RCS file: /cvsroot/mozilla/mailnews/test/data/bugmail3,v done Checking in mailnews/test/data/bugmail3; /cvsroot/mozilla/mailnews/test/data/bugmail3,v <-- bugmail3 initial revision: 1.1 done RCS file: /cvsroot/mozilla/mailnews/test/data/bugmail4,v done Checking in mailnews/test/data/bugmail4; /cvsroot/mozilla/mailnews/test/data/bugmail4,v <-- bugmail4 initial revision: 1.1 done RCS file: /cvsroot/mozilla/mailnews/test/data/bugmail5,v done Checking in mailnews/test/data/bugmail5; /cvsroot/mozilla/mailnews/test/data/bugmail5,v <-- bugmail5 initial revision: 1.1 done RCS file: /cvsroot/mozilla/mailnews/test/data/bugmail6,v done Checking in mailnews/test/data/bugmail6; /cvsroot/mozilla/mailnews/test/data/bugmail6,v <-- bugmail6 initial revision: 1.1 done RCS file: /cvsroot/mozilla/mailnews/test/data/bugmail7,v done Checking in mailnews/test/data/bugmail7; /cvsroot/mozilla/mailnews/test/data/bugmail7,v <-- bugmail7 initial revision: 1.1 done

Which version did those changes go into?

The change is in the trunk. So any of the TB3 preliminary releases should have it, including the current beta1.