On Sun, 2006-11-26 at 14:10 -0800, Ned Freed wrote:
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.
Ok, I just read draft-degener-sieve-multiscript-00, and it exactly what
I was looking for with respect to the 'system scripts'.
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.
Ok, this makes sense.
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.
Hence the non-standard actions that you mentioned? Could you give a few
examples of these actions?
They tend to be non-overrideable variants of existing actions. For example,
we have a jettison action that's like discard except that it cannot be
overridden by user sieves.
In retrospect I wish we'd done this as a :system or :nooverride parameter, but
we initially didn't see a reason for wanting this sort of behavior with more
than one action. But it too late for us to change now - the best we could do is
add support for an alternate approach.
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.
Right, there's two issues here, and they're sort of sharing the same
terminology. How about 'system scripts' and 'global scripts' where the
system scripts are scripts that are run during delivery, as you and
Jutta have described.
We already use the term "system scripts" this way, so this works for me.
I'm thinking that if there's a user who owns the system scripts, then
that user might also be the owner of the scripts in Cyrus'
include :general namespace. Better than trying to create a #Public
namespace for Managesieve uploads :-P
I don't have strong feelings about this either way, but I agree that a
naming convention would be useful.
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?
You mean not changing your implementation of multiple script
semantics :-P That's ok if you don't want to change it, but I'm
interested in looking into it a bit more and documenting the execution
path if it generally useful to anybody else out there. Reviving Jutta's
multiscript draft certainly looks like an easy way to start working on
this again.
I'm with Tony on this - the goal should be to document this space so
implementors have a place to start, not necessarily to have a standards-track
specification for it. Even if there weren't existing implementations,
implementations specifics are likely to make the exact semantics hard
to nail down.
Ned