Mark Crispin <[EMAIL PROTECTED]> wrote: > If the message is "no longer available" the server should have sent an > untagged expunge.
Of course - if it has had a chance. If it hasn't (i.e., when there hasn't been any intermediate command that allows the EXPUNGE response), then what? This is the situation I've had in mind all along, as far as deletion goes - sorry for not making that clear earlier. In this case, NO seems entirely, and uniquely, appropriate. This seems to be a weakness in the protocol, since there is no way for the server to explicitly say exactly what has happened. But to me, NO seems like the least bad option. > You are effectively saying that clients be required to know about a server > state that was created by a poorly-implemented server that allows messages to > become unavailable prior to the sending of an untagged expunge. If the server doesn't allow that, then I can DOS it by holding a connection open without sending any commands that allow EXPUNGE, so no messages can ever be deleted, and the message store grows monotonically. I'd prefer my server not to be DOS'able in this way, and fortunately, RFC3501 gives me the latitude I need for that. >> Look at the situation more closely: earlier, the server said this >> message was present. Later, when a FETCH command is given, the server >> says it can't provide the message. > > This is a server bug. Supporting concurrent access by other clients, or by non-IMAP agents, is a bug? Accurately reporting changes made by other agents is a bug? paul
