Jusqu’à sa version 4 incluse, BlueMind intégrait Cyrus-imap – un serveur IMAP open source reconnu qui servait de base au serveur de messagerie. Depuis la version 5 sortie en 2024, BlueMind a fait le choix de tirer un trait sur cette brique et d’intégrer les fonctionnalités messagerie IMAP/POP directement dans le core, composant coeur de BlueMind).
Pourquoi ? Comment ? On vous explique !
Pourquoi et comment utilisions-nous Cyrus IMAP?
Dans BlueMind 4 et antérieur, Cyrus IMAP est utilisé pour gérer les protocoles de messagerie standard IMAP et POP3. C’est aussi le serveur de stockage des emails, qui enregistre et gère la donnée physique des emails, pièces jointes,, les métadonnées (par exemple « lu » ou « non lu ») et le HSM (Hierarchical Storage Management), soit la hiérarchisation des données au niveau du stockage.
Le support natif d’Outlook, une exclusivité BlueMind
BlueMind, pour pouvoir proposer une alternative souveraine et répondre à la demande de sortie des serveurs de Microsoft, propose, en exclusivité le support natif d’Outlook, sans extension ou modification d’Outlook (que ce soit au niveau des IHM, des fonctionnalités ou du comportement), car c’est ce que veulent les utilisateurs : conserver Outlook tel qu’il fonctionne aujourd’hui chez les clients avec Exchange. Cela se traduit par le support des protocoles/formats natifs d’Exchange/Outlook, soit MAPI côté serveur.
MAPI fonctionne comme une base de données, par synchronisation, et les requêtes qu’effectue Outlook ne sont absolument pas compatibles avec le fonctionnement/principes d’un serveur IMAP.
Pour supporter MAPI et répondre de façon correcte et rapide à ses requêtes, qui nécessitent des lectures/écritures très rapides, très fréquentes et complexes, il était nécessaire de contourner le serveur IMAP Cyrus et donc de stocker les données des e-mails (plus exactement les méta-données et la structure des e-mails) dans une base de données. Le corps des e-mails étant gardé uniquement dans Cyrus.
Pour BlueMind 4, nous avons donc mis en place une réplication qui permet de préparer les données de messagerie pour Outlook mais également pour d’autres usages (nouveau webmail, périphériques mobiles en particulier).
Le serveur de réplication permet à Cyrus de transmettre une copie des messages au service bm-core. Celui-ci récupère les métadonnées des messages nécessaires pour Exchange Active Sync (bm-eas), Outlook (bm-mapi) et ElasticSearch et les stocke en base de données (comme le fait Exchange) et dans ElasticSearch.
Par exemple, quand vous marquez un email comme « lu » dans Outlook, BlueMind v4 doit faire un appel IMAP à Cyrus, attendre le retour de Cyrus, répliquer la donnée sur le serveur de réplication puis l’enregistrer dans PostGrés et ElasticSearch.
C’est ce qu’on appelle la boucle de réplication en BlueMind v4 et ce fonctionnement fait de Cyrus la référence pour l’ensemble des données emails pour tous les accès (Outlook, Thunderbird, mobile, webmail, autres clients IMAP,..). Si quelque chose « casse », on repart de Cyrus pour « reconstruire » à partir de ses informations.
Mais alors… pourquoi se passer de Cyrus ?
Cyrus présente plusieurs limites qui ne sont plus compatibles avec les enjeux de performance et les évolutions de fonctionnalités de messagerie et de BlueMind.
C’est le cas en matière de stockage objet, nécessaire quand on envisage une plateforme en technologies cloud. En effet, depuis BlueMind v4 il est possible d’activer un SDS (Software Defined Storage) pour la gestion de gros volumes de mails. Cyrus ne supportant pas le stockage objet, nous avons du l’adapter pour permettre ce support. Cependant pour aboutir à un support efficace du stockage objet dans Cyrus, il faudrait re-écrire complètement Cyrus pour qu’il soit pensé et conçu en tenant compte des spécificités de ce mode.
Ainsi, à partir de la version 5 et la suppression de Cyrus IMAP, l’infrastructure de BlueMind est entièrement pensée pour le stockage objet (tout en fonctionnant également sur un système de fichiers traditionnel) et ainsi permet des fonctionnalités comme la mise à jour ou un PRA/PCA à chaud.
Autres points noirs de Cyrus :
- son architecture technique (une connexion par processus) est dépassée et conduit à de faibles performances tout en étant gourmande en ressources serveur (CPU, RAM, I/O),
- L’architecture de Cyrus est « non cloud ». Les données de référence sont stockées en local (cyrus.index, cyrus.header, mailbox_NN.conversations, annotations.db, mailboxes.db,..) et le fonctionnement de l’application est basé sur la gestion de fichiers locaux.
- Le format de mail est immuable, impossible à faire évoluer pour intégrer de nouvelles informations ou enrichir les emails.
- Les partages sont très contraignants dans le cas d’infrastructures multi-backend (plusieurs serveurs Cyrus avec du routage ou du placement intelligent), et limitent fortement la collaboration.
- Un stockage non optimal en espace consommé puisque les emails sont stockés tel quels en local et en clair.
Le constat de BlueMind est que le protocole IMAP, qui accuse lui aussi son âge (très verbeux, non optimal et loud) n’est plus l’accès principal aux données. En effet, les mobiles passent essentiellement par le protocole ActiveSync, notre nouveau webmail utilise nos API mail et Outlook passe par le protocole MAPI. Finalement, le protocole IMAP est utilisé par Thunderbird et pour permettre la compatibilité avec certains clients moins diffusés.
Si le support d’IMAP reste important pour des aspects de compatibilité et de respect des standards (notamment pour un logiciel Open Source), il n’a plus à être le cœur du système et limiter ses possibilités.
BlueMind a donc fait le choix de se séparer de Cyrus pour améliorer les performances, consommer moins de mémoire et d’espace de stockage, permettre des partages globaux sans limitations de backend et préparer l’enrichissement de la messagerie.
La nouvelle architecture de BlueMind v5
BlueMind 5 permet de passer de cette situation :
A celle-ci :
Les avantages sont nombreux :
- Performances de fonctionnement nettement améliorées. Les chemins d’accès aux données sont plus courts et plus directs.
- Consommation de mémoire et stockage diminuée. Nous passons d’une connexion par processus à une architecture évènementielle (event loop) : quand un client se connecte au serveur, BlueMind identifie sa présence mais ne consomme que très peu de ressources pour maintenir la session active.
- Plus de la limitation au niveau d’un backend sur les partages, sans perte fonctionnelle.
- Une architecture pensée pour le stockage objet.
- Amélioration de la sécurité logicielle. Cyrus est écrit en langage C (langage de bas niveau souvent utilisé pour le code système) or la nouvelle architecture de BlueMind est conçue en Java (langage dit de « haut niveau » souvent utilisé pour les applications web et mobiles permettant une vérification statique et une gestion automatique de la mémoire).
- Le PRA/PCA et la mise à jour à chaud deviennent possibles.
- Amélioration globale du processus de sauvegarde.
- Services POM & IMAP respectant l’architecture logicielle globale et proposant les mêmes règles de cohérence et de vérifications dans les accès aux données
Comment bénéficier de cette nouvelle architecture ?
La version 5 de BlueMind qui a inauguré cette nouvelle architecture est disponible depuis mai 2024, nous vous invitons à nous contacter pour en savoir plus ou, si vous êtes en version 4, à vous rapprocher de votre intégrateur pour préparer la migration. Sachez que le travail d’un éditeur de logiciel ne s’arrête jamais et l’ouvrage doit constamment être remis sur le métier afin d’être adapté et suivre les évolutions technologiques ! Ecrire un serveur IMAP complet et implémenter le stockage objet sont des chantiers d’envergure menés en parallèle d’autres activités clés (UX, webmail, mobiles, maintenance sécurité, résorption de la dette technique et maintenance et évolutions du socle, enrichissement fonctionnel, collaboratif étendu, consolidation Outlook…).
BlueMind 4, BlueMind 5, BlueMind 5.1, 5.2… Pour tout comprendre sur notre politique de nommage de version, c’est par ici !
