Nos correctifs acceptés par Cyrus IMAP

Notre messagerie, nos agendas et nos carnets d’adresses reposent sur Cyrus IMAP, un serveur libre de courrier, d’agendas et de contacts. Quand nous y trouvons un défaut, nous le reproduisons, nous le corrigeons, puis nous proposons le correctif au projet. Trois de ces propositions ont été fusionnées entre août et septembre 2026.

Nous remercions l’équipe de Cyrus pour ses relectures et pour l’accueil fait à ces contributions.

Stabilité : un plantage du serveur CalDAV

Une demande de disponibilité ne fait plus tomber httpd. Quand un client demande les créneaux libres de plusieurs personnes à la fois (un POST de free/busy vers la boîte d’envoi d’ordonnancement), et que l’une d’elles publie ses heures de présence (CALDAV:calendar-availability), le processus serveur s’arrêtait sur une erreur de segmentation. Le client voyait la connexion se fermer au milieu de la réponse ; derrière un mandataire inverse, cela devenait une erreur 502.

La cause : la fonction qui intègre les heures de présence utilisait le composant iCalendar sans vérifier qu’il avait bien été lu. Une valeur illisible, ou un composant sans contenu reconnu, donnait un pointeur nul. Le correctif refuse ce qui est inutilisable, libère la mémoire correspondante, et le client reçoit une réponse de disponibilité sans ces heures au lieu de perdre la connexion. Un test Cassandane, la suite de tests de Cyrus, accompagne le correctif.

Le défaut était trompeur : interroger les mêmes personnes une à une répondait correctement à chaque fois, si bien qu’il semblait dépendre des données.

cyrus-imapd#6262

Fiabilité : des réponses HTTP/2 coupées en chemin

Une réponse de plus de 64 Ko ne reste plus bloquée en HTTP/2. Une grosse réponse CalDAV ou CardDAV (un REPORT sur un agenda chargé, par exemple) s’arrêtait vers 65 535 octets, et le flux n’était jamais clos : le client attendait jusqu’à son propre délai d’expiration.

Le serveur soumettait une nouvelle source de données à la bibliothèque nghttp2 pour chaque morceau de la réponse, alors que nghttp2 n’en accepte qu’une à la fois par flux. Tant que la fenêtre de contrôle de flux restait ouverte, chaque morceau partait aussitôt et rien ne se voyait. Dès qu’elle se refermait, toutes les soumissions suivantes étaient refusées, y compris la dernière, celle qui clôt le flux. Le défaut n’apparaissait qu’avec les clients récents, qui laissent réellement la fenêtre se fermer ; les mandataires qui parlent HTTP/1.1 au serveur le masquaient entièrement.

Le correctif ne garde qu’une source par flux, alimentée par un tampon. Mesuré après coup :

La limite connue est dite dans la PR plutôt que cachée : face à un client très lent, le tampon peut contenir toute la réponse. C’est inhérent, puisqu’on ne peut pas jeter des octets qu’on n’a pas encore envoyés, et c’est toujours mieux que de les perdre.

cyrus-imapd#6347

Discrétion : le numéro de version des agendas

serverinfo: off masque aussi la version dans les objets iCalendar. Le réglage serverinfo décide de ce que le serveur dit de lui-même. Partout ailleurs sur HTTP, Cyrus le respectait déjà, mais le champ PRODID posé sur chaque objet iCalendar portait toujours la version exacte du serveur, paquet de distribution compris.

Ce champ voyage loin : dans chaque événement exporté ou partagé, y compris hors de l’organisation, et dans les réponses de l’espace /freebusy, qui peut être servi sans authentification. Avec le correctif, le produit reste nommé, comme le demande la RFC 5545, et seule la version disparaît :

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

serverinfo: on reste la valeur par défaut, et rien ne change pour qui ne l’a pas modifié.

cyrus-imapd#6279

Où en sont ces correctifs

Les trois sont dans la branche principale de Cyrus. Les dernières versions publiées (3.12.4, 3.10.4 et 3.8.8, du 9 septembre 2026) sont bâties sur leurs propres branches de maintenance et ne les contiennent pas. Elles seront livrées avec une prochaine version.

Pourquoi rendre à l’amont

Un correctif gardé pour soi doit être réappliqué à chaque mise à jour du serveur, et ne protège que ses propres utilisateurs. Rendu au projet, il est relu par ceux qui connaissent le code le mieux et protège toutes les installations. Chacune de ces propositions décrit le défaut, la façon de le reproduire et la mesure qui prouve qu’il est fermé.

Vous exploitez une messagerie Cyrus et cherchez une équipe qui connaît son code ? Découvrez nos services ou parlons-en. Et suivez-nous sur GitHub.