In the IMAP protocol the server cannot unilaterally inform the client that a message has been removed. The server can inform the client only when the client explicitly requests a folder status update. It's true that some clients crash, or are otherwise unable to gracefully handle the situation where the requested message is not available. There's nothing that the server can do about that.
I'm not asking for the server to tell the client that a message is removed. The problem is that when the client polls the server a minute later, the server still says it has X messages, where X > 0, when X is in fact 0.
That's how IMAP works. If the server previously told the client there are X messages in the folder, the server can't suddenly tell the client that there are now X-1 messages in the folder, unless the server first notifies the client that a message was removed.
And the server cannot notify the client that the message is removed until the client asks whether or not messages were removed.
I'm not worried at all about the client trying to access the email that is now gone. I want the client to accurately reflect the number of total and unread messages, which it is not doing. And, as near as I can tell, this is a server problem and not a client problem.
This behavior is required by the IMAP protocol.
Additionally, the client has no business whatsoever asking the server how many messages there are in the current folder. The client already knows that, as part of the IMAP protocol exchange. Such a request indicates that the client is poorly designed.
pgp00000.pgp
Description: PGP signature
