nissim p:

> Hello all ,

> I am interested in knowing how can i configure imapd with qmail running =
> the mbox ( /var/spool/mail  mailbox ) .
> I have checked the FAQ and there is no indication of how to use the =
> imapd with the regular mailbox with tcpserver wrapping it like the=20
> way it is done with qmail-pop3d .

[...]

Qmail can deliver mail in two formats, namely Mailbox and
Maildir. Mailbox is the traditional Unix approach with all mails for
one user concatenated in one (maybe large) file in somewhere like
/var/spool/man/USERNAME. Maildir is a completely different approach
that puts each delivered mail into a separate file in a directory
under (normally) a users homedirectory. qmail-pop3d is only suitable
for Maildir, not for Mailbox. For that you have to get another daemon
that can access Mailboxes, like Qualcom Qpopper for instance.

For imap access you can either use the University of Washington imap
server (Mailbox) or Courier Imapd (Maildir, can be found via
www.qmail.org).

Now, you might want to rethink wether you want use the Mailbox format
full stop, probably for pop3 access and most definitely for imap
access. The reason is that Mailbox files can i) become garbled easily
ii) scale terribly for a large amount of mails. In the imap scenario a
user would manipulate (view/delete/change status) mail on the server
right inside the mailbox file. Consider what happens if a piece of
mail has to be deleted that sits in the middle of a 100 MB Mailbox:
First all of the mails that precede it have so be scanned and saved
somewhere and then all the mails following it appended. So the entire
mailbox file has to be once read and written for each delete
operation. You don't even want to think about a crash while such an
operation is in progress.

Pop3 access might just about be fine (apart from reliability questions
and garbled mailbox files) if your users retrieve their mails
regularily. On the other hand, there is always the dreaded "Leave Mail
on Server" setting in pop3 mailclients that leads to ever increasing
mailbox files, that users are not even aware of, except for the
increase in time that it takes to get at their most recent mail.

Maildir does not suffer from either of these problems since the
delivery algorithm guarantees that a Maildir is always in a sane state
and since each mail sits in its own file there is not much of a
performance penalty associated with deleting the mail or changing its
status (Courier Imapd does this by just altering the filename, not
even the file itself). Depending on the underlying filesystem you
might run into performance problems for very large amounts of mails in
one directory of a Maildir, but that tends to be in the thousands of
mails.

For a third alternative for imap/pop3 access there is also the Cyrus
imap and pop3 combination (http://asg.web.cmu.edu/cyrus/), which
stores mails away from user home directories in either a format not
dissimilar to Maildir (Cyrus versions < 2.0) or in Berkeley DB
database format (Cyrus versions > 2.0) which gives you transaction
protected storage and manipulation of mails.

hope that helps,


-- 

Joerg Lenneis

email: [EMAIL PROTECTED]







Reply via email to