>> Cyrus Admin
Status | Content

Status
This document is a consolidation of information, with draft recommendations.

Content
Deploying Cyrus for mail will require several changes to procedure and software to integrate successfully with the local environment. Several areas of concern are raised here.

Authentication and Encryption

Cyrus supports plaintext authentication, optionally over SSL, and Kerberos based authentication. For simplicity in software support and configuration, only plaintext over SSL should be supported. Plaintext over non-SSL should not be supported for obvious reasons. Declining to offer Kerberos based authentication simplifies the testing and support scenarios. All modern email clients support plaintext over SSL.

Users

Cyrus does not permit usernames containing dots. The only name meeting this restriction appears to be the legacy account u.daemon, so this should not be a concern.

Of greater concern is that Cyrus does not support renaming users. When an address is changed, a postmaster or other administrator will be required to move the contents of the user's mail account to the new username before the old name is deleted. Appropriate procedures will need to be developed for this operation.

Permissions and Quotas

Cyrus supports a complicated set of permissions over each mailbox. For simplicity, the initial deployment should only support standard user-only permissions on each user's mailboxes, with support for shared mailboxes and other more complicated permissions added later.

Quotas are attached to points in the heirarchy, and are then referred to as quota roots. It is possible for different portions of a user's mail space to have different quotas. However, again for simplicity, the initial deployment should only support one quota root per person, established at the time of account creation (and subsequently subject to change if required).

Note that Cyrus will always permit the delivery of one message to a user's inbox regardless of the size of the message even if that message would send the user above quota. Once over quota, however, no new messages may be sent. Under the proposed scenario, a user's delivery quota would be the same quota as the user's mail store quota.

Account Administration

All operations are performed via the cyradm command. Creating a mailbox user.joebob enables the user joebob to receive mail, using user.joebob as the INBOX. Deleting this mailbox will delete all of joebob's mailboxes and remove joebob from the system.

It will be necessary to modify the existing ID system to issue commands to create and delete this mailbox when a user who is eligible to receive mail is created or deleted. Additionally, it will be necessary to modify the existing ID system to send an appropriate command for quota changes. Most other commands, at least initially, will be performed by postmasters or other administrators. Note also that, for the first set of users, the appropriate commands can be issued manually and/or via a script, so that no ID system modifications would be required.

It may be necessary to track which servers each user is attached to. Whether this is placed in the ID system itself or in an alternate location may depend on what system is chosen to handle IMAP proxying.

Disk Layout

Cyrus can use multiple partitions on a single host for storage of mail. However, for initial deployment it would be preferable to keep a single partition, ideally one that can be enlarged with the simple addition of more disks (optionally followed by commands to the RAID controller). More complicated layouts can be considered later.

Additionally, the initial deployment should likely consist of only one server, with additional hardware ready as needs and performance are assessed.