RE: [Dovecot] Hooks on folder operations
Hi Grahame,
Hi all,
I'm interested in implementing an anti-spam system using bayesian filtering. I had the idea of modifying and IMAP server to assist in training the spam filter. Why do you want to hook it up into your imap server? I think it would be better to prevent emails to enter the mailbox with the MTA rather than removing it when the user is reading his email using imap.
Why? Because the spam that is in the mailbox might push the user over his quota limit, and thus preventing legitimate emails to be delivered.
I was thinking of running a program whenever a message in moved to the folder "Spam" or to a "Safe" folder. This could be easily added to the server as a generic feature, with hook programs for: possible.
- new message in a folder (either new, or moved into the folder)
- message in folder is modified
- message in folder is removed and so on. If the support was generic enough there could be many uses for it. Security of the external program needs to be considered but doesn't really affect the IMAP server itself. With the new API code that Timo is making now, I guess this would be
(After all: if quota's are updated, something was written to the mailbox, or deleted of course!)
Anyway, if I were to write a patch to add support for running an external program in these cases, would it be included? Any feedback would be appreciated, if I'm going to do this I might as well do it in a way that can be integrated back into the main tree! You can always build a plugin, and plugins can be loaded whenever an administrator wants them to load. I don't know if Timo wants to include all plugins that are / will be written for dovecot, but I guess there might be a plugins part, where people can "post" their plugins so other people can benefit from them :)
Cheers Grahame
Kind regards,
Maikel Verheijen
On Wed, 2003-07-23 at 17:50, Maikel Verheijen wrote:
I'm interested in implementing an anti-spam system using bayesian filtering. I had the idea of modifying and IMAP server to assist in training the spam filter. Why do you want to hook it up into your imap server? I think it would be better to prevent emails to enter the mailbox with the MTA rather than removing it when the user is reading his email using imap.
Why? Because the spam that is in the mailbox might push the user over his quota limit, and thus preventing legitimate emails to be delivered.
Well, I'd actually want that too. I don't have quota problems and I make spamassassin put all spam into spam mailbox. The few spams that go through to inbox I usually just delete because I'm too lazy to make spamassassin's bayesian filter to learn it. If I only had to move them to spam mailbox, I'd probably do it :)
With the new API code that Timo is making now, I guess this would be possible.
Yep.
You can always build a plugin, and plugins can be loaded whenever an administrator wants them to load. I don't know if Timo wants to include all plugins that are / will be written for dovecot, but I guess there might be a plugins part, where people can "post" their plugins so other people can benefit from them :)
I'll probably just add a plugins web page. Some of the most useful ones I'll include in the tarball. Also I'll make it possible to compile the plugins into the main binary so there's no overhead in dynamically loading them.
At least quota and ACLs are going to be plugins. I'll make sure my APIs are flexible enough to allow that.
On Wed, 2003-07-23 at 23:17, Timo Sirainen wrote:
On Wed, 2003-07-23 at 17:50, Maikel Verheijen wrote:
I'm interested in implementing an anti-spam system using bayesian filtering. I had the idea of modifying and IMAP server to assist in training the spam filter. Why do you want to hook it up into your imap server? I think it would be better to prevent emails to enter the mailbox with the MTA rather than removing it when the user is reading his email using imap.
Why? Because the spam that is in the mailbox might push the user over his quota limit, and thus preventing legitimate emails to be delivered.
Well, I'd actually want that too. I don't have quota problems and I make spamassassin put all spam into spam mailbox. The few spams that go through to inbox I usually just delete because I'm too lazy to make spamassassin's bayesian filter to learn it. If I only had to move them to spam mailbox, I'd probably do it :)
With the new API code that Timo is making now, I guess this would be possible.
Yep.
Ah, cool.
The idea (I don't think I was clear enough) is to allow the user to move their spam into the "spam" folder manually. This is for spam that gets through the filter. When the mail is moved, a program runs (at the instigation of the IMAP server) that parses the spam email and updates the statistical information used to detect spam.
Actual detection of spam is done in the local delivery agent, rather than in the IMAP server :-) We do tend to store mail we think is spam so the users can check, as most spam detection systems get a lot of false positives.
You can always build a plugin, and plugins can be loaded whenever an administrator wants them to load. I don't know if Timo wants to include all plugins that are / will be written for dovecot, but I guess there might be a plugins part, where people can "post" their plugins so other people can benefit from them :)
I'll probably just add a plugins web page. Some of the most useful ones I'll include in the tarball. Also I'll make it possible to compile the plugins into the main binary so there's no overhead in dynamically loading them.
At least quota and ACLs are going to be plugins. I'll make sure my APIs are flexible enough to allow that.
Great - I'll look at this at work in the morning. Thanks for the idea, I'll look at implementing this as a plug-in.
By the way, thanks for your work on Dovecot. I'm looking at moving quite a few systems over to it from UW-IMAPd. It's really very good :-)
-- Grahame Bowland Email: grahame@ucs.uwa.edu.au University Communications Services Phone: +61 8 9380 1175 The University of Western Australia Fax: +61 8 9380 1109 CRICOS: 00126G
On Thu, Jul 24, 2003 at 12:32:22AM +0800, Grahame Bowland wrote:
The idea (I don't think I was clear enough) is to allow the user to move their spam into the "spam" folder manually. This is for spam that gets through the filter. When the mail is moved, a program runs (at the instigation of the IMAP server) that parses the spam email and updates the statistical information used to detect spam.
Actual detection of spam is done in the local delivery agent, rather than in the IMAP server :-) We do tend to store mail we think is spam so the users can check, as most spam detection systems get a lot of false positives.
I can see where that kind of thing would be useful- to have a hook on moving a message so that the message could essentially be reprocessed. One could do this to re-apply filters or to test a new filter set. (Or, as somebody said, to be assimilated into a spam database.)
Of course to truly re-deliver a message it would be cool to have a folder type that was a essentially a pipe. You could use IMAP commands to move a message to the folder, and the result would be that it got piped into whatever agent you had specified. One could have various folders to accomplish things like "refile" or "report as spam" or "open a ticket" or "redistribute to a group" or anything.
By the way, thanks for your work on Dovecot.
Indeed!
mm
On Wed, 2003-07-23 at 21:12, Mark E. Mallett wrote:
Of course to truly re-deliver a message it would be cool to have a folder type that was a essentially a pipe. You could use IMAP commands to move a message to the folder, and the result would be that it got piped into whatever agent you had specified. One could have various folders to accomplish things like "refile" or "report as spam" or "open a ticket" or "redistribute to a group" or anything.
Hmm. I suppose a named pipe/socket could work as a mbox..
participants (4)
-
Grahame Bowland
-
Maikel Verheijen
-
Mark E. Mallett
-
Timo Sirainen