Soeren D. Schulze wrote:
Alessandro Vesely wrote:
Soeren D. Schulze wrote:
[...]
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.
A cron- or fam- driven job would. A patched imap daemon would only invoke
external commands when it moves the files itself, if I remember correctly.
Webmail operates on files directly, without bothering the imap daemon.
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.
That makes sense. I still don't understand if users have direct access
to the password database. Are you planning to produce ad hoc web modules?
What would be a bit more flexible is a user's callback script that is
run whenever a user moves a message.
That's the idea of the above mentioned patch. Webmail would require a
similar patch. The resulting scheme may work, but is very rigid because
moving files to or from dedicated folders are the only communication.
Design changes are likely to require more dedicated folders... Yes,
I think it may be confusing for some users.
7 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Automatic SPAM le...
