Installer Stalwart : serveur mail tout-en-un sur VPS

Ce que Stalwart regroupe dans un seul binaire

Stalwart est un serveur de messagerie que vous exécutez sur un seul VPS sous la forme d’un binaire Rust. Le même processus répond à SMTP, IMAP, POP3, JMAP, CalDAV, CardDAV et WebDAV. Il intègre aussi son propre filtre antispam, son propre stockage des messages et son propre client ACME. Une stack classique répartit ces fonctions entre Postfix, Dovecot, Rspamd, une base de données pour les comptes et un outil distinct pour les certificats. Stalwart remplace l’ensemble par une seule unité de service et un seul fichier de configuration dans /etc/stalwart/config.json.

Chaque valeur, nom de paramètre et commande ci-dessous provient de la documentation, des pages de versions et du script d’installation de Stalwart. Ces informations ont été consultées le 28 août 2026 avec la version v0.16.19 (publiée le 24 août 2026), puis vérifiées le 12 octobre 2026, lorsque la version la plus récente était v0.16.26 (publiée le 11 octobre 2026). Vous devez exécuter ces commandes sur votre propre serveur. Chaque commande est suivie du contrôle qui permet de vérifier son bon fonctionnement.

Stalwart est distribué sous deux licences : la GNU Affero General Public License v3.0 (AGPL-3.0) et la Stalwart Enterprise License v2. Certaines fonctions sont réservées à l’édition Enterprise. La liste documentée des points de terminaison HTTP les marque /scim/v2/* de cette façon. Lisez les conditions de licence avant de concevoir un déploiement reposant sur une fonction que vous n’avez pas testée vous-même.

Un seul binaire réduit réellement le nombre de composants. Il ne réduit pas les deux éléments qui déterminent si vos messages arrivent à destination.

Le port 25 et la réputation DNS ne dépendent pas du logiciel utilisé

Le port TCP sortant 25 est le premier point de contrôle. De nombreux fournisseurs de VPS le bloquent par défaut sur les nouveaux comptes. Un port 25 bloqué empêche votre serveur de remettre directement des messages au serveur de messagerie d’un autre domaine. Testez-le avant d’installer quoi que ce soit.

sudo apt update && sudo apt install -y netcat-openbsd
nc -vz -w 5 alt1.aspmx.l.google.com 25

Un résultat normal affiche Connection to alt1.aspmx.l.google.com ... 25 port [tcp/smtp] succeeded! en environ une seconde. Un blocage se manifeste de deux façons. Si les paquets sont abandonnés en amont, aucun reset ne vous est renvoyé. nc reste donc bloqué pendant les cinq secondes complètes, puis affiche nc: connect to alt1.aspmx.l.google.com port 25 (tcp) failed: Connection timed out. Si le firewall les rejette, il renvoie une erreur ICMP. Le rejet de netfilter envoie une erreur « port unreachable », sauf si vous lui demandez d’en envoyer une autre, comme « administratively prohibited ». L’échec revient alors immédiatement, généralement sous la forme de Connection refused ou No route to host. Dans les deux cas, ouvrez un ticket auprès de votre fournisseur.

Si le fournisseur refuse de l’ouvrir, la seule solution consiste à utiliser un relay. Stalwart peut remettre tous les messages sortants à un smarthost via une route Relay. Son port est 25 par défaut, mais accepte toute valeur comprise entre 1 et 65535. La route prend également en charge une option implicitTls, ainsi que les champs authUsername et authSecret pour un relay authentifié sur les ports 465 ou 587. Vos messages sortent alors avec la réputation du relay, et non avec la vôtre.

Le deuxième point de contrôle est la manière dont les réseaux destinataires évaluent votre adresse IP et votre domaine. Cela comprend le reverse DNS de l’IP, SPF, DKIM, DMARC et l’historique d’envoi du bloc d’adresses dans lequel vous êtes arrivé. La page de configuration DNS de Stalwart, telle que nous l’avons consultée le 28 August 2026, indique clairement où effectuer ce travail : les enregistrements reverse DNS « sont généralement configurés par le fournisseur d’hébergement, et non par Stalwart lui-même ». Il en va de même pour le reste de cette configuration. Elle se trouve dans votre zone DNS et dans le panneau de contrôle de votre fournisseur, pas sur le serveur de messagerie.

Cette page ne réexplique donc pas ces enregistrements. Nous avons une page qui le fait : Configurer SPF, DKIM et DMARC une seule fois pour tous les services qui envoient des messages. Si vous n’avez pas encore décidé d’héberger vous-même votre messagerie, commencez par notre analyse honnête de l’intérêt actuel de l’auto-hébergement de la messagerie. Choisir Stalwart ne change rien à ces contraintes.

Ce dont a besoin un petit VPS pour exécuter un serveur de messagerie Stalwart

La page des exigences système de Stalwart, consultée le 12 octobre 2026, indique les valeurs suivantes. La consommation mémoire au repos est d’environ 100 MB. Un petit déploiement de 5 à 10 utilisateurs fonctionne avec 1 GB de RAM. Une installation peu sollicitée d’environ 5 utilisateurs fonctionne sur un seul cœur CPU. La page précise que « lorsque la simultanéité et l’activité augmentent, davantage de cœurs CPU sont nécessaires pour maintenir une faible latence et un débit élevé ». La limite par défaut est de 8,192 connexions simultanées pour l’ensemble des services, et elle est configurable.

Cette page n’indique aucune taille minimale de disque. Dimensionnez donc le disque en fonction du volume de messages que vous prévoyez de conserver, en ajoutant une marge pour permettre la compaction du store.

Trois flux sortants doivent fonctionner. Sinon, le serveur semble défaillant pour des raisons qui n’ont rien à voir avec la messagerie. Il récupère le bundle de l’interface web depuis https://github.com/stalwartlabs/webui/releases/latest/. Il doit accéder à https://acme-v02.api.letsencrypt.org/directory pour obtenir les certificats. Il a besoin de DNS sur les ports UDP et TCP 53 pour les recherches d’enregistrements MX et d’authentification. Un pare-feu de sortie restrictif qui bloque le premier flux vous laisse avec un serveur de messagerie opérationnel, mais sans interface d’administration.

Installer une version figée, pas « latest »

L’installateur officiel est un script shell. Lisez-le avant de l’exécuter.

curl --proto '=https' --tlsv1.2 -sSf https://get.stalw.art/install.sh -o install.sh
less install.sh
sudo sh install.sh

La lecture de ce script le 12 octobre 2026 montre exactement ce qu’il fait. Il crée un compte de service stalwart et les répertoires nécessaires. Il télécharge ensuite depuis https://github.com/stalwartlabs/stalwart/releases/latest/download. Le binaire est installé dans /usr/local/bin/stalwart avec le mode 0755. La configuration est placée dans /etc/stalwart/config.json, les données dans /var/lib/stalwart et les journaux dans /var/log/stalwart. Ces trois répertoires utilisent le mode 0750 et appartiennent à stalwart. Un fichier d’environnement est écrit dans /etc/stalwart/stalwart.env avec le mode 0640 et appartient à root:stalwart. Le script accepte un préfixe d’installation facultatif et un indicateur --fdb pour le build FoundationDB. Il n’accepte aucun argument de version.

Ce dernier point est important. Le script récupère toujours la version la plus récente. Deux serveurs installés à une semaine d’intervalle n’exécutent donc pas forcément le même code. Épinglez vous-même le binaire juste après l’installation. C’est également la procédure de mise à niveau indiquée dans les notes de version de v0.16.26 : « If you are upgrading from v0.16.x, replace the binary (or run docker pull). » Sept versions de correctifs sont sorties entre le 24 août et le 11 octobre 2026. Plusieurs contenaient des correctifs de sécurité. Épinglez donc la version la plus récente, puis déplacez volontairement ce pin.

STALWART_TAG=v0.16.26
curl -fsSLO "https://github.com/stalwartlabs/stalwart/releases/download/${STALWART_TAG}/stalwart-x86_64-unknown-linux-gnu.tar.gz"
tar zxf stalwart-x86_64-unknown-linux-gnu.tar.gz
sudo systemctl stop stalwart
sudo install -m 0755 -o root -g root stalwart /usr/local/bin/stalwart
sudo systemctl start stalwart
systemctl is-active stalwart

systemctl is-active stalwart doit afficher active. Dans le cas contraire, consultez journalctl -u stalwart -n 50. Chaque artefact de version est fourni avec un bundle .sigstore.json correspondant. La signature du téléchargement peut donc être vérifiée avant l’installation.

L’unité créée par le script s’exécute avec User=stalwart et définit AmbientCapabilities=CAP_NET_BIND_SERVICE. Cette capacité permet à un compte non privilégié d’écouter sur les ports 25, 443, 465 et 993. Si vous créez ensuite votre propre unité et omettez cette ligne, le service échoue au démarrage, car un utilisateur normal ne peut pas écouter sur un port inférieur à 1024.

Emplacement où le premier mot de passe administrateur est affiché

Stalwart démarre en mode bootstrap et écrit une fois un mot de passe temporaire de 16 caractères dans le journal du service.

sudo journalctl -u stalwart -n 200 | grep -A8 'bootstrap mode'

L’assistant de configuration écoute en HTTP non chiffré sur le port 8080. N’exposez donc pas ce port. Créez plutôt un tunnel depuis votre ordinateur portable via SSH :

ssh -N -L 8080:127.0.0.1:8080 you@your-vps

Ouvrez ensuite http://127.0.0.1:8080/admin et connectez-vous en tant que admin avec le mot de passe extrait du journal. L’assistant demande le nom d’hôte du serveur, le domaine de messagerie par défaut, TLS, le stockage, l’annuaire des comptes, la journalisation et la gestion du DNS. Redémarrez le service lorsque la configuration est terminée, puis utilisez https://<your-host>/admin à partir de ce moment.

Si le mot de passe n’apparaît plus dans le journal, définissez-en un fixe. /etc/stalwart/stalwart.env contient des entrées commentées prévues à cet effet, notamment STALWART_RECOVERY_ADMIN=admin:changeme, STALWART_RECOVERY_MODE=true et STALWART_RECOVERY_MODE_PORT (8080 par défaut). Décommentez-les, redémarrez, connectez-vous, puis commentez-les de nouveau. La page de renforcement de la sécurité de Stalwart recommande de conserver cet identifiant uniquement pour les situations d’urgence et de ne jamais se connecter à IMAP, JMAP ou WebDAV avec un compte administrateur.

La même page indique quels listeners conserver : le port 25 pour le SMTP entrant, 465 pour la soumission avec TLS implicite, 993 pour IMAPS et 443 pour tout le trafic HTTP. Elle considère les ports 587, 143, 4190, 110, 995 et 8080 comme non essentiels et recommande de désactiver 8080 une fois la configuration terminée.

Exécuter le service avec Docker en utilisant un tag figé

L’image documentée est stalwartlabs/stalwart. Le tag v0.16.26 était présent sur Docker Hub le 12 octobre 2026, avec une variante -alpine. La page Docker de Stalwart recommande le tag mineur v0.16 en production. Utilisez plutôt la version de patch complète, pour la même raison que pour le binaire ci-dessus.

services:
  stalwart:
    image: stalwartlabs/stalwart:v0.16.26
    container_name: stalwart
    restart: unless-stopped
    ports:
      - "25:25"
      - "465:465"
      - "993:993"
      - "443:443"
      - "127.0.0.1:8080:8080"
    volumes:
      - stalwart-etc:/etc/stalwart
      - stalwart-data:/var/lib/stalwart
volumes:
  stalwart-etc:
  stalwart-data:

Ce fichier reprend la commande docker run documentée, écrite au format Compose, en supprimant les listeners non essentiels et en liant le port de configuration à localhost. Démarrez le service et recherchez la même ligne d’initialisation :

docker compose up -d
docker compose logs stalwart 2>&1 | grep -A8 'bootstrap mode'

La page Docker documente également -e STALWART_RECOVERY_ADMIN=admin:mySecretPass pour définir un identifiant fixe au démarrage. Dans Compose, il s’agit de la clé environment:, si vous préférez cette méthode à la lecture des journaux.

Si Compose est nouveau pour vous, notre tutoriel Docker Compose pour un VPS présente l’organisation des fichiers et le modèle de volume nommé utilisé ici. Attention, un point particulièrement important pour les serveurs de messagerie : Docker publie les ports en ajoutant ses propres règles de pare-feu. Ces règles sont évaluées avant celles d’ufw. Par conséquent, ufw deny 8080 ne ferme pas un port publié par Compose. Il faut lier le port à 127.0.0.1 dans le mapping des ports pour réellement le fermer. C’est pourquoi le fichier ci-dessus utilise cette configuration, tout en conservant le tunnel SSH.

TLS sans certbot : contreparties

Stalwart implémente directement ACME (automatic certificate management environment). Il n’y a donc ni certbot ni hook de renouvellement. La documentation répertorie quatre méthodes de validation. HTTP-01 répond à une requête de challenge sur le port 80. TLS-ALPN-01 présente un certificat dédié sur le port 443 en utilisant le protocole ALPN spécifique à ACME. DNS-01 publie des enregistrements TXT temporaires et fait partie des deux méthodes capables d’émettre des certificats wildcard. DNS-PERSIST-01 utilise des enregistrements TXT d’autorisation à longue durée au lieu d’en créer un nouveau à chaque renouvellement.

La contrepartie est que Stalwart veut gérer lui-même le handshake TLS. TLS-ALPN-01 fonctionne en terminant lui-même le handshake. Cette méthode ne peut donc pas fonctionner derrière un reverse proxy qui termine TLS à votre place. Si nginx ou Caddy occupe déjà le port 443 sur ce serveur, trois solutions sont possibles. Le guide nginx de Stalwart configure nginx en TCP passthrough, avec listen 443; proxy_pass 127.0.0.1:10443; proxy_protocol on;, afin que la connexion TLS parvienne à Stalwart sans modification. Toutes les connexions sur le port 443 sont alors transmises à Stalwart. Cette configuration convient donc à un serveur sur lequel nginx ne sert rien d’autre sur ce port. Sinon, utilisez DNS-01 ou HTTP-01 avec Stalwart, ou attribuez-lui sa propre adresse IP.

DANE et MTA-STS : les valeurs par défaut à connaître

Les deux mécanismes se configurent par stratégie TLS sur l’objet MtaTlsStrategy, sous Settings, MTA, Outbound, TLS Strategies dans l’interface web. Le champ dane vaut par défaut optional. Il tente de valider DANE lorsque le destinataire publie des enregistrements TLSA, puis revient à STARTTLS standard dans le cas contraire. Avec require, la remise ne se poursuit que si un enregistrement TLSA vérifiable est disponible. Le champ mtaSts fonctionne de la même manière et vaut par défaut optional. Les délais associés sont tlsTimeout (3 minutes par défaut) et mtaStsTimeout (5 minutes par défaut).

Côté entrant, Stalwart peut publier votre propre stratégie MTA-STS à l’adresse https://mta-sts.<domain>/.well-known/mta-sts.txt, qui doit être accessible sur le port 443. Le singleton MtaSts contient mode (testing par défaut), maxAge (7 jours par défaut) et mxHosts. Lorsque ce dernier champ est vide, il utilise les noms d’hôte présents dans votre certificat TLS. Vous devez fournir deux enregistrements DNS : un enregistrement CNAME mta-sts pointant vers l’hôte de messagerie, et un enregistrement TXT _mta-sts contenant l’identifiant de la stratégie.

dig +short TXT _mta-sts.example.org
curl -s https://mta-sts.example.org/.well-known/mta-sts.txt

La requête TXT doit renvoyer une chaîne v=STSv1; id=... et curl doit renvoyer le contenu de la stratégie. Si curl ne renvoie rien, le port 443 est fermé ou le certificat pour mta-sts.example.org n’a jamais été émis.

Laissez mode à testing tant que ces deux vérifications n’ont pas abouti. Une stratégie en mode enforce avec un certificat défectueux empêche les autres serveurs de vous remettre des messages. Vos utilisateurs vous le signaleront avant que vous ne trouviez le problème dans un journal. DANE présente un piège similaire : il exige une zone signée avec DNSSEC, et un enregistrement TLSA qui épingle le certificat feuille doit être republé à chaque renouvellement ACME. Épinglez plutôt l’AC émettrice, ou acceptez cette tâche de renouvellement.

Le chiffrement au repos n'est pas un chiffrement de bout en bout

C'est la fonctionnalité la plus souvent mal comprise. Voici exactement ce qu'indique la documentation. Les messages en clair de chaque utilisateur sont automatiquement chiffrés avec son certificat OpenPGP ou S/MIME avant leur écriture sur disque. encryptAtRest est activé par défaut et s'applique aux messages reçus via SMTP ou LMTP, à condition que le destinataire ait enregistré une clé de chiffrement. encryptOnAppend vaut false par défaut, « ce qui laisse les messages ajoutés intacts afin que les clients conservent le contrôle total de leur contenu ». OpenPGP utilise PGP/MIME et non l'ancien format PGP/Inline, avec AES-256 ou AES-128. Stalwart ne génère pas les clés : les utilisateurs exportent une clé publique au format ASCII-armored et l'enregistrent comme objet PublicKey sous Account, Public Keys.

Cela protège donc contre le vol d'une image disque, le vol d'une sauvegarde et la lecture du store par un opérateur après la livraison. Sans la clé privée, les octets stockés sont illisibles. L'administrateur ne peut pas non plus les déchiffrer.

Cela ne protège pas le message pendant son transport. Un message traverse Internet avec le niveau de TLS négocié par les deux serveurs. Il arrive en clair, puis Stalwart le chiffre à ce moment-là. L'expéditeur, le fournisseur de l'expéditeur et tout hop ayant supprimé TLS ont déjà vu le message en clair.

Trois autres limites doivent être précisées. Les dossiers Sent et Drafts sont écrits par le client, sous la forme d'un append, et encryptOnAppend vaut false par défaut. Ils restent donc en clair, sauf si vous modifiez ce paramètre. La documentation que j'ai relue le 12 octobre 2026 décrit uniquement le contenu des messages. Elle n'indique pas que les données d'enveloppe, les en-têtes ou les entrées d'index sont chiffrés. Ne le supposez donc pas. Elle n'indique pas non plus que les messages déjà stockés avant l'importation d'une clé sont rechiffrés. Supposez que ce n'est pas le cas et vérifiez-le. La documentation ne précise pas davantage si la recherche en texte intégral fonctionne encore sur les corps chiffrés. Testez ce point avec un compte de test avant de le promettre à qui que ce soit.

Et si un utilisateur perd sa clé privée, ses messages sont perdus. Il n'existe aucune procédure de récupération, conformément à la conception du système.

WKD relève d’un serveur web, pas d’un serveur de messagerie

WKD (Web Key Directory) constitue l’autre volet d’OpenPGP et répond à un problème différent. Il publie votre clé publique à une URL HTTPS fixe sous votre domaine, afin que le client de messagerie de l’expéditeur puisse la trouver et chiffrer le message avant même qu’il ne quitte sa machine. Il s’agit d’un chiffrement de bout en bout. Le chiffrement au repos de Stalwart concerne la copie stockée sur votre disque. Configurer l’un ne configure pas l’autre.

Stalwart ne fournit pas WKD. Sa documentation des endpoints HTTP, consultée le 12 octobre 2026, répertorie les chemins well-known pour jmap, caldav, carddav, oauth-authorization-server, openid-configuration, acme-challenge, mta-sts.txt, mail-v1.xml et autoconfig. Aucun chemin openpgpkey n’existe. Servez-le depuis un serveur web statique classique.

La spécification définit deux arborescences. La méthode avancée utilise https://openpgpkey.example.org/.well-known/openpgpkey/example.org/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe. La méthode directe utilise https://example.org/.well-known/openpgpkey/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe. Cette chaîne de 32 caractères correspond au SHA-1 de la partie locale convertie en minuscules, puis encodée en z-base-32. C’est pourquoi vous ne devez jamais créer ces noms de fichiers manuellement. GnuPG les génère pour vous.

gpg --export --armor you@example.org > you.asc
gpg-wks-client --print-wkd-url you@example.org
gpg-wks-client --install-key you.asc you@example.org

--print-wkd-url affiche l’URL qu’un client interrogera, en utilisant la forme avec sous-domaine. --install-key écrit la clé dans une arborescence locale qui reproduit la structure WKD, sous un répertoire racine nommé openpgpkey par défaut et modifié avec -C dir. Copiez cette arborescence dans la racine web, ajoutez le fichier policy requis à côté du répertoire hu (un fichier vide est valide), puis interrogez votre propre URL avec curl pour vérifier qu’elle renvoie bien les octets de la clé et non une erreur 404.

Stockage sur un seul VPS

Stalwart répartit le stockage entre quatre rôles : un data store pour les enregistrements structurés, comme l’état des boîtes aux lettres, un blob store pour les octets bruts des messages et les pièces jointes, un search store pour l’indexation en texte intégral, et un in-memory store pour les limiteurs de débit, les jetons d’authentification et les données de session. Chaque rôle peut utiliser un backend différent. La liste des backends pris en charge comprend RocksDB, FoundationDB, PostgreSQL, MySQL, SQLite, le stockage objet compatible S3, Azure Blob Storage, Redis, ElasticSearch et Meilisearch.

Sur un seul VPS, la réponse est simple. La documentation présente RocksDB comme « le backend recommandé pour les installations Stalwart à nœud unique, en raison de sa rapidité et de sa fiabilité ». Redis est pris en charge uniquement comme in-memory store. Il ne peut pas servir de data store ou de blob store. Aucun conteneur Redis distinct n’est donc nécessaire pour commencer. Vous pourrez déplacer le blob store vers S3 si les boîtes aux lettres finissent par dépasser la capacité du disque.

Les sauvegardes dépendent du backend. Pour les bases de données externes, utilisez la procédure propre à la base concernée. Pour les bases intégrées, la FAQ indique de copier le répertoire /var/lib/stalwart. Faites-le lorsque le service est arrêté, ou à partir d’un snapshot du système de fichiers ou du volume. Une copie au niveau des fichiers d’un key-value store en fonctionnement peut intervenir pendant une écriture. Vous ne le découvrirez qu’au moment de tenter une restauration.

Le filtre antispam qui remplace Rspamd

Le filtrage s’exécute dans le même processus. Aucun second daemon ne doit donc rester actif. Le classifieur se configure dans le singleton SpamClassifier, sous Settings, Spam Filter, Classifier. Il utilise l’algorithme FTRL-Proximal avec le feature hashing. FtrlFh est le réglage par défaut recommandé pour la plupart des déploiements. FtrlCcfh utilise à la place le cuckoo feature hashing afin de réduire les collisions de hachage. Il convient aux déploiements à grande échelle. Le classifieur s’entraîne en continu : lorsque les utilisateurs marquent un message comme spam ou ham, cette étiquette est immédiatement réutilisée pour les décisions suivantes.

Autour du classifieur se trouvent les DNS blocklists, la greylisting, la détection du phishing, les spam traps et Pyzor. Vous pouvez aussi appeler SpamAssassin via milter si vous avez des règles auxquelles vous refusez de renoncer.

Quand mailcow reste le bon choix

Stalwart n’intègre pas de webmail. C’est de loin sa principale lacune, et l’écart est important. La documentation de mailcow, consultée le 12 octobre 2026, répertorie seize composants, dont SOGo. Celui-ci fournit à vos utilisateurs une boîte de réception accessible depuis un navigateur, ainsi qu’une interface CalDAV et CardDAV, directement après l’installation. Dans son billet du 20 juin 2025 consacré à la roadmap, Stalwart indique qu’un webmail intégré est « prévu, mais ne constitue pas actuellement notre priorité immédiate ». Il doit être développé en Rust avec Dioxus après la version 1.0, « très probablement courant 2026 ». Au 12 octobre 2026, le blog du projet ne contient aucun billet annonçant sa disponibilité. Avec Stalwart, vous devez donc soit déployer Roundcube vous-même, soit demander à chaque utilisateur de configurer un client de messagerie.

Stalwart dispose bien d’une interface d’administration web. Ce n’est donc pas la lacune à laquelle on pourrait s’attendre. La deuxième lacune concerne la maturité des versions. La FAQ indique que Stalwart est encore en 0.x et que la structure des données et la configuration peuvent changer avant la version v1.0, ce qui peut nécessiter une migration. Le billet publié par le projet en juin 2026 s’intitule « Zero open bug reports: The road to Stalwart 1.0 ». Cela indique clairement son niveau de maturité : le projet est proche, mais n’y est pas encore. Au 12 octobre 2026, la version la plus récente reste v0.16.26.

La troisième lacune est absente de la plupart des listes de fonctionnalités. Postfix, Dovecot et Rspamd disposent de dix ans de réponses documentées. À deux heures du matin, lorsque des messages sont en file d’attente et que les utilisateurs attendent, une recherche qui renvoie une chaîne d’erreur correspondante vaut plus qu’une architecture élégante. Si vous êtes dans cette situation, notre guide d’installation de mailcow décrit toute la pile de bout en bout et votre nuit sera plus courte.

Choisissez Stalwart si vous voulez un seul binaire, un seul fichier de configuration et JMAP, et si vous acceptez d’utiliser une solution encore récente. Choisissez mailcow si vous voulez un webmail dès aujourd’hui et un vaste corpus de réponses existantes.

Déplacer le courrier existant

La méthode générique consiste à utiliser IMAP vers IMAP avec imapsync. Elle ne dépend pas du logiciel utilisé de chaque côté. Commencez par une simulation.

imapsync --dry \
  --host1 old.example.org --user1 you@example.org --passfile1 /root/.old.pw \
  --host2 mail.example.org --user2 you@example.org --passfile2 /root/.new.pw

--dry demande à imapsync de « ne rien exécuter réellement et d’afficher uniquement les actions prévues ». Lisez donc cette sortie avant de supprimer l’option. Chaque fichier de mots de passe contient le mot de passe sur sa première ligne. Utilisez donc chmod 600 pour les deux fichiers, puis supprimez-les.

Stalwart fournit également des outils plus récents que la plupart des guides tiers n’ont pas encore intégrés. Son blog présente Vandelay, un outil d’importation et d’exportation JMAP (29 May 2026), ainsi qu’un proxy de migration pour effectuer des mises à niveau sans interruption (10 June 2026). Lisez ces deux articles avant de planifier une migration importante, car ils sont plus récents que presque toutes les informations disponibles ailleurs.

Modes d’échec et messages affichés

L’interface d’administration ne se charge jamais. La FAQ mentionne explicitement ce cas : le bundle de l’interface web est téléchargé depuis GitHub lors de la première exécution. Un serveur qui ne peut pas établir de connexion HTTPS sortante vers github.com exécute donc un service fonctionnel, mais toutes les routes de l’interface web renvoient 404. Vérifiez ce point avec curl -sI https://github.com/stalwartlabs/webui/releases/latest/ depuis le serveur. Les autres causes fréquentes mentionnées sont un schéma HTTP ou HTTPS incorrect et un reverse proxy qui ne transmet pas l’adresse IP du client.

Aucun mot de passe d’amorçage dans le journal. Il est affiché une seule fois au démarrage, en mode bootstrap. Si le service a redémarré depuis, élargissez la fenêtre de recherche avec sudo journalctl -u stalwart --since today | grep -A8 'bootstrap mode'. S’il a réellement disparu, définissez STALWART_RECOVERY_ADMIN dans /etc/stalwart/stalwart.env, puis redémarrez le service.

Le relais via un proxy local est refusé. Les notes de version de v0.16.19 signalent la correction du rejet des routes de relais avec host resolves loopback address. Si vous rencontrez exactement ce message, vous utilisez une version plus ancienne. Mettez à niveau vers une version ultérieure au lieu de contourner le problème.

Le service ne démarre pas après la création de votre propre unité. Sans AmbientCapabilities=CAP_NET_BIND_SERVICE, l’utilisateur stalwart ne peut pas ouvrir les ports 25, 443, 465 ou 993, et le démarrage échoue sur le premier listener. Copiez la ligne de capacité depuis l’unité générée par l’installateur.

Les certificats ne sont jamais délivrés. HTTP-01 nécessite que le port 80 soit accessible et libre. TLS-ALPN-01 nécessite que Stalwart réponde lui-même au handshake TLS sur le port 443. Si un autre service utilise l’un de ces ports sur le serveur, ACME continuera d’échouer silencieusement alors que tout le reste semblera fonctionner correctement.

FAQ

Stalwart remplace-t-il Postfix, Dovecot et Rspamd sur un même VPS ?

Oui. Un seul binaire Rust prend en charge SMTP, IMAP, POP3, JMAP, CalDAV, CardDAV et WebDAV. Il inclut également le filtre antispam, le stockage des messages et un client ACME. Vous avez une seule unité systemd et un seul fichier de configuration à /etc/stalwart/config.json, au lieu de quatre daemons et de leur configuration d’intégration. Stalwart ne remplace pas votre zone DNS ni la politique de votre fournisseur concernant le port 25. C’est pourtant là que l’hébergement de messagerie détermine sa réussite ou son échec.

De combien de RAM un serveur de messagerie Stalwart a-t-il besoin ?

La page des exigences système de Stalwart, consultée le 12 octobre 2026, indique environ 100 MB au repos et précise que 1 GB de RAM convient à un petit déploiement de 5 à 10 utilisateurs. Une installation peu sollicitée d’environ 5 utilisateurs fonctionne sur un seul cœur CPU. La limite par défaut est de 8,192 connexions simultanées pour l’ensemble des services. Elle est configurable. La consommation maximale augmente donc avec le nombre de connexions et le volume de messages, et pas seulement avec le nombre d’utilisateurs. Aucune taille minimale de disque n’est publiée. Dimensionnez donc le disque en fonction des messages que vous conservez.

Le passage à Stalwart améliorera-t-il la délivrabilité de mes e-mails ?

Non. La délivrabilité dépend de l’ouverture du port TCP 25 sortant sur votre VPS, du reverse DNS de votre adresse IP et de la configuration SPF, DKIM et DMARC de votre domaine. Stalwart prend bien en charge DANE, MTA-STS et les rapports SMTP TLS. Il peut également publier votre stratégie MTA-STS. Ces mécanismes sécurisent toutefois le transport. Ils ne déterminent pas si le réseau destinataire fait confiance à votre adresse. Testez le port 25 avec nc -vz -w 5 alt1.aspmx.l.google.com 25 avant d’installer quoi que ce soit.

Stalwart inclut-il un webmail ?

Pas au 12 octobre 2026. Stalwart fournit une interface d’administration web, ce qui est différent. L’article de la roadmap du projet, publié le 20 juin 2025, indique qu’un client webmail est prévu après la version 1.0. Il devrait être développé en Rust avec Dioxus, « très probablement courant 2026 ». Le blog du projet n’en a toutefois pas encore annoncé la disponibilité. Si vos utilisateurs ont besoin d’une boîte de réception dans un navigateur, déployez Roundcube à côté de Stalwart ou utilisez une stack qui inclut SOGo.

Que protège le chiffrement des données au repos de Stalwart ?

Il chiffre les messages de chaque utilisateur avec sa propre clé publique OpenPGP ou S/MIME avant de les écrire sur le disque. Ainsi, une personne qui vole le disque ou une sauvegarde, ou un administrateur qui lit le stockage, ne peut pas récupérer le contenu. Il ne s’agit pas d’un chiffrement de bout en bout. Le message arrive en texte clair et est chiffré lors de sa remise. Chaque relais précédent pouvait donc le lire. encryptOnAppend vaut false par défaut. Les messages enregistrés dans Sent et Drafts par votre client restent donc en clair tant que vous ne modifiez pas ce paramètre. La documentation traite uniquement du contenu des messages. Elle ne précise rien concernant les métadonnées, les entrées d’index ni le rechiffrement des messages stockés avant l’importation de la clé. Vérifiez donc ces points vous-même au lieu de les supposer.