MBOX-Line: From mrc at CAC.Washington.EDU  Thu Jun  7 09:03:21 2007
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:39 2018
Subject: [Imap-protocol] Concurrent Mailbox Changes.
In-Reply-To: <1181230565.6639.15.camel@mike-laptop>
References: <46581509.7050201@buni.org> <1180182602.32181.1919.camel@hurina>
	<alpine.OSX.0.99.0705260804430.3501@pangtzu.panda.com>
	<1181230565.6639.15.camel@mike-laptop>
Message-ID: <alpine.OSX.0.99.0706070855180.11475@pangtzu.panda.com>

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.

