till schrieb: > On Tue, Jul 14, 2009 at 4:57 PM, Andreas > Wenk<[email protected]> wrote: >> till schrieb: >>> On Tue, Jul 14, 2009 at 4:12 PM, Andreas >>> Wenk<[email protected]> wrote: >>>> till schrieb: >>>>> On Tue, Jul 14, 2009 at 1:36 PM, emi<[email protected]> wrote: >>>>>> Hi, >>>>>> If you're going to do a filter plugin, I see three ways to do so: >>>>>> * Implement a unique plugin that will be able to handle multiple >>>>>> filtering >>>>>> systems (client-side, sieve, exim, etc) >>>>>> * Implement multiple plugins, one for each filtering system >>>>>> * Implement one general plugin with some hooks (Filter API) where each >>>>>> particular plugin (client-side, sieve, etc) would use them >>>>>> >>>>>> Just as a suggestion, I recommend to implement the simpler one (just >>>>>> client-side filtering plugin, as you say) and then see wich of these >>>>>> options >>>>>> is better/easier to implement and to manage. Personally, I'd prefer the >>>>>> thirst solution, which is extensible, clearer and faster (I suppose). >>>> +1 >>>> >>>>> I'm inclined to agree. :-) I wanted to write a plugin for dspam as >>>>> well. I think providing an "internal" filter API and offering drivers >>>>> would be the best solution, but that's just my personal opinion. >>>>> >>>>> Till >>>> hopefully you will agree ;-) >>>> >>>> I think this would be the best solution. Starting with a simple filtering >>>> and leave it extensible. So now that turns me on but actually I don't >>>> know >>>> yet if I have the time to start writing a plugin for that - especially >>>> because I have to learn the plugin structure before (but it seems to be >>>> very >>>> clear). >>>> >>>> Filtering was the first thing I missed in roundcube. I'll keep you >>>> informed >>>> ... >>>> >>> Feel free to ping me wherever if you need help. Also, do you have >>> something else on the server? I'm wondering if cpanel etc. offer an >>> API to add/edit filters too. >>> >>> Till >> Till, thanks a lot for the great offer ;-) I will do so ... >> >> Actually our mailserver setup is fairly simple. We use postfix for smtp and >> courier for POP and IMAP. Then, the user accounts are virtual and placed in >> a postgresql database. Postfix is giving the mails to Spamassasin and ClamAV >> (handled by Amavis). That's the only filtering we have. Because of that >> (among other pounts) I like the client side filtering in roundcube most ;-) >> >> Cheers >> >> Andy > > Yeah, point taken. The [Our] argument for server-side filters are that > they can work email before you pick it up. E.g. push email into > folders, delete email, etc.. With client-side scripting you re-create > rules in each client you end up using. E.g. webmail, desktop, and > maybe even mobile.
agreed - this is a good reason for having server-side filters. In my first post I was allready wondering how a client-side filter will decrease performance. > Among those things is also the auto-reply feature (aka "vacation") -- > imho useless, when it's webmail based and only executed once you > access the inbox. Instead it needs to be on the server and executed > when email comes in not three days later when I get back to email. > [All IMHO, of course.] Totally agreed - but I see a auto reply functionality as an extra plugin - which would be really cool to have for sure ;-) (maybe this sohould be a next one). Actually we don't offer that (because only one person asked for ;-) ) although Suirell Mail has such a plugin I think. Just an idea concerning auto reply - would it be possible to have a "cronjob" running checking if there is set up an auto reply and then send the auto reply message? Maybe this could be a perl, ruby python script .... sure I don't wanna destroy the principle architecture ;-) > I do see the obstacle people face when they have no control over the server. This is indeed a problem for single user - but on the other hand software like roundcube will help them out ;-) > Till Cheers Andy _______________________________________________ List info: http://lists.roundcube.net/dev/
