I think trying to patch in little solutions to how sieve currently works are going to meet with problems that the current model wasn't designed with this kind of broad functionality in mind. Going to a slightly different model would not only solve this problem, but others as well.
Here's what I would propose: --* In addition to the user sieve directories, add an additional directory tree for system scripts. However, rather than make the directory structure tied to mailbox names, have it be a separately organized general repository for scripts. If you want to get fancy, maintain ACLs on the scripts as to who can read them, activate them, write them, and administrate the rights on them. (rewa?) Munge the namespace on the sieve scripts such that all system scripts start with system: and use colons to demarcate directories, so that $systemscriptdir/spamcontrol/rejectrelays is available in the script namespace as system:spamcontrol:rejectrelays . --* Change the way the scripts are invoked so that a single mailbox may have multiple scripts attached to it. Store this list of attached (activated) scripts in the cyrus.header file of the mailbox. Have lmtpd execute the scripts in the order in which they are listed. --* Allow users to manipulate the scripts in their own private user space, but additionally allow them to activate system scripts. For example, if the user specified the following list: "default myforwards system:spamstopper", mail delivered would execute "default" and "myforwards" in their own personal space, then execute "spamstopper" as stored in the system directory. --* Execute all scripts as the user whose mailbox is being delivered to, or in the case of shared mailboxes, er, refer to earlier discussion... :) This is an awful lot of coding and patching, I realize. I'll be happy to give it a shot, but I unfortunately can't get into it for another month or so (other stuff on the plate). I know this sort of model would work better for us; I'd be interested to hear if this would work for other people. Michael
