[Top] [All Lists]

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

2008-05-23 16:44:59

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 - 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 Cridland - mailto:dave(_at_)cridland(_dot_)net - 
 - acap://
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade