[GLLUG] mbox or maildir

Adam McDougall mcdouga9 at egr.msu.edu
Wed Jan 24 09:29:26 EST 2007


On Tue, Jan 23, 2007 at 10:21:19PM -0500, Marshal Newrock wrote:

  On Tue, 23 Jan 2007 21:04:19 -0500
  "Jason Folkens" <jason at acd.net> wrote:
  
  > the one good thing that came from qmail is maildir
  > 
  > ...  and i think thats about it.
  > 
  > maildir works well because if you have multiple MTA's delivering to
  > the same mailbox, you won't get a corrupted inbox.   the same is not
  > true for mbox... Since mbox is one contiguous file, if two apps write
  > to the same file, you either get a dirty write, or a corrupted
  > file...   Neither of which are desireable
  > 
  > plus, certain good mail apps only use maildir (like courier imap
  > etc...) I'm not sure wether or not dovecot supports mbox, but I doubt
  > it.
  
  Dovecot supports maildir, mbox, and its own dbox format, although I
  don't know what dbox is, really.
  
  As stated, there are no locking issues with maildir.  It's also easier
  to grep and find a specific message.  imap works better with maildir,
  as it can just read the beginning of each file for the headers, rather
  than scanning the entire file.  I'm a maildir fan.
  
Incremental backups would take less space, and restoring an email is as
simple as restoring a single file (assuming you do backups).  Maildir is
great if you have lots of users randomly accessing (or receiving) mail
since only files containing wanted data have to be accessed or rewritten,
and is ideal for NFS where the mail might be accessed by more than one
program.  On the other hand, since every email is a file, lots of emails
means lots of inodes on your disk, which usually need to be planned for
when the partition is created (try df -i to check limits), and slower 
full backups, slower to open a large mailbox (most filesystems don't like
having thousands of files in one directory), slower email searches, and
much slower disk checks if you have to perform one.  I'd say plan for 
the future if the server might gain more users, its tougher to convert
everyone after the fact.  Maildir has perfectly reasonable performance
for the average client if you keep messages in any one mailbox under a
few thousand.  And if some clients choose to have large mailboxes, it 
won't severely affect anyone else, only themselves.  Client side IMAP
caches can help the apparent Maildir performance alot (such as thunderbird)
and also every client can benefit when the server has enough ram for the
kernel to store tidbits of frequently accessed mail headers in memory.

If you aren't sharing mailboxes between programs or users, and you don't
have lots of heavy read/writes to your mail storage, and you'd prefer
to have somewhat large mailboxes containing tens of thousands of emails,
you can benefit from the raw speed of mbox reads, and almost universal
compatibility with mail programs and IMAP/pop servers.  mbox makes every
mail user suffer when any user has mailboxes that are large in size that are 
accessed, partly during delivery but mainly when the client re-reads or 
modifies large mailboxes frequently.  

Regarding imap daemons that support Maildir, I have used courier and dovecot.
Courier seems to work pretty well, but the logging is almost nonexistant,
which makes it hard when you have a problem, and I think it only supports
Maildir (no mbox).  Dovecot is on the verge of a 1.0 final release, has
more configuration flexibility, supports more than just Maildir, definitely
has better logging, but fine tuning the configuration might take a little
more work.  It pretty much works out of the box with only a little config
however.  


More information about the linux-user mailing list