This documentation is for Dovecot v2.x, see wiki1 for v1.x documentation.
Differences between revisions 14 and 15
Revision 14 as of 2010-06-15 15:05:44
Size: 3480
Editor: TimoSirainen
Comment:
Revision 15 as of 2010-09-06 08:56:49
Size: 4926
Editor: WilliamBlunn
Comment: Add section "Mailbox directory name"
Deletions are marked like this. Additions are marked like this.
Line 65: Line 65:

== Mailbox directory name ==

When using LAYOUT=fs, there is a potential for naming clashes between Maildir's {{{new/}}}, {{{cur/}}} and {{{tmp/}}} subdirectories and mail folders of the same names. For example, consider a mail folder "foo/bar". Under LAYOUT=fs, this mailbox will have Maildir's usual three directories {{{~/Maildir/foo/bar/{new,cur,tmp}/}}}.

If the user then tries to create a mail folder "foo/bar/new", this would then imply Maildir's usual three directories {{{~/Maildir/foo/bar/new/{new,cur,tmp}/}}}. But this overlaps the Maildir {{{new/}}} subdirectory of mail folder "foo/bar".

This may not be a problem in many installations, but if it is desired to eliminate this issue, then the DIRNAME configuration directive can be used. For example, if we specify mail location as:

{{{
mail_location = maildir:~/Maildir:LAYOUT=fs:DIRNAME=mAildir
}}}

then this will push Maildir's {{{new/}}}, {{{cur/}}} and {{{tmp/}}} subdirectories down into a subdirectory {{{mAildir/}}}, so a mail folder "foo/bar" would be stored at {{{~/Maildir/foo/bar/mAildir/{new,cur,tmp}/}}}. A mail folder "foo/bar/new" would be stored at {{{~/Maildir/foo/bar/new/mAildir/{new,cur,tmp}/}}}, which would then have no overlap with the mail folder "foo/bar".

The value for DIRNAME should be chosen carefully so as to minimise the chances of clashing with mail folder names. In the example here, unusual upper/lower casing has been used.

Maildir configuration

See MailboxFormat/Maildir for a complete description of how Dovecot has implemented Maildir support.

Mail location

Maildir exists almost always in ~/Maildir directory. The mail location is specified with:

mail_location = maildir:~/Maildir

Directory layout

By default Dovecot uses Maildir++ directory layout. This means that all mailboxes are stored in a single directory and prefixed with a dot. For example:

  • Maildir/.folder/
  • Maildir/.folder.subfolder/

If you want maildirs to use hierarchical directories, such as:

  • Maildir/folder/
  • Maildir/folder/subfolder/

you'll need to enable fs layout:

mail_location = maildir:~/Maildir:LAYOUT=fs

Control files

Dovecot stores some Maildir metadata into two control files:

  • dovecot-uidlist file contains IMAP UID <-> Maildir filename mapping

  • dovecot-keywords file contains Maildir filename flag (a..z = 0..25) <-> keyword name mapping

Both of these files are described fully in MailboxFormat/Maildir. The important thing to remember about them however is that they shouldn't be treated the same way as index files. Index files can be deleted and rebuilt without any side effects, but if you delete control files you'll cause messages to get new UIDs and possibly lose keyword names.

If the messages get new UIDs, the IMAP clients will invalidate their local cache and download the messages all over again. If you do this for all the users, you could cause huge disk I/O bursts to your server.

Dovecot can't currently handle not being able to write the control files, so it will cause problems with filesystem quota. To avoid problems with this, you should place control files into a partition where quota isn't checked. You can specify this by adding :CONTROL=<path> to mail_location, for example:

mail_location = maildir:~/Maildir:CONTROL=/var/no-quota/%u

Index files

See MailLocation#indexfiles for full explanation of how to change the index path. For example:

mail_location = maildir:~/Maildir:INDEX=/var/indexes/%u

Optimizations

  • maildir_very_dirty_syncs=yes: Assume that only Dovecot accesses cur/ directory. If another process (or even Dovecot which doesn't update index files) does changes to cur/ while the mailbox is simultaneously being modified by Dovecot, Dovecot may not notice those external changes. It's still safe to deliver new mails to new/ using non-Dovecot software.

  • maildir_copy_with_hardlinks=yes (default): When copying a message, do it with hard links whenever possible. This makes the performance much better, and it's unlikely to have any side effects. Only reason to disable this is if you're using a filesystem where hard links are slow (e.g. HFS+).

  • maildir_stat_dirs=no (default): Assume that all the files beginning with a dot in the maildir are maildirs. You shouldn't have any non-directory files beginning with a dot in the maildirs, but if you do you may need to set this to "yes", in which case Dovecot needs to stat() each directory entry, which degrades the performance. Some filesystems provide the directory/non-directory status for free without having to stat(). In those filesystems this setting is ignored.

Filesystem optimizations

See "Maildir and filesystems" section in MailboxFormat/Maildir.

Mailbox directory name

When using LAYOUT=fs, there is a potential for naming clashes between Maildir's new/, cur/ and tmp/ subdirectories and mail folders of the same names. For example, consider a mail folder "foo/bar". Under LAYOUT=fs, this mailbox will have Maildir's usual three directories ~/Maildir/foo/bar/{new,cur,tmp}/.

If the user then tries to create a mail folder "foo/bar/new", this would then imply Maildir's usual three directories ~/Maildir/foo/bar/new/{new,cur,tmp}/. But this overlaps the Maildir new/ subdirectory of mail folder "foo/bar".

This may not be a problem in many installations, but if it is desired to eliminate this issue, then the DIRNAME configuration directive can be used. For example, if we specify mail location as:

mail_location = maildir:~/Maildir:LAYOUT=fs:DIRNAME=mAildir

then this will push Maildir's new/, cur/ and tmp/ subdirectories down into a subdirectory mAildir/, so a mail folder "foo/bar" would be stored at ~/Maildir/foo/bar/mAildir/{new,cur,tmp}/. A mail folder "foo/bar/new" would be stored at ~/Maildir/foo/bar/new/mAildir/{new,cur,tmp}/, which would then have no overlap with the mail folder "foo/bar".

The value for DIRNAME should be chosen carefully so as to minimise the chances of clashing with mail folder names. In the example here, unusual upper/lower casing has been used.

None: MailLocation/Maildir (last edited 2015-12-06 11:41:10 by TimoSirainen)