Re: Sieve include, 'global scripts' and managesieve

[Ned Freed <[e-mail]>]

> 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