cyrus-imapd: a mail server designed for sealed machines and many users

The sealed server assumption drives the whole design

Cyrus is an IMAP server, where IMAP is a protocol for accessing mail. The README is explicit about how it differs from other implementations: it is generally intended to be run on sealed servers, where normal users are not permitted to log in, and the mailbox database is stored in parts of the filesystem that are private to the Cyrus IMAP system. All user access to content goes through JMAP, IMAP, POP3, CalDAV, CardDAV and WebDAV protocols.

That single sentence explains most of the design decisions. A server where nobody can log in does not need the mailboxes to be readable as ordinary files, so it can store them in a format optimised for concurrent access rather than for human inspection. A server that serves many accounts can afford a per-user filesystem structure and gains efficiency, scalability and administrability from it, which the README lists as the advantages of the private mailbox database design.

The features that fall out of this are the ones a hosting provider wants. Multiple concurrent read and write connections to the same mailbox are permitted, the server supports access control lists on mailboxes, and it supports storage quotas on mailbox hierarchies. Those three together are the difference between a mail server for one person and a mail server for a department.

The scope is broader than mail. The project description calls Cyrus an email, contacts and calendar server, and the protocol list includes CalDAV for calendars, CardDAV for contacts and WebDAV for general file access, alongside JMAP as a modern alternative to IMAP for some clients.

The audience is therefore institutional: hosting providers, universities, companies that run mail for a workforce, and anyone who wants a mail store that can be delegated to a protocol layer rather than to filesystem permissions.

Three ways to get it, and only one of them is recommended

The README lays out three flavours of Cyrus, and the difference between them is the first decision an adopter makes.

The first is the release source tarballs from the project's releases page, and this is the recommended route for most users. The README notes these are packaged by the Cyrus team, that the documentation is pre-built for you in doc/html, and that they are definitively tagged to a particular release version with up to date release notes.

The second is raw source from the git repository, for when you need a version containing an unreleased patch, fix or feature. The README warns that these bundles require a lot more dependencies to build than a packaged tarball, and that the git repository does not have a pre-built configure script.

The third is operating system distribution packages. The README lists the distributions that ship Cyrus packages, including Fedora, Red Hat Enterprise Linux, CentOS, Scientific Linux, Debian, Ubuntu, openSUSE, Gentoo, Mageia and ClearOS. It then says something that should make you pause: the Cyrus team does not maintain these packages, so some distributions are out of date, and if you run into problems with a packaged distribution you should contact the source of the distribution.

That last point is a real operational risk rather than a footnote. A distribution package gives you a fast install and a package manager, and in exchange you are at the mercy of when that distribution last rebuilt the package against a newer upstream with a newer dependency. The upstream recommendation to use the tarball exists precisely because of this.

The three latest release tags visible in the project, all published on 2026-09-09, are for three different stable series at once, 3.8.8, 3.10.4 and 3.12.4, which tells you the project maintains parallel branches rather than a single line.

Building from a tarball: configure, make, make install

For a packaged release, the basic installation instructions are three commands:

    $ ./configure
    $ make
    $ sudo make install

The README asks you to read the documentation, notes that the latest version is online at the project site, and says the version current for your distribution can be found in the doc subdirectory. The detailed instructions are in the installation page under the from-tarball section of the packaged documentation.

This is a conventional autotools build of a large C project. The presence of configure.ac and Makefile.am at the repository root, along with a libcyrus.pc.in for pkg-config, tells you what you are dealing with: several libraries are built and installed alongside the server, with pkg-config files so that other software can find them.

For the git tree the sequence is longer, because the configure script has to be generated first:

    $ autoreconf -i
    $ ./configure
    $ make
    $ sudo make install

GNU Make is required, and the README warns that if you are not on Linux it might be called gmake. That is the sort of detail that stops a build halfway on a macOS or BSD machine.

The README also points to the upgrade documentation at doc/html/imap/download/upgrade.html for anyone coming from an existing installation, which is the right thing to read before touching a running mail server.

The cyruslibs dependency build is the real cost of using git

For version 3.0 or later, the README asks you to build the main dependencies from source before building Cyrus, and the dependencies live in a separate repository, cyruslibs.

The build script is run from the cyruslibs tree:

    $ ./build.sh

By default everything is installed under /usr/local/cyruslibs, and then your environment has to be pointed at it before you compile Cyrus. The README gives the three exports explicitly, one for the cyruslibs path, one for pkg-config and one for the linker flags:

    $ export CYRUSLIBS=/usr/local/cyruslibs
    $ export PKG_CONFIG_PATH="$CYRUSLIBS/lib/pkgconfig:$PKG_CONFIG_PATH"
    $ export LDFLAGS="-Wl,-rpath,$CYRUSLIBS/lib -Wl,-rpath,$CYRUSLIBS/lib/x86_64-linux-gnu"

The rpath entries in the linker flags are what let the installed binary find its libraries without you setting LD_LIBRARY_PATH at runtime, which is the difference between a working install and one that breaks after a reboot.

Xapian, the search engine, has its own wrinkle. The README strongly recommends the custom Xapian fork in cyruslibs, and if that is not an option in your environment you should fetch the latest stable upstream Xapian release instead. The cost of going upstream is stated plainly: Cyrus will omit custom features such as word boundary analysis for Chinese, Japanese and Korean.

That is a concrete example of the general rule here. The packaged tarball gives you these dependencies pre-solved, and the git route hands you the whole problem. For an evaluation of Cyrus itself, the tarball is the sane starting point.

Versioning: 3.13 in development, 3.12 as the stable series

The README states that this is the developer version 3.13, that it is under active development, and that it is not considered stable. The current stable series is 3.12, and the README says that release still receives security updates and some non-security bug fixes.

That is the normal arrangement for a server project with a security advisory obligation, and it is worth internalising for planning. Running the developer version means running code that upstream does not consider stable, on a system holding other people's mail.

The branch naming is explicit. The latest development code is on the branch called master, and the latest code destined for the stable release is on the branch named cyrus-imapd-$major.$minor, so the current stable release is called cyrus-imapd-3.12. The repository root shows the release branches exist in parallel, with the build badge for the stable 3.12 branch tracked separately from the master build.

The last push to the repository was on 2026-10-21 and the repository is not archived, so both the development line and the stable line are being worked on.

The licence deserves a note. The README says to see the COPYING file in the distribution, and the repository root carries a COPYING file. The project metadata does not classify the licence as one of the standard identifiers, so anyone with a compliance obligation should read that file rather than assume a permissive grant, because a mail server's licence terms are exactly the kind of thing that gets reviewed.

Where cyrus-imapd is the wrong tool

The first wrong-tool case is a single user or a small homelab. Cyrus is built for a sealed server with a private mailbox database, shared by many accounts, with per-mailbox ACLs and quotas. For one person on one machine, that machinery is pure overhead, and a mail server that stores messages in a format you can read with an ordinary mail client is simpler in every way that matters.

The second is an environment where users must log in to the host. The private database design assumes they do not, and the README says so. If your users need shell access, or your monitoring expects to find mailboxes in a user's home directory, the design works against you rather than for you.

The third is a team that wants a managed service. The README says Cyrus packages ship with every major distribution but are not maintained by the Cyrus team, and it says the current stable series receives security updates and some non-security bug fixes. That is an upstream project doing maintenance on a schedule, and it is a different proposition from a commercial mail platform with a support contract. For an organisation that needs someone to call, this is not it.

The fourth is a requirement for a modern webmail-first or JMAP-first deployment where IMAP compatibility is secondary. The protocol list includes JMAP, CalDAV, CardDAV and WebDAV, so the capability is there, but the server, the administration tooling and the documentation are built around IMAP conventions and Cyrus-specific configuration. Adopting it means adopting that model, not just adding a protocol to an existing stack.

The fifth is a team unwilling to read the documentation. The README repeatedly redirects to doc/html pages, including a specific installation page, an upgrade page and a separate developer documentation tree under docsrc/developer. The build is a large C project with a dependency chain, and the README is candid that the git route needs a lot more dependencies than a tarball. The documentation is thorough; reading it is a prerequisite, not a nicety.

Editorial conclusion

cyrus-imapd fits an organisation hosting mail, calendars and contacts for many accounts on a server that ordinary users never log into, and that wants per-mailbox access control and quotas. It is the wrong choice for a single-user setup, for a host that expects people to log in and read mailboxes as files, and for anyone who wants a packaged install without reading the documentation. Before committing, read the installation page in doc/html, decide whether you are building the 3.13 developer version or the 3.12 stable series, and plan for the cyruslibs dependency build, since the git tree does not ship a pre-built configure script.

Frequently asked questions

Official sources

1. cyrusimap/cyrus-imapd on GitHub
2. Issues
3. Project website
4. README
5. Releases