69 lines
3.2 KiB
Plaintext
69 lines
3.2 KiB
Plaintext
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.
|
|
|