 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
7 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Automatic SPAM le...| From | Sent On | Attachments |
|---|---|---|
| Soeren D. Schulze | Jun 23, 2007 11:55 am | |
| Jérôme Blion | Jun 23, 2007 12:10 pm | |
| Alessandro Vesely | Jun 24, 2007 2:22 am | |
| Soeren D. Schulze | Jun 24, 2007 4:03 am | |
| mouss | Jun 24, 2007 11:40 am | |
| Alessandro Vesely | Jun 24, 2007 3:41 pm | |
| Soeren D. Schulze | Jun 25, 2007 1:48 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [courier-users] Automatic SPAM learning | Actions... |
|---|---|---|
| From: | Soeren D. Schulze (soer...@gmx.de) | |
| Date: | Jun 24, 2007 4:03:55 am | |
| List: | net.sourceforge.lists.courier-users | |
Alessandro Vesely wrote:
Soeren D. Schulze wrote:
Hello,
I found the following patch:
http://da.andaka.org/Doku/imapspamfilter.html
To describe it briefly, it automatically trains the SPAM filter when the user moves messages to a SPAM or HAM folder.
First, what do you think about this in principal?
I see two design issues: 1. The user does not have the chance to use his own preferred settings, as everything is controlled by an environment variable. 2. The server freezes until the SPAM learner has done its job.
I liked that patch when I first saw it. Thinking twice, I found no way to turn it into a sound generically useful improvement that Sam can accept.
Training a filter is an interactive job. Blindly moving messages will always lack feedback or context sensitive help. Users will have a hard time trying to match that with their client's spam filter settings.
You mean such an interface would be confusing to some users? May be true.
On the other hand, moving messages is much more convenient than acting on the mail client and the command line at the same time.
But a clever cron solution might also do the job (thanks, Jérôme), even though not so well. For my own usage, I am considering a setup where my SPAM filter drops the mail into some folder, I then sort it and put it in an Actual-SPAM and Actual-HAM folder, and a cron job cleans the Actual-SPAM folder and reprocesses the Actual-HAM folder as if it was new mail.
In addition, it will be incompatible with webmail. In my case, the latter is primarily needed during off-site work or vacations, which is exactly when light travelers mostly miss their client's spam filters. Hence, I realized it's not much of an option for me.
I don't understand. As long as you are able to move messages with your webmail, it would work.
Or are you talking about a configuration where you fetch your mail into your Courier server from another webmail provider?
Personally, I would solve it by specifying a new column (or more than one) in the user database which includes the SPAM policy. The learning would be done in the background without the server waiting for the process to finish.
And how do users set their own policy?
I was thinking about some columns in the password database. Users can specify where their filter has put the filtered messages, where they put them in order to confirm they are SPAM, where they move HAM messages in order to re-process them by maildrop, etc.
What would be a bit more flexible is a user's callback script that is run whenever a user moves a message.
Sören