"Michael Smith" <[EMAIL PROTECTED]> wrote:
>We're currently looking at mail solutions for our online email
>system, and we've hit against an interesting conundrum. We were
>wondering what the advantages are to listing mail messages as
>individual files over a spool file?
The choice is file-per-mailbox (a la mbox) or file-per-message (a la
maildir).
They each have their pros and cons, of course.
Adding a new message to either is pretty cheap, but in the case of
mbox, locking is required to ensure that multiple simultaneous updates
don't conflict.
Deleting a message from an mbox requires reading the entire file and
writing it all back out, except for the deleted message. Deleting a
message from a maildir only requires unlinking the file containing the
message. Again, updating the mbox requires locking.
Indexing an mbox mailbox requires reading the entire mailbox and
parsing the messages--parsing is undesirable. Indexing a maildir
mailbox requires opening each file and reading the header--that means
lots of directory accesses and open() system calls.
Large mbox mailboxes are huge, unwieldy files. Large maildir mailboxes
are huge, unwieldy directories--most filesystems don't handle them
efficiently after they grow to a few thousand files.
>We're looking for a system which will scale to several tens of thousands of
>users on each machine.
How will mailboxes be served? POP? IMAP? Which daemon? Which mailbox
format(s) does it support well? Where will they be stored? If the
storage is network attached (which is good for redundancy), does the
storage system provide a satisfactory locking mechanism?
-Dave
