Hello,

It has been a while since I migrated from Courier to Dovecot, but I don't remember any special problems. They both were using $HOME/Maildir for storage so I did not even had to move anything, just remove that INBOX root prefix from the client config and refresh the folder list.

Best wishes Eugene

-----Original Message----- From: Charles Marcus Sent: Saturday, December 21, 2013 9:12 PM To: dovecot@dovecot.org Subject: Re: [Dovecot] Eliminate legacy INBOX namespace - how?

On 2013-12-21 10:58 AM, Timo Sirainen tss@iki.fi wrote:

On 21.12.2013, at 17.49, Charles Marcus CMarcus@Media-Brokers.com wrote:

...

Our mailstore was converted from a Courier-IMAP system last year, but I am planning a migration to a shiny new VM, and would really like to clean things up and do away with the legacy INBOX namespace.

My goal is to simplify IMAP client setup - no special 'INBOX' namespace needed, they just enter the server info and credentials.

Also important because I will be rolling out SOGo, which has a nice web interface, and I want the mailstore to be as close to default dovecot settings as possible - although I do plan on converting from maildir to mdbox when I do the conversion

I also don't want other folders to show up as subfolders of the Inbox in IMAP clients, they should all show up on the same level as the Inbox.

I've read http://wiki2.dovecot.org/Migration/Courier, but I don't see anything about how to eliminate this stupid legacy INBOX. namespace, so that new IMAP clients won't show all folders as subfolders of the INBOX unless/until they add the INBOX namespace prefix in the advanced settings.

I've also been reading http://wiki2.dovecot.org/Namespaces, but I'm still confused as to how to go about this. 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...

--

Best regards,

*/Charles/*

On 12/21/2013 4:57 PM, Timo Sirainen wrote:

On 21.12.2013, at 19.12, Charles Marcus CMarcus@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