Subject: [sieve] draft-ietf-sieve-imap-sieve-00 comments

From: Timo Sirainen <[email-masked]>
Date: Wed, 25 Aug 2010 17:18:08 +0100

> [[anchor1: General note: Sieve was designed to work at final
>    delivery, and makes many assumptions about the context.  Will those
>    assumptions break this environment without our realizing it fully?]]

Some weeks ago I had a drunken dream about this. I realized there was a
big problem with this draft, but I forgot the next day what it was. I'm
not sure if it was one of the ones described below, something new I
can't think of right now, or maybe it was just as useful as the few "I
know the meaning of life" dreams I've had.

> [[anchor2: Note about identity: We might want to use Sieve to impose
>    fine-grained access controls.  In final delivery, there's no identity
>    for the "filer".  Here, there is: the logged-in IMAP user.  How do we
>    get at that identity?]]

I'm not really sure what this talks about, but for ACL checks there are
problems:

 - Should ACLs limit what mailboxes a script can be added to? METADATA
RFC allows setting them even to +lr or +lp mailboxes. But is this
problematic enough that it should require +a right?

 - Are the scripts even triggered when another user triggers it in
shared mailbox? I guess it should be, so..

 - Whose rights are the script run as? If user has ability to enable a
script for a shared mailbox, is the script run with the enabler's ACL
rights or the rights of whoever triggers the script? Should this be
different when the script is enabled by administrator?

 - If user has enabled a Sieve script using a name (rather than another
metadata: entry) for a shared mailbox and another user triggers it,
which script is run? The shared mailbox owner's script or the user who
is triggering it?

> [[anchor3: Sieve has no way to get the annotations, so is there
>    really value in being told about annotation changes here?  Maybe push
>    that into a sieve-annotations extension later.]]

I don't much care.

> [[anchor4: Redirect assumes message can be submitted as is - not a
>    valid assumption in this context.  What do we do if the decision is
>    "redirect" and there's not enough information to do it?  Also, some
>    have been concerned about, say, a flag change that has the Sieve
>    effect of forwarding the message somewhere.  Perhaps we should just
>    forbid redirect.]]

I'd also prefer forbidding redirects.

> [[anchor5: Should editheader be allowed to change header fields that
>    aren't saved in place, such as for redirect or fileinto?  Editheader
>    would still have to be banned for "keep", but not otherwise.]]

Normally fileinto could be implemented the same way as COPY, which could
be a simple reference count change. With editheader it would require
creating a new message. Not impossible, but more work to implement.

> [[anchor6: Should this just require imap4flags?  Some implementors
>    have said they wouldn't bother with it without the ability to
>    manipulate flags.  And what values of flags does it see -- before or
>    after the change?  If it changes them, can it see the originals?  Can
>    it reset changes?]]

Isn't the "what flags it sees" solved by using a combination of hasflag
test and "changedflags" environment test? Or am I misunderstanding what
this is about?

> o  The invocation of a Sieve script on an existing message, where the
>       Sieve implementation supports the [IMAP4Flags] extension and the
>       script uses one of the actions defined in that extension.

Okay, so a Sieve script trigger can trigger execution of another script,
except..

> Only one Sieve script may currently be defined per mailbox,
> eliminating the complexity and possible ambiguity involved with
>    coordinating the results of multiple scripts.

So it can actually only trigger itself, but

> The exception is that in order to avoid
>    script loops, flag changes that are made as a result of a script that
>    was itself invoked because of flag changes SHOULD NOT result in
>    another script invocation.  In any case, implementations MUST take
>    steps to avoid such loops.

So is it not allowed to call itself then after all? Although that
wording says "another", not "self". So all of this makes any sense only
when multiple scripts are supported. But this draft specifies only a
single script, so all of the looping problems could be avoided simply by
removing the ability of a Sieve trigger to do anything with flag
changes. Or if that's wanted, I guess the loop detection text needs to
change somehow to allow executing the script itself if it just goes via
a different code path the next time..

Also first I was wondering why only flag change loops are mentioned and
not message copy-loops, until I realized that e.g. "fileinto" doesn't
have a problem because only APPEND and COPY commands can trigger those
scripts, not "fileinto". But is this really intended? If it is, why are
flag changes treated differently?