What I think you may be missing is that event reports do not necessarily
follow the same announcement order as the events occurred.
To elaborate on your example, let's suppose that there are five messages
in the mailbox. A session deletes and expunges messages 2 and 4. Then,
three new messages are added.
Meanwhile, another client has the mailbox open, and the client does not do
a command (a NOOP in this example) that announces the expunge until the
new messages have been delivered. Here is what that other client will
see:
a001 FETCH ...
* n FETCH ...
a001 OK FETCH completed
a002 FETCH ...
* n FETCH ...
* 8 EXISTS
* 3 RECENT
a002 OK FETCH completed
a003 NOOP
* 2 EXPUNGE
* 3 EXPUNGE
* 6 EXISTS
* 3 RECENT
a003 OK NOOP completed
In this example, the expunge happened during command a001, but the
announcement was deferred since FETCH can not announce EXPUNGE.
The same deferral happened during command a002, but the three new messages
were noticed. Note the EXISTS count of 8; the other session probably has
an EXISTS count of 6 since it successfully expunged, but this one has an
EXISTS count of 8. In what I consider to be the correct implementation,
we can still FETCH the data for those two messages.
Finally, command a003 causes the announcement of the expunge of messages 2
and 4. Note that the second EXPUNGE event is for message 3; this is
because the effect of expunging message 2 is immediate and thus what was
message 4 becomes message 3. This is an important point to understand
IMAP expunge correctly. If you expunge every message in the mailbox you
will probably get a lot of "* 1 EXPUNGE"....
On Thu, 7 Jun 2007, Michael Barker wrote:
> On a similar note, what is the preferred behaviour when another client
> expunges a mailbox, then new messages are added? Should the EXISTS
> response, indicating new message, be sent straight away or should it
> wait until after the server has sent the EXPUNGE response?
>
> Regards,
> Michael Barker.
>
> On Sat, 2007-05-26 at 08:09 -0700, Mark Crispin wrote:
>> Note that the inventor of IMAP disagrees with the very last sentence of
>> Timo's message (see below). He thinks that the preferred order of
>> behavior is:
>> (1) which everybody thinks is the best
>> (5) which at least maintains consistant protocol state
>> (4) annoying to users, but doesn't violate protocol state
>> (2)/(3) which mislead some clients, breaks others, and
>> violates protocol state,
>>
>> As far as the inventor of IMAP is concerned, (1) and (5) are the ONLY
>> acceptable choices.
>>
>> On Sat, 26 May 2007, Timo Sirainen wrote:
>>> This is discussed in RFC 2180. Summing up your possibilities:
>>>
>>> 1. Keep the message around until there are no sessions that see it. This
>>> is the preferred behavior.
>>>
>>> 2. Give some dummy replies for the message. Such as empty flags, and
>>> other fields being NILs or whatever is legal for the field. The downside
>>> to this is that it violates the IMAP protocol if the client had already
>>> asked something about this message.
>>>
>>> 3. Don't return the FETCH reply for the message at all and return a
>>> tagged NO reply. Doing this makes some clients ask the same message
>>> range over and over again infinitely. This could be avoided also:
>>> http://mailman1.u.washington.edu/pipermail/imap-protocol/2006-September/000=
>>> 281.html
>>>
>>> 4. Disconnect the client anytime you can't handle the request. I used to
>>> do this but it was annoying when it happened.
>>>
>>> 5. Don't allow EXPUNGE until there's only session. I think this is the
>>> worst of the possibilities.
>>
>> -- 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.
>
>
-- 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.