Our fixes accepted by Cyrus IMAP

Our mail, calendars and address books run on Cyrus IMAP, a free mail, calendar and contacts server. When we find a defect in it, we reproduce it, fix it, then offer the fix to the project. Three of these proposals were merged between August and September 2026.

We thank the Cyrus team for their reviews and for the welcome given to these contributions.

Stability: a CalDAV server crash

A free/busy request no longer brings httpd down. When a client asked for the free time of several people at once (a free/busy POST to the scheduling Outbox), and one of them published office hours (CALDAV:calendar-availability), the server process died with a segmentation fault. The client saw the connection close mid-response; behind a reverse proxy, it surfaced as a 502.

The cause: the function that folds in office hours used the iCalendar component without checking that it had actually been parsed. An unparsable value, or a component with nothing recognisable inside, left a null pointer. The fix refuses what cannot be used, frees the matching memory, and the client gets a free/busy answer without those hours instead of losing the connection. A Cassandane test, Cyrus’s test suite, comes with the fix.

The defect was misleading: asking about the same people one at a time answered correctly every time, so it looked data-dependent.

cyrus-imapd#6262

Reliability: HTTP/2 responses cut short

A response larger than 64 KB no longer stalls over HTTP/2. A large CalDAV or CardDAV response (a REPORT on a busy calendar, for example) stopped around 65,535 bytes, and the stream was never closed: the client waited until its own timeout.

The server submitted a new data source to the nghttp2 library for every chunk of the response, while nghttp2 accepts only one at a time per stream. As long as the flow-control window stayed open, each chunk left at once and nothing showed. As soon as it closed, every later submission was refused, including the last one, which closes the stream. It only appeared with recent clients, which really let the window close; proxies speaking HTTP/1.1 to the server hid it entirely.

The fix keeps a single source per stream, fed from a buffer. Measured afterwards:

The known limitation is stated in the PR rather than hidden: against a very slow client, the buffer can hold the whole response. That is inherent, since you cannot discard bytes you have not sent yet, and it is still better than losing them.

cyrus-imapd#6347

Discretion: the version number in calendars

serverinfo: off now also hides the version in iCalendar objects. The serverinfo setting decides what the server says about itself. Cyrus already honoured it everywhere else over HTTP, but the PRODID field stamped on every iCalendar object still carried the exact server version, distribution packaging included.

That field travels far: in every event exported or shared, including outside the organisation, and in answers from the /freebusy namespace, which can be served without authentication. With the fix, the product is still named, as RFC 5545 asks, and only the version goes:

PRODID:-//CyrusIMAP.org/Cyrus//EN

serverinfo: on remains the default, and nothing changes for anyone who has not changed it.

cyrus-imapd#6279

Where these fixes stand

All three are on Cyrus’s main branch. The latest releases (3.12.4, 3.10.4 and 3.8.8, of 9 September 2026) are built from their own maintenance branches and do not contain them. They will ship with a future release.

Why give back upstream

A fix kept to yourself has to be reapplied at every server update, and only protects your own users. Given back, it is reviewed by the people who know the code best and protects every installation. Each of these proposals describes the defect, how to reproduce it and the measurement that proves it is closed.

Running Cyrus mail and looking for a team that knows its code? See our services or let’s talk. And follow us on GitHub.