wasm-demo/demo/ermis-f/imap-protocol/cur/1600095108.22889.mbox:2,S

42 lines
1.9 KiB
Plaintext

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.