Some things about Dovecot, its index files, and the IMAP LIST command
We have a backwards compatibility issue
with our IMAP server, where people's IMAP roots are
$HOME, their home directory,
and then clients ask the IMAP server to search all through the IMAP
namespace; this causes various bad things to happen, including
running out of inodes. The reason we ran
out of inodes is that Dovecot maintains some index files for every mailbox it looks
We have Dovecot store its index files on our IMAP server's local
/var/local/dovecot/<user>. Dovecot puts these in a
hierarchy that mirrors the actual Unix (and IMAP) hierarchy of the
mailboxes; if there is a subdirectory
Drafts, the Dovecot index files will be in
.../<user>/Mail/.imap/Drafts/. It follows that you can hunt
through someone's Dovecot index files to see what mailboxes their
clients have looked at, although this may tell you less than you
think and what their active mailboxes are.
(One reason that Dovecot might look at a mailbox is that your client
has explicitly asked it to, with an IMAP
SELECT command or perhaps
MOVE operation. However, there are other
When I began digging into our IMAP pain and working on our planned migration (which has drastically changed directions since then), I was operating under the charming idea that most clients used IMAP subscriptions and only a few of them asked the IMAP server to inventory everything in sight. One of the reasons for this is that only a few people had huge numbers of Dovecot index files, and I assumed that the two were tied together. It turns out that both sides of this are wrong.
Perhaps I had the idea that it was hard to do an IMAP
operation that asked the server to recursively descend through
everything under your IMAP root. It isn't; it's trivial. Here's
the IMAP command to do it:
m LIST "" "*"
That's all it takes (the unrestricted * is the important bit). The sort of good news is that this operation by itself won't cause Dovecot to actually look at those mailboxes and thus to build index files for them. However, there is a close variant of this LIST command that does force Dovecot to look at each file, because it turns out that you can ask your IMAP server to not just list all your mailboxes but to tell you which ones have unseen messages. That looks like this:
m LIST "" "*" RETURN (SPECIAL-USE STATUS (UNSEEN))
Some clients use one LIST version, some use the other, and some seem to use both. Importantly, the standard iOS Mail app appears to use the 'LIST UNSEEN' version at least some of the time. iDevices are popular around the department, and it's not all that easy to find the magic setting for what iOS calls the 'IMAP path prefix'.
For us, a user with a lot of Dovecot index files was definitely
someone who had a client with the 'search all through
problem (especially if the indexes were for things that just aren't
plausible mailboxes). However, a user with only a few index files
wasn't necessarily someone without the problem, because their client
could be using the first version of the
LIST command and thus not
creating all those tell-tale index files. As far as I know, stock
Dovecot has no way of letting you find out about these people.
(We hacked logging in to the Ubuntu version of Dovecot, which involved some annoyances. In theory Dovecot has a plugin system that we might have been able to use for this; in practice, figuring out the plugin API seemed likely to be at least as much work as hacking the Dovecot source directly.)
Sidebar: Limited LISTs
IMAP LIST commands can be limited in two ways, both of which have more or less the same effect for us:
m LIST "" "mail/*" m LIST "mail/" "*"
For information on what the arguments to the basic LIST command mean, I will refer you to the IMAP RFC. The extended form is discussed in RFC 5819 and is based on things from, I believe, RFC 5258. See also RFC 6154 and here for the special-use stuff.