

What is Dovecot?

Well, let's follow the path of a typical mail message from start to finish and see where Dovecot would fit.

To begin with, a someone out in the world creates a mail message in their mail-user-agent [MUA]. Examples of typical MUA's include [ Mozilla Thunderbird] and Microsoft Outlook Express. Whatever was used, a message was created and sent to that user's mail-transfer-agent [MTA] - using the SMTP protocol. Then that MTA checks the message to determine the recipient (we'll pretend that's YOU), queries its DNS servers to find out the responsible MTA for the recipient's domain, and sends the message to that MTA - again using the SMTP protocol. At this point, the message has traveled from the remote user's workstation, to their ISP's mailserver, and has reached your domain. Now what happens?

Depending on the network configuration, it's quite possible that the message will be relayed to yet another MTA. But at some point, one MTA will take responsibility for the message and become responsible for delivery. At this time, the MTA will pass the message to a mail-delivery-agent [MDA]. At its core, an MDA is responsible for actually saving the mail to disk. Some MDA's do other things as well, such as filtering mail or delivering to subfolders. But it is the MDA that stores the mail on the server.

Now, it's time to check your mail. Starting up your MUA, you query your mail server using one of the standard protocols: [ IMAP] and [ POP3]. The mail server confirms your identity, then retrieves the list of messages from the mail storage area and returns them to the MUA. You can now read your mail. And the mail server that just handed you that mail was Dovecot.

As an [ IMAP] and [ POP3] server, Dovecot provides a way for mail-user agents [MUA] to access their mail. As such, Dovecot is NOT responsible for receiving mail from other servers. Dovecot presents mail already stored on the system to MUA's.

[ IMAP] and [ POP3] are the two common protocols used by MUA's to communicate with mail storage servers. [ POP3] is commonly used by users who do not have a high-speed connection to the mail server. One of [ POP3]'s basic principles is that MUA's download mail and store it locally - and then delete the mail from the server. IMAP is intended for LAN's and high-speed connections. The intent of [ IMAP] is contact the server each time a given message needs to be read (apart from MUA-specific caching). Dovecot has a number of optimizations for [ IMAP] that make it an exceptionally good performer for most IMAP applications.

With the possible, optional, exception of the deliver MDA, Dovecot is not involved with reception, delivery, and storage of mail. That function is provided by a MTA such as [ postfix]. It is the MTA that determines where and how mail is stored - Dovecot must then be configured to retrieve the mail accordingly. Obviously, a working MTA installation is a prerequisite of a working Dovecot installation.

There are two primary storage options of mail in the *NIX world - mbox and Maildir. Mbox stores multiple messages - sometimes hundreds or thousands of messages - in a single file. Maildir stores each message a separate file. While there may have been some issues with older filesystems that made mbox reasonable, for most new installations maildir offers a far more robust implementation and all-things-being-equal is the recommended choice. There are other storage options in existence, such as [ dbmail], however these are unsupported by Dovecot (at least at this time).

Again, it bears repeating, Dovecot is not responsible for mail delivery or storage. Any questions on these issues involve your MTA and MDA. Get those working first.

Dovecot configuration primarily consists of mail storage type, mail storage location, user list, and password list. Dovecot currently supports a variety of user & password sources, including *NIX passwd, shadow, PAM, LDAP, SQL, and vpopmail. It's usually best to select a source supported by all the parts of your overall mail solution, including your MTA, MDA, and Dovecot.