Closed Bug 71413 Opened 24 years ago Closed 22 years ago

Right click filtering (i.e. "Block this Address" in context menu)

Categories

(MailNews Core :: Filters, enhancement, P2)

Product:
MailNews Core
Component:
Filters
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX
Milestone:
mozilla1.2alpha

People

(Reporter: Peter, Assigned: sspitzer)

References

(Blocks 1 open bug,
URL
)

Details

(Whiteboard: You can create a filter by right clicking on the sender's address in the msg header or from the message menu) 

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. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: esther → laurel
Summary: Improved Spam Filter: right click on incoming mail address and select "Block this Address" → Spam Filter: right click on incoming mail address and select "Block this Address"
reassigning to naving
Assignee: gayatrib → naving
*** Bug 85590 has been marked as a duplicate of this bug. ***
Keywords: mozilla0.9.2
Keywords: ui
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
Assignee: naving → varada
Keywords: mozilla0.9.2
Target Milestone: --- → mozilla0.9.6
Blocks: 102231
Keywords: nsbeta1
Depends on: 106186
marking nsbeta1+
Keywords: nsbeta1 → nsbeta1+
moving to 0.9.9
Target Milestone: mozilla0.9.6 → mozilla0.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).
Priority: -- → P2
No longer blocks: 102231
Keywords: nsbeta1+ → nsbeta1-
Target Milestone: mozilla0.9.9 → mozilla1.2
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
Blocks: 11035
OS: Windows NT → All
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.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
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.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: Spam Filter: right click on incoming mail address and select "Block this Address" → Right click filtering (i.e. "Block this Address" in context menu)
Whiteboard: You can create a filter by right clicking on the sender's address in the msg header or from 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.
Assignee: varada → sspitzer
Status: REOPENED → NEW
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.
Status: NEW → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WONTFIX
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.
Product: MailNews → Core
Product: Core → MailNews Core
See Also: → 223716
You need to log in before you can comment on or make changes to this bug.