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?
The situation should never come up.
The message shouldn't go away until that EXPUNGE has happened. There are implementation techniques to accomplish this.
If you read RFC 2180, you are immediately struck by something (or should be): all the listed strategies but one require substantial client complexity to work around what should be a server-internal issue. That should indicate to you that that one strategy is the right one, and the others listed there are bogus.
This seems to be a weakness in the protocol, since there is no way for the server to explicitly say exactly what has happened.
Wrong -- it is a tremendous strength in the protocol! It forces server implementors to make sure that it never happens, otherwise their server is non-compliant.
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.
There is a simple -- and quite compliant -- defense: * BYE Connection holding too many expunged messages
I'd prefer my server not to be DOS'able in this way, and fortunately, RFC3501 gives me the latitude I need for that.
If you are talking about sending a NO to a FETCH then you are quite mistaken.
This is a server bug.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.Supporting concurrent access by other clients, or by non-IMAP agents, is a bug? Accurately reporting changes made by other agents is a bug?
No, a server that does not comply with IMAP is a bug.
Believe it or not, server implementors have figured out how to support concurrent access by other clients or by non-IMAP agents, and accurately report changes made by other agents, *AND* comply with IMAP.
It CAN be done. It is not easy. It requires considerable thought and care in the implementation, not just of the server but also the mail store.
But it CAN be done, and it HAS been done.
-- Mark --
http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
