[Top] [All Lists]

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

2008-05-24 00:33:57

Dave Cridland wrote:
On Fri May 23 16:40:57 2008, Ned Freed wrote:
Alexey Melnikov wrote:
> While this is a Lemonade WG document, this document is of relevance to
> the Sieve WG mailing list and should be reviewed here.
> So please review
> <>
> before May 5th.
I haven't seen any reviews of this. Can you please send me a quick "I've
reviewed it and it looks fine" or "this needs more work" to me, if
you've done a review.
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
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).
- 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.
The Security Considerations section clearly states that implementations might choose to do so, maybe, but only for flagchanges on Tuesdays in Summer during non-leap years.