> > 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. 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.
> - 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.
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.)
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?
Ned