"Christof Drescher" <[EMAIL PROTECTED]> writes: ... >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 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? (Personally, I doubt the "real world" would care to draw a distinction between "inaccessible to a session once the EXPUNGE command has been processed" and "inaccessible to a session once the EXPUNGE command has been processed and the session has sent a command other than STORE, FETCH, or SEARCH". If they *do* draw that distinction, what about data in application output buffers? The OS's socket buffers? Does the application need to crash the machine to prevent the sending of data that has already reached the socket buffers?) (Also, why does it matter whether the mailbox is heavily connected or only lightly connected? I don't see why that would matter as far as server design or the legal effects run.) >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. 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. Philip Guenther [EMAIL PROTECTED]
