MBOX-Line: From MRC at CAC.Washington.EDU  Fri Nov 16 13:22:02 2007
To: imap-protocol@u.washington.edu
From: Mark Crispin <MRC@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:40 2018
Subject: [Imap-protocol] FETCH/STORE on out-of-range sequence number
In-Reply-To: <1195240890.6039.172.camel@hurina>
References: <2123708120.202451195235056495.JavaMail.root@dogfood.zimbra.com>
	<6199.1195236170.977095@invsysm1>
	<alpine.OSX.0.99999.0711161051240.7038@pangtzu.panda.com>
	<1195240890.6039.172.camel@hurina>
Message-ID: <alpine.WNT.0.99999.0711161315230.5744@Tomobiki-Cho.CAC.Washignton.EDU>

On Fri, 16 Nov 2007, Timo Sirainen wrote:
>> I have NEVER seen any client confusion due to 4.1.4.
> Even if clients can handle it, humans probably can't. I often have my
> INBOX opened from two clients, and it would be really annoying if I had
> to shut down the other one of them just to get messages expunged.

I can say that humans have handled 4.1.4 behavior for years.  However, I 
agree that they find it annoying.

Fortunately, it is possible to upgrade 4.1.4 behavior to 4.1.1 behavior 
fairly easily.  Have a flag in the mail store that declares the messages 
to be "invisible" if you can not actually remove them, and send your 
untagged EXPUNGEs to the client; then as other IMAP sessions go 
EXPUNGE-capable, they send an untagged EXPUNGE for each message that went 
invisible.  When the last concurrent session sends the untagged EXPUNGE, 
you can then remove the invisible message.

My server does this.  Actually, it takes the cheap way out; it only 
removes messages when it has exclusive access.  Otherwise it marks 
messages as invisible.  It's been on my list to have a message share count 
so I can remove messages even when there is shared access, but I haven't 
gotten around to it yet.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

