Manuel Lemos wrote: > Hello, > > I thought that some of you would like to know that I just posted this > design proposal for an anti-spam add-on to Mozilla Mail/News in > news:news.mozdev.org/public.mozdev.mozspam . > > Like I just realized about the existence of this news groups (also > available as mailing list with Web archive), I think some of you would > like to follow up there. >
I know there have been a number of developers thinking about anti-spam features for Mozilla. Ideally, we can end up with some spam-prevention features that are actually a part of Mozilla Mail, not just an add-on. I'll ask those I know of to join the discussion here... thanks for kicking this off. > Subject: mozspam design proposal > From: Manuel Lemos <[EMAIL PROTECTED]> > Date: Sun, 23 Jun 2002 04:31:14 -0300 > > Regardless if and how this could be implemented here follows a summary > of how I think it should work. > > Most of e-mail anti-spam systems filter messages on the mail server side It's true, this is very common. The server provides an ideal place to do spam filter, in large part because things can be queued there, and instant responses from (eg) blacklist/whitelist lookups are not required. > but that is no good to me because most of them use rules that are too > generic and often confuse messages that you want to receive with real > spam, even if those messages would be considered as spam by others. I don't understand what this has to do with server-side vs. client-side solutions. Most spam-filtering systems have some set of rules, often including blacklist/whitelist lookups. Additionally, most have the option of putting some messages aside for inspection by humans, in large part because, as you've noted, they don't get it right all the time. Is the distinction you're making that it's the end-user receiving the mail who gets to do this judging, rather than a server admin? > So what I propose should work this way: > > - Operation should be split in two parts: filtering and action. > > - Filtering is determines if a messages is considered to be spam, not > spam or maybe. Besides the usual rules for filtering, there should be a > way to add more methods to figure if a message is spam/not/maybe. A couple of possibilities for expanding basic filtering capabilities that have been floating around for a while include regular expression-based filters, and javascript filters (like those available in 4.x). Neither of these should be terribly difficult to implement. > This should allow the addition of plugins, maybe using Javascript to query > remote knowledge anti-spam knowledge bases like Razor's. I like the plugin idea. It seems likely that XPCOM can provide us with all the plugability that we need. Remote databases, like Razor, DCC, etc have an added challenge: because they require accessing the network, so response may not be immediate. This is one of the reasons that server-side solutions are somewhat better suited to spam-filtering functionality. We would likely need to queue up any messages received into a "Spam Processing" folder, and not actually deliver them to their final mailboxes until some background thread has gone through and looked up each message. This has some implications for folks who want to download messages for offline delivery as well. > - Action should be a list of known actions to apply in each of the three > situations that the filtering part determined. There should be the > possibility to add more actions, maybe using Javascript plugins. > Built-in actions could be: delete message, move message to a standard > folders to be named like "spam" and "maybe spam", leave message in in > inbox flagging properly, report possible spam to existing knowledge > bases. All actions should have an additional property that would tell if > they should be executed auto-matically or ask the user first. Sounds reasonable. One of the interesting things about a spam-filter feature is that there probably needs to be a couple levels of UI available, one basic, and one more detailed. Figuring out the best way to put this together in a way that's easy to interact with will be one of the bigger challenges, I think. FWIW, I like "Possible Spam" as a folder name. > - Users should have a way to specify exception rules that would override > automatic actions associated to some filters, like those that query > remote spam knowledge bases, so users can override the decision that > others made that some types of message are to be considered spam but > they disagree. This is something that I suspect only advanced users are likely to be able to formulate in any meaningful way. > I could detail this more, but for now it should be enough to kickoff a > healthy discussion on what should be a useful Mozilla based anti-spam > extension. Thanks for bringing this up; with luck some other folks will chime in as well. I've spent some time looking over the various spam filters that are available on the net lately, and I've heard a bunch of good things about SpamAssassin. I suspect we'd do well to model our filtering after theirs; they have useful ways of classifying things such as whether matches happen in headers, body, both, etc. Dan
