Hi, I'd like to sum up Arnt's, Mark's and Tim's comments on the problem, together with my idea:
Mark favors keeping an expunged message in the mailstore until no session still accesses it. I know the advantages, but I dislike it for various reasons (security, privacy and - though not important - implementation issues). This was stated before, see RFC2180 4.1.1. I accept any server which does so, but I would not recommend it, and discard this idea (sorry, Mark :-) ) Tim and Mark (2nd choice) favor ghost messessages, while Arnt opposes it (what are your reasons?). I see the argument that it's because a) users don't get dumb error messages and b) current clients may handle this better than error or disconnection. On the other hand, it gives "false" informatione, in that it states message data for a nonexisting message. It is ok when - e.g. in the next command exchange - this message is deleted anyway, so the user actually does only see this "NIL" message under very rare conditions, and it is mainly a "fill-up" for the command chain. If this is correct, I could live with this idea (though it somehow seems not "fine" to me...) Arnt favors (or least dislikes) a forced disconnection, while Mark opposes it (at least a bit). It is meant as the last ressort if a command cannot be fulfilled (i.e. the server waits as long as it can, possibly to give the expunge information to the client anytime before it still works with its old data). This has the same disadvantage as any NO response (probably an error message to the user like "server unexpectedly disconnected"), but does not reveal any false data. It is very easy to implement, but this is not the the main issue for me (nor should it be). Question: Are there clients which gracefully reconnect without error message? I doubt it, and I don't think this should be "advisable" for client implementors, should it? So, last was my idea, where I am a little puzzled about the answer: > > > My answer would be the following: I'd do the expunge immediately to the > > > message store. I then postpone the expunge messages as required by the specs > > > for Client A. Any request to FETCH/STORE/SEARCH would be answered with a > > > tagged NO response then (as described in RFC2180 4.1.2) until the EXPUNGE > > > could be delivered. > > It makes sense to me, but it's not compatible with the existing RFC. If you > > had suggested this before RFC 1730/2060 were published, it might have become > > part of the protocol, at least if Mark likes it. But now I guess it's too > > late. Why?! Where is it not compatible (I only answer "NO", which should always be compatible?!). Anyway, it's a "recommended" way to handle this situation, as far as I understand RFC2180?! > I don't think that it's a good idea, and I would have opposed it. It > creates needless error conditions for clients. Agreed, but please read below. > If you can't keep the message data around for the benefit of other > sessions, then simply forbid shared expunge. OK, Mark, but this is not an option: 1) is the same as argument above for keeping the message data - I WANT expunge to do its job as soon as possible, 2) it may make EXPUNGE impossible for heavily shared accounts and 3) you get error messages (EXPUNGE failed) to the clients. Actually, I still like the bit in RFC2180, the NO response to requests which cannot be satisfied due to pending expunge messages. It is stated: 4.1.2 [...] After receiving a tagged NO FETCH response, the client SHOULD issue a NOOP command so that it will be informed of any pending EXPUNGE responses. The client may then either reissue the failed FETCH command, or by examining the EXPUNGE response from the NOOP and the FETCH response from the FETCH, determine that the FETCH failed because of pending expunges. So it is actually already an implementaion recommendation to try again a failing fetch command after a NOOP. If all clients would do so (I mean in a perfect world, not in reality), the result would be what we (I) favored: Responses which mirror the real situation on the server, no error messages to the user and immediate result of the expunge for security/clarity/whatever reson. And the client would definitelty catch up with the next command. Maybe it would be perfect if the IMAP4 command response for FETCH/STORE/SEARCH would allow an optional [TRYAGAIN] or [PLEASENOOP] or even [PLEASECHECK] response which would direct a client to to just that (e.g. NOOP or CHECK to receive new messages). So I'm currently favoring this tagged NO [PLEASENOOP] thing, or second ghost messages. What do you think? Christof
