On 13 Jul 2007, at 05:03, David Carter wrote:
1) admin users can see the deleted mailboxes and just rename them back into the live mailbox space:DELETED/453f56443/user/dpc22/foo -> user/dpc22/foo
A downside of this approach is that the total size of the mailbox list is increased. This can cause significant load in some environments.
2) We can use cyr_expire to remove deleted mailboxes as well as expunged messages, which seems to be an open issue in your version. Presumably Umich use some kind of external utility to clear away old mailboxes?
cyr_expire could be used in either case, assuming you want to add code to it. However, a major benefit of your methodology is that delayed delete benefits from replication. In my version, it doesn't. With my version, an admin can choose to have delayed deleted enabled separately on the primary and replica backends. When the sync protocol says to delete something, if delayed delete is enabled, the deleted mail is moved to the deleted hierarchy. In your version, delayed delete only makes sense on the primary backend, but the deleted hierarchy is replicated so it doesn't really matter.
I wonder if the deleted hierarchy needs to pay attention to the mailbox name hashing.
:wes
