Per dicussion with Seth, I'm filing a general bug about doing spam filters with a whitelist, rather than the classically attempted blacklist. What this basically means is that you consider all mail spam, unless it meets some specific criteria... since most spam comes from a fairly unique address (i.e. alec948@somehost.com) blacklist filters catch very little spam - once you've gotten spam from some address, you don't usually get spam from the same address again. There is a whole lot of issues/feature that could surround this, so I guess this could become a tracking bug. A few ideas off the top of my head: - using the addressbook for the whitelist - basically saying that if the sender of a message isn't in your address book, then it's probably spam. (note, this would be a pain for mailing lists which have many members) - seeing a particular address more than X number of times adds it to a whitelist, perhaps something like "You've recieved 10 mail messages from yourfriend@yahoo.com, would you like to add them to (Your Whitelist|Your Addressbook)" - probably using the history address book to count the occurances - automatically adding a all senders of all messages in a one or more folders to your whitelist - using address book mailing lists to further distinguish between whitelist entries (i.e. further filtering beyond just keeping the message)

filtering against addressbook would be very useful.

This is a variant of bug 34340, which asks for the "is in <specified> address book" filter condition.

Regarding the concern about whitelist filters and mailing lists with lots of members - not really a problem. First of all, you likely have a separate folder for such lists, anyway. Even if not, you can still make your non-spam filter have multiple conditions such as, "in address book", or "some-field has foo", whatever you want to use to dtermine if a message is from some list...

> This is a variant of bug 34340, which asks for the "is in <specified> address > book" filter condition. Yes, but it goes way beyond just filtering for addresses in the address book. One thing I'd like to (optionally) enable is: -Upon receipt of an email from an unrecognized address, autorespond with an email form asking them to identify themselves, explain the reason for contacting, etc. Send it as a reply with the original email attached. -If a person replies (most spammers won't), show me their responses and ask if I want to receive email from them. Most emailers will automatically attach the original email, so I can see that too if I want to. If I say "yes", then add them to my addressbook. Otherwise, blacklist their email address.

I'm tentatively marking this dependent on bug 34340, because we might need that capability to actually fix this bug - as david points out, this bug is a superset of that bug. David - for your other features, why don't you file seperate bugs.. they would both be useful features independent of this feature...

A little clarification: I don't think it's intuitive to most (l)users to have to set up filtering rules to do whitelist spam filtering. Many of them will think that this is just too complicated. As a programmer, it makes perfect sense to me to do it that way. However, I think most users will prefer a checkbox added to the account settings: [x] Enable unwanted email protection for this account Maybe along with a brief explanation of what this does. Perhaps it would be most useful to implement this by automatically adding or removing the appropriate rules to the account so we programmers who obsessivly have to customize everything can. ;-) *djo goes off to search for other bugs to annotate with the other feature requests. :-)

Dave, I agree -- most users don't want to set up filters. I do think, however, that they *are* willing to import filters that someone else sets up for them. (See bug 151612.) It might even be reasonable to come up with some default filters that ship with the distribution, e.g. "if sender is in address book, stop processing further filters." However, whitelists only solve part of the problem. Mailing lists must be treated differently. This spam solution has to have filters that filter mailing list messages based on the TO line, not the FROM line. There are a few ways to tell which addresses belong to mailing lists:: + Mailing list TO addresses go into a special address book + There needs to be a special Mailing List Manager (like in Outlook Express) + The user needs to explicitly create filters for each mailing list If you give the users a package solution that throws away all of their mailing list messages, they *will* *not* use it. There's also the problem of legitimate messages from unrecognized email address. The classic is someone sending you their new address! Thus I think that a strict rejection of all messages not from whitelisted senders is a bad idea. To give users a one-button spam solution thus requires a number of things: + mailing list manager + easy import/export of rules (perhaps with automatic downloading) (see bug 151612) + spam scoring (to score non-whitelisted messages) (see bug 151622)

Kaitlin--all good points. I have a small comment about one thing. >There's also the problem of legitimate messages from unrecognized email address. >The classic is someone sending you their new address! I know that making someone fill out a form once in order to re-register to send me email is a hassle for them. However, I have been drowning in spam (about 2-4% of my email is stuff I care about) and have concluded that in my case, I have two ways out: (1) change my email address (and hope I don't forget to tell someone about the new one). (2) Use draconian whitelist filtering including making people re-register if they get a new email address. (1) is really only a temporary solution until spammers discover the new address. (2) is a perminent solution; if the email form my autoresponder sends is apologetic enough, people will hopefully only be mildly annoyed when they have to re-register. I agree that whitelist filtering isn't for everyone. As you point out, it's ideally not the only way a product like Mozilla could help manage spam. However, I hope I've made a case that for some people it's probably the only real solution, as distasteful as as this may be.

Dave Orme -- *If* whitelisted messages are passed through *and* mailing lists are magically taken care of, then it's reasonable to ask people to re-register. With an auto-respond filter action (see Bug 21210) and auto-add filter action (see Bug 106963), you could do this automatically. See my comment in Bug 106963.

FYI: Bug 110813's proposal might be of interest to people watching this bug. I especially like the idea presented in the second to last paragraph of that proposal. In bug 134602 and bug 134603, I've made suggests that also might be of interest.

Beside the whitelist/blacklist approach, there is another one which is being used e.g. by Exim (a Unix Message Transfer Agent - www.exim.org)and is based on checking the compliance and consistency of a mail: what it basically does is the following: A) check mail-header (fields) for correct format (e.g. return address) B) perform dns-lookup/reverse-lookup for mail server name and ip in the header C) contact mail server and check whether specified "from:" email-address exists advantages: -> no maintenance efforts -> should kill the majority of your spam Ideally this should be combined with rule-based filters.

please.. FILE A NEW BUG. This bug is for whitelist filtering, that's it.

There's a solution to the usual problem of whitelists (namely, that you can't receive legitimate email from new addresses). See bug #187044, about challenge/response systems.

I was thinking about the think you call whitelist as wel; my solution would use a 'password' in the automatic reply message. This password would be required in a subject of the next message from this e-mail address. (Ofcourse all the messages coming from addresses that are not in my whitelist should contain the proper password. How many times you recieve a mean message from a person that is not in your address-book?) I think it is a pretty simple way of 'identifying' yourself. (The password should be 'hidden' in the message, to avoid the robots to filter it out and reply with the proper message subject.)

mass re-assign.

How about "Personal IP-whitelisting" ? IP's are taken from the mail headers. Mailers with known IP's pass to inbox. Mail from unknown IP's are moved to "Unknown FOlder"=UFO. Sorting UFO contents into black and white IP's can be done with one click per mail. Whitelisting one IP makes all the mails from that IP in UFO move to inbox at once. This feature takes care of all the open-relay spam and the rouge ISP's.

(In reply to comment #16) > How about "Personal IP-whitelisting" ? > > IP's are taken from the mail headers. Mailers with known IP's pass to inbox. > Mail from unknown IP's are moved to "Unknown FOlder"=UFO. Sorting UFO contents > into black and white IP's can be done with one click per mail. Whitelisting one > IP makes all the mails from that IP in UFO move to inbox at once. This feature > takes care of all the open-relay spam and the rouge ISP's. IP-based whitelisting really ought to be done on the SMTP server. The current Spam Filter implementation does whitelisting, and the current Filter implementation has a criteria for "Sender" "is in address book" so I think this bug should be resolved/Fixed.

By the way, a large proportion of spam I receive now uses forged email addresses, harvested from mailing lists and other sources. A lot of these are the addresses of people I actually correspond with, thru various lists. As such, whitelisting sender addresses the way Mozilla does now is useless.

Bug 352184 is adding whitelisting on trusted domain (domains?).

It might be helpful to review the functionality of an Outlook Add-In that used to be called Qurb and is now marketed by CA. Have a look at http://www.qurb.com This seems to me to be a good basic model for a white-lister in ThunderBird - either future core functionality or perhaps an add in. I have experience of Qurb on another machine and it is pretty simple AND effective. All mail that is not in the white-list gets moved into a junk folder WHERE you can then review the junk folder for any items that should not be there. The review interface is probably the niftiest bit (and not rocket science) - all else is pretty standard white-list. The review window offers the usual list of mails, with sender, and subject, plus an abbreviated preview if you mouse-over the mail. Each mail also has a single tick-box. If you want to rescue it, tick the box. Once you've reviewed the junk click OK. Rescued mail gets sent back to Inbox and all other mail is then marked as read. Normal folder processing then determines how much longer it hangs around before flushing away - a couple of days for me just in case I make a mistake. I'd also personally be keen to be able to white-list by selected domains which is beyond the present capabilities of Qurb. Qurb also doesn't make it easy to see your white-list, though it does include all addresses currently in your address-book. That would be good added functionality to make a ThunderBird white-lister more friendly. OK. Had my say. Wsih I had the time and current skills to actually implement this. As a guy who started programming in the 1960's you can guess that I'm stating to get a little left behind by current methods! All the best

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"

Whitelisting has been implemented for some time now, so I see no point to this bug any more. ->WFM

The idea about looking at the IP-numbers in the message header and using these for white-listing is not implemented. Maybe the idea is bad, but it is not implemented and therefore is nor resolved neither worksforme. Howard Chu argues that IP-filtering should be done on the smtp server but this does not allow for personal whitelisting. The current whitelist filter does not provide any way to filter on IP addresses in the message headers.

(In reply to comment #24) Your comment 16 is the first mention of IP-based white listing. If you would like to promote that idea, then please file a separate bug. This bug has been mostly about address-based whitelisting. And "mostly about" is part of the problem, the bug is too vague to serve any useful purpose anymore.