disconnect_on_vanished_mailbox

Bron Gondwana brong at fastmail.fm
Sat Dec 4 16:41:44 EST 2010


On Sat, Dec 04, 2010 at 10:33:49AM -0500, Chris Conn wrote:
> Hello,
> 
> I am looking at this option for 2.4.5;
> 
> disconnect_on_vanished_mailbox: 1
> 
> If enabled, IMAP/POP3/NNTP clients will be disconnected by the server if 
> the currently selected mailbox is (re)moved by another session. 
> Otherwise, the missing mailbox is treated as empty while in use by the 
> client.
> 
> Some techs have the nasty habit of renaming mailboxes as some sort of 
> means to remove POP3 locks on a dead customer session.

Oh my god.  Removing locks, ur doin ir rong.  W.T.F.

And what happens if an email gets delivered via LMTP during this window?

Is the plan to rename that mailbox straight back again afterwards?

> This renaming 
> atrocity seems to work on pop3 clients, however my tests show that if we 
> rename a mailbox on a active IMAP connection, the rename works, however 
> the original mailbox is only deleted once the socket times out or the 
> client closes his client.

Yeah, pretty much.  Next time the client actually TRIES anything, they'll
get a "this mailbox is now deleted" back, and that option will make the
connection drop.  Basically, they're holding the namelock on the mailbox
name still - but the index header has a "this is deleted" flag, so the
mailbox_lock_index call will notice that when it refreshes the index
header and return IMAP_MAILBOX_NONEXISTENT.

> I was hoping this option would disconnect the 
> IMAP client, as I added a pop3test to try and remove the IMAP mailbox 
> lock on the old mailbox, but to no avail.  The end result is a duplicate 
> account, mail is moved to the new mailbox and we have to manually move 
> back the mailbox name.

Yeah, so don't do it.  Sheesh.

> Is there any way I can cheat on a mailbox lock to allow a rename when an 
> active IMAP connection is on that locked mailbox?

No.  This kind of bogus, racy, non-deterministing messing is precisely what
the strong consistent locking design of Cyrus 2.4 is designed to avoid!

You could always:

cd /var/imap/proc; grep -l $username * | xargs kill

if you actually want to kill the user connections.

Bron.


More information about the Info-cyrus mailing list