MBOX-Line: From mrc at CAC.Washington.EDU  Fri Sep 15 07:37:13 2006
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:37 2018
Subject: [Imap-protocol] reporting/detecting expunged messages
In-Reply-To: <LWKbk3lpdVhtHUTm38BDeA.md5@libertango.oryx.com>
References: <4505F2FE.8090807@sun.com>
	<Pine.WNT.4.65.0609111648410.5544@Tomobiki-Cho.CAC.Washington.EDU>
	<450713AB.4090601@sun.com>
	<Pine.WNT.4.65.0609121316280.2164@Tomobiki-Cho.CAC.Washington.EDU>
	<45071A57.5080406@sun.com>
	<9SYO8YZNXU3qj9EYGtuGNg.md5@libertango.oryx.com>
	<Pine.WNT.4.65.0609121437140.2164@Tomobiki-Cho.CAC.Washington.EDU> 
	<2xKZXsAOqJTXDcZB/xUw7g.md5@libertango.oryx.com> 
	<Pine.WNT.4.65.0609141841560.1540@Tomobiki-Cho.CAC.Washington.EDU>
	<LWKbk3lpdVhtHUTm38BDeA.md5@libertango.oryx.com>
Message-ID: <Pine.OSX.4.64.0609150710160.368@pangtzu.panda.com>

On Fri, 15 Sep 2006, Arnt Gulbrandsen wrote:
>> Instead of looking at it from the protocol viewpoint, you are looking at it 
>> from the viewpoint of how some server implementation may implement it.
> I'd say: I'm looking at what the promises made by IMAP standard to client 
> authors, which standards-conformant servers must fulfill. In particular what 
> promises made about the effects of the EXPUNGE command.

It's not much different from what promises are made by operating systems 
when a process deletes a file when some other process has the file open. 
On UNIX, the file is deleted; on Windows NT, the delete is rejected.

Neither pulls the rug out from the other process.  Specifically, on UNIX 
the other process continues to access the file and its data for as long as 
it wants as if it wasn't deleted.

> My issue is rather the opposite - can a client force destruction of a message 
> on a server, such that other IMAP clients cannot access the message?

It can stop new access; that is, a new SELECT from accessing the message.

What it can not do is stop IMAP clients which are already accessing the 
message (which is what SELECT does) from accessing the message.  It can 
only get those other clients to de-access the message at defined points in 
their session.  Those points are normally quite frequent in an IMAP 
session.

> (Btw, I changed our code today to use 4.1.2+loopbreaker. The first time a 
> client fetches a message which another client has expunged, but whose expunge 
> has not yet been reported in this session, the server issues a NO as in 
> 4.1.2, and makes a note of the UID(s). If any of those UIDs are fetched again 
> before the server can report the expunge, the server issues a BYE. When it 
> reports expunges, it clears its UID set. I think that's as good as 
> 4.1.1+period.)

I think that 4.1.2 is a bug, and servers that do it are broken.

I think that the security issues are specious (otherwise, we wouldn't be 
using UNIX).  It's all a matter of 4.1.1/4.1.4 being difficult to 
implement with maildir-style one-file/one-message mail store and 
4.1.2/4.1.3 being easy.

When a client author complains to me about such servers (and they do 
complain), my response is "complain to that server's vendor."

-- 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.

