Stalwart : un serveur mail moderne tout-en-un en Rust

Monter un serveur mail self-hosted reste un rite de passage exigeant : il faut empiler Postfix, Dovecot, OpenDKIM, SpamAssassin, OpenDMARC, Rspamd, peut-être Sieve, configurer chaque pièce, faire dialoguer le tout sans erreur. Stalwart propose une autre approche : un serveur mail tout-en-un écrit en Rust, qui parle l'ensemble des protocoles de messagerie modernes dans un seul binaire avec une seule configuration.

Cet article présente Stalwart (architecture, protocoles, sécurité), détaille un déploiement type, et le compare à la stack classique Postfix + Dovecot.

• Qu'est-ce que Stalwart
• Protocoles supportés
• Sécurité et anti-spam intégrés
• Architecture et stockage
• Déploiement Docker
• Comparaison Stalwart vs Postfix/Dovecot
• Limites et points d'attention

Stalwart est un serveur mail et collaboration open source développé par Stalwart Labs. Le code est distribué sous double licence AGPLv3 et Stalwart Enterprise License v1 (SELv1). La dernière version stable au moment de la rédaction est la v0.16.4, publiée le 5 mai 2026.

L'écriture en Rust (98.5 % du codebase) garantit la sécurité mémoire et une empreinte ressources nettement plus basse que les stacks Postfix/Dovecot/Rspamd équivalentes. Le binaire unique embarque tous les composants : transport, livraison, IMAP, JMAP, CalDAV/CardDAV, anti-spam, anti-malware, gestion d'identité.

Trois éléments distinguent Stalwart :

1. Une seule configuration TOML pour tout. Pas de jonglage entre main.cf, dovecot.conf, rspamd.local, etc.
2. Un seul binaire pour tous les protocoles. SMTP, IMAP, JMAP, POP3, CalDAV, CardDAV, WebDAV cohabitent dans le même processus.
3. Une UI web d'administration. Pour la gestion des comptes, des domaines, des règles de filtrage, sans recourir uniquement à un fichier de config.

Stalwart couvre l'éventail des protocoles de messagerie et collaboration :

JMAP mérite une mention : c'est le successeur moderne d'IMAP, plus efficient et adapté aux clients web/mobiles. Stalwart est l'un des rares serveurs open source à l'implémenter en première classe (l'autre étant Cyrus).

Stalwart embarque nativement les mécanismes d'authentification et anti-spam que la stack classique impose d'ajouter à la main.

Authentification email :

• DKIM (signature et vérification, rotation automatique des clés).
• SPF.
• DMARC avec rapports agrégés.
• ARC (Authenticated Received Chain).
• DANE (DNS-based Authentication of Named Entities).
• MTA-STS et SMTP TLS Reporting.

Anti-spam et anti-malware :

• Filtres bayésiens entraînables.
• Greylisting, reputation lists, RBL.
• Intégration ClamAV pour l'antivirus.
• Module Sieve pour les filtres utilisateurs.

Identité et chiffrement :

• OpenID Connect et OAuth 2.0 pour l'authentification.
• TOTP (2FA).
• S/MIME et OpenPGP pour le chiffrement at-rest des messages.
• TLS automatique via ACME (Let's Encrypt ou autre).

Backends d'identité : LDAP, Keycloak, Authentik, interne.

Tout cela dans le même binaire, configuré dans le même fichier.

Stalwart sépare logiquement le stockage en quatre catégories :

• Data : index principal des messages et métadonnées.
• Blob : stockage des corps de messages.
• FTS (Full-Text Search) : index de recherche.
• Lookup : caches, listes, données de configuration.

Chaque catégorie peut pointer vers un backend distinct :

• RocksDB : embarqué, par défaut, pour des déploiements single-node.
• PostgreSQL : pour des bases relationnelles.
• MySQL / MariaDB : alternative SQL.
• SQLite : pour les très petits déploiements.
• FoundationDB : pour la haute disponibilité distribuée (cluster).
• S3 : pour les blobs (offload des corps de message vers un object store).
• Redis : pour le cache de lookup.

Cette flexibilité permet de démarrer simple (RocksDB tout-en-un) et de migrer progressivement vers un backend distribué quand le volume l'impose, sans changer d'application.

Le déploiement minimal docker-compose :

services:
  mail:
    image: stalwartlabs/stalwart:v0.16.4
    container_name: mail
    restart: unless-stopped
    network_mode: host
    volumes:
      - ./data:/opt/stalwart-mail
    environment:
      RUST_LOG: info

Au premier démarrage, Stalwart génère une configuration interactive ou par variables d'environnement. L'installation guide l'administrateur sur :

• Le domaine principal et les domaines additionnels.
• Le mot de passe administrateur.
• Le backend de stockage choisi.
• Les certificats TLS (auto via ACME ou manuels).

Une fois lancé, l'UI d'administration est accessible sur https://mail.example.com:8080. Les ports standard sont exposés :

• 25/tcp SMTP MX (réception).
• 465/tcp SMTPS (soumission TLS implicite).
• 587/tcp SMTP submission (STARTTLS).
• 143/tcp IMAP STARTTLS / 993/tcp IMAPS.
• 110/tcp POP3 STARTTLS / 995/tcp POP3S.
• 8080/tcp HTTP/JMAP/admin.

Les enregistrements DNS à configurer (MX, SPF, DKIM, DMARC) sont générés et affichés par l'UI à la création du domaine.

Pour un nouveau déploiement, Stalwart offre un raccourci spectaculaire : un binaire au lieu d'une stack à six composants, une configuration au lieu de cinq, un suivi de version simple. Pour une infrastructure mail établie sur Postfix/Dovecot avec des intégrations spécifiques (filtres custom, antispam fine-tunés, scripts d'opération), la migration n'est pas anodine et l'écosystème mature de la stack classique reste un argument fort.

Maturité encore en construction. La 1.0 n'est pas encore atteinte. Les retours en production existent (notamment dans les communautés self-hosting et plusieurs MSP) mais l'historique est plus court que Postfix. Pour un cas d'usage critique avec SLA serré, c'est à intégrer dans la décision.

Licence SELv1 pour certaines fonctionnalités enterprise. Dans les futures versions, certaines fonctionnalités avancées (clustering, SSO complet, support commercial) sont sous SELv1, pas AGPLv3. Pour la majorité des déploiements self-hosted, l'édition AGPL suffit.

Écosystème de plugins limité. Pas de plugins SpamAssassin custom, pas de scripts Sieve étendus avec des extensions exotiques, pas d'intégrations natives avec tous les outils périphériques classiques.

Documentation en croissance. Solide mais moins exhaustive que les ressources accumulées sur Postfix/Dovecot. Pour des cas tordus, on retombe parfois sur le code ou les issues GitHub.

Pas de migration automatique depuis Postfix/Dovecot. L'import de mailboxes existantes passe par IMAP migration tools (imapsync, offlineimap). Reste manuel.

PME ou MSP qui démarre une plateforme mail

Pour une équipe sans expert dédié à la stack mail, Stalwart est l'option qui demande le moins d'investissement initial. Une journée pour comprendre la configuration, une journée pour mettre en production, et le système est opérationnel.

Self-hosting personnel ou associatif

Pour un homelab ou une association qui veut héberger ses mails sans monter une stack complexe, Stalwart est imbattable en simplicité. Les ressources requises sont minimales (1 vCPU, 1 Go RAM suffit pour quelques dizaines de comptes).

Plateforme JMAP-first

Pour des organisations qui veulent miser sur JMAP (clients web modernes, intégrations API) sans s'aventurer sur Cyrus ou des stacks plus complexes, Stalwart est aujourd'hui la voie la plus simple en open source.

Couplage avec Authentik / Keycloak

L'authentification OIDC native permet d'intégrer Stalwart directement dans une infrastructure SSO existante, sans bricoler avec des bridges LDAP comme c'est souvent le cas avec Postfix/Dovecot.

• Postfix et Dovecot : la stack mail classique
• Mail souverain : enjeux d'hébergement
• Authentik : IdP moderne
• Keycloak SSO et OAuth2
• TLS et bonnes pratiques 2026

• Stalwart (dépôt GitHub) code, releases, version v0.16.4
• Site officiel stalw.art, documentation, getting started
• Documentation Stalwart, configuration, déploiement
• Standards implémentés, RFC supportés

Stalwart n'a pas la maturité de Postfix, mais il propose ce qu'aucune stack mail open source n'a réussi à simplifier auparavant : un binaire unique, une configuration cohérente, tous les protocoles modernes y compris JMAP et CalDAV/CardDAV, le tout en Rust avec une empreinte minime. Pour un nouveau déploiement, c'est aujourd'hui l'option la plus rationnelle si l'équipe est à l'aise avec un projet jeune.