Please see Chapter 11, “Server Commands” for further details on the usage of the following servers.

This daemon process provides authentication services to the M-Store imapd and pop3d servers. This server fulfills two roles: to isolate all code requiring superuser privileges into a single process, and to provide proxy authentication services to clients that do not understand SASL-based authentication.

msadm_tclsh is a powerful and flexible command line interface that provides many tools needed for mailstore administration. It is built with the Tcl/Tk shell scripting language. See “IM-Store Administration Command Interpreter (msadm_tclsh)” in Chapter 12 for more information.

The following is the M-Store database layout:

The M-Store mailbox directory is laid out as follows (additional details can be found in Chapter 9, “File and Directory Layouts”.).

Partitions, or mailstores, are directories on a hard disk that contain mailboxes and stored mail messages. Upon creation, mailboxes are assigned a specific partition according to rules defined in the configuration file.

M-Store fully supports the use of multiple domains in the message store. Domains are used to group sets of users in a logical or logistic manner. For example, a web hosting company hosts separate companies Foo and Bar, using the domains foo.com and bar.com to separate email addresses belonging to the companies. Or a company may wish to distinguish between offices in different cities and would then use the sub-domains city1.company.com and city2.company.com to partition the employee email addresses. Domains can be administered through the web-based administration interface or through msadm_tclsh (See “IM-Store Administration Command Interpreter (msadm_tclsh)” in Chapter 12.).

The mailbox hierarchy refers to the collection of visible folders for a particular user. For example, Joe's mailbox hierarchy may include:

To create a new mailbox called foobar the client just needs to send:

0 create foobar

---

Note: This command is only for IMAP.

---

This has improved the administration interface because users can now see the mailbox hierarchy in which they are working.

Quotas are used to restrict the size of mailboxes and effect all sub-mailboxes. The mailbox that has a quota directly applied to it is called a 'quotaroot'. For example, we apply a quota of 2000 Kbytes to the quota root user/joe. Now user/joe and all of his sub-mailboxes can contain at most 2 Mbytes of mail. After filling the quota, no more mail can be delivered into the quotaroot or its sub-mailboxes. Quotas can also be applied to domains to restrict disk usage.

Mailbox access control refers to a set of controls used to restrict the types of access to the mailbox of individual users. The controls include, but are not restricted to, read, write, create, delete, and administration rights. These rights are assigned on a per user basis. A user may be assigned positive or negative rights to a particular mailbox to allow or disallow a particular type of access. M-Store uses access control lists or ACLs to restrict access to mailboxes. ACLs may be modified through the IMAP protocol (RFC2086) or through the included Web-based administration interface (See Chapter 6, “ Site Administration”.)

M-Store separates the concepts of users, authentication identifiers (the string used to login), and mailboxes for architectural reasons. A mailbox and authentication identifier cannot exist without a user, but a user can exist without a mailbox or without an authentication identifier. Hence, to create a typical user, the following multiple steps are required:

Note that even though steps 2 and 3 are optional, all three steps are the typical procedure. Steps 1 and 2 are usually combined in the administration tools to create both a user and inbox for incoming mail. Step 3 allows the user to authenticate to the IMAP or POP server if M-Store will not be holding the authentication accounts. For example, this is used if your site uses an external authentication mechanism like kerberos4 or the /etc/passwd file.