need ability to right click on incoming mail address and select "Block this Address" This would be an awesome way to easily block spam :) Of course, we would also need a UI to show and edit blocked email addreeses, in case we changed our mind or accidentally added someone. For user ease of use, I suggest to add "View Blocked Addresses" to right click too. This would be the mose intuitive place and also a good reminder to check there for accidentally added names.

See also bug 10097: Ability to add user to 'killfile' with a single click. Duplicate?

I think bug 10097 is mainly concerned with newsgroups, rather than mail. I think this us a cool idea and I'm surprised it hasn't been suggested before (though I haven't checked, so it might have been). Peter, I assume you think the "Block this Address" option should be added to the menu that appears when you left- or right-click on a From, To or Cc address in the message header area of an email (that currently contains "Add Address To Address Book" and "Send Mail To"). This is a dead useful, but powerful feature. The user should be given a confirmation dialog (along the lines of "Are you sure you want to stop receiving messages from this address?") when they select it. As for dealing with messages from blocked addresses, there are two options I can think of. The first would be that the message would be downloaded and moved straight to the relevant Trash folder. The second is that the message would be deleted from the server and the user would never know about it. I believe the user should be given the choice, preferably on an address-by-address basis. Another cool addition to the menu would be "Block This Domain" that would block all messages from a particular domain (e.g. evilspammers.com). This would be great as many spammers use several addresses and some domains seem to be there soley for the purpose of spam. Obviously, this feature could be extremely dangerous, so there should be lots of warning. When a user chooses to block mail from a domain, a dialog box should appear that allows him or her to edit the domain before adding it. This is because a message may come from extremely.evilspammers.com and the user may want to block just extremely.evilspammers.com or all mail from evilspammers.com (there should be safeguards to stop users selecting .com or .co.uk etc.). The "View Blocked Addresses" dialog is needed, but I'm not sure if it should be placed in the same context menu (maybe in the Edit menu, next to the Message Filters option would be good location?). The dialog should allow users to edit or delete addresses/domains, as well as manually add addresses or domains. For a comparison, I checked out M$ Outlook Express 5's Block Sender function. It allows you to block addresses or domains. It only lets users choose to have mail from blocked addresses/domains automatically placed in Deleted Items (Trash). When you choose to block an address, it does offer to move all mail from that address to Deleted Items, which is cool. Its Blocked Senders dialog is a tab of the Message Rules (a.k.a. filters) dialog box.

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

reassigning to naving

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

Instead of creating a new UI to be able to be able to remove addresses that we have previously blocked, the "Block this Address" command (when fist called) could simply create a new message filter in the curent UI and call it "Blocked Addresses" which would be configured to delete the mail. All subsequent "Block this Address" commands would add the addresses to this message filter's list.

that sounds like a great idea to me.

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

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

The right click options might be expanded to included: Move To Copy To *Filter To* <-- add this option

In regards to the Filter to option This is a great idea.. but what if it is expanded to Filter by Subject to *List of folders* Filter by Sender to *List of folders* Then all future messages will be filtered to that folder. This is WAY easier then opening the filter box, typing it in by hand say for 30 filters.

reassigning to varada. See also http://www.mozilla.org/mailnews/specs/filters/FilterPrefill1.html#b

marking nsbeta1+

moving to 0.9.9

I agree with Alexandre, we should use the general filtering mechanisms as much as possible, while adding some UI shortcuts to make it easier to use. I would go a bit further, though. Implement bug 34340, then add a new address book "Blocked Addresses" in addition to "Collected Addresses". Make a filter "Block Messages" to do what ever the user wants for messages sent by someone contained in "Blocked Addresses" address book. Make the context menu just add the address to the address book. No need to implement special blocked address management dialogs or code.

From a trainer's point of view, risto.kankkunen's suggestion above is excellent! With a pre-defined / pre-activated / undeletable message filter (that can be enabled or disable) this feature becomes as easy as drag-and-drop or right clicking. There would be no need to know what a filter is or how to set one up. And on first use, the user could be presented with an informational dialogue box that highlights the expanded options available through custom filtering and where to learn more. "Block Address" ("Block Mail" might be a better name) is probably the only filtering function that most end-users will ever use. From my experience most end-users are unaware that filtering exists. Of the few that do know, many are still unsure what it is used for ("Sort" or "Organize" might be better terms than "Filter") or find it just too confusing to setup.

Adding the Blocked Senders to the Address Book doesn't seem right to me because in general, the Address Book is a positive thing. Its where you store info about people you want to remember, Addresses you want autocomplete to work against, etc. Devoting an AB to people you want out of your life doesn't seem right. Users won't want to see a nice little card entry for these people. I agree this feature should be easy to use, no need to know about what a filter is or how to create one. The spec putterman mentioned attempts to take this into consideration. One click to add someone to list. Confirmation. Simple dialog with list of people currently being blocked. Ability to add or remove addresses from list. http://www.mozilla.org/mailnews/specs/filters/FilterPrefill1.html#b risto's idea is great, but i think that is a separate issue. If bug 34340 was implemented, more experienced users could decide to (1)create their own "Blocked Addresses" AB. (2) Make a filter against that AB. (3)Add addresses to a specific address book (click on person's name in email envelope area when reading message).

Sounds good. The list of blocked addresses (definetely not in the AB!!! unless that list is NOT part of the autocomplete!) could have collums for: Blocked address, Name (if available), Date Address was Blocked, and Comment. The date and optional comment would greatly help the user remember when and why he blocked an address. The user would be prompted for an *optional* comment when blocking the address. The comment could be limited to, oh, say 50 characters, so as to be readable on one line in the table. +-- Spam Filter --------------------------------------------+ | | |Blocked Address Name Date Blocked Comment | +-----------------------------------------------------------| |jerk@spamfest.net Joe Shmo 24.12.1999 A real jerk | |pam@blowme.com 04.07.2001 sells porn vids | | | +-----------------------------------------------------------+ |<add an address> <delete sel. address> <edit sel. address>| +-----------------------------------------------------------+

What I'm concerned here is the UI and code bloat. Implementing totally new elements just for this specific function bloats the UI with new elements for the user to learn, and also adds code that cannot be reused for other features. It would be nice, if this feature could be implemented by combining some general but powerful basic functions WHILE making sure it's still easy to use for novices. > Adding the Blocked Senders to the Address Book doesn't seem right to me > because in general, the Address Book is a positive thing. Its where you store > info about people you want to remember, Addresses you want autocomplete to > work against, etc. Devoting an AB to people you want out of your life doesn't > seem right. This argument would be much easier to buy, if we didn't already have Collected Addresses with all the spammers' names in it! Not very positive to me. And I could say the same thing about mail folders: A mail folder for spam messages doesn't seem right, mail folders are for positive things like nice messages I want to remember... > The list of blocked addresses (definetely not in the AB!!! unless > that list is NOT part of the autocomplete!) [...] Of course it would not be autocompleted. But guess what, even if it was, it wouldn' be any worse than now: the Collected Addresses contain all the spammers' addresses already. The fact that we need a list of addresses you don't want to autocomplete against is not a reason to implement a separate list. It's a reason to add this feature to the address books. I already have ABs I wouldn't like to autocomplete against, and with LDAP address books there will be even greater need for this. (I'll try to remember to file a bug, if there isn't one already.) > [...] could have collums for: Blocked address, Name (if available), Date > Address was Blocked, and Comment. Certainly. But to me it seems you are now implementing a new address book. The Date field would be very nice in any address book (the others are there already). I was just cleaning up my address books and noticed I had a number of addresses for a single person. It would have been easier to remember which were obsolete and which active, had those been attached with modification dates... The one thing not yet mentioned but what you _definitely_ need is searching. The blocked addresses list is going to grow quite large. To be able to remove an (accidentally) added address, you have to find it first. If the blocked addresses were a normal address book, you would get this (and many other) features for free. I'd like to extend my earlier proposal with the following idea: There is the problem of Collected Addresses getting all the addresses of all messages, even spam, arriving to INBOX. I think it would be very useful to have per-folder Collected addresses. Opening folder properties you would have a dropdown for "Collect addresses from messages entering this folder into address book:" with a list of your addressbooks and of course some way to disable it all. What's this got to do with spam filtering? Well, we have an address book "Blocked addresses" or whatever and a filter "Move to folder Spam messages from addresses contained in Blocked addresses", like before. But we would also have Spam folder set to collect to address book "Blocked addresses"! Now when you see a spam message, you just move it to Spam folder using any of the available and familiar methods you already know (drag it to folder, use context menu, use toolbar, use menu, ...). The message goes to spam folder, the folder discovers a new message and adds its address to Blocked addresses AB. Now all the other messages coming from the same address are automatically filtered to Spam! Of course we could still have "Block address" in the context menu to make this feature more discoverable. But this would only need to be a shortcut to "move message to Spam" and it would be the only spam-filtering-related coding needed! This/these features would be as useful or even more so in other uses as well. E.g. I have an address book and filters for Mozilla related mails. Now when I get a message from a new address that my filters don't catch, the only thing I'd need to do is to move the message to the Mozilla folder. All the other messages from that same address would follow there automatically! Isn't this handy? (I'll file a RFE for this, too.)

To mimic AOL/Netscape Instant Messenger's list structure, I once created a Family, a Buddies, and a Co-Workers address book only to recombine them again due to one simple fact: It was meaningless. All I had accomplished was the creation of a functionality disadvantage (complicating address searches) while failing to create a single functionality advantage. Risto's great idea gives a "meaning" or "purpose" to an address book. I urge everyone involved with spam filtering: Stop thinking like a developer and start thinking like an end user. The current interface for filtering is too reminiscent of DOS command line construction. Filtering based on cards in an address book is the kind of GUI representation of a concept that end users love. Abandoned this current effort to create yet another "feature" for end users to ignore and consider the much more intuitive interface Risto has proposed. I tip my hat to Mr. Risto for his brilliant insight ... Again!!

Risto's arguments are pretty good. I see two problems with it though: 1. Most people do not want to retain a copy of spam in a "spam" folder. They just want to get rid of it (delete). That is what 99% of users will do - BOOM, delete. Although a nice sounding feature, it is likely to be used by few. More important is to develop and perfect the "right-click to block this address" feature. The user would get a dialogue that all *future* mail from this address will be automatically deleted. Only advanced users use filters. Only a FEW advanced users will (for reasons unknows to me) want to file spam. Therefore, it would not be too much of an imposition to expect those users to manually create a filter for spam-to-be-filed. All they would have to do is create the filter once and then copy-paste new spam addresses into the filter. 2. The per folder address collection seems uneffective and too cumbersome for regular users. To make this useful, the user would have to turn off autocollection for their inbox (that's where ALL mail goes). Many mails I get, I just delete, but I still might like to have that persons address in the autocomplete. This feature would break (brake?) that since "add to autocomple" would be disabled for the inbox. Additionally, this would cause massive cycled because the filter would fire through likely very long folders everytime something was copied into any folder with this filter. ----------------------- I do like the idea of increasing the functionality of the existing AB to include: Blocked (Y/N)? and Date Modified; instead of creating a new AB. However, address that were blocked via the context menu ("Block this Address") should be placed into a *separate* AB call "Blocked Addresses (Spam)". [brainstorming] Come to think of it, there is a difference between *Blocked Addresses* (which are not part of autocomplete AND are auto-moved to the trash) and *exclude from autocomplete*. Maybe these should be two separate boolean (Y/N) functions in all ABs. That way ... oh heck, I can't think of a use right now. But maybe someone else could. If not, then forget it ;) [/brainstorming]

I forgot to mention that if the user selects a sender to be blocked (via context menu), then (assuming that address has already been copied to the "Collected AB") that copy should be autodeleted from the "Collected AB".

Let me clarify a few things: 1) Filtering by Address Book would only present the concept in a more intuitive manner. A toolbar at the top of the address book could present the "Perform this action" section of the filter creation dialog: +---------------------------------------------------- | For Messages from addresses in this book: | [Main Action [v]] [Sub Action [v]] +---------------------------------------------------- where Main Action is "Move to Folder", "Delete", "Label", or etc. and Sub Action would change to accommodate Main Action (Folder list, label list, or etc.) The appropriate filter could then be auto generated. If I have an folder called "WorkRelated" into which I want all my co-workers' email to be stored then I could set up a Co-Workers Address Book with a default action of "Move to Folder - WorkRelated" *** Spam filtering could then be replaced / implemented as a pre-defined "Block Address Book" with a pre-defined Main Action set to "Delete" *** 2) Autocollection by Drag and Drop in Folder is a separate but complimentary feature. Instead of maintaining a filter with a long list of addresses, users could interact with an address books. An Autocollection property for folders could bring up a dialog: +-----------------------------------------+ | On Drag and Drop to this Folder: | | | | Add address to [Address Book [v]] | | | | [ OK ] [ Cancel ] | +-----------------------------------------+ If I have an address book called "Co-workers" into which I want all my co-workers address to be stored then I could set my "WorkRelated" folders Autocollection to "Co-Workers" *** The current Autocollection behavior could then be replaced / implemented by defaulting Autocollection property for all folders to "Collected Address Book" *** 3) Together, these two feature have greater powers than either alone. If I have an folder called "WorkRelated" into which I want all my co-workers email to be stored and I have an address book called "Co-workers" into which I want all my co-workers address to be stored then I could set up a "Co-Workers" address book with a default action of "Move to Folder - WorkRelated" and set my "WorkRelated" folders Autocollection to the "Co-Workers" address book. With this setup, if a new employee sends me an email all I would have to do is drag it to my "WorkRelated" folder -- the address would be automatically added to my "Co-Workers Address Book" and, hence, all future email from the new employee will be "Moved to" folder "WorkRelated". ------------------- The above is a far more intuitive way for novice end users to create and maintain filters without having to really know what a filter is. All current behaviors can be simulated. It expands the use for current Autocollection code. No special code for Spam filtering is needed. Power users can still access all the features of expanded features of custom filtering.

Ian's comment at http://bugzilla.mozilla.org/show_bug.cgi?id=71413#c23 is definitely in the spirit of what I was proposing in bug 34340. I'm not sure I'd go for the drag to folder creates filter part of it, but there's good food for thought in the proposal. Will we implement 34340 along with this bug? Seems like the same underpinnings would exist and would only need to be exposed in the filter UI.

"Autocollection by Drag and Drop in Folder" is a "Autocollection" feature and has nothing to do with filtering. It is only mentioned here because of the synergy that can be created between it and "Filtering by Address Book"

These suggestions are getting pretty far off topic. I suggest to focus on getting right-click functionality to add an address to some list. The only real decision is whether to have a separate list (ala cookies) or to add some functionality to the addressbook (ala. Blocked Address (Y/N), or a special "Blocked Addresses" AB). The other suggestions, although good, are definetely OT (and IMHO a more complex and less accessible solution. They are good for power users though). These suggestions should go into a new bug. If you like, you could make a "spam" META bug and make this bug and the new bug(s) dependant on it.

FYI, I submitted the per-folder collected addresses RFE as bug 110813.

first, i've never added a comment or written a line of code to mozilla. second, i'm here because i was thinking of implementing this feature myself. i never block addresses, i only block domains, so an address book representation of a filter is useless to me. i think the ui should allow the person reading mail to multi-select messages based on the information in the headers listbox and then right click to select "filter->by sender,by domain". and/or it should be possible to drag them into existing filters represented by icons. in other words, it should be as similar as possible to the existing process of deleting spam. further, an imap/pop server interface should be developed that allows the collection of these filters at the mail server, so that user chosen rules can be implemented there as well. should be easy with capabilities already provided with postifix and others. this gets rid of the problem of overly centralized authority with spam databases such as MAPS. These two features would be of great value to end users, and, in the case of the client/server combination, to isp's. i would love to help with this. my 2¢. ww

>> i never block addresses, i only block domains, so an address book >> representation of a filter is useless to me. A domain could easily be represent as a card with an email address of *@domain.xxx Note: I promise to refrain from making any more comments about that UI option in this bug. Thanks for the thoughtful consideration though!

as far as implementation, see http://www.mozilla.org/mailnews/arch/BlockSender.html here's an idea, that might have already been suggested: use a hidden addressbook to implement the blocked list, say blocked.mab hidden, as in you can't autocomplete against it, and it won't show up in the addressbook UI, or any of the UI elements. http://www.mozilla.org/mailnews/specs/filters/images/MailFilt5.gif is very similar to the "Select Addresses" dialog we could implement that UI with abResultsPaneOverlay.xul, rooting the nsIAbView in blocked.mab after I land the AB_OUTLINER_BRANCH, the addressbook is generic enough were we could have an addressbook with two generic columns: _BlockedValue _BlockedType _BlockedValue _BlockedType sspitzer@netscape.com email for now, we'd only support type of email. one day, maybe: _BlockedValue _BlockedType hotmail.com domain XXX subject *@netscape.net regex-email once I land the AB_OUTLINER_BRANCH, it would be easy to do all this. for now, if we only support emails, the way we'd do the compare is to search blocked.mab for a card containing the current incoming message's From: email, which is also easy to do. comments?

> we could implement that UI with abResultsPaneOverlay.xul, rooting the nsIAbView > in blocked.mab actually, we couldn't use abResultPaneOverlay.xul, we'd have to have another outliner, with different column, but you get the idea.

RE: comment #30 it sounds like an excellent idea. I particularly like the "it would be easy to do all this" part. :) My only concern: The blocked.mab probably should be accessible via some UI since it is likely that a user will want to un-block someone (because: accidentally blocked, sender repented, etc.)

The idea of using an address book has been suggested before and some were opposed to it, but I think it is a good idea. One bonus feature of using an address book is that we could probably use the address book import/export code to import/export anti-spam filter lists.

> My only concern: The blocked.mab probably should be accessible via some UI since > it is likely that a user will want to un-block someone (because: accidentally > blocked, sender repented, etc.) it will be accessable vi some UI (the blocked address UI), but not the generic addressbook UI. it will be implemented as an addressbook, but you'd only know that if you looked at the blocked.mab file, or if you looked at the code. > One bonus feature of using an address book is that we could probably use the > address book import/export code to import/export anti-spam filter lists. good thinking! That would make it much more usuable, although we'll have to make sure we continue to perform well with a large blocked.mab

another pie-in-the-sky idea about addressbooks, using AB Sync to update with spam black lists. I feel good about using a hidden addressbook for the back end. the question is now more about the front end. putterman suggested "filtering by address book / mailing list" that is also relevant.

Right, I'm just reiterating what Ian wrote in Point 1 of comment 23 which is Bug 34340. I'd suggest that we use the Block Addresses UI as currently proposed in the spec which I'll add to the url field. If we can use an AB, we could consider using a hidden filter to perform the operation rather than write all of the backend from scratch (of course this depends on how hard it is to add this new filter condition). Exposing it in the filter UI would be 34340.

> http://www.mozilla.org/mailnews/specs/filters/images/MailFilt5.gif is very > similar to the "Select Addresses" dialog ... which is currently being redesigned (bug 89495).

Bug 116931 is related.

adding self to cc list

(Sorry for not having read the previous comments, merely looking at summary) I think this is a bad idea. Spammers usually use forged or throw-away addresses or even addresses of innocent third-parties* as From, so this feature will have almost no effect, but - encourage users to waste their time by trying to block spammers - fill up their lists with useless one-time addresses - block legal senders * I have been victim of that myself recently, see <http://www.beonex.com/support/announce/news.html> 2002-02-26. So, if you happened to get that spam and blocked the "sender", you would have ended up blocking me, although I had nothing to do with the spamming.

I have to agree with Ben. Let's concentrate on what we want to accomplish before getting down to details on _how_ to implement it. A "block sender" or even "block sender's domain" feature is de facto quite useless to filter out spam (which seems to have been the main selling point behind requesting this feature in the first place). To reassure myself, I just went over the ~300 spam messages I've received and archived over the last couple of months, and less than 10% of the sender addresses and ~8% of the sender domains occured more than once.

Well, I receive over 500 spam messages EVERY DAY and I can provide you with a list of over 100 addresses and domains that do nothing but send out spam. From my experience this would be a VERY useful feature. Ask Dawn Endico if it is beneficial to block email based on the sender's domain or address.

I agree that this approach may not be the best way to deal with generic spammers but there are other steps I have taken that have dramatically reduced the amount of external spam I receive. Now, unfortunately, 90% of the spam I get at work is from specific sources within the company. These are memos, bulletins, and updates that are NOT SPAM TO OTHERS BUT ARE SPAM TO ME. At home my ISP, my bank and other services to which I subscribe, all love to send me personalize spam that no generic filter could (or should) block. It's this latter class of spam that this bug addresses. I want ... no, I demand! ... the ability to quickly and easily add or remove addresses from MY PERSONAL SPAMMER LIST. I simply will not use a mail client without it since the resulting headache would be unbearable. I already spend too much time hand filtering garbage emails for which neither approach is appropriate.

For what it's worth: I get flooded by loads of korean, chinese, japanese etc spam mail, which I even do not understand! It would be very convenient to be able to block character sets, e.g. ks_c_5601-1987. I sure hope that this is implementable! These mails also often do not have a From address, but they do have a reply-to header. Although a filter can be created to block this reply-to address, it does not seem to work: messages are not filtered if they only contain the address in a reply-to header.

Most of the comments here echo my desires for for spam avoidance. So let me add my tuppence. As an end user, blocking an address is not much use, due to the intelligence of most spammers, who invent a differnet one each time, either through forged headers or a new free isp account. Some people have already said this: http://bugzilla.mozilla.org/show_bug.cgi?id=34340#c17 A blocked senders list has been suggested: http://bugzilla.mozilla.org/show_bug.cgi?id=71413#c6 But this does not solved the problem of the "worlds-worst-offenders", perhaps 1000 people who send 100,000 messages per day (figures off the top of my head and not backed up by any research). THe spammers tactics cannot be beaten by the lowly end user alone, but in parallel, there is hope. If each message download is combined with a lookup to a *centralised* db of blocked senders (an ldap address book, perhaps), then large scale spammers could be avoided by 99.x% of the Mozilla using population. If, as an end user, I receive a message I consider to be spam, I might click on an "Inform Moz About Spammer", which sends the from address, or the subject to the db. Deciding what to block should still be done by the end user, so perhaps a threshold could be included in preferences - say - only block senders where 10, 100, or 1000 people have previously informed upon the spammer. This could possibly reduce the spammers potential audience from hundreds of thousands of people per campaign, to hundreds. This service could be open to abuse, legitimate addresses being targetted by unscrupulous folk, so perhaps a registration process would be required before a user can submit a spammer. I'm also a firm believer that prevention is better than cure, and whilst we're waiting for spam-law to catch up, perhaps the service coul de extended to inform the spammer (logarithmically) that 10, 100, 1000, 10000 etc copies of their message "Earn $$$ now" has not been delivered - this discouragement, combined with positive press might begin to discourage spammers from even attempting such braindead campaigns. Sending the info based on a log of the number of messages blocked would avoid the danger of the servioce ever being seen as a spammer. End users killfiles can get very large, to avoid this with a central DB, each entry should have a life of perhaps only a couple of weeks - long enough for people going on holiday to return, and still have their mail filtered when they open it. if the service could be extended to ISP's then so much the better - if it were directory based, then the ISP's could possibly hold their own replica of the stopped address book, and filter messages before delivery, reducing load on the central db, and reducing download times for end users. i think this would have to be a subscription service since there's probably legal issues about deleting a message before it arrives at it's recipient. also, in terms of legal issues, how likely is it that spam "companies" would seek legal recourse for infringement of their freedom of speech? so, how hare-brained does this sound? has it been said before and I've missed it? does the hardware, infrastruc

final sentence was curtailed somehow... so, how hare-brained does this sound? has it been said before and I've missed it? does the hardware, infrastructure, desire exist to implement such a service?

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

A very useful feature.

I would like to add my opinion to this thread, from a user's point of view. (I'm a developer, but not a Mozilla developer) I certainly think that using the existing address book with a category of "Blocked" which can be edited is a desirable first step. I think it would also be handy from a power-user perspective to combine the address book with filters in other ways such as filtering/filing messages based on Work/Personal/Spam. However, while we're talking address book "Black List" we should also consider address book "White List" being a precaution against users accidently blocking IMPORTANT contacts. (The white list includes everying in address book except Blocked and Collected, trying to block a white-listed contact should prompt to remove the sender from other areas of address book.) I can also see a need to block everything except white-listed contacts. I know of people who want email without the exposure to random internet noise and junk - Grandma wants to be in contact with familiy and friends, but can't cope with an inbox full of crud. In this context it makes some sense to prompt for each collected outgoing address, to add to "Approved" list in address book. So now we have "Blocked" list and "Approved" list, being "spammers" and "desired" contacts. Senders neither blocked or approved could either be blocked, accepted or bounced. A bounce would notify the sender that the email adress accepts email from only approved sources - and to contact the recipient in person, if necessary. I encourage Mozilla developers to put some resources into this - I would like to see Mozilla being the premier Internet software for average joe users, and my feeling is that solving SPAM is a killer feature for a killer app! The key issue is to allow flexible control measures that are not confusing to average users. Anti-spam is basically a security policy that Mozilla developers should be dictating - simply supplying options that users can make sense of. Cheers, Nigel Stewart

I'd like be able to simply right click e-mail messages and choose to block what I want to, as follows: Right-click e-mail, Block --> Sender --> Domain --> Words in Subject --> Words in sender's address The latter two menu items could bring up simple dialogs that allow you to block e-mails based simply on words; simplified versions of what's in current message filters system.

Block by words in subject or sender's addres are a great idea because, although the suject/sender are usually not exactly identical, there often is a common pattern that we (users/mozilla) could use to our advantage. Since the subject or sender's name could have variances, it would be useful if an edit/confirm window came up allowing the user to trim the text to the (hopefully) non-varying portion: 1. Context Menu > Block > by Words in Subject 2. Editable Dialoge: +- Block (move to spam-folder) future mails with these words in the subject ---+ | | | [ This requires your strictest confidentiality ] [exact match, any/all words]| | | | [OK ] [ Cancel ] | +------------------------------------------------------------------------------+

OH, and maybe some of this code and UI can be used for filtering/killfiling in Newsgroups. That would solve two of Mozilla's most requested deficiencies. :-D

I'd like to see the ability to not just block at the client, but to bounce the message, or to leave it on the server, as a possible filtering operation. Mailwasher (http://www/mailwasher.net) goes part way to doing these things, but is not integrated with the mail client, and so is a drag to use. G.

wontfix. we've got the bayesian spam filter, so we aren't going to do block sender. see http://www.mozilla.org/mailnews/spam.html there are other ideas in this bug, so feel free to spin them out to new bugs.

Given that: 1) The Bayesian filter will take a while to perfect 2) There are often e-mail addresses that we NEVER want to hear from again 3) The block-by sender's address would be relatively simple to implement 4) People are familiar with the idea of blocking by sender's address 5) Block by sender could easily co-exist with Bayesian filter 6) Many people want this feature I think it should be implemented. I think WONTFIX is a bad idea.If the owner things it is a bad idea, then give it up to someone who doesn't.

The problem is, block by sender isn't (and can't possibly) be very effective, because spammers rarely use the same address more than once. So it would just clutter the UI and leave users with false expectations.

I am inclining to agree with the last post. I have somehow made it to the list of some spammer. I get messages everyday promising me wealth or whatnot but never from the spams are never from the same address. So, an address based spam filter would be of little use.

I believe that this bug should NOT be WONTFIX because : 1) There are spammers who do consistantly send from the same address. 2) There are mailing lists from which it is impossible to unsubscribe that consistantly send from the same address. 3) There are reasons for wanting to block mail from a specific address that have nothing to do with spam.

mark@ky.net makes a good point. There are reasons besides spam for wanting to exclude a particular address. Besides the mother-in-law that we do not want to hear from, there are some nuisance senders who have managed to get hold of my address and sent me trash for the longest time.

reopening for consideration by module owner (see also bug 134365) by the way, you can create a filter by right clicking on the sender's address in the message header and choose "Create filter form message...". Or you can do so via the Message menu.

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

I am now using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212 However, the option does not appear by right clicking. I works ok from the menu, however.

taking all of varada's bugs.

we're not going to implement this. you can do this with filters. there's no need for another way to do this. and we've got bayesian spam filtering.

Seth, no offense, but I think you missed the point. This bug is simply about adding a context menu item. "you can do this with filters. there's no need for another way to do this." Huh? This bug is about providing the means to create a filter via an email link context menu. "and we've got bayesian spam filtering." The bayesian filtering is irrelevant to this bug. Although some comments here have been about spam, there are various justifications for this bug that have absolutely nothing to do with spam.