[Dovecot] Eliminate legacy INBOX namespace - how?

[Jeff Hardy]

On 12/21/2013 4:57 PM, Timo Sirainen wrote:
> On 21.12.2013, at 19.12, Charles Marcus <CMarcus at Media-Brokers.com> wrote:
>
>>> I don't think it can be done easily with just a single config. Whatever you do to new users might break existing setups. So the only good way I think would be to use two different IPs. One for the new setups, one for the old. For example imap.domain.com -> mail.domain.com or vice versa.
>>
>> Actually, that's a good idea... thanks!  :)
>>
>> Then I guess I proxy the old users to the old server until I get them all converted? Now I'm off to read about how to implement that...
>
> You can use a single Dovecot, just use something like:
>
> namespace inbox {
>    prefix =
> }
>
> local 1.2.3.4 {
>    namespace inbox {
>       prefix = INBOX.
>    }
> }
>
> Where 1.2.3.4 would be the IP for the old configuration.
>


We migrated from Courier-IMAP to Dovecot 1.1(?) many years ago, and used 
the alternative mentioned in the wiki with few problems.  This is what 
our Dovecot 1.2 config looked like:

namespace private {
    separator = .
    prefix =
    inbox = yes
}
namespace private {
   separator = .
   prefix = INBOX.
   inbox = no
   hidden = yes
   list = no   # for v1.1+
}

For our current Dovecot 2.0.9, it changed only slightly:

namespace {
    separator = .
    prefix =
    inbox = yes
}
namespace {
    separator = .
    prefix = INBOX.
    inbox = no
    hidden = yes
    list = no
    alias_for =
}

Note that what I have is different than what is currently in the wiki, 
and it has been awhile since I was hip-deep in this, so apologies if it 
is not current recommended practice (or wrong).

What I can say is that most/all of our Courier users had set "INBOX." as 
their namespace folder prefix (depends what the client calls it), with 
the intention of shifting their subfolders out from underneath Inbox in 
their clients.  With the change, they still worked, and new unconfigured 
clients work, side-by-side.  At this point we probably have no clients 
with any special configuration in this regard (which is why I won't 
discard the possibility that this is now wrong and not even doing what 
was originally intended).

The only namespace-related problem I can even think of over the years is 
what we call "nested inbox hell," example:

.INBOX.INBOX.INBOX.INBOX.INBOX.INBOX.Sent
.INBOX.INBOX.INBOX.INBOX.INBOX.Sent
.INBOX.INBOX.INBOX.INBOX.Sent
.INBOX.INBOX.INBOX.Sent
.INBOX.INBOX.Sent
.INBOX.Sent

This seems limited to Apple mail clients, is not global, and I have no 
idea if it is even related, but thought it worth mentioning.  We 
scripted the cleanup/merge, and nail it if it appears.  Rare.

Cheers.

-Jeff