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 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..