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

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
> > >  
> > <http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-sieve-05.txt>
> > > 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
> 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 - 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.

> The general problem I see here is that Sieve is specified to  
> operate in a
> fairly narrow context: At or around the time of final delivery.  
> This has
> influenced Sieve design choices in subtle ways and, now that we  
> have such an
> extensive body of work on Sieve-related stuff, tracking down all of  
> the
> implicit assumptions of context and reworking them so that Sieve  
> can operate in
> the context of the message store is very difficult. There are  
> almost certainly
> going to be things we miss or get wrong, and I think implementation  
> experience
> is about the only way we're going to find all the impedance  
> mismatches.
I have to admit to having had some concern over the document since  
its inception, but I've really been unable to pin down exactly what  
was bothering me about it - but in general terms it was indeed the  
unspoken assumptions.
The scary thing is that what you describe is a whole class of  
assumption I hadn't even considered - I was merely considering the  
class of assumption that IMAP client authors - who are hard enough to  
persuade into doing any actual IMAP client authoring, frankly, at the  
best of times - might well have made, and probably will wish to  
continue making, over time. A halfway predictable message store would  
be one of them, speaking personally.
Another class of assumption is that IMAP server developers are used  
to the requirements that certain operations are atomic, and running  
an arbitrary SIEVE script atomically doesn't quite fit into this  
frame of thought. Still, there are worse things, such as repeatedly  
stabbing myself in the navel with a rusty fork, and I suppose I  
shouldn't complain, since in as much as I can see, there is no  
requirement for self-mutilation anywhere in the specification. Nor,  
though, is there any mention of this in, say, Section 2.2.2, where it  
talks about the MULTIAPPEND case. (I was looking for a discussion of  
atomicity, not fork-stabbing, in case that's not clear. I did have a  
quick scan for self-mutilation, but aside from a brief mention of  
ManageSIEVE, there's nothing).
Uploading viruses, or uploading messages over a certain size, are  
both sensible things to want to prevent - but I have to admit to  
struggling to understand why an administrator would prefer to use a  
complicated script instead of a simple configuration setting,  
especially given that the complicated script will get executed for  
every flag change, too. Yay, go efficiency.
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. 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.
There may very well be useful cases for this extension, above and  
beyond bringing on nervous breakdowns in IMAP implementors, hence the  
reason I'm obviously trying to appear positive about it, but these  
are not only likely to be quite rare and uncommon, but if they're  
not, then better solutions are undoubtedly possible.
So, to get back to your original question, I have not yet implemented  
it, and I don't think we have any imminent plans to do so, but I  
cannot speak for my employer in this regard.
I hope this helps answer your question.

Dave.
--
Dave Cridland - mailto:dave(_at_)cridland(_dot_)net - 
xmpp:dwd(_at_)jabber(_dot_)org
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade