"Christof Drescher" <[EMAIL PROTECTED]> writes: >Philip Guenther wrote: >>>Not only that. Two examples: 1) Mails which confidential data should be >>>erasable as soon as possible; it is not acceptable (especially on heavily >>>connected mailboxes) to have it delivered after an EXPUNGE anymore. >> >>Who decides what is acceptable here? Confidentiality is generally tied >>to legal or contractual requirements; is there some legal definition >>and/or body of relevant case-law that is controlling in this situation? > >That need not be. Confidentially can be a purely subjective idea, and >therefore it may only hold for the user himself.
Have the UNIX users at your site complained about how the kernel lets processes access files after they have been unlinked? Hmm, perhaps that's the model to follow: some 'trusted' versions of UNIX support a means of revoking access to a file by processes that already have it open. However, this is *not* the default behavior and involves a separate system call. Ergo, if this behavior is desired in an IMAP server then clients should request it by using an extension designed to provide it. That way clients would actually know for sure whether they were getting the behavior when they really wanted it. >>That you used the phrase "as soon as possible" might be considered to >>weaken the argument. If the requirement isn't absolute, why can't it >>accept 'ghost' messages? > >The argument was just against keeping the mails around though they >should have been expunged before, so it's no argument against 'ghost' >messages (that would meet the requirement too). Ghosts were abandoned >for another reason as Arnt stated. Please note that I use "ghost messages" here in the sense of rfc2180, section 4.1.1, as messages that have been expunged in some but not all sessions and that are still fully retrievable in those other session. (btw, the meaning of phrase "should have been expunged before" depends on what you believe is allowed.) >>>2) we work on a shared Mailbox ourselves, where each mail should be >>>work on only once. We set it flagged when we're on it, and delete it >>>when we're done. Does not help if they fly around after expunge either. >> >>That the message be inaccessible after EXPUNGE doesn't seem a real >>requirement here, as clients would just skip messages marked \deleted. > >No. >There are clients which show messages marked as deleted only with some >sort of flag or striking. Also, it is still accessible like before. That sounds like a feature, not a bug, to me. If there's any specialization (even mild) among the people watching this mailbox, it would be perfectly reasonable for someone to want to look at a messages handled by someone else. Where that isn't an issue, what's wrong with the "people solution" of just making sure people understand that their time is valuable and they can be confident that messages marked deleted have been handled by someone else? What does this have to be pushed into the protocol? >I want the message to disappear on the server at once, which happens >at an EXPUNGE for all clients. So the *real* problem is that the involved clients display things differently and/or unacceptably? >>Atomic fetch-and-set of flags is addressed by the CONDSTORE extension, >>which I understand to have beeen designed for *exactly* the situation >>you describe. > >Might be. I'll have a look at it, but as I read the synopsis, it does >not deal with EXPUNGE, so it misses the point. You've missed the intent: it provides the only means to perform atomic fetch-and-alter with IMAP. If you need atomic operations like that, then you need to obtain a) a server that supports the extension, and b) a client that uses the extension to implement the desired behavior. Since the client already has to be modified to use the UNCHANGEDSINCE modifier on its STORE commands (where needed), you're not going to be doing this with any old IMAP client you have lying around. I agree that it doesn't answer your complaint that your client clutters the mailbox view with messages marked \deleted, but, IMHO, that's a client issue, not a protocol issue. Philip Guenther [EMAIL PROTECTED]
