For reasons beyond the scope of this entry, we've recently wanted to let certain people read some shared mailboxes through our IMAP server instead of other mechanisms such as 'mail to HTML' and an access restricted Apache setup. In our configuration, there are broadly three approaches we could take to do this, two of which actually work. The obvious but non-working approach is to tell people to use the absolute path to the mailbox; this doesn't work because Dovecot index files get in the way.

The sort of working approach is to tell people to make a symlink in their IMAP home directory to the mailbox, under whatever name they want. With certain restrictions this works (assuming that Unix filesystem permissions allow you access, which they do in our case), and because you've put the symlink in your home directory you avoid the Dovecot index file problem. However, everyone who wants to read the mailbox has to go do this (or you have to do it for them) and there are various things that can go wrong with the symlink.

What is probably the best way is Dovecot namespaces, which let you inject additional mailboxes into the IMAP client's view of the world, with some restrictions. We get some additional restrictions because we're trying to do this with mbox format mailboxes, which appear more restricted in what Dovecot 2.2.33 will accept.

The first confusing thing about Dovecot namespaces is that it uses different terminology than RFC 2342 on IMAP4 Namespaces. The RFC talks about 'personal' or 'private' namespaces (your own mailboxes), 'other users' namespaces' (their mailboxes) and 'shared namespaces' (mailboxes that are shared among various users). Dovecot's terms for these are 'private', 'shared', and 'public' namespaces.

Every Dovecot namespace must has a prefix (which is what the IMAP client will use to access it). If the namespace is listable, the prefix must end with the hierarchy separator, which is normally '/'. Each namespace will normally also have a 'location', which says where to find the underlying mailboxes and what format they're in. Locations can also specify where their index files go, and you will want to use this for public mailboxes to avoid index file problems. For the location of mbox format mailboxes, it appears that you can only specify a directory where they're found in; you cannot directly specify a single mailbox.

(To translate this to practical terms, you can inject a 'List-Archives/' namespace that points to /local/list-archives/ that has archives of mailing lists in mbox format, but you can't inject a 'Fred-Archive' namespace that points directly to /local/list-archives/fred-archive. Because you have to point a namespace to a directory, if the directory has a bunch of mailboxes with different access permissions, everyone with the namespace will see all of the files listed even if they can't access most of them.)

Unfortunately, you can't change mailbox locking methods on a per location basis, for example if you have a read-only set of mailboxes that Dovecot should never attempt any locking on. In addition, if you have Dovecot set to do 'dotlocking' on mbox files, you will normally need to configure your Dovecot settings to use the 'dotlock_try' locking method instead of 'dotlock'. Otherwise, all public mailboxes will have to be in directories that everyone can create dotlock files in.

Even with dotlocking entirely turned off, Dovecot is unhappy with mbox mailboxes on read only filesystems under at least some situations, which is something we run into with our 'oldmail' feature. Dovecot will cope with read only mailboxes owned by other people in normal filesystems, and it might cope with them on, for example, a read only NFS mount (I haven't tested).

My personal view is that you probably want to set any read-only public namespaces up with 'ignore_on_failure = yes', so that if for some reason there are problems accessing the location of the public mailbox, people can still get access to their regular IMAP mail. Whether you want to do this with public namespaces that people modify mail in depends on what you're using them for. However, I'm not certain what Dovecot considers a failure to load the location; for mbox locations, it doesn't appear to check that the directory you give is accessible to it at the time when it sets up your session.

It's possible to only add a namespace to some people's IMAP sessions instead of to everyone's, but doing this is complicated and well beyond the scope of this entry. You can see one way of doing this in Dovecot's page on post-login scripting. Note that the post-login script (or scripts) run as the Dovecot user, not as the authenticated user, so you can't use Unix file permissions to tell if they will have access to things. For certain purposes, it may be simpler to add a namespace with restricted mailboxes to everyone's session, but set it hidden and not list-able, and then tell appropriate people what magic IMAP name to use to access things in it. Sufficiently nosy people could try to access 'Restricted/Fred' (or list all of 'Restricted/'), but they'd get a Unix file access permission error, and hiding the namespace means that people who don't have access to it aren't confused or irritated by seeing it.

(In some cases it's an active feature that the namespaces you're adding don't show up in IMAP LIST commands, for example if they're a mixed directory that has a few things you can access mixed in with a pile of things you can't.)

If you want to either cloak the existence of mailboxes within a namespace or not annoy people with a bunch of new things showing up in LIST output (some or much of which they may not be able to access), my impression is that it's more important to set the namespace to 'list = no' than it is to set it 'hidden = yes'. Setting it hidden just keeps it out of IMAP NAMESPACE commands, at least as I understand things right now.

PS: It's possible that using Maildir format mailboxes will make various parts of this easier and better. We haven't had good experiences with Maildir in our environment, especially with large mailboxes. Some of this is due to NFS's issues dealing with tons of small files.