Bug 89222 - make spam-filtering independent of normal filtering-gui
Summary: make spam-filtering independent of normal filtering-gui
Status: RESOLVED WAITINGFORINFO
Alias: None
Product: kmail
Classification: Applications
Component: filtering (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-10 11:13 UTC by S. Burmeister
Modified: 2012-08-19 00:49 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description S. Burmeister 2004-09-10 11:13:39 UTC
Version:            (using KDE KDE 3.3.0)
OS:                Linux

It is argued that kmail will not develop its own anti-spam engine, as this would mean the re-invention of the wheel. After some discussion I found out for myself, that this makes sense for the engine itself. Yet exatly this argumentation is ignored by re-inventing the GUI-functionalities for the user to handle spam in kmail instead of using Mozilla's GUI-functionalities which have proven to be robust and sensible, so why re-invent?
 
"Normal" filters created by the wizard are not robust:
- they can be deleted by mistake
- are not deleted when re-running the wizard (pile up!)
- toolbar_filter_actions cannot be brought back
- there are duplicate entries in the toolbar-configuration (bug 89216)
- there are problems handling the filter-buttons in the toolbar (crashes)
- there are problems to bring them back to the toolbar when toolbar_filter_actions is deleted (bug 89221)
- even if the above works it includes all manual filters wasting space in the toolbar
- they do not have a shortcut (bug 89217)
- they are not accesible from the spam-column in the message-headers field to (un-)mark (bug 89217)

Thus spam-filtering should be independent of the normal filtering GUI.

I would like to suggest once more to use bogofilter or another external bayesian tool with hardcoded filter rules in order to simulate an internal anti-spam-tool and provide exactly the same funtionality as Mozilla does, i.e. not re-inventing this part either. The current wizard can be preserved, although advanced users do not need it anyway.

A copy of Mozilla's functionality includes a configuration-tool in the kmail-configuration:
- to select a folder,
- whether to move mail manually marked as spam,
- whether to delete spam older than x days,
- whether to show the spam button in the toolbar, i.e. using it on a non-spam message marking it as spam, using it on a spam-message to mark it as ham,
- provide a column in the messages-field to not have to move the mouse to the toolbar to (un-)mark a mail as spam,
- provide a shortcut to (un-)mark mail as spam.

The current wizard does not store any configuration which results in a lack of functionality, e.g. not deleting duplicate filters

The functionalities are already in kmail, they just have to be assembeled. Mozilla's way (not the internal tool, just the way to mark, way to set up...) has proven to be useful, so one should not try to re-invent the wheel and waste time on handling all the problems that come up with it.
Comment 1 S. Burmeister 2004-09-16 20:42:40 UTC
As a proof that my claims about the potential issues with unexperienced users altering/deleting filters I would like to point to bug 89569. I would think that unexperiencd users do not file that many bugs, so one can multiply the users having these issues by many more times than it would be the case for issues bothering experienced users that file a bug about it.
Comment 2 Tom Albers 2004-09-16 20:59:38 UTC
Sven, overloading us with referals to bugreports which we have already read costs a lot of time and does not help. Vote at the bugs and wishes help (and keeping the wish compact). This area is of course work in progress. 
Comment 3 S. Burmeister 2004-09-17 12:24:33 UTC
> ------- Additional Comments From tomalbers kde nl  2004-09-16 20:59 -------
> Sven, overloading us with referals to bugreports which we have already read
> costs a lot of time and does not help. Vote at the bugs and wishes help
> (and keeping the wish compact). This area is of course work in progress.

Ok. I just think that because it would mean a lot of "wasted" time one sticks 
to the current way of handling rather than re-thinking it. That's why I tried 
to get as many hints into the bug that proof that there are serious issues.

I'll try to get rid of that skepticism and not cause more work than necessary. 
When I get my internet-connection back I'll try to get you a bit of work out 
of the way by answering bugs that are in my scope of knowledge, so that you 
guys can concentrate on the real issues.

Sven

Comment 4 Juha Tuomala 2005-03-22 11:42:32 UTC
I'm against this. Make it separate tool and keep the kmail light, simple and stable. 

Most people do their spam filtering in server and don't want their desktop become more bloated because of spam. KDE should not follow M$ with bloating.
Comment 5 S. Burmeister 2005-03-22 12:04:03 UTC
Hello, hello!

Somehow I cannot follow you. You want to have it seperate, yet you are against this bug-report which wants it to have seperated? Or are you against all kind of anti-spam functionality in a mail-client?

Thunderbird is light, simple and stable, so this is not really an issue for not implementing kmail's own engine, yet this is not even part of this bug-report.

Further, most people do not have a server, so they would have to rely on their provider without the ability to train that tool, unless they use webmail, which they do not, as they use kmail. Of course they can set-up spamassasin on their own desktop, yet you did not want it to be bloated, did you not?

As far as I know, thunderbird and other email-clients are not owned by MS and had anti-spam tools a long time before MS considered it, so integrating an anti-spam engine is not an MS way either. Yet again, this is not about integrating kmail's own anti-spam engine.

This bug report is simply about not mixing anti-spam filters with other filters and implementing functionality tested in other GUIs for a long time, i.e. not trying to re-invent the wheel.
Comment 6 Ingo Klöcker 2005-06-06 00:19:58 UTC
Making spam-filtering independent is difficult because then it won't be possible to control when the spam filters should be applied. Usually it doesn't make that much sense to apply the spam filters to all messages because it's slow and checking obvious non-spam is just a waste of cpu time. A possible alternative would be to run the spam filters only on messages which haven't been marked by other filters as "non-spam".

Some of the problems that you mentioned should be fixed though, i.e. we should at least show a warning when the user tries to delete the spam filters and rerunning the wizard should not create duplicate filters.
Comment 7 Maciej Pilichowski 2008-02-05 17:56:46 UTC
Is this report still valid? KMail can use bogofilter (I use it) for some time now.
Comment 8 Myriam Schweingruber 2012-08-18 08:08:42 UTC
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented.
Thank you for your understanding.
Comment 9 Luigi Toscano 2012-08-19 00:49:17 UTC
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.