SOGo avec n’importe quelle boîte aux lettres sans perdre la session administrateur, les mises à jour de mailcow depuis l’interface, et les enregistrements DNS de chaque domaine mailcow, aussi dans Cloudflare.

mailcow-dockerized conserve une session par nom d’hôte. Quand un administrateur clique sur SOGo à côté d’une boîte aux lettres, cette même session bascule vers la boîte aux lettres : SOGo s’ouvre, mais l’administrateur n’est plus connecté à l’interface d’administration, et tant que la session administrateur est ouverte, SOGo vous renvoie au tableau de bord administrateur. Mettre à jour mailcow signifie une session SSH et update.sh. Chaque nouveau domaine de courrier a besoin de ses enregistrements MX, SPF, DKIM et DMARC, définis à la main chez le fournisseur DNS. mailcow Toolkit corrige ces trois problèmes, dans votre propre mailcow, et continue de fonctionner après les mises à jour de mailcow.

Ce qu’il fait

SOGo avec n’importe quelle boîte aux lettres, en gardant la session administrateur

Le bouton SOGo dans la liste des boîtes aux lettres (pour l’administrateur de la plateforme uniquement ; les administrateurs de domaine gardent le bouton de mailcow) ouvre SOGo en tant que cette boîte aux lettres, dans un nouvel onglet. Votre onglet administrateur reste connecté.
SOGo tourne sur un nom d’hôte webmail séparé (par exemple webmail.example.com), donc il a son propre cookie de session, à part de l’interface d’administration.
La passation utilise un jeton à usage unique, valable 60 secondes et utilisé une seule fois. Sur l’hôte webmail, une nouvelle session de boîte aux lettres démarre ; elle n’hérite jamais du rôle administrateur.
Il utilise les règles propres à mailcow : il faut ALLOW_ADMIN_EMAIL_LOGIN=y et la permission Login as mailbox user, et les boîtes aux lettres inactives sont refusées.
Chaque utilisation est journalisée : dans le journal de connexion de cette boîte aux lettres dans mailcow (comme une connexion SSO) et dans le journal d’audit du Toolkit, avec qui l’a ouverte et depuis quelle adresse.
Sans nom d’hôte webmail, le bouton garde le comportement standard de mailcow.

Mettre à jour mailcow depuis l’interface d’administration

Une nouvelle page, System > Updates (Toolkit), affiche la version installée de mailcow, la dernière vérification et les nouveaux changements.
Le serveur cherche une nouvelle version de mailcow tous les jours et envoie un e-mail par nouvelle version à l’adresse définie sur la page.
Update now fait d’abord une sauvegarde (crypt, redis, rspamd, postfix et mysql, conservée 14 jours), puis exécute le update.sh propre à mailcow, puis attend que chaque conteneur fonctionne et que l’interface réponde. Le journal est affiché en direct sur la page.
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 l’indique et conserve le journal.
La page suit la langue de l’interface mailcow : anglais ou roumain.

Enregistrements DNS et Cloudflare

Nouveau dans 0.3.0 : la page System > DNS & Cloudflare (administrateurs uniquement) liste, pour chaque domaine mailcow et domaine alias, les enregistrements dont mailcow a besoin, d’après la vérification DNS propre à mailcow :

Required : l’enregistrement A de MAILCOW_HOSTNAME (DNS-only dans Cloudflare ; listé pour le domaine dont la zone contient le nom d’hôte), MX 10 vers MAILCOW_HOSTNAME, SPF, DKIM (le sélecteur et la clé de mailcow) et DMARC.
Recommended : les CNAME autodiscover et autoconfig (DNS-only), les enregistrements SRV pour autodiscover, IMAPS, submission et SMTPS, POP3S (quand POP3 est autorisé), CalDAV et CardDAV avec leur TXT path=/SOGo/dav/ (avec SOGo), et MTA-STS et TLS-RPT quand MTA-STS est actif pour le domaine dans mailcow.
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 téléversez (un export Cloudflare ou n’importe quel fichier BIND) et, avec des identifiants Cloudflare, à la zone Cloudflare live. L’état est OK, missing, different, proxied (doit être DNS-only), fix by hand ou unknown.
Download BIND zone file donne un fichier que Cloudflare importe (DNS > Records > Import and Export), avec cf_tags=cf-proxied:false sur les enregistrements qui doivent rester DNS-only.
IPv4 seul par défaut : pas d’enregistrement AAAA et un SPF en v=spf1 ip4:<IPv4> -all. Le réglage Use IPv6 ajoute AAAA, ip6: et la vérification du reverse DNS IPv6. Un serveur qui publie un AAAA sans reverse DNS IPv6 correspondant se voit rejeter son courrier en IPv6 par Gmail et d’autres.
DMARC : une politique valide existante est conservée ; sinon v=DMARC1; p=quarantine;, avec les rapports (rua) vers dmarc@ ou postmaster@ du domaine, uniquement quand cette adresse existe.
Les ports SRV (IMAPS 993, Submission 587, SMTPS 465, POP3S 995, HTTPS 443) suivent mailcow.conf et peuvent être définis à la main, pour les serveurs derrière un proxy ou du NAT.
Un état pour chaque domaine : la page 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 pas être livré ou envoyé, ou finira en spam : l’enregistrement A de l’hôte mail, MX, SPF, DKIM ou DMARC manquant, erroné ou proxifié, pas de clé DKIM, un reverse DNS erroné, ou le domaine pas encore connu de SOGo), warning (enregistrements facultatifs manquants : autodiscover, autoconfig, SRV, CalDAV / CardDAV, MTA-STS, TLS-RPT) ou all good. Le dernier domaine sélectionné est mémorisé. Pour chaque domaine, la page explique ce qui ne va pas et comment le corriger. Les états sont rafraîchis toutes les 10 minutes en arrière-plan ; Re-check now vérifie un domaine aussitôt.
Les actions Cloudflare d’un domaine n’apparaissent que lorsque les identifiants enregistrés fonctionnent et peuvent modifier le DNS dans la zone de ce domaine (jeton API : Zone > Zone > Read et Zone > DNS > Edit) ; sinon, la page indique pourquoi.
Cloudflare : avec un jeton API délimité (recommandé) ou le Global API Key, vous cochez des enregistrements, prévisualisez les changements et les appliquez. 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 va au 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 nouveaux domaines se configurent tout seuls

Configuration Cloudflare automatique (désactivée tant que des identifiants ne sont pas enregistrés) : dans un délai d’environ 2 minutes après 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 (désactivé tant qu’une destination n’est pas définie) : 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 en tant qu’alias vers une adresse de votre choix, pour ne pas compter dans la limite de boîtes aux lettres. noreply@ supprime le courrier silencieusement. Une boîte aux lettres ou un alias existant n’est jamais touché.
Les domaines qui existent déjà quand vous activez une fonctionnalité sont laissés tranquilles ; Provision now et Run wizard les traitent un par un.

SOGo et les nouveaux domaines

SOGo lit les domaines de mailcow au démarrage : un domaine ajouté plus tard lui est donc inconnu : ses boîtes aux lettres obtiennent « Unauthorized » dans SOGo et avec le bouton SOGo.
Nouveau dans 0.4.0 : toutes les 2 minutes, le Toolkit trouve ces domaines et redémarre uniquement le conteneur SOGo (et vide memcached), environ 3 à 10 minutes après l’ajout du domaine : une fois pour plusieurs nouveaux domaines, au plus toutes les 10 minutes, uniquement avec une licence valide. Chaque redémarrage va au journal d’audit.
Pendant qu’un domaine attend, la page DNS affiche un avertissement et un bouton Restart SOGo. L’option propre à mailcow Restart SOGo lors de l’ajout d’un domaine évite l’attente.

Vérification du reverse DNS (PTR)

Toutes les 6 heures (et sur Check now), le serveur vérifie que chaque IPv4 publique (et IPv6, avec Use IPv6) a un PTR égal à MAILCOW_HOSTNAME, et que MAILCOW_HOSTNAME se résout vers elle.
En cas d’échec, un ! rouge apparaît à côté du menu System sur chaque page d’administration et une ligne Reverse DNS (PTR) sur System > Information. La page vous dit comment la corriger : le PTR appartient à qui détient l’IP (votre hébergeur ou fournisseur de VPS, ou votre FAI), pas à votre zone DNS.

Licence, essai gratuit et mises à jour du Toolkit

La section License en haut de System > Updates (Toolkit) active le Toolkit avec votre clé de licence, ou lance l’essai gratuit de 30 jours avec votre adresse e-mail : la carte est demandée sur la page de paiement Stripe et n’est pas débitée pendant les 30 jours, et la page active le Toolkit dès le début de l’essai. L’essai peut être utilisé une fois par serveur et par adresse e-mail.
La licence est vérifiée au démarrage du serveur puis une fois par jour. Sans Internet, le Toolkit continue de fonctionner 7 jours après la dernière vérification réussie.
Sans licence valide, les fonctionnalités du Toolkit s’arrêtent : le bouton SOGo garde le comportement standard de mailcow, la vérification des mises à jour de mailcow, les e-mails et les mises à jour ne s’exécutent pas, les vérifications DNS, l’indicateur de reverse DNS, Cloudflare et l’assistant de nouveau domaine s’arrêtent, et les pages n’affichent que la section License ou un avertissement. Rien n’est supprimé ; une licence valide tout rallume.
Avec une licence valide, la même section met à jour le Toolkit vers la dernière version, ou revient à la version précédente : l’archive signée est téléchargée depuis medialab.works, sa taille et son SHA-256 sont vérifiés, l’agent hôte exécute l’installateur de cette version, et si cela échoue, la version actuelle est réinstallée. Les installations existantes reçoivent 0.4.0 ainsi.
Depuis 0.4.0, le paquet contient aussi Sign-up for mailcow (inscription en libre-service) et Cashier for mailcow (formules payantes via votre propre compte Stripe), chacun avec sa propre licence et son propre essai de 30 jours ; la page affiche une carte License par produit, et le pack mailcow couvre les trois avec une seule clé.

Survit aux mises à jour de mailcow

Le Toolkit ajoute ses propres fichiers à côté de ceux de mailcow et ne modifie aucun fichier suivi par mailcow : ses fichiers web sont exclus du git de mailcow, le dossier partagé vit là où le git de mailcow ne regarde pas, et l’agent hôte et ses timers tournent depuis systemd. Une mise à jour de mailcow conserve le Toolkit en place. Plusieurs installations mailcow sur un même hôte sont prises en charge.

Prérequis

mailcow-dockerized, testé avec 2026-09 et 2026-09a, sous Linux avec docker compose et systemd.
Un accès root sur l’hôte, avec git, jq, flock, curl, tar et sha256sum installés.
Le serveur doit atteindre medialab.works en HTTPS (vérification de licence, essai, mises à jour du Toolkit).
Pour SOGo en tant que boîte aux lettres : ALLOW_ADMIN_EMAIL_LOGIN=y dans mailcow.conf et la permission Login as mailbox user pour l’administrateur.
Un deuxième nom d’hôte pour le webmail, pointé vers mailcow via le même reverse proxy que l’interface mailcow.
Pour les sauvegardes avant les mises à jour : un dossier de sauvegarde sur l’hôte (--backup-dir).
Facultatif, pour écrire les enregistrements dans Cloudflare : un compte Cloudflare qui détient les zones des domaines, et un jeton API.

Questions fréquentes

Pourquoi SOGo me renvoie-t-il au tableau de bord administrateur ? Parce que mailcow conserve une seule session par nom d’hôte : avec la session administrateur ouverte, la session de la boîte aux lettres ne peut pas exister à côté d’elle sur le même hôte. Le Toolkit ouvre SOGo sur un nom d’hôte webmail séparé, où la boîte aux lettres obtient sa propre session. Voir le guide.

Cela modifie-t-il des fichiers de mailcow ? Aucun fichier suivi de mailcow n’est modifié. sudo ./uninstall.sh retire tout ce que le Toolkit a ajouté ; les sauvegardes de mailcow sont conservées.

Que se passe-t-il quand la licence se termine ? Les fonctionnalités du Toolkit s’arrêtent et mailcow fonctionne comme avant le Toolkit : le bouton SOGo rebascule la session administrateur, les mises à jour se font par SSH, et les enregistrements DNS ne sont plus vérifiés ni écrits. Rien n’est supprimé, dans mailcow ni dans Cloudflare. Renouvelez la licence, ou saisissez une nouvelle clé, dans la section License.

Puis-je mettre à jour sans sauvegarde ? Si vous installez sans --backup-dir, Update now s’exécute sans sauvegarde au préalable. Nous recommandons de définir un dossier de sauvegarde.

Ai-je besoin de Cloudflare ? Non. Sans identifiants Cloudflare, la page DNS liste toujours les enregistrements, les compare au DNS public et à un fichier de zone que vous téléversez, et vous donne un fichier de zone BIND à importer. Cloudflare n’est nécessaire que pour écrire les enregistrements tout seuls.

Peut-il supprimer ou casser mes enregistrements DNS ? Il ne crée ou met à jour que les enregistrements qu’il liste, et ne supprime jamais un enregistrement. Une sauvegarde JSON de la zone est enregistrée avant chaque modification, et Undo these changes l’annule (elle ne retire que les enregistrements que ce changement a créés, s’ils n’ont pas été modifiés depuis). La configuration automatique conserve une politique SPF, DMARC ou TLS-RPT que vous avez déjà.

Pourquoi n’y a-t-il pas d’enregistrement AAAA ni de ip6: dans le SPF ? Parce que l’IPv6 est désactivé par défaut : si un serveur publie un AAAA sans reverse DNS IPv6 correspondant, Gmail et d’autres rejettent son courrier en IPv6. Activez Use IPv6 une fois le reverse DNS IPv6 défini.

Licence

Le Toolkit est open source (GPL-3.0), comme mailcow lui-même. Ce que vous achetez, c’est l’abonnement aux nouvelles versions, aux mises à jour et au support pour un serveur mailcow : le Toolkit avec sa vérification de licence, chaque nouvelle version tant que l’abonnement est actif, et de l’aide quand quelque chose ne fonctionne pas. Le Toolkit est fait de scripts shell, de PHP et de JavaScript : vous recevez donc le code source complet. Voir la section 11 de la Licence (CLUF).

mailcow Toolkit est notre propre code, écrit par MediaLab Works ; il ne contient aucun code tiers. Il s’exécute dans mailcow-dockerized et utilise les fonctions propres à mailcow (sessions, permissions, update.sh, le script de sauvegarde, la création d’alias) ; mailcow est un projet open source distinct (GPL-3.0) de The Infrastructure Company GmbH, voir Droits d’auteur. Cloudflare est un service distinct, utilisé uniquement avec votre propre compte et vos propres identifiants.

mailcow Toolkit