Hi Cyrus and list,
One of the issues raised in San Diego was how to upload scripts meant to
be included with 'include :global'. A request that's been made more than
a few times on the DBMail mailing list is to have sieve scripts that are
always run during message delivery, controlled by the mail administrator
rather than individual users.
Has this idea been discussed before?
Yes. There was even a draft (by Jutta if memory serves) describing how
to deal with multiple sieve results that apply to the same message.
Does anybody have an implementation
that runs 'global scripts' in this way?
Yes, our implementation does this. In our implementation there can be many
sieves associated with different subsets of the recipients of a message.
Basically it ends up being an inverted tree with each branch representing one
or more recipients. The so-called "system" sieve sits at the root, "channel"
sieves above that, moving on out to user sieves on the leaves.
After all the sieves are evaluated the result that ends up attaching to each
address is basically the first sieve along the path to the root that said to do
something besides an implicit keep. This way a user can override a system-level
action like discard, e.g. in the case of a per-user whitelist.
There are exceptions. We've found it necessary to implement some nonstandard
actions that can be used in system-level sives which then cannot be overridden
by users.
I am inclined to believe that this is a good idea, and that basically I
need a dummy postmaster user to own the global scripts and mark one as
active, to be executed prior to the user's delivery scripts.
We don't implement managesieve currently. Our user sieves are typically stored
in LDAP. System and channel sieves tend to live in files, although they can
also be placed in LDAP.
The main problem in the provisioning space is that the stuff you tend to do in
system sieves is somewhat differnet from what you do in user sieves.
The special considerations I can think of are that the implicit keep
does not cross between the postmaster script and the user's script,
except in the case of a reject. That is, if the postmaster does a
fileinto, discard, keep, redirect, whatever, this affects only the
"postmaster's copy" of the message. A reject should trash the message
and cancel the user's delivery, however.
Hmm. Can of worms? Can we tease out a consistent behavior? Would
recommending a dummy postmaster user solve the managesieve question for
global scripts?
The approach Jutta documented was based on having multiple sieves, not on
having a single sieve that incorporates other sieves through some sort of
include mechanism. Our implementation ended up being semantically quite
close to what she described even through we didn't collaborate on the
details.
Whether or not this effort is worth reviving is another matter. It is far too
late for us to consider making any sort of significant changes to multiple
script semantics. Too many customers depend on things continuing to work
the way they do now, and who cam blame them?
Ned