I'm in the process of upgrading an old server which is running
uw-imap to a new one running Dovecot. With the old machine,
unfortunately, my users had the opportunity to store their e-mails in
various locations. For example, some have their mail boxes stored in
~/mail/[various mbox files], others ALSO have a ~/mail/clients/[various
mbox files] and yet others simply stored them in their ~/ path (thanks
to the old IMAP). Is there a way to create per-user namespaces? I
don't want to create a "mail/", "mail/clients/", etc.,
etc. global name
space that will end up showing up on everyone's mail client, nor do I
want to individually change each user's setup (and rewrite their
.subscriptions file).
Any solutions here, or am I SOL?
AMK4
--
W | It's not a bug - it's an undocumented feature.
+--------------------------------------------------------------------
Ashley M. Kirchner <mailto:ashley at pcraft.com> . 303.442.6410 x130
IT Director / SysAdmin / Websmith . 800.441.3873 x130
Photo Craft Imaging . 2901 55th Street
http://www.pcraft.com ..... . . . Boulder, CO 80301, U.S.A.
On Mon, 2009-08-24 at 11:13 -0600, Ashley M. Kirchner wrote:> I'm in the process of upgrading an old server which is running > uw-imap to a new one running Dovecot. With the old machine, > unfortunately, my users had the opportunity to store their e-mails in > various locations. For example, some have their mail boxes stored in > ~/mail/[various mbox files], others ALSO have a ~/mail/clients/[various > mbox files] and yet others simply stored them in their ~/ path (thanks > to the old IMAP). Is there a way to create per-user namespaces? I > don't want to create a "mail/", "mail/clients/", etc., etc. global name > space that will end up showing up on everyone's mail client, nor do I > want to individually change each user's setup (and rewrite their > .subscriptions file).I think the best solution would be to just finally standardize everyone's mailboxes under ~/mail/. It'll probably help you in future.. But yeah, it's possible to create per-user namespaces by returning namespace_* extra fields from your userdb. There isn't existing documentation how exactly to do that, but basically you'll just have to return the same namespace_* fields that exist in NAMESPACE_* environment variables. You can get a dump of those using post-login script, see http://wiki.dovecot.org/PostLoginScripting. Alternatively you could just set up those NAMESPACE_* settings directly in the post-login script by e.g. reading some file from home dir. But don't let users specify anything, the process is still running as root at that point and they'll get root privileges by changing just a few environment settings.. http://wiki.dovecot.org/Plugins/Virtual also gives a simple example how to return a different inbox=yes namespace for different users. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20090824/a90fc00e/attachment-0002.bin>
Timo Sirainen wrote:> I think the best solution would be to just finally standardize > everyone's mailboxes under ~/mail/. It'll probably help you in future.. >I'm leaning that way, but at the same time dreading it.> http://wiki.dovecot.org/Plugins/Virtual also gives a simple example how > to return a different inbox=yes namespace for different users. >The good thing is that *everyone's* INBOX lives in /var/spool/mail/ (it's actually an NFS mount from the mail spooler). It's the multiple mboxes they've created over the years to sort out (and empty out) their INBOX and store in their user space. Thanks for the suggestions and pointers! AMK4 -- W | It's not a bug - it's an undocumented feature. +-------------------------------------------------------------------- Ashley M. Kirchner <mailto:ashley at pcraft.com> . 303.442.6410 x130 IT Director / SysAdmin / Websmith . 800.441.3873 x130 Photo Craft Imaging . 2901 55th Street http://www.pcraft.com ..... . . . Boulder, CO 80301, U.S.A.
Timo Sirainen wrote:> On Mon, 2009-08-24 at 11:13 -0600, Ashley M. Kirchner wrote: > >> I'm in the process of upgrading an old server which is running >> uw-imap to a new one running Dovecot. With the old machine, >> unfortunately, my users had the opportunity to store their e-mails in >> various locations. For example, some have their mail boxes stored in >> ~/mail/[various mbox files], others ALSO have a ~/mail/clients/[various >> mbox files] and yet others simply stored them in their ~/ path (thanks >> to the old IMAP). Is there a way to create per-user namespaces? I >> don't want to create a "mail/", "mail/clients/", etc., etc. global name >> space that will end up showing up on everyone's mail client, nor do I >> want to individually change each user's setup (and rewrite their >> .subscriptions file). >> > > I think the best solution would be to just finally standardize > everyone's mailboxes under ~/mail/. It'll probably help you in future.. > > But yeah, it's possible to create per-user namespaces by returning > namespace_* extra fields from your userdb. There isn't existing > documentation how exactly to do that, but basically you'll just have to > return the same namespace_* fields that exist in NAMESPACE_* environment > variables. You can get a dump of those using post-login script, see > http://wiki.dovecot.org/PostLoginScripting. Alternatively you could just > set up those NAMESPACE_* settings directly in the post-login script by > e.g. reading some file from home dir. But don't let users specify > anything, the process is still running as root at that point and they'll > get root privileges by changing just a few environment settings.. > > http://wiki.dovecot.org/Plugins/Virtual also gives a simple example how > to return a different inbox=yes namespace for different users. >It sounds like a similar issue I had to deal with, I ended up making several global name-spaces equivalent to ~, ~/mail, and ~/Mail but I made the last two hidden so legacy client setups will still work but new clients would not automatically find them. The only drawback I found was client apparently could not see my public folder namespaces unless they used the ~ namespace (blank prefix in the client). Since so few of my users need public folders I was fine with that.