Contexte et objectifs

Stalwart atteint la version 1.0 après cinq ans de développement continu depuis le premier commit du 3 octobre 2021. Le projet, né d’une bibliothèque de parsing Rust nommée mail-parser, s’est transformé en serveur complet supportant JMAP, IMAP, POP3, SMTP, CalDAV, CardDAV et WebDAV. La version stable poursuit deux objectifs mesurables : maximiser la vitesse d’exécution de chaque composant et garantir la stabilité du schéma de base de données afin d’éliminer les migrations complexes lors des mises à jour.

Optimisations du parsing et du décodage

Le cœur du gain de performance repose sur l’utilisation conjointe de SIMD (SSE2, SSSE3, AVX2, NEON) et de SWAR. Les kernels SIMD de mail-parser 1.0 localisent les frontières MIME et les champs d’en‑tête en comparant 16 ou 32 octets par instruction, tandis que SWAR exploite des opérations arithmétiques sur des mots de 64 bits pour tester huit octets simultanément. Ces deux approches sont sélectionnées dynamiquement au démarrage et validées par fuzzing contre une implémentation scalaire de référence. Les mesures indiquent que le nouveau parser est 3 fois plus rapide que le crate Rust mailparse, 9 fois plus rapide que le parser natif de Dovecot, et entre 15 et 31 fois plus rapide que libEtPan!, VMime et GMime sur un parse complet.

Le module encodify ajoute des kernels SIMD pour Base64, Base32 et quoted‑printable. Sur un serveur AMD EPYC, le décodage d’une pièce jointe Base64 est 22 fois plus rapide que le crate Rust standard, et le décodage quoted‑printable est 9 fois plus rapide que la bibliothèque quoted_printable. Tous les encodages courants, y compris la conversion IMAP UTF‑7, sont désormais traités par ces kernels.

Gestion du stockage et du cache

Pour réduire les latences liées aux accès disque, les identifiants sont créés dans la même transaction d’écriture que leur utilisation, supprimant ainsi un aller‑retour réseau par livraison de message. Les mises à jour de type read‑modify‑write sont fusionnées directement dans le backend, et chaque objet stocké est compressé avec zstd à l’aide de dictionnaires entraînés sur les données d’e‑mail, de calendrier et de contacts.

Chaque moteur de stockage a reçu un réglage dédié : RocksDB utilise des column families spécialisées, des filtres Bloom pour les recherches ponctuelles et jusqu’à 256 slots pour les compteurs chauds afin d’éviter les conflits d’écriture ; PostgreSQL et MySQL exploitent des statements préparés en cache et limitent les allers‑retours par écriture ; FoundationDB précharge en parallèle les lectures anticipées ; SQLite ajuste la taille de page, le cache et le mode WAL pour un profil de charge de messagerie. Au-dessus, un sous‑système de cache conserve les index de messages dans une forme compacte en mémoire, avec une tier supplémentaire pour les comptes volumineux et la possibilité de basculer les instantanés vers disque local, Redis ou un blob store.

Benchmarks et laboratoire de test

Le laboratoire de validation s’appuie sur Microsoft Azure, déployé dans plus de 30 régions, avec jusqu’à 18 laboratoires simultanés mobilisant plusieurs centaines de vCPU. Le catalogue comprend 35 types de tests répartis sur plus de 550 cellules individuelles, couvrant l’ensemble des protocoles (IMAP, JMAP, SMTP, CalDAV, CardDAV, WebDAV). Un exemple de performance : sur une boîte de 250 000 messages, la recherche plein texte complète s’exécute en moins de 4 ms. Ces mesures confirment que les optimisations de parsing, de décodage, de stockage et de cache se traduisent par des temps de réponse compatibles avec les exigences des services de messagerie à grande échelle.