On Sat, Nov 20, 2004 at 06:24:08PM -0500, Roger Sistla wrote: > I'm not sure how much work this would be to code or if it breaks > any IMAP RFC's. Your comments would be welcome, even if you think > this idea is way out in left field.
I've been thinking about a similar solution, but using only one specially named folder and a cron job reading the folder. Our two approaches each have benefits, I think your way is indeed more elegant, but it may also be problematic if LOTS of users bang on the server at the same time - requiring massive fork()s, which are expensive. Nevertheless, I think the general concept is great; being able to extend Binc per folder, much like I'm able to extend qmail per mailbox using .qmail files. For things spammy I would certainly want to control some of these extensions (or perhaps hooks is a better word) centrally, but for power users it could also be very useful to put .binc files in folders, triggering different actions when the client tries to store a message in the corresponding folder. Then there's the question of IMAP breakage. For the particular case with spam learning/unlearning I see no reason it should be an issue. The message simply stays in the folder until it is deleted. I would set up cronjobs to delete (old) files from each user's learning folder(s) on my system, or just tell users that they first have to move the message to the learning folder, and then delete it, in order to train the filter. For the general case there may be a problem if the message doesn't actually get stored in a folder so that it is retrievable by Binc again, if Binc's IMAP reply to a message delivery to this folder implies (according to the standard) that the delivery succeded. The risk here is that the client will get confused when trying to read the same folder, and finding it's empty. But I don't know enough IMAP to say whether this is an issue. Anyway, I think these folder hooks is a really good idea! :) What do others think? Andreas? //Peter
