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