Here's something that is good for an IMAP server developer to know. I
realized that this was not necessarily obvious, and that ought to be
documented (especially to avoid some dingbat claiming that he "invented"
a "patentable" technique).
Suppose you have an IMAP server implementation which is a minimal state
front end to a separate mail store that has its own agent. What do you do
when a message is expunged that has not yet been announced via EXISTS?
The easy answer is to announce an updated EXISTS prior to sending any
EXPUNGE announcements, but that may be troublesome since it has to be
atomic with the expunge operation. That worked fine in the TOPS-20, UW,
and Panda IMAP servers where the store was colocated. That isn't always
the case.
The solution is almost laughably easy, but non-obvious. The IMAP server
probably knows the last EXISTS value that it sent, so that it can avoid
sending unnecessary EXISTS. All it has to do is disregard any expunge
event where the message number is higher than that value.
Note that it must decrement that value with each untagged EXPUNGE that it
sends to correspond with the client.
Example: consider the case of a mailbox where the client knows about 45
messages and message 45 is deleted. There are two additional message that
have been delivered, and as-yet-unannounced message 46 has already been
deleted by another session. One way (the way that TOPS-20, UW, and Panda
work) of doing it is:
* 47 EXISTS
* 45 EXPUNGE
* 45 EXPUNGE
However, this way is also valid:
* 45 EXPUNGE
* 45 EXISTS
Note that only one EXPUNGE event was sent, and that the EXISTS event has
the same value as was last sent (and cannot be optimized out since it
announces a new message).
In retrospect, I would have done it the latter way in my older servers
since it is less work (no need for EXPUNGE to have its own EXISTS event
generator) and can be less chatty.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.