Back to message filtering

Steve Block scblock at
Fri Apr 7 17:44:26 CEST 2006

On Fri, Apr 07, 2006 at 10:27:16AM -0500, Trae Dorn wrote:
>Server side filtering is not available to many, and most desktop clients 
>have the capability.  Should it be a focus in RoundCube's development at 
>the moment? Probably not - but long term I think client side filtering 
>is a logical feature for RoundCube.
>-Trae Dorn
>Josh King wrote:
>>On Fri, 7 Apr 2006 08:35:06 +0800, "Derek Hinchliffe" 
>><iamplebian at> wrote:
>>>I think Roundcube still has a way to go in some other more common
>>>areas of webmail functionality before anyone tackles filtering in a
>>>big way.  But I would also question whether a webmail system is the
>>>right spot for mail filtering.  This really should be done at the mail
>>>server level.  That way the filtering occurs regardless of how you
>>>view your mail (eg. some days you might access it through Thunderbird,
>>>other days through Roundcube - you don't want to have to maintain two
>>>different sets of filters).
>>>What is appropriate for a webmail client however is some sort of hook
>>>into that backend filtering system so that you have a nice way of
>>>configuring it within the webmail.  An example that comes to mind is
>>>there is a plugin for squirrelmail that lets you manipulate sieve
>>>scripts on a cyrus backend.  I am almost certain there would be a
>>>similar procmail one if you looked around.
>>>So the best way would be to write the filtering interface as
>>>generically as possible, then write seperate backends for the various
>>>filtering systems around (procmail, sieve, etc).
>>>But my main point is, in the meantime there is nothing stopping you
>>>from having filtering with your roundcube - it all depends on what
>>>mail system you use in the backend.  You just have to configure it in
>>>there instead of having the convenience of doing it through roundcube.
>>Just my $0.02, but I would have to agree with Derek here. Adding filtering 
>>would, IMO, take RC from being a client to an LDA (local delivery agent) 
>>and could cause issues for those who already have this functionality 
>>handeled within procmail, etc. .
>>Focusing on being the most able webmail client and having some ability for 
>>plugins to be added to have this functionality would be much more 

Looking this thread over, it seems that it may be best to do something 
along these lines:

Option 1:
  Build a plugin architecture
  Build a filtering interface on top of that
  Have different backend drivers for that filtering interface. 
    Candidates would include procmail, sieve, maildrop, and 
    roundcube-based filtering. The last would perhaps run when the 
    user logs in or checks for new mail.

This is similar to how Horde handles filtering. A semi-separate 
application (ingo) handles filtering with a standard interface, and 
there are various backend drivers to choose from including filtering at 
by the webmail program itself.

Option 2:
  Build a plugin architecture
  Let people build filtering plugins for it.

This option is more like squirrelmail's handling. The avelsieve plugin 
driver I use with SM looks and feels much different than the procmail 
driver that is available. I think this option is simpler and probably 
more lightweight, but it is also less consistent.

Either option could allow one to write a filtering that is actually 
handled within RC, but could alternatively use whatever server-side 
filtering system is available to the user.

Steve Block
scblock at

More information about the Dev mailing list