mailboxes.db discrepancies between mailbox and mupdate servers

[Shawn Winnington-Ball]

Hi Dave,

Thanks for the quick, helpful response.

> If you log in to mailbox-03-internal and run:
> 
> # ctl_mboxlist -d | grep "^user\.foo"
> 
> is anything returned?  For that matter, run this on each of your backend
> servers and see if it exists anywhere.

None of the mailbox servers have any record of user.foo, only the
mupdate server does.

> It might be safer to clear the reserved state via mupdate protocol.  You
> can do this manually by using mupdatetest.  You can google for the mupdate
> RFC if you want more details about the protocol, but basically:
> 
> $ mupdatetest your.mupdate.server.com.
> 1 ACTIVATE "user.foo" "mailbox-03-internal!spool" "foo" "lrswipcda"

This worked to change the status of user.foo on the mupdate server:

user.foo	1 mailbox-03-internal!spool foo lrswipkxtecda

> You can force a backend to push all of its mailboxes to the mupdate master
> by running "ctl_mboxlist -m" on the backend.  If you're not 100% sure
> whether you want to push every mailbox before you know what state things
> are in, you can individually push mailboxes, again using mupdate protocol.
>  Log in to the backend and run
> 
> $ mupdatetest your.mupdate.server.com.
> 1 MUPDATEPUSH user.foo

However, I tried running this command and got

B01 MUPDATEPUSH user.foo
B01 BAD "Unrecognized command"

I can't find MUPDATEPUSH in RFC 3656 either.

Shawn