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 at.

We have Dovecot store its index files on our IMAP server's local disk, in /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 Mail in your home directory with a mailbox 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 an APPEND, COPY, or MOVE operation. However, there are other reasons.)

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 LIST 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 $HOME' 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.

(The unofficial IMAP protocol wiki may be something I'll be consulting periodically now that I've stumbled over it, eg this matrix of all of the IMAP RFCs.)