On 01/03/04 19:01:37 +0200 Timo Sirainen <[EMAIL PROTECTED]> wrote:
On 3.1.2004, at 00:43, Mark Crispin wrote:
You will not tempt fate if you either: . forbid shared expunge . keep the message text around until the last client that has the mailbox open is notified about the expunge
The other strategies tempt fate.
Why subject yourself to the risk, when there is such a clear answer that does not tempt fate?
Wasn't IMAP supposed to work with existing mail stores? How exactly do you do this with maildir or mbox? Or anything else than mbx and other formats explicitly designed for IMAP?
UW-IMAP's solution to unexpectedly changing mbox is BYE. Maybe that's the correct answer then.
just for the record. I just tested with cyrus imap and verified by reading
source. In it's proprietary mailstore the message text is stored in one file per message. Upon expunge it immediately unlinks the files making the
message text unavailable for other sessions.
Cyrus also caches frequently used fetch responses like body, bodystructure, envelope and metadata like flags. These it seems to keep around even after the message text itself has been expunged.
It's response to a FETCH of expunged message text is an empty string
--snipp-- a0001 FETCH 3:7 BODY[] * OK Message 3 no longer exists * 3 FETCH (BODY[] "") * OK Message 4 no longer exists * 4 FETCH (BODY[] "") * OK Message 5 no longer exists * 5 FETCH (BODY[] "") * OK Message 6 no longer exists * 6 FETCH (BODY[] "") * OK Message 7 no longer exists * 7 FETCH (BODY[] "") a0001 OK Completed --snipp--
It seems cyrus also chose to avoid sending NO FETCH responses.
Greetings Christian
-- Christian Kratzer [EMAIL PROTECTED] CK Software GmbH http://www.cksoft.de/ Phone: +49 7452 889 135 Fax: +49 7452 889 136
