[Dovecot] global vs user script

[Mark E. Mallett]

On Tue, May 08, 2007 at 08:45:31AM +0200, Steffen Kaiser wrote:
> 
> On Tue, 8 May 2007, M1 wrote:
> 
> I glanced over the current Sieve library (CMU):
> 
> >1) 3 global scripts, 1 execute before user script, 1 execute after user 
> >script, 1 execute only if there is no user script.
> 
> I didn't found an easy way to let the parser read in more than one script 
> in a row. There is a function that translates just one file into the 
> bytecode. It is not iterative.
> 
> >2) Call global script from user script or call user script from global 
> >script.
> 
> Maybe, one could expand Sieve to have some sort of "include" statement. It 
> could work.
> 
> However, there are at least two other Sieve implementations, too, there 
> had been some suggestions to look into them, but nobody jump into til now.

Speaking as the author of one of them, maybe, depending on whether mine
was one of the two you refer to, I can say how my implementation handles
it.  

This is only quasi-on-topic, hit 'd' if you don't care; I hesitated
quite a while before responding since I've rambled on about it here
before, but in the end wasn't able to resist, as you can see.

mvmda, which is the beast I refer to, is intended to be both
system-admin-friendly and expert-user-friendly.  Having both those
things at once is hard to arrange.  One of the ways it tries to do this
is to defer a lot of its control flow and logic to a site-wide script,
which the system administrator must install and tweak (well, you can get
by without one, but that would be another tangent).  This would be the
global script.  The global script executes in an "admin" mode in which
all permissions are enabled, meaning that the global script can pretty
much do what it wants.  A typical script ("typical" because I'm using
one like this and because one like it comes with the distribution) would
do something like:

 - define namespaces and mailstore locations, probably tailored to
   the specific user being delivered to;

 - interpret any command line arguments as if they were script file
   names, and attempt to run them (e.g. from the user's homedir or base
   dir), each in turn, with admin mode turned off;

 - if no scripts are found, attempt to run one with a standard name
   (e.g. "filter.mfl" or "filter.sieve" -- so no script need be named on
   the command line);

 - if still no scripts have been found, attempt to run a system-wide one
   (the name could be derived from the username or the user's group name
   or any other variable information, to provide for classes of global
   scripts).

Since control always returns to the site-wide script, there can also be
common post-user-script actions taken.

The scripting language is an mixture of Sieve and C-like constructs.
User-level scripts need not use anything other than Sieve, but the
system-wide script pretty much has to use non-Sieve elements (and
advanced script writers can as well).

http://www.mvmf.org/

I'm actively using it in dovecot environments as well as in UW
environments, and in qmail as well as sendmail environments- it adapts
well.  One downside is indeed the requirement for a system-wide script
and potentially other system-wide stuff, as that presents a steeper
install/learning curve than you might expect from a delivery agent.  On
the upside, you can get a lot of consistency at the user script level,
and you also get a nice qmail-smtpd replacement :)

mm