mailcow : ouvrir SOGo comme n'importe quelle boîte, mettre à jour depuis l'interface et configurer le DNS

Le problème : trois corvées qui vous prennent la semaine

Si vous exploitez mailcow-dockerized pour vous-même ou pour quelques clients, vous connaissez la routine. Quelqu'un vous demande de vérifier une boîte aux lettres : vous cliquez sur SOGo à côté de celle-ci dans l'interface d'administration, et votre session d'administrateur disparaît. mailcow garde une session par nom d'hôte, donc la même session bascule sur la boîte aux lettres. Et tant que la session d'administrateur est ouverte, SOGo vous renvoie de toute façon au tableau de bord.

Ensuite vient la mise à jour. mailcow publie souvent, et mettre à jour suppose une session SSH, update.sh, et l'espoir d'avoir pensé à une sauvegarde. Et chaque nouveau domaine de messagerie exige de configurer à la main ses enregistrements MX, SPF, DKIM et DMARC chez le fournisseur DNS, plus une vérification du DNS inverse dont personne ne se souvient avant que Gmail ne commence à rejeter le courrier.

mailcow Toolkit est un plugin qui règle ces trois points depuis votre propre mailcow, et qui continue de fonctionner après les mises à jour de mailcow parce qu'il ne modifie aucun fichier suivi de mailcow. Ce tutoriel déroule l'installation une fois, pour que les corvées quotidiennes se réduisent à des clics.

Prérequis

• mailcow-dockerized sous Linux (le Toolkit est testé avec 2026-09 et 2026-09a), installé par exemple dans /opt/mailcow-dockerized, avec docker compose et systemd.
• Un accès root sur l'hôte, avec git, jq, flock, curl, tar et sha256sum installés.
• Un accès HTTPS sortant vers medialab.works depuis le serveur (vérification de licence, essai, mises à jour du Toolkit).
• Une clé de licence issue de votre compte medialab.works, ou une adresse e-mail pour l'essai gratuit de 30 jours.
• Un second nom d'hôte pour le webmail (par exemple webmail.example.com) dans le DNS, servi par le même reverse proxy que l'interface mailcow.
• Un dossier de sauvegarde, par exemple /srv/backup/mailcow.
• Pour SOGo comme boîte aux lettres : ALLOW_ADMIN_EMAIL_LOGIN=y dans mailcow.conf et la permission Login as mailbox user.
• En option, pour écrire les enregistrements DNS : un compte Cloudflare et un jeton d'API avec Zone > Zone > Read et Zone > DNS > Edit.

Étape 1 — Installer le Toolkit

Téléchargez mailcow-toolkit-<version>.tar.gz depuis votre compte, décompressez-le sur l'hôte mailcow et lancez, en root :

sudo ./install.sh --mailcow-dir /opt/mailcow-dockerized \
  --webmail-url https://webmail.example.com --backup-dir /srv/backup/mailcow

• --mailcow-dir indique où se trouve mailcow (par défaut /opt/mailcow-dockerized).
• --webmail-url est l'adresse du webmail, https:// plus le nom d'hôte (un port facultatif est autorisé). Si vous l'omettez, le bouton SOGo conserve le comportement d'origine de mailcow.
• --backup-dir est l'emplacement des sauvegardes effectuées avant les mises à jour. Si vous l'omettez, Update now s'exécute sans sauvegarde préalable, et l'installateur vous en avertit.
• --name n'est nécessaire que si vous exploitez plusieurs installations mailcow sur un même hôte.

L'installateur active cinq unités systemd, dont une minuterie quotidienne pour la vérification de version et de licence, une qui vérifie le DNS inverse toutes les 6 heures et une qui recherche les nouveaux domaines mailcow toutes les 2 minutes. À la fin, il recharge php-fpm et vous invite à ouvrir la section License.

Étape 2 — Activer la licence

Ouvrez System > Updates (Toolkit) en tant qu'administrateur. La section License en haut fonctionne même sans licence : saisissez votre clé et appuyez sur Activate, ou démarrez l'essai gratuit de 30 jours avec votre adresse e-mail et ouvrez le lien de paiement Stripe affiché (la carte est demandée à cet endroit et n'est pas débitée pendant l'essai). La page active le Toolkit d'elle-même dès que l'essai démarre. Sans licence valide, les fonctionnalités du Toolkit s'arrêtent et rien n'est supprimé.

Étape 3 — Un nom d'hôte webmail séparé

C'est tout l'astuce pour conserver votre session d'administrateur. Votre navigateur garde un cookie de session par nom d'hôte, donc SOGo a besoin de son propre nom.

1. Faites pointer webmail.example.com vers votre serveur dans le DNS.
2. Dans votre reverse proxy, servez-le exactement comme l'interface mailcow : même backend, mêmes en-têtes. C'est le même mailcow, simplement sous un autre nom.
3. Attribuez-lui un certificat TLS, comme à l'interface.

Si vous avez déjà installé avec --webmail-url, c'est fait. Sinon, relancez install.sh depuis la nouvelle version ; votre adresse webmail et votre dossier de sauvegarde précédents sont conservés lorsque vous les omettez.

Étape 4 — Activer SOGo comme boîte aux lettres

1. Dans mailcow.conf, définissez ALLOW_ADMIN_EMAIL_LOGIN=y, puis appliquez-le depuis l'interface mailcow.
2. Vérifiez que l'administrateur dispose de la permission Login as mailbox user.

Dès lors, le bouton SOGo dans la liste des boîtes aux lettres (pour l'administrateur de la plateforme ; les administrateurs de domaine conservent le bouton d'origine de mailcow) ouvre SOGo en tant que cette boîte aux lettres, dans un nouvel onglet, tandis que votre onglet d'administration reste connecté. Le transfert utilise un jeton à usage unique, valable 60 secondes et utilisé une fois ; sur l'hôte webmail, une nouvelle session de boîte aux lettres démarre et n'hérite jamais du rôle d'administrateur. Les boîtes aux lettres inactives sont refusées, selon les règles propres à mailcow.

Chaque usage est consigné deux fois : dans le journal de connexion de cette boîte aux lettres dans mailcow, comme connexion SSO, et dans le journal d'audit du Toolkit, avec qui l'a ouvert et depuis quelle adresse. C'est le point que les auditeurs et les clients apprécient.

Étape 5 — Mises à jour depuis l'interface, avec sauvegarde d'abord

Ouvrez System > Updates (Toolkit). La page affiche la version de mailcow installée, la dernière vérification et les nouveautés. Le serveur vérifie chaque jour une nouvelle version de mailcow et envoie un e-mail par nouvelle version à l'adresse que vous avez définie sur la page.

Quand vous êtes prêt, appuyez sur Update now. Le Toolkit effectue d'abord une sauvegarde (crypt, redis, rspamd, postfix et mysql, conservée 14 jours), puis lance le update.sh de mailcow, puis attend que tous les conteneurs tournent et que l'interface réponde. Le journal s'affiche en direct sur la page.

Deux garanties comptent : si la sauvegarde échoue, la mise à jour est arrêtée et rien n'est modifié ; si update.sh échoue ou qu'un conteneur ne démarre pas, la page le signale et conserve le journal. La page suit la langue de l'interface mailcow, anglais ou roumain.

Étape 6 — Les enregistrements DNS de chaque domaine

Ouvrez System > DNS & Cloudflare (administrateurs uniquement). Pour chaque domaine mailcow et domaine alias, la page liste les enregistrements dont mailcow a besoin, selon la vérification DNS propre à mailcow :

• Requis : l'enregistrement A de MAILCOW_HOSTNAME (DNS-only dans Cloudflare), MX 10 vers MAILCOW_HOSTNAME, SPF, DKIM (sélecteur et clé de mailcow) et DMARC.
• Recommandés : les CNAME autodiscover et autoconfig (DNS-only), les enregistrements SRV pour autodiscover, IMAPS, submission, SMTPS, POP3S (lorsque POP3 est autorisé), CalDAV et CardDAV avec leur TXT path=/SOGo/dav/ (avec SOGo), et MTA-STS et TLS-RPT lorsque MTA-STS est actif pour le domaine.
• Les domaines alias reçoivent MX, SPF, DKIM, DMARC et, avec MTA-STS, ses enregistrements TXT.

Chaque enregistrement est comparé au DNS public, à un fichier de zone que vous importez (un export Cloudflare ou n'importe quel fichier BIND) et, avec des identifiants Cloudflare, à la zone Cloudflare en direct. Les états sont OK, missing, different, proxied (doit être DNS-only), fix by hand ou unknown.

Deux valeurs par défaut vous évitent des ennuis. IPv4 uniquement par défaut : pas d'enregistrement AAAA et un SPF de v=spf1 ip4:<IPv4> -all ; le réglage Use IPv6 ajoute AAAA, ip6: et la vérification du DNS inverse IPv6, car un serveur qui publie AAAA sans PTR IPv6 correspondant voit son courrier en IPv6 rejeté par Gmail et d'autres. Et DMARC : une politique valide existante est conservée ; sinon vous obtenez v=DMARC1; p=quarantine;, avec des rapports vers dmarc@ ou postmaster@ uniquement lorsque cette adresse existe. Les ports SRV suivent mailcow.conf et peuvent être définis à la main pour les serveurs derrière un proxy ou un NAT.

Download BIND zone file vous fournit un fichier que Cloudflare importe via DNS > Records > Import and Export, avec cf_tags=cf-proxied:false sur les enregistrements qui doivent rester DNS-only.

Étape 7 — Appliquer à Cloudflare, en toute sécurité

Avec un jeton d'API à portée limitée (recommandé) ou la Global API Key, cochez des enregistrements, prévisualisez les changements et appliquez-les. Une sauvegarde JSON de la zone est enregistrée d'abord et le changement peut être annulé ; seuls les enregistrements sélectionnés sont créés ou mis à jour, rien n'est supprimé, et chaque changement est consigné dans le journal d'audit. Les identifiants sont vérifiés auprès de Cloudflare, stockés chiffrés sur votre serveur et ne sont plus jamais affichés. Les actions Cloudflare d'un domaine n'apparaissent que lorsque les identifiants enregistrés peuvent modifier le DNS de cette zone ; sinon, la page en explique la raison.

Étape 8 — Laisser les nouveaux domaines se configurer seuls

Deux fonctionnalités restent désactivées tant que vous ne les configurez pas :

• Configuration automatique de Cloudflare : dans les 2 minutes environ suivant l'ajout d'un domaine ou d'un domaine alias dans mailcow (interface ou API), ses enregistrements sont créés dans la zone Cloudflare existante. Les enregistrements erronés sont mis à jour, les enregistrements sans rapport ne sont jamais supprimés, et une politique SPF, DMARC ou TLS-RPT existante et différente est laissée telle quelle. Une zone manquante est signalée, ou créée si vous l'autorisez ; les échecs peuvent vous être envoyés par e-mail.
• Assistant de nouveau domaine : les adresses de rôle (postmaster, abuse, hostmaster, webmaster, contact, info, office, dmarc, tls-rpt, noreply, security, chacune facultative, plus les vôtres) sont créées comme alias vers une adresse que vous choisissez, pour qu'elles ne comptent pas dans la limite de boîtes aux lettres. noreply@ rejette le courrier silencieusement. Une boîte aux lettres ou un alias existant n'est jamais touché.

Les domaines qui existent déjà lorsque vous activez une fonctionnalité ne sont pas modifiés ; Provision now et Run wizard les traitent un par un.

Étape 9 — Surveiller le PTR et l'état de chaque domaine

Le Toolkit vérifie le DNS inverse toutes les 6 heures et affiche un « ! » rouge dans le menu d'administration en cas d'échec. La page DNS s'ouvre sur un résumé et un sélecteur de chaque domaine et domaine alias, les pires d'abord : critical (le courrier ne peut être remis ou envoyé, ou finira en spam), warning (enregistrements facultatifs manquants) ou all good, avec pour chaque domaine une explication du problème et la marche à suivre pour le corriger. Les états se rafraîchissent toutes les 10 minutes en arrière-plan ; Re-check now vérifie un domaine immédiatement. Le dernier domaine sélectionné est mémorisé.

Astuces et dépannage

• SOGo répond « Unauthorized » pour un nouveau domaine. SOGo lit les domaines de mailcow à son démarrage, donc un domaine ajouté plus tard lui est inconnu. Depuis 0.4.0, le Toolkit repère ces domaines toutes les 2 minutes et redémarre uniquement le conteneur SOGo (et vide memcached), dans les 3 à 10 minutes environ suivant l'ajout du domaine : une fois pour plusieurs nouveaux domaines, au plus toutes les 10 minutes, uniquement avec une licence valide. Chaque redémarrage est consigné dans le journal d'audit.
• Le bouton SOGo se comporte comme dans mailcow d'origine. Vérifiez que --webmail-url a bien été passé, que ALLOW_ADMIN_EMAIL_LOGIN=y est appliqué et que l'administrateur dispose de la permission Login as mailbox user.
• Update now est grisé ou s'exécute sans sauvegarde. Le dossier de sauvegarde vient de --backup-dir ; relancez install.sh pour le définir.
• Un enregistrement apparaît comme proxied. Cet enregistrement doit être DNS-only dans Cloudflare ; l'export du fichier de zone les marque avec cf_tags=cf-proxied:false.
• Serveur derrière un proxy ou un NAT. Définissez les ports SRV à la main sur la page DNS ; sinon, ils suivent mailcow.conf.
• Pas de connexion à medialab.works. Après la dernière vérification réussie, le Toolkit continue de fonctionner pendant 7 jours.
• Mettre à jour le Toolkit lui-même. Passez par la section License : elle télécharge l'archive signée, vérifie la taille et le SHA-256, et conserve la version précédente, de sorte qu'une installation échouée est annulée. Un install.sh d'une version plus récente fonctionne aussi.

Conclusion

Aucune de ces trois corvées n'est difficile ; elles sont simplement faciles à oublier. Un nom d'hôte webmail séparé transforme SOGo en une vue sûre, auditée et en un clic de n'importe quelle boîte aux lettres, tandis que votre session d'administrateur reste ouverte. Un bouton de mise à jour avec sauvegarde préalable supprime l'étape SSH et les incertitudes. Et une page DNS qui compare chaque domaine au DNS public et à Cloudflare, plus une vérification du PTR toutes les 6 heures, détecte les problèmes avant un destinataire. Comme le Toolkit ne modifie aucun fichier suivi de mailcow, il survit aux mises à jour de mailcow : vous le configurez donc une seule fois.

Le guide utilisateur détaille chaque réglage, le changelog liste ce que chaque version a apporté, et notre base de connaissances en dit plus pour les auto-hébergeurs. Des questions ? Contactez-nous.