On 2/20/2012 4:58 PM, Jim Lawson wrote:
On 2/20/12 3:36 PM, Steve Campbell wrote:
Thanks for that input. I still think I'm missing something since I
too used the compatibility link that you pointed to. Only thing is
that proceeding those namespaces, I used the first example of:
namespace {
type = private
separator = /
prefix = "#mbox/"
location = mbox:~/mail:INBOX=/var/mail/%u
inbox = yes
hidden = yes
list = no
}
namespace {
type = private
separator = /
prefix =
location = maildir:~/mail
}
This seemed to get the ball rolling so that users could access
anything at all. I still have the problem of client imap folders
being different from webmail imap folders. That's pretty much why I'm
thinking of using mbox as the INBOX and all other imap folders in the
~/mail directory in maildir format.
You ought to be able to get webmail to see the same folders as the
imap clients.
Should I remove the first two namespaces, in your opinion? Right now,
the whole thing is kind of fragile.
From your added namespaces, it looks like you are trying to support
mbox and maildir and ~/mail at the same time. Do you already have
maildir folders to support? If not, I would try to get things working
well with mbox first before I started a conversion to maildir. I
would also ask why you're thinking of moving to maildir. Yes, there
are caching benefits, but when you add the Dovecot indexing on top of
mbox, it's pretty much a wash. If you are using file-level backup,
rather than some sort of snapshot technology, maildir will be much,
much slower to back up. Your system will spend all its time walking
directories, opening and closing files. If you don't have many users
to worry about it might be OK, but make sure it's worth it. A lot of
sites went to maildir in the 1998-2004 era and have regretted the
decision as their systems get overloaded with files and they can't
back them up.
No, I've got all mbox formats. Previous posts probably suggested that I
wanted to move to maildir, but all of the replies I've received have
convinced me that I do not want to do that. The folders in ~ and ~/mail
are mboxes, so I need to see what damage I've done with a maildir
namespace. The maildir reference could be part of the problems I'm seeing.
I'm still not sure whether I should be seeing .subscriptions or
mail/subscriptions anywhere and whether Dovecot will use the
.mailboxlist that exists. The wiki suggests that I need to recompile
Dovecot to continue using .mailboxlist. This is something I don't want
to do.
Horde/Imp updates are probably out of the question until I can get a
server to install the upgrade on.
For Dovecot and IMP both, you should set up an alternate server to
test out your config changes on before you put them into production.
If you are running on a bare metal single server, set up another
Dovecot instance on a different set of ports (I commonly use 20143
(imap), 20993 (imaps), 20110 (pop3)) which you can fiddle with
freely. Once you are satisfied with the result in your various
clients, put it into production. You can do the same with Horde/IMP
by putting an installation in a different location on your webserver.
Jim
I've got a second server that is totally independent of the one I'm
messing with. I've done the horde/imp alternate port/config. It all went
well. The downside is that I didn't realize those secondary folders in
~/mail were being hidden. Kinda late to switch back, but the secondary
server supports another domain, so I have it to test with.
Again, the damage I've caused to those secondary imap folders needs to
be determined to get this fixed properly. Most users are seing the
secondary folders and can use them. It's just those users who have
folders in ~ that are seeing problems as far as I can tell.
Thanks
steve
