[Dovecot] Eliminate legacy INBOX namespace - how?
Jeff Hardy
hardyjm at potsdam.edu
Tue Dec 24 00:59:44 EET 2013
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
More information about the dovecot
mailing list