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