Hello, On 07/03/2002 12:30 AM, Dan Mosedale wrote: >> 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.
Yes, that would be ideal. A built-in and powerful spam filtering advisory system would be a killer feature for Mozilla. >> 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? I don't trust server admin decisions. Simple example, ACM has decided to install some spam filtering system that dumped many personal messages (read solicited) as well messages from Yahoo groups to which I voluntarily subscribed. They goofed because they outsourced the spam decision system that was certainly based on the wrong assumptions of what is spam or it isn't. I'd rather not use any filtering that discard solicited messages and get all the spam in the world than to be forced to trust somebody decisions what is spam. >> 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. Yes, but keep in mind that spam and virus have pretty much the same problem: it keeps coming in new forms. So what I think it would a be a killer feature would be to be able to update new sets of spam filter rules that you download before you even download your e-mail from a central server that keeps being updated with new sets of rules by volunteer reporters. This way you avoid getting spam and virus that was already detected and reported by other users. >> 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 I think that most people will not be able to use server-side solutions. > 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 It seems that SpamNet plugin of Cloudmark for Outlook seems to be an efficient solution. Take a look: http://www.cloudmark.com/ > implications for folks who want to download messages for offline > delivery as well. Can't have it all because the rules of what is Spam and what isn't are not static and if you have to query an online database to figure it out, there is no magic that will solve the problem for users reading messages offline. All you can do is to process black/while listing rules first. >> - 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. Yes, I think the default configuration should remain to not filter anything to not confuse inexperienced users. >> - 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. Sure. Anyway, I see this a simple list of currently set rules that you can disable on your current blacklist rules or additional rules that you can add to your white list rules. Regards, Manuel Lemos
