[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lemonade] draft-ietf-lemonade-imap-sieve-00

On Wed Dec 21 03:44:32 2005, Barry Leiba wrote: 
Dave says...

> There's quite a few mentions of atomic moves - these can be quite
> slow for some mailstores, and in general they're tricky, and they
> almost invariably involve maintaining locking on multiple mailboxes.

I don't see that what I'm describing as an "atomic move" is any more of
a burden for servers than
COPY 5 Newmailbox
STORE 5 +Flags.Silent (\Deleted)
EXPUNGE

What the spec means is that one of these "moves" must implement that
sequence as one operation, and what that mostly means is that if
something fails, none of it is done...


That's the burdensome bit.

> Moreover, I really do fear what a naïve client - or indeed any
> client - will do when it casually flips a flag, and discovers the
> message has just been expunged.

The same thing it does when it sees any message expunged. I remind you
that every client, nowever naïve or worldly, MUST deal with EXPUNGE
responses, and the underlying expungement (is that a word?) of the

I'm not sure that expungement is a word, but to a client, the phrase you're looking for is "irrevocable destruction without trace".


messages.  Why should you think this should be a problem?  This can
happen in other situations, such as this:

Client 1                          Client 2
                                  C: X1 STORE 5 +Flags (\Deleted)
                                  S: * FETCH 5 Flags (\Deleted)
C: T1 STORE 5 +Flags (\Answered)
                                  S: X1 OK done
                                  C: X2 EXPUNGE
                                  S: * 5 EXPUNGE
S: T1 NO failed                   S: X2 OK done
C: T2 NOOP
S: * 5 EXPUNGE
S: T2 OK done


Right. But that's not what's happening. It's what *looks* like what's happening, but it's not.


> most intelligent and aware client in the world, I don't see how it's
> going to detect the difference between "this flag change caused the
> message to be atomically moved" and "this flag change didn't happen
> because the message was already expunged".

I don't see why it has to detect the difference.  Can you explain?


The above case is a rare race condition, which isn't a big deal. (That is, it's a circumstance that arises by a combination of events happening in a precise timing, not a security flaw).

When hit send on this message, your message (or rather, the copy of it in my mailbox), will get flagged as answered by Polymer. If it happens to be deleted by another session, that's not a real worry - it's also pretty unlikely.

If that happens to every message, Polymer doesn't know what's happening, it just assumes that by fluke, some other session happens to have vapourized the message.

Polymer won't get paranoid, although the user might.

If Polymer wanted to both answer the message and forward it, however, it now can't - the act of answering the message has destroyed it forever. Of course, in fact, it might not have been destroyed, but Polymer cannot know that.

If some other client had cheerfully decided to automatically sweep read messages to an archival folder, that will instantly break things badly for Polymer, and people will think that Polymer is broken, and doesn't support attachments, since Polymer happens to be an online client relying on the implicit Seen.

You *could* add in protocol messages to indicate third-party COPY operations, but Polymer won't understand those, so that doesn't actually change the situation at all.

Neither of these are problems with Polymer, incidentally. You can subsitute any other client name you like.


> I also have a nasty feeling that some clients will take it upon
> themselves to make setting the \Deleted flag instantly expunge the
> message.

This certainly doesn't give them license to do that.

That's exactly what it does do. This grants full license to anyone and everyone to provide their very own favourite semantics for mailstores.

  If someone wants
to have a Sieve script do that, they certainly can, of course:

  if allof (${IMAPSieve.cause} :is "FLAG", hasflag "\\Deleted") {
      discard;
  }

Whether this is a good idea or not is something the implementer of the
script has to decide.


No, it's not. It's up to the one client author who doesn't like a two phase delete, and sticks an innocuous checkbox marked "Delete Immediately" somewhere.

Moreover, there are already server implementors who use precisely the arguments you do here to do immediate expunges of messages. This makes the argument altogether easier - "Well, *if* I supported X, and *if* there was a script Y, then... So it doesn't make a difference."


> I also think it's likely to break UIDPLUS - a client will lose track
> of apparently witnessed moves, because it has no idea of what the new
> UID is, as well as not knowing if the message still exists somewhere
> else on the server. If even one message is moved in a MULTIAPPEND,
> then the APPENDUID response cannot be sent.

Huh? This makes no sense. Even if the server responds with a UID, the
message can disappear before the client can do anything with it anyway.
This automates things, perhaps making such situations more apt to
happen, but it doesn't change the fact that they can happen.


Okay, so it can lie about the UIDs all the time, breaking the client's cache. That helps things in a Lemonade setting how, exactly? Clients will waste storage space until they happen to look at the mailbox and realize that UID doesn't exist anymore, never knowing that attempting to preserve the cache was a waste of time and resource.

In any case, I really dislike the notion of a server saying "OK, I did what you asked, here is the result", and the client later finding out that not only did the server lie about the result, but it did something completely different, which the client cannot find out about.

All this is not to say that the likes of fileinto and discard have no purpose for IMAP-level Sieve, just that they really shouldn't be implicit actions that the client might be unaware of. Running a Sieve script explicitly over a set of messages would be nice, and would allow for all sorts of useful behaviour, commonly handled by clients locally:

- It could be used to flag a set of messages matching complex criteria currently unexpressable in IMAP's SEARCH.
- It could be used to sweep old or irrelevent messages from the INBOX.
- etc.

The key thing here is "explicit" - the client wouldn't be taken by surprise here, and existing semantics aren't broken.


> Section 3.8 suggests that even if the message isn't shifted about
> atomically behind the client's back, and UIDPLUS actually works, then
> because the headers may be edited, a client will potentially have the
> wrong data in the cache.

That IS a good point, and I'd originally started to write it to ban
EditHeader, but then changed my mind.  What do other client-writers
think about this?


Without meaning to sound arrogant, it doesn't matter a jot what anyone thinks. Message content in IMAP is immutable. The only way to allow EditHeader would be to allocate a new UID for the message, which in turn destroys the cache.

These message moves and edits *do* destroy the cache. You're increasing the chances of a client downloading the same thing twice, wasting both a round trip *and* a hefty chunk of bandwidth. I don't see why this can possibly be considered a good thing.


> Oddly enough, I do think we could use reject, though. Reject could
> generate a protocol level error, hence an APPEND or COPY to a mailbox
> could be forced to fail for a fairly arbitrary reason, for instance.

I hadn't thought about that.  Yes, we could allow/define the reject
action.  Other comments?

> Of course, with APPEND and LITERAL+, that's going to make client
> implementors a little upset.

Using APPEND with LITERAL+ is a bad idea anyway, since the server can
always say NO to APPEND, without the client's being able to determine
that in advance. Again, this doesn't change that.


No, it most certainly does change this.

If a client understands ACL sufficient to handle MYRIGHTS, then a failed APPEND becomes very much an exceptional condition, and it can eliminate one round trip by using LITERAL+.

Moreover, failed APPENDs *are* exceptional anyway, given that they're almost always used in the message send scenario, and, in general, if an APPEND works once, it'll work again. Failed COPY is relatively common, but a failed APPEND is usually a sign of misconfiguration in real-world MUAs.

Of course, theoretically, all things are possible, but theory is only right in theory.

Dave.
--
          You see things; and you say "Why?"
  But I dream things that never were; and I say "Why not?"
   - George Bernard Shaw

_______________________________________________
lemonade mailing list
lemonade at ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade