Cyrus Server Configuration
There are essentially two ways we could set up a server:
- one standalone server (called
altadmmail for the discussion below), or
- build a Cyrus cluster (called
mailservices for the discussion below), with initially only one server in it.
This page discusses those options, with the viewpoint that this system is initially to be used to handle the overflow from
, but it gives us the opportunity to phase in some of the tools we will need to use sometime in the near future to handle increasing e-mail loads.
In this case we could call the server say
, and tell all users to forward their incoming mail there, and they read the mail using IMAP by pointing their mail client at
. To keep things consistent, we should tell users also to route outgoing mail (SMTP) through
, although that is not strictly necessary, as mail clients keep incoming and outgoing functions separate.
- We are free to install any IMAP system on the server. We could even use UWashington IMAP, which we all know so well. Or Dovecot, or Courier Maildir, or whatever we're most comfortable with. These are all available under RHEL.
- The users will simply need to change any reference to
altadmmail in their e-mail client setup.
- Maintenance on a single machine would be simpler, since the location of all problems would be fairly easy to identify.
- We can delay dealing with issues of scalability until we are more comfortable with the system.
- We will need to deal with issues of scalability really soon, and by delaying even further we'd miss a good chance to get a start on these issues. We also risk having to rush things if it comes to a crunch.
- The system is not scalable (by adding more servers) without introducing more names, such as
altadmmail3, without either:
- additional server names becoming visible, which will cause confusion (is
altadmmail2?) Some of this could be mitigated by using
firstname.lastname@example.org e-mail addresses, and hiding the details with forwarding from there; or
- using an IMAP `proxy' server, which would handle the details of locating the server that stores and individual's IMAP folders, but this only takes care of IMAP: we'd need to maintain a list of aliases on the SMTP servers to direct incoming mail to the correct place, unless we can automate this somehow; or
- we decide to use the built-in facilities of Cyrus to hide the addition of a second and subsequent servers by now calling a new cluster
altadmmail, and say rename the first server to
altadmmail1, and call the new one
Here we would configure the load-balancing and redundancy options of Cyrus, but initially with all functions being directed at the single host, say
. However, to maintain future flexibility and give us the option to add capacity completely transparently to people using the system, we would point people to the cluster
, not an individual machine.
- The actual mail server
altadmmail is completely firewalled off from normal users -- only the sysadmins need access, and that can be provided by
- The users will simply need to change any reference to
mailservices in their e-mail client setup.
- We have had a load-balanced, redundant Linux cluster running for a number of years now, and its job is primarily to deal with e-mail. It would not be a stretch to consider dealing with e-mail storage and forwarding part of that function, especially as that cluster can be used to provide all the `front end' functions for a Cyrus cluster. All we need to add are `back end' mail storage machines, as needed, and we can start with just one.
- The actual location of a user's mailbox is unknown to them (they don't know the physical machine name, only the cluster name), which means we can add servers and move their mailbox to a different server without even telling them. Or if a mailbox server fails, users' mailboxes could be restored elsewhere and bought back online without the users needing to change any configuration.
- We have had a lightly used test server running on and off in various configurations for over a year. A more stable and carefully configured system is now available, so this is an ideal time to put some more real users on it, and gain some valuable experience before we are perhaps forced to provision a large system in a hurry.
- We have a working clustered configuration already.
- Only Cyrus provides the sort of scalability and flexibility we would need to handle a large number of users (thousands) transparently, and without extra software such as third-party IMAP proxies, so we're pretty much forced onto Cyrus in this case.
- The system is initially more complex than an single server, but not frightfully so.
Unless we decided to use something like UWashington's IMAP server, the system administrators would need to learn how the new software works. However, this would be true with either the single server or clustered environment, so this is not listed as an advantage of disadvantage in any section above. Similarly, either option allows us to introduce a more modern mailbox format than the one we are currently using, so this is not discussed.
Redhat Enterprise Linux supports all the common e-mail system options, including everything we'd need to run a cluster, right out of the box, so there is no advantage or disadvantage to either way from the software point of view. We'd just need to configure the various services.
We can completely separate the issues of incoming and outgoing mail, by telling all users, regardless of who they are, to use the SMTP server named
. This points at an existing service on the mail cluster that has been operational for years. Then we are left dealing only with what to do about incoming mail (IMAP).
If we decide to use the cluster approach, we should make some effort not to get the name of the cluster into people's address books, onto their business cards, and so forth. One big step in that direction would be to hide the cluster's name in UWLDAP's mail forwarding results, so any user whose email is forwarded to
would have their e-mail address actually displayed as
. This can be done if the entry point to the cluster for incoming mail is also the mail MX target for
. This gives us further flexibility in moving users onto different servers without visible changes (perhaps in the background we'd shunt some mail to an Exchange server in the future).
The physical specifications for a machine, be it a standalone server, or the first server in a cluster, would be pretty much identical, so that is not discussed above.
If point 3 under the single server disadvantages listed above is admitted to be a possibility, then by not creating a cluster now we're merely delaying the inevitable.