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

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 unique. Le même processus gère SMTP, IMAP, POP3, JMAP, CalDAV, CardDAV et WebDAV. Il intègre également son propre filtre antispam, son propre stockage des messages et son propre client ACME. Une pile classique répartit ces fonctions entre Postfix, Dovecot, Rspamd, une base de données pour les comptes et un outil de certificats distinct. Stalwart remplace l’ensemble par une seule unité de service et un seul fichier de configuration à /etc/stalwart/config.json.

Chaque valeur, nom de paramètre et commande ci-dessous provient de la documentation, des pages de publication et du script d’installation officiels de Stalwart, consultés le 28 August 2026 pour la version v0.16.19, publiée le 24 August 2026. Vous pouvez exécuter ces commandes sur votre propre serveur. Chaque commande est suivie de la vérification qui indique si elle a fonctionné.

Stalwart est distribué sous une double licence : la GNU Affero General Public License v3.0 (AGPL-3.0) et la Stalwart Enterprise License v2. Certaines fonctionnalités sont réservées à l’édition Enterprise. La liste documentée des endpoints HTTP les signale avec /scim/v2/*. Lisez les conditions de licence avant de baser un déploiement sur une fonctionnalité que vous n’avez pas testée vous-même.

Un binaire unique réduit réellement le nombre de composants à gérer. Il ne réduit pas les deux facteurs 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 contrôle. De nombreux fournisseurs de VPS le bloquent par défaut sur les nouveaux comptes. Un port 25 bloqué signifie que votre serveur peut communiquer avec lui-même, mais avec aucun autre serveur. 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 correct affiche Connection to alt1.aspmx.l.google.com ... 25 port [tcp/smtp] succeeded! en environ une seconde. Un port bloqué attend les cinq secondes complètes, puis affiche nc: connect to alt1.aspmx.l.google.com port 25 (tcp) failed: Connection timed out, car les paquets sont abandonnés en amont et personne ne vous renvoie de paquet TCP reset. Si c’est le cas, ouvrez un ticket auprès de votre fournisseur. Aucun serveur de messagerie ne peut contourner un paquet abandonné.

Le deuxième contrôle concerne la manière dont les réseaux destinataires évaluent votre adresse IP et votre domaine. Il s’agit du reverse DNS de l’adresse IP, de SPF, DKIM et DMARC, ainsi que de l’historique d’envoi du bloc d’adresses auquel vous appartenez. La page de configuration DNS de Stalwart indique clairement où ce travail doit être effectué : 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 dans le serveur de messagerie.

Cette page ne réexplique donc pas ces enregistrements. Nous avons une page dédiée : Configurer SPF, DKIM et DMARC une seule fois pour tous les services qui envoient des e-mails. Si vous n’avez pas encore décidé de gérer 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 à cette réalité.

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

La page des exigences système de Stalwart, consultée le 28 août 2026, fournit les chiffres suivants. 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 avec un seul cœur de CPU. La page précise que « lorsque la concurrence et l’activité augmentent, davantage de cœurs de 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. Elle est configurable.

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

Trois chemins 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 egress restrictif qui bloque le premier accès laisse un serveur de messagerie fonctionnel, 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 28 août 2026 montre précisément ce qu’il fait. Il crée le compte de service stalwart ainsi que 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 une option --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 le même code. Figez 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.19 : « Si vous effectuez une mise à niveau depuis v0.16.x, remplacez le binaire (ou exécutez docker pull). »

STALWART_TAG=v0.16.19
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 release est fournie avec un bundle .sigstore.json correspondant. Vous pouvez donc vérifier la signature du téléchargement avant de l’installer.

L’unité écrite par le script s’exécute sous User=stalwart et définit AmbientCapabilities=CAP_NET_BIND_SERVICE. Cette capability permet à un compte sans privilèges d’écouter sur les ports 25, 443, 465 et 993. Si vous écrivez 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 et un tag figé

L’image documentée est stalwartlabs/stalwart. Le tag v0.16.19 était disponible sur Docker Hub le 28 août 2026, avec également une variante -alpine. Figez la version de correctif plutôt que le tag flottant v0.16, pour la même raison que pour le binaire ci-dessus.

services:
  stalwart:
    image: stalwartlabs/stalwart:v0.16.19
    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 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. Il s’agit de la clé Compose 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 explique l’organisation des fichiers et le modèle de volume nommé utilisé ici. Attention, en particulier avec les serveurs de messagerie : Docker publie les ports en écrivant ses propres règles de pare-feu, qui 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 la configuration du mapping de ports pour réellement le fermer. C’est pourquoi le fichier ci-dessus utilise cette configuration et que le tunnel SSH continue de s’appliquer.

TLS sans certbot, et ce que cela implique

Stalwart implémente directement ACME (automatic certificate management environment). Il n’y a donc ni certbot ni hook de renouvellement. La documentation liste 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 propre à ACME. DNS-01 publie des enregistrements TXT temporaires. C’est l’une 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.

En contrepartie, Stalwart doit pouvoir prendre possession du port. TLS-ALPN-01 fonctionne en établissant lui-même la négociation TLS. Il ne peut donc pas fonctionner derrière un reverse proxy qui termine TLS à votre place. Si nginx ou Caddy utilise déjà le port 443 sur ce serveur, passez Stalwart à DNS-01 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 interprétée. 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 est désactivé par défaut, « ce qui laisse les messages ajoutés tels quels afin que les clients conservent le contrôle total de leur contenu ». OpenPGP utilise PGP/MIME plutôt que 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 une image disque volée, une sauvegarde volée et la lecture du store par un opérateur après la livraison. Sans la clé privée, les octets stockés sont illisibles, et l’administrateur ne peut pas non plus les déchiffrer.

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

Trois autres limites doivent être énoncées clairement. Les dossiers Sent et Drafts sont écrits par votre client, ce qui constitue un ajout, et encryptOnAppend est désactivé par défaut : ils restent donc en clair, sauf si vous modifiez ce réglage. La documentation consultée le 28 August 2026 décrit uniquement le contenu des messages et n’indique pas que les données d’enveloppe, les en-têtes ou les entrées d’index sont chiffrés. Ne partez donc pas du principe qu’ils le sont. Elle n’indique pas non plus que les messages déjà stockés avant l’importation d’une clé sont rechiffrés. Considérez donc que ce n’est pas le cas et vérifiez-le. La documentation ne précise pas non plus si la recherche en texte intégral fonctionne toujours sur les corps chiffrés. Testez ce point sur un compte de test avant de le garantir à qui que ce soit.

Enfin, si un utilisateur perd sa clé privée, ses messages sont perdus. Il n’existe aucun mécanisme 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 moitié du fonctionnement 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 sert pas WKD. Sa documentation, consultée le 28 August 2026, répertorie des 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’est prévu. Servez-le depuis un serveur web statique classique.

La spécification définit deux structures. 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 est le SHA-1 de la partie locale convertie en minuscules, encodé en z-base-32. Vous ne devez donc jamais construire ces noms de fichier 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 récupérera, 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 récupérez votre propre URL avec curl pour vérifier qu’elle renvoie les données 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 encore important. La documentation de mailcow, consultée le 28 August 2026, liste seize composants, dont SOGo, qui fournit directement à vos utilisateurs une boîte de réception accessible depuis un navigateur ainsi qu’une interface CalDAV et CardDAV. La publication de la roadmap de Stalwart du 20 June 2025 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 à un moment en 2026 ». Au 28 August 2026, le blog du projet ne contient aucune publication 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é de la version. La FAQ indique que Stalwart est en version 0.x et que la structure des données et la configuration peuvent encore changer avant la v1.0, ce qui peut nécessiter une migration. La propre publication du projet datée de June 2026 s’intitule « Zero open bug reports: The road to Stalwart 1.0 ». Elle indique clairement l’état du projet : la version 1.0 est proche, mais elle n’est pas encore disponible.

La troisième lacune est celle que personne ne mentionne dans une liste de fonctionnalités. Postfix, Dovecot et Rspamd s’appuient sur une décennie 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 mieux qu’une architecture élégante. Si c’est votre situation, notre guide d’installation de mailcow couvre toute la pile de bout en bout et votre nuit de dépannage sera plus courte.

Choisissez Stalwart si vous voulez un seul binaire, un seul fichier de configuration et JMAP, et si vous acceptez d’adopter 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 directement ce cas : le bundle de l’interface web est téléchargé depuis GitHub lors du premier démarrage. Un serveur sans accès HTTPS sortant vers github.com peut donc exécuter le service tout en affichant une page vide. Vérifiez l’accès avec curl -sI https://github.com/stalwartlabs/webui/releases/latest/ depuis le serveur. Les autres causes courantes indiqué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 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 relais via un proxy local est refusé. Les notes de version de v0.16.19 signalent un correctif pour les routes de relais rejetées avec host resolves loopback address. Si vous rencontrez exactement ce message, vous utilisez une build plus ancienne. Mettez à niveau directement 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 capability 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 au handshake TLS sur 443. Si un autre service utilise l’un de ces ports sur le serveur, ACME continuera à échouer silencieusement alors que tout le reste semble fonctionner.

FAQ

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

Oui. Un seul binaire Rust gère SMTP, IMAP, POP3, JMAP, CalDAV, CardDAV et WebDAV. Il intègre également le filtre antispam, le stockage des messages et un client ACME. Vous avez une seule unité systemd et un seul fichier de configuration à l’emplacement /etc/stalwart/config.json, au lieu de quatre daemons et de leur configuration d’intégration. En revanche, Stalwart ne remplace ni votre zone DNS ni la politique de votre fournisseur concernant le port 25. C’est sur ces points que l’hébergement autonome de messagerie réussit ou échoue.

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

La page des prérequis système de Stalwart, consultée le 28 août 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 limite augmente donc avec le nombre de connexions et le volume de messages, pas uniquement avec le nombre d’utilisateurs. Aucune taille minimale de disque n’est publiée. Dimensionnez donc le disque selon la quantité de 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, ainsi que des enregistrements SPF, DKIM et DMARC de votre domaine. Stalwart prend bien en charge DANE, MTA-STS et les rapports TLS SMTP. Il peut également publier votre politique MTA-STS. Ces mécanismes contrôlent toutefois la sécurité du transport, pas la confiance qu’un réseau destinataire accorde à votre adresse. Testez le port 25 avec nc -vz -w 5 alt1.aspmx.l.google.com 25 avant toute installation.

Stalwart inclut-il un webmail ?

Pas au 28 août 2026. Il fournit une interface d’administration web, ce qui est différent. L’article de la roadmap du projet daté du 20 juin 2025 indique qu’un client webmail est prévu après la version 1.0. Il doit être développé en Rust avec Dioxus, « most likely sometime in 2026 ». Le blog du projet n’annonce encore aucun client de ce type. Si vos utilisateurs ont besoin d’une boîte de réception accessible depuis un navigateur, déployez Roundcube à côté de Stalwart ou utilisez une stack qui intègre SOGo.

Contre quoi le chiffrement au repos de Stalwart protège-t-il ?

Stalwart 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 des messages. Il ne s’agit pas d’un chiffrement de bout en bout : le message arrive en clair et est chiffré lors de sa remise. Chaque relais précédent a donc pu 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 couvre uniquement le contenu des messages. Elle ne précise rien concernant les métadonnées, les entrées d’index ou le rechiffrement des messages stockés avant l’importation de la clé. Vérifiez donc vous-même ces points au lieu de les supposer.