Subject: managesieve + include

From: Marc Mutz <[email-masked]>
Date: Sun, 19 Oct 2003 18:53:35 +0200

Hi!

Now that managesieve is being moved forward, we should consider it's 
relation to draft-daboo-sieve-include.

I've got a few points that I think have to be added to the managesieve 
draft or would suffice to do in an extension of the protocol.

1. The managesieve draft needs to mention that it acts on the local 
script storage, not on the global one.

2. It needs to be clarified that the active script is the "start script" 
and that included (local) scripts need not (and cannot) be set active 
to be executed.

3. Either the managesieve or the include spec need to clarify that 
scripts that other scripts depend on (e.g. "includees") may not be 
removed from the script store (return NO) and that includees have to be 
uploaded before their includers.

4. There needs to be a managesieve protocol extension to report more 
precise errors (machine-readable) for PUTSCRIPT: E.g. parse, syntax, 
site policy, and dependency errors, together with line and optionally 
column number. Actually, I think this should go into managesieve 
proper.

5. A method (read: managesieve extension) to specify more than one 
active script and the order in which those are to be processed would 
also be nice, although personally, I'd be fine with using driver 
scripts (which, however, requires the include extension).

Marc

-- 
It takes 5 minutes to create [a OpenPGP key].
Of course it takes a bit more time to get it signed...
                                                 -- David Faure

---

From: [email-masked]
Date: Sun, 19 Oct 2003 12:23:58 -0700 (PDT)

> relation to draft-daboo-sieve-include.

Seems reasonable.

> script storage, not on the global one.

Agreed.

> and that included (local) scripts need not (and cannot) be set active

Agreed.

> uploaded before their includers.

I think this belongs in the include specification. It should deal with the
generic issue of how sieve storage schemes (including but not limited to
managesieve) manage dependencies.

> column number. Actually, I think this should go into managesieve

I've like to hear how others feel about how much checking the managesieve
facility should perform on the sieves it processes.

> scripts (which, however, requires the include extension).

I think this is the topic for an extension, assuming it is done at all.

				Ned

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 19 Oct 2003 15:37:42 -0400

Hi Marc,

--On Sunday, October 19, 2003 18:53 +0200 Marc Mutz <[email-masked]> wrote:

| Now that managesieve is being moved forward, we should consider it's
| relation to draft-daboo-sieve-include.

(A new version of include has just been sent to the draft repository)

| I've got a few points that I think have to be added to the managesieve
| draft or would suffice to do in an extension of the protocol.
|
| 1. The managesieve draft needs to mention that it acts on the local
| script storage, not on the global one.

Actually it might be nice to allow access to the global script space. That 
could be done by adopting the new syntax used in include, e.g.:

a PUTSCRIPT :global "aGlobalScript" {31+}

etc

There could be a new "INCLUDE" capability for ManageSIEVE to do that. 
Whether that is part of the ManageSIEVE draft or the include draft or a 
separate document is open for debate.

| 2. It needs to be clarified that the active script is the "start script"
| and that included (local) scripts need not (and cannot) be set active
| to be executed.

Why would you prevent a script that can be used as an include from being 
made active? For example, I would like to 'wrap' my default script inside 
of a 'vacation' script. So most of the time the default script is active, 
but sometimes I will make the vacation one active.

| 3. Either the managesieve or the include spec need to clarify that
| scripts that other scripts depend on (e.g. "includees") may not be
| removed from the script store (return NO) and that includees have to be
| uploaded before their includers.

That kind of dependency is going to be a pain.

| 4. There needs to be a managesieve protocol extension to report more
| precise errors (machine-readable) for PUTSCRIPT: E.g. parse, syntax,
| site policy, and dependency errors, together with line and optionally
| column number. Actually, I think this should go into managesieve
| proper.

With includes it may actually be useful to have a 'CHECKSCRIPT' command 
that verifies a script and produces verbose error comments. That would be 
useful when constructing a set of scripts with includes dependencies.

| 5. A method (read: managesieve extension) to specify more than one
| active script and the order in which those are to be processed would
| also be nice, although personally, I'd be fine with using driver
| scripts (which, however, requires the include extension).

That would be just the same as having one top level script that includes 
all the 'active' scripts in the order you want - I don't see why 
ManageSIEVE should allow that directly if include is supported in SIEVE 
itself.

-- 
Cyrus Daboo

---

From: Tony Hansen <[email-masked]>
Date: Sun, 19 Oct 2003 18:49:11 -0400

Cyrus Daboo wrote:
> made active? For example, I would like to 'wrap' my default script 
> inside of a 'vacation' script. So most of the time the default script is 
> active, but sometimes I will make the vacation one active.

I agree with Cyrus.

	Tony Hansen
	[email-masked]

---

From: Marc Mutz <[email-masked]>
Date: Mon, 20 Oct 2003 13:49:11 +0200

Hi Cyrus,

On Sunday 19 October 2003 21:37, Cyrus Daboo wrote:
<snip>
> Actually it might be nice to allow access to the global script space.
> That could be done by adopting the new syntax used in include, e.g.:
>
> Whether that is part of the ManageSIEVE draft or the include draft or
> a separate document is open for debate.

I don't think it's good to allow any user to access the global script 
space. List it, yes, so the Sieve editor can present the global scripts 
in the GUI to choose from, but adding new ones should be left to the 
admin or another role. So if the person filling the role of global 
script manager needs to access the global script store, then she can 
just as well log in as that role.

> | 2. It needs to be clarified that the active script is the "start
> | script" and that included (local) scripts need not (and cannot) be
> | set active to be executed.
>
> Why would you prevent a script that can be used as an include from
> being made active?

Sorry, I was not precise enough. Of course, if your scripts form the 
following DAG:

A
+ B
  + C
+ D

where A is the active script, you can make any one of B, C, D active and 
it becomes the start script, at which execution starts. What I wanted 
to say is that only the start script needs and can be made active and 
that B can then be included, even though it isn't set active. In short, 
the active flag does not act like an exec permission.

> | removed from the script store (return NO) and that includees have
> | to be uploaded before their includers.
>

Then
  include "non-existant-script.siv";
needs to be made legal and a noop. I've got no strong preferences either 
way, and can see nice use cases for the include-if-exists behaviour, 
but execution of a formerly valid script MUST not error out only b/c 
one of the included scripts has been deleted meanwhile.

> | 4. There needs to be a managesieve protocol extension to report
> | more precise errors (machine-readable) for PUTSCRIPT: E.g. parse,
> | syntax, site policy, and dependency errors, together with line and
> | optionally column number. Actually, I think this should go into
> | managesieve proper.
>
> With includes it may actually be useful to have a 'CHECKSCRIPT'
> command that verifies a script and produces verbose error comments.
> That would be useful when constructing a set of scripts with includes
> dependencies.

According to the current draft, PUTSCRIPT must (or should?) not accept 
invalid scripts. So it needs to parse them for validity and probably 
also perform some more sophisticated analysis on it (various nesting 
depths, site policy violations, etc.) anyway. So you can just as well 
tell the client about your findings. CHECKSCRIPTS duplicates 
PUTSCRIPT-in-non-authenticated-state.

> | active script and the order in which those are to be processed
> | would also be nice, although personally, I'd be fine with using
> | driver scripts (which, however, requires the include extension).
>
> That would be just the same as having one top level script that
> includes all the 'active' scripts in the order you want - I don't see
> why ManageSIEVE should allow that directly if include is supported in
> SIEVE itself.

That's what I meant by driver script. ;-)

Marc

-- 
[...] the USA needs a German product: Vergangenheitsbewältigung
   -- Craig Morris: US boycott of products from countries against war?
      www.telepolis.de

---

From: Ken Murchison <[email-masked]>
Date: Mon, 20 Oct 2003 10:30:04 -0400

> just as well log in as that role.

IMO this is an authorization issue which should not be enforced by 
MANAGESIEVE.

I agree with Cyrus that MANAGESIEVE should provide a facility to access 
the global script space.  Who has access to this space is a site policy 
decision which would most likely be tied to the authid/authzid.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: [email-masked]
Date: Mon, 20 Oct 2003 08:07:49 -0700 (PDT)

> decision which would most likely be tied to the authid/authzid.

I agree as well. To the extent that MANAGESIEVE provides a means to
use sophisticated tools for sieve construction and maintenance, it doesn't
seem reasonable to deny these tools to admins maintaining global scripts, or
allow them but require an implementation-specific step on the server to
turn an admin user script into a global script.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Tue, 21 Oct 2003 17:27:07 -0400

> That kind of dependency is going to be a pain.

Indeed- there has to be a line drawn for how much the managesieve
server can know.  Might want to put some text in with dire warnings
about what can happen if you remove a script that's included by
another, but I would frown on having the server having to have
a dependency graph far outside of its current operation.

If somebody does remove a needed included file, their mail delivery
should start generating error messages soon thereafter.  Shift the
focus towards error handling and recovery in the scripting language
and execution environment, and not to the tool used to install and
delete individual files.

And personally I disagree with the notion that an "include" of a
nonexistent file should be treated as a no-op.  Mistakes should generate
error reports.

Agree with the desire for CHECKSCRIPT.

-mm-

---

From: Lyndon Nerenberg <[email-masked]>
Date: Tue, 21 Oct 2003 16:28:00 -0600

> nonexistent file should be treated as a no-op.  Mistakes should generate

Or if resources permit, incoming messages could be queued for processing 
later, once the errors are fixed. This is a gnarly problem, though. The 
closest analogy I can think of is a sendmail :include: alias that 
references an unreadable file.

This sort of error handling gets very complicated very quickly. It might 
be better to just say "deliver to the INBOX" if the include fails.

--lyndon