Re: WGLC on IMAP Sieve (draft-ietf-lemonade-imap-sieve)

[Alexey Melnikov <[e-mail]>]

Ned Freed wrote:

>> > > I finally had a chance to look at this. Having done so, the 
>> question I really
>> > > want to ask is has anyone implemented this, and if they  did, how 
>> well did it
>> > > work? And if the answer to that is "no implementations yet", I'd 
>> then like to
>> > > hear if anyone is planning to implement this, and if so, when and 
>> for what
>> > > puropse?
>
>> > The whole thing just leaves me a quivering mess, whimpering in a
>> > corner and yearning for the good old days, when if one APPENDed
>> > message literal in a MULTAPPEND set was accepted, one could breathe a
>> > sigh of relief and use LITERAL+ to do heavy pipelining on the rest.
>
>> > I'm still not entirely sure how IMAP-SIEVE would signal *which*
>> > message failed in a MULTIAPPEND set, actually
>
>> Dave, I don't understand how is this different from MULTIAPPEND without
>> IMAP Sieve: an IMAP Sieve script can't "fail" append. It can only
>> discard message after it gets appended (see section 3.6).
>
> And as I said in my comments, I view this as a significant omission 
> that needs
> to be corrected.

Possibly (I haven't made my mind on this yet).
I would just point out that your change would create an extra failure 
case that isn't present in IMAP Sieve now.

> As for the MULTIAPPEND issue, well, I've already commented on
> what I view to be the inadequacy of IMAP error reporting in other 
> contexts.

This is solvable by defining a new response code (or a new response).

>> > - I did look, and Section 2.2.2's coverage of this particular problem
>> > is, well, exceedingly economic.
>> >
>> > But this is a specific issue, rather than the more general problem.
>>  [...]
>> > This ignores the interesting cases of whether an implementation
>> > ignores, for the purposes of Sieve, events caused by Sieve scripts,
>> > since otherwise two mailboxes could have conflicting scripts that
>> > cheerfully bounced an APPENDed message backwards and forwards for all
>> > eternity.
>
>> Sieve fileinto caused by IMAP Sieve is not the same as IMAP COPY, but in
>> order to avoid any doubts I agree that the Security Considerations
>> should also mention that.
>
> I agree with this as far it goes, but it caused me to review the text on
> fileinto in the base Sieve specification as well as in the IMAP sieve 
> document,
> and I'm afraid what turned up is another impedance mismatch that needs 
> to be
> addressed.
>
> The base spec basically says that
>
>   fileinto "foo";
>
> causes the message to be placed in a mailbox named "foo". It then goes 
> on to
> discuss the access control issues this can cause, especially in the 
> case where
> the mailbox doesn't already exist. Conspiciously absent from any of 
> this is
> discussion of mailbox hierarchy - what, say,
>
>   fileinto "foo/bar";
> means is entirely implementation dependent. And if this case is 
> interesting,
> something like
>
>   fileinto "/foo/bar";
>
> has even more interesting implications. The reason for not nailing any 
> of this
> down is of course that Sieve does not presuppose a particular store 
> backend of
> any kind.
>
> Also implicit in this discussion is that the sieve in question has an
> identifiable owner that has access rights to the store. Also, in 
> practice the
> argument of fileinto is also interpreted in the context of where the 
> user's
> default mailbox is located - foo is normally placed at the same level 
> in the
> hierarchy as their inbox.
>
> Now consider how this changes when Sieves are used in IMAP. Now we're 
> dealing
> with a specific sort of store with very specific semantics. So now these
> semantics can and should be nailed down, but the draft currently fails 
> to do
> so.

Maybe so. I am not entirely clear what needs to be written to clarify that.

Isode's implementation just treats the fileinto argument as an IMAP 
mailbox name. So if it contains a shared folder prefix, this would cause 
mail to be filed into the shared folder.

> And then there's the access control issue. Presumably if a script is 
> attached
> to a user mailbox is "owned" by that user and inherits his or her access
> rights. (If so, this also needs to be explicitly stated.)

Right.

> But what about scripts attached to public mailboxes, ones that have no 
> owner?
> Who owns them and what rights do such scripts have?
>
> And what about the server script? Who owns it and what rights does it 
> have?

These are all interesting questions. I agree that they should be discussed.