mailcow Toolkit — guide

Avant de commencer

mailcow-dockerized sous Linux (testé avec 2026-09 et 2026-09a), installé par exemple dans /opt/mailcow-dockerized.
Un accès root sur l’hôte et ces commandes : docker avec docker compose, git, jq, flock, curl, tar, sha256sum et systemd.
Du HTTPS sortant vers medialab.works depuis le serveur (vérification de licence, essai, mises à jour du Toolkit).
Votre clé de licence, depuis votre compte medialab.works, ou une adresse e-mail pour l’essai gratuit de 30 jours.
Un deuxième nom d’hôte pour le webmail (par exemple webmail.example.com) dans le DNS, et un reverse proxy capable de le servir.
Un dossier pour les sauvegardes, par exemple /srv/backup/mailcow.
Facultatif, pour DNS et Cloudflare : un compte Cloudflare qui détient les zones de vos domaines. Pour trouver les adresses publiques du serveur, le Toolkit interroge ip4.mailcow.email et ip6.mailcow.email (comme la vérification DNS propre à mailcow).

Installation

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

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

--mailcow-dir : où mailcow-dockerized est installé (par défaut /opt/mailcow-dockerized).
--webmail-url : l’adresse du webmail, https:// + nom d’hôte (un port facultatif est autorisé). Sans lui, le bouton SOGo garde le comportement standard de mailcow.
--backup-dir : où vont les sauvegardes avant les mises à jour. Sans lui, Update now s’exécute sans sauvegarde au préalable (l’installateur vous avertit).
--name : uniquement si vous avez plusieurs installations mailcow sur le même hôte : un nom par installation (lettres, chiffres et -).

L’installateur place les fichiers web dans data/web de mailcow (exclus du git de mailcow), le dossier partagé dans data/hooks/phpfpm/.mlw-toolkit, l’agent hôte dans /usr/local/sbin/mlw-mailcow-agent-<name>, les réglages dans /etc/mlw-mailcow-toolkit/<name>.conf, une copie de la version installée dans /var/lib/mlw-mailcow-toolkit/<name>/package, et active cinq unités systemd : une qui exécute les requêtes de l’interface d’administration, un timer qui vérifie la licence et cherche une nouvelle version de mailcow au démarrage du serveur puis une fois par jour, mlw-mailcow-rdns-<name>.timer, qui vérifie le reverse DNS toutes les 6 heures, et mlw-mailcow-domains-<name>.timer, qui cherche les nouveaux domaines mailcow toutes les 2 minutes (il ne fait rien tant que la configuration automatique Cloudflare et l’assistant de nouveau domaine sont désactivés tous les deux) et, depuis 0.4.0, mlw-mailcow-accounts-<name>.timer, qui exécute les tâches de Sign-up for mailcow et de Cashier for mailcow toutes les 5 minutes. Depuis 0.4.0, le paquet installe aussi Sign-up et Cashier (leurs tables mlw_su_* et mlw_ca_* dans la base de données de mailcow) ; ils restent désactivés tant que chacun n’a pas sa propre licence. À la fin, il recharge php-fpm et vérifie la licence ; tant que la licence n’est pas active, il vous dit d’ouvrir la section License.

Mettre à jour le Toolkit : depuis la section License (voir ci-dessous), ou en exécutant à nouveau install.sh depuis la nouvelle version. Votre ancienne adresse webmail et votre dossier de sauvegarde sont conservés si vous les laissez de côté. La mise à jour vers 0.3.0 depuis la section License active aussi les deux nouveaux timers ; la page DNS & Cloudflare apparaît alors dans le menu System.

Licence et essai gratuit

Ouvrez System > Updates (Toolkit) (administrateurs uniquement). La section License en haut affiche l’état de la licence et fonctionne même sans licence :

Enter your license key et appuyez sur Activate. La clé se trouve dans votre compte medialab.works.
Ou lancez l’essai gratuit de 30 jours : saisissez votre adresse e-mail, choisissez mensuel ou annuel pour après l’essai et appuyez sur Start the free trial. Ouvrez la page de paiement Stripe depuis le lien affiché : la carte y est demandée et n’est pas débitée pendant les 30 jours. Si l’adresse a déjà un compte medialab.works, le lien lui est envoyé par e-mail à la place. La page active alors le Toolkit dès le début de l’essai. L’essai peut être utilisé une fois par serveur et par adresse e-mail.
Depuis 0.4.0, la page affiche une carte License par produit (License · mailcow Toolkit, License · Sign-up for mailcow, License · Cashier for mailcow), chacune avec sa propre clé et son propre essai. Une clé du pack mailcow est saisie dans chaque carte. Les mises à jour du paquet peuvent être lancées depuis la carte de n’importe quel produit avec une licence valide. Voir le guide de Sign-up et le guide de Cashier.
Avec une licence active, la section affiche la clé (partiellement masquée), le type, la date de fin, la dernière vérification, jusqu’à quand le Toolkit fonctionne sans connexion, et l’identifiant de ce serveur. Check now vérifie aussitôt (au plus deux fois par heure, avec les mises à jour et les retours en arrière).
Remove from this server (après avoir coché la confirmation) libère la licence pour que vous puissiez l’utiliser sur un autre serveur mailcow ; le Toolkit s’arrête ici.

La licence est vérifiée au démarrage du serveur puis une fois par jour. Si medialab.works est injoignable, le Toolkit continue de fonctionner 7 jours après la dernière vérification réussie.

Sans licence valide (aucune pour l’instant, expirée, retirée, déplacée vers un autre serveur, ou non vérifiée depuis plus de 7 jours), 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 la page n’affiche que la section License. Rien n’est supprimé.

Mettre à jour le Toolkit ou revenir à une version antérieure

Avec une licence valide, la section License affiche la version installée et la dernière version publiée :

Update the Toolkit to x.y.z télécharge l’archive signée depuis medialab.works, vérifie sa taille et son SHA-256, et la place dans la file de l’agent hôte, qui la vérifie à nouveau, exécute le install.sh de cette version et conserve la version précédente : si l’installation échoue, la version précédente est réinstallée. La page affiche la progression et se recharge une fois terminé.
Roll back to x.y.z fait de même avec la version précédente autorisée par votre licence.

Si votre licence ne couvre pas la version installée (par exemple une licence à vie dont la période de mises à jour s’est terminée avant cette version), le Toolkit s’arrête et la section License propose le bouton Roll back to pour la dernière version que votre licence permet, ainsi que le lien pour renouveler le pass de mises à jour.

Le nom d’hôte webmail

SOGo en tant que boîte aux lettres ne fonctionne que sur un nom d’hôte différent de celui de l’interface mailcow, car le navigateur conserve un cookie de session par nom d’hôte.

Pointez le nom d’hôte webmail (par exemple webmail.example.com) vers votre serveur dans le DNS.
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.
Donnez-lui un certificat TLS, comme à l’interface.

Activer SOGo en tant que boîte aux lettres

Dans mailcow.conf, mettez ALLOW_ADMIN_EMAIL_LOGIN=y, puis appliquez-le depuis le dossier mailcow avec docker compose up -d.
Assurez-vous que l’administrateur a la permission Login as mailbox user.

Ensuite, dans E-Mail > Configuration, onglet Mailboxes, le bouton SOGo à côté d’une boîte aux lettres ouvre un nouvel onglet sur l’hôte webmail, connecté à SOGo en tant que cette boîte aux lettres. Votre onglet administrateur reste connecté. Le lien derrière le bouton fonctionne une seule fois et seulement pendant 60 secondes ; si un onglet affiche This link has expired, cliquez à nouveau sur SOGo depuis la liste des boîtes aux lettres.

Le bouton est réservé à l’administrateur de la plateforme : les administrateurs de domaine gardent le bouton SOGo de mailcow. Les boîtes aux lettres inactives sont refusées.

Ce qui est journalisé : chaque utilisation apparaît 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 (qui a ouvert quelle boîte aux lettres, quand et depuis quelle adresse).

Mettre à jour mailcow

Avec une licence valide, System > Updates (Toolkit) affiche, sous la section License :

la version installée et la dernière vérification (Up to date ou Update available, avec les nouveaux changements) ;
la dernière exécution (en cours, terminée ou échouée) avec son message ;
le journal de la dernière mise à jour.

Check now cherche aussitôt une nouvelle version ; sinon, le serveur vérifie une fois par jour.

Update now est disponible quand la dernière vérification a trouvé une nouvelle version. Après votre confirmation, il exécute, dans cet ordre :

une sauvegarde de crypt, redis, rspamd, postfix et mysql dans votre dossier de sauvegarde, avec le script de sauvegarde propre à mailcow ; les sauvegardes de plus de 14 jours sont supprimées. Si la sauvegarde échoue, la mise à jour s’arrête et rien n’est modifié ;
le update.sh de mailcow ;
une attente pouvant aller jusqu’à 5 minutes jusqu’à ce que chaque conteneur fonctionne et que l’interface réponde.

Pendant la mise à jour, les conteneurs redémarrent : le courrier et l’interface sont donc indisponibles quelques minutes. La page continue d’afficher le journal et se recharge d’elle-même au retour du serveur. Quand la mise à jour se termine, un e-mail est envoyé à l’adresse de notification.

Notifications

Sur la même page, sous Notifications, saisissez l’adresse qui doit recevoir les e-mails et enregistrez. Le serveur envoie alors un e-mail par nouvelle version de mailcow (pas un par jour) et un quand une mise à jour se termine. Une adresse vide désactive les e-mails.

DNS et Cloudflare

Ouvrez System > DNS & Cloudflare (administrateurs uniquement). Sans licence valide, la page n’affiche qu’un avertissement et rien ne s’exécute en arrière-plan.

État des domaines

En haut, une ligne récapitulative (combien de domaines sont critiques ou ont des avertissements) et un sélecteur de Domain avec chaque domaine mailcow et domaine alias, les pires d’abord, chacun avec son état. La page mémorise le dernier domaine sélectionné.

critical : le courrier ne peut pas être livré ou envoyé, ou finira en spam : l’enregistrement A (ou AAAA) de l’hôte mail, MX, SPF, DKIM ou DMARC manquant, erroné ou proxifié ; pas de clé DKIM dans mailcow ; un reverse DNS erroné du serveur ; ou le domaine pas encore connu de SOGo (voir SOGo et les nouveaux domaines ci-dessous).
warning : des enregistrements facultatifs manquent : autodiscover, autoconfig, SRV, CalDAV / CardDAV, MTA-STS, TLS-RPT.
all good : tout ce dont le domaine a besoin est en place.

La vue du domaine liste What needs attention, les critiques d’abord, avec pourquoi c’est important et How to fix it, puis le fichier de zone, les actions Cloudflare du domaine, l’assistant et le tableau complet des enregistrements. Les états sont rafraîchis toutes les 10 minutes en arrière-plan ; Re-check now vérifie le domaine sélectionné aussitôt. Les réglages de tous les domaines (reverse DNS, identifiants Cloudflare et automatisation, ports de service, l’assistant, SOGo) se trouvent dans des sections repliables ci-dessous.

Les enregistrements de chaque domaine

Le tableau des enregistrements du domaine sélectionné affiche ce dont mailcow a besoin pour lui, d’après la vérification DNS propre à mailcow :

required : l’enregistrement A de MAILCOW_HOSTNAME, pour le domaine dont la zone contient le nom d’hôte (DNS-only dans Cloudflare, car SMTP et IMAP ne peuvent pas passer par le proxy de Cloudflare) ; MX 10 → MAILCOW_HOSTNAME ; SPF ; DKIM avec le sélecteur et la clé de mailcow ; DMARC ;
recommended : les CNAME autodiscover et autoconfig → MAILCOW_HOSTNAME (DNS-only ; un enregistrement A avec l’IP du serveur à la place est accepté) ; les enregistrements SRV _autodiscover, _imaps, _submissions, _submission, _pop3s (quand POP3 est autorisé), _caldavs et _carddavs avec un TXT path=/SOGo/dav/ (quand SOGo est activé) ; avec MTA-STS actif pour le domaine dans mailcow, le CNAME mta-sts, le TXT _mta-sts et l’enregistrement TLS-RPT _smtp._tls ;
pour un domaine alias : MX, SPF, DKIM (la ligne reste unknown tant que mailcow n’a pas de clé pour lui), DMARC et, avec MTA-STS, les enregistrements TXT _mta-sts et _smtp._tls.

Le SPF proposé est v=spf1 ip4:<IPv4> -all. Quand un SPF existe déjà et ne couvre pas le serveur, la proposition y ajoute l’adresse du serveur et conserve le reste ; quand il repose sur include ou redirect, la page vous dit de le vérifier.

DMARC : un enregistrement DMARC valide que vous avez déjà est conservé tel quel. Sinon, la proposition est v=DMARC1; p=quarantine;, avec rua=mailto:dmarc@<domain> (ou postmaster@<domain>) uniquement quand cette adresse existe dans mailcow. Les rapports TLS-RPT vont vers tls-rpt@ ou postmaster@ du domaine.

Chaque ligne est comparée avec trois sources : le public DNS, une zone importée (si vous en avez téléversé une) et la zone Cloudflare (avec les identifiants). L’état est OK, missing, different, proxied — must be DNS-only, fix by hand (par exemple des enregistrements A là où le CNAME devrait être, ou plusieurs enregistrements SPF) ou unknown (pas encore de clé DKIM dans mailcow, ou IPv4 publique pas encore connue).

Fichier de zone : export et import

Download BIND zone file enregistre les enregistrements du domaine en fichier de zone. Dans Cloudflare, importez-le depuis DNS > Records > Import and Export > Import DNS records : les enregistrements qui doivent rester DNS-only portent cf_tags=cf-proxied:false. Les lignes encore unknown sont omises.
Compare with a zone file lit un export Cloudflare (DNS > Records > Import and Export > Export) ou n’importe quel fichier de zone BIND, jusqu’à 1 Mo, et ajoute une colonne Imported zone à la comparaison. Forget the imported file le supprime.

IPv4 et IPv6

Par défaut, le Toolkit fonctionne en IPv4 seul : pas d’enregistrement AAAA, ip4: seul dans le SPF, et le reverse DNS IPv6 n’est pas vérifié. Un serveur qui publie un AAAA sans reverse DNS IPv6 correspondant se voit rejeter son courrier en IPv6 par Gmail et d’autres. Quand le reverse DNS IPv6 du serveur est défini, activez Use IPv6 (publish AAAA, SPF ip6, check the IPv6 rDNS) et enregistrez.

Ports de service

La carte Service ports (SRV records) définit les ports que les enregistrements SRV annoncent : IMAPS (993), Submission (STARTTLS, 587), SMTPS (465), POP3S (995) et HTTPS (443, pour autodiscover, CalDAV et CardDAV). Chaque champ est facultatif (1–65535). Laissé vide, le port vient de mailcow.conf quand c’est un nombre simple, ou c’est le port standard quand mailcow.conf lie une adresse comme 127.0.0.1:12587 (un proxy ou du NAT est devant) ; un HTTPS vide utilise le port de la page d’administration. Sous chaque champ, la page affiche le port utilisé et d’où il vient. L’export, la comparaison et Cloudflare (manuel et automatique) utilisent tous ces ports.

Identifiants Cloudflare

Les actions Cloudflare d’un domaine (la colonne live, l’aperçu et l’application, Provision now) n’apparaissent que lorsque les identifiants enregistrés fonctionnent maintenant et peuvent modifier le DNS dans la zone de ce domaine ; sinon, la page indique pourquoi (pas d’identifiants, connexion refusée, la zone pas dans le compte ou pas dans les ressources de zone du jeton, ou Zone > DNS > Edit manquant). Run wizard fonctionne sans Cloudflare.

Dans la carte Cloudflare, choisissez l’une des options :

API token (recommandé) : dans Cloudflare, My Profile > API Tokens > Create Token, avec Zone > DNS > Edit et Zone > Zone > Read sur toutes les zones. N’ajoutez Zone > Zone > Edit que si le Toolkit peut créer les zones manquantes. Si un tel jeton fuite, il peut changer les enregistrements DNS et rien d’autre, et il peut être révoqué seul.
Global API Key avec l’e-mail du compte : il fonctionne aussi, mais il peut tout faire dans tout le compte Cloudflare (facturation, membres, chaque produit). Utilisez-le uniquement si vous acceptez ce risque.

Check and save vérifie d’abord les identifiants auprès de Cloudflare. Ils sont stockés chiffrés (AES-256-GCM) dans le dossier du Toolkit sur votre serveur ; la clé est conservée dans le redis de mailcow, pas à côté du fichier, donc une copie du dossier ou des sauvegardes de mailcow ne les révèle pas. Ils ne sont plus jamais affichés : la page montre seulement le type et les 4 derniers caractères. Remove the credentials les supprime et désactive la configuration automatique. Les identifiants restent sur votre serveur et ne sont envoyés qu’à l’API de Cloudflare.

Appliquer les enregistrements à Cloudflare

Sélectionnez le domaine. Les enregistrements requis et ceux affichés comme proxifiés sont cochés ; cochez ou décochez les autres.
Preview changes for Cloudflare liste ce qui serait créé ou mis à jour, avec la valeur maintenant et après.
Apply to Cloudflare enregistre d’abord une sauvegarde JSON de toute la zone, puis crée ou met à jour uniquement ces enregistrements. Rien n’est supprimé. Si la zone a changé depuis l’aperçu, rien n’est appliqué et vous prévisualisez à nouveau ; un aperçu expire après 15 minutes.

Chaque sauvegarde est listée sous Cloudflare backups : Download enregistre le JSON, Undo these changes annule ce changement (les enregistrements mis à jour retrouvent leurs anciennes valeurs ; les enregistrements créés sont supprimés, uniquement s’ils n’ont pas été modifiés depuis). Chaque application et annulation est écrite dans le journal d’audit du Toolkit.

Configuration automatique des nouveaux domaines

Avec des identifiants enregistrés, activez Configure new mailcow domains in Cloudflare by themselves. Ensuite, dans un délai d’environ 2 minutes après l’ajout d’un domaine ou d’un domaine alias dans mailcow (depuis l’interface ou l’API), le Toolkit place ses enregistrements dans la zone Cloudflare existante :

il attend jusqu’à 10 minutes la clé DKIM de mailcow ; sans elle, il définit les autres enregistrements et ajoute DKIM plus tard (il réessaie toutes les heures) ;
les enregistrements manquants sont créés et les erronés mis à jour ; l’enregistrement A de l’hôte mail et les CNAME sont définis DNS-only ;
les enregistrements qu’il ne gère pas ne sont jamais supprimés ; une politique SPF, DMARC ou TLS-RPT existante et différente est left as it is (existing policy) et signalée (l’aperçu manuel peut encore la mettre à jour) ;
une sauvegarde de la zone est enregistrée avant chaque modification, comme pour l’application manuelle ;
si la zone n’est pas dans Cloudflare, le domaine affiche zone missing. Avec Create the zone in Cloudflare if it does not exist (nécessite Zone > Zone > Edit ou le Global API Key), le Toolkit la crée et affiche les Cloudflare nameservers à définir chez votre registreur. Quand les identifiants voient plusieurs comptes Cloudflare, Cloudflare account for new zones choisit le compte (par défaut le premier) ;
avec E-mail the notification address when provisioning fails, un échec est envoyé par e-mail à l’adresse sous Notifications sur la page Updates (Toolkit) ; le Toolkit réessaie après 15 minutes.

Les domaines qui existent déjà quand vous activez cela sont laissés tranquilles : utilisez Provision now à côté d’un domaine pour le configurer de la même manière.

Assistant de nouveau domaine

La carte New domain wizard: role addresses crée, pour chaque nouveau domaine mailcow, les adresses de rôle en tant qu’alias mailcow, pour qu’elles ne comptent pas dans la limite de boîtes aux lettres du domaine :

les adresses : postmaster, abuse, hostmaster, webmaster, contact, info, office, dmarc, tls-rpt, noreply, security, chacune facultative, plus vos propres parties locales (séparées par des virgules) ;
Destination (all role addresses) : où elles livrent ; chaque domaine peut avoir sa propre destination dans sa vue (vide = la destination globale) ;
dmarc@ et tls-rpt@ peuvent aller vers une adresse reports séparée ;
noreply@ utilise le « discard silently » de mailcow (null@localhost) : le courrier qui y arrive est accepté puis supprimé.

Activez Create the role addresses for new domains by themselves (il faut une destination). L’assistant s’exécute avant la configuration Cloudflare, donc les enregistrements DMARC et TLS-RPT d’un nouveau domaine envoient leurs rapports à ses dmarc@ et tls-rpt@. Une adresse qui existe déjà comme boîte aux lettres ou alias n’est jamais touchée : elle est ignorée et signalée. Les domaines alias sont ignorés, car mailcow les mappe déjà sur les adresses du domaine cible. Les alias sont créés avec les fonctions propres à mailcow, donc ils apparaissent dans le journal de mailcow. Les domaines qui existaient quand vous avez activé l’assistant sont laissés tranquilles : utilisez Run wizard à côté d’un domaine.

SOGo et les nouveaux domaines

SOGo lit les domaines de mailcow au démarrage. Un domaine ajouté plus tard lui est inconnu : ses boîtes aux lettres obtiennent « Unauthorized » dans SOGo et dans le bouton SOGo du Toolkit jusqu’au redémarrage de SOGo (l’échec de recherche est aussi conservé dans memcached).

Avec une licence valide, le Toolkit vérifie toutes les 2 minutes si SOGo connaît chaque domaine mailcow. Quand il en manque un, il redémarre uniquement le conteneur SOGo et vide memcached, environ 3 minutes après le premier domaine manquant (pour que plusieurs nouveaux domaines partagent un redémarrage) et au plus une fois toutes les 10 minutes : en pratique, environ 3 à 10 minutes après l’ajout du domaine. Les sessions webmail sont interrompues quelques secondes. Chaque redémarrage est écrit dans le journal d’audit.

Pendant qu’un domaine attend, la page DNS affiche un avertissement avec un bouton Restart SOGo (le même bouton se trouve dans la section SOGo, avec le dernier redémarrage). Si vous cochez l’option propre à mailcow Restart SOGo lors de l’ajout du domaine, SOGo le connaît aussitôt et aucun second redémarrage ne suit.

Reverse DNS (PTR)

Les autres serveurs de courrier vérifient que chaque IP publique de votre serveur a un enregistrement PTR égal à MAILCOW_HOSTNAME, et que MAILCOW_HOSTNAME se résout vers la même IP (forward-confirmed reverse DNS). Le Toolkit vérifie cela toutes les 6 heures pour chaque IPv4 publique (et IPv6, avec Use IPv6) ; Check now sur la page DNS l’exécute aussitôt.

Quand la vérification échoue, un ! rouge apparaît à côté du menu System sur chaque page d’administration, et une ligne Reverse DNS (PTR) sur System > Information. Sans Use IPv6, une adresse IPv6 ne la déclenche jamais.

Pour la corriger : l’enregistrement PTR d’une IP appartient à qui détient l’IP, pas à votre zone DNS. Définissez-le dans le panneau de contrôle de votre hébergeur ou fournisseur de VPS (souvent « Reverse DNS » ou « PTR » à côté de l’IP), ou demandez à votre FAI, exactement vers MAILCOW_HOSTNAME. Puis assurez-vous que MAILCOW_HOSTNAME a un enregistrement A avec la même IP (DNS-only dans Cloudflare).

Le serveur trouve ses adresses publiques via ip4.mailcow.email / ip6.mailcow.email, sinon depuis ses interfaces réseau. Derrière un NAT ou avec plusieurs adresses, listez-les dans RDNS_IPS (voir Réglages).

Réglages

/etc/mlw-mailcow-toolkit/<name>.conf (le nom par défaut est default) contient :

BACKUP_DIR : le dossier de sauvegarde (vide = pas de sauvegarde avant la mise à jour, non recommandé) ;
BACKUP_COMPONENTS : ce qui est sauvegardé, par défaut crypt redis rspamd postfix mysql ;
BACKUP_KEEP_DAYS : combien de temps les sauvegardes sont conservées, par défaut 14 ;
RDNS_IPS : les IP publiques à vérifier pour le reverse DNS, séparées par des espaces, par exemple RDNS_IPS="203.0.113.10" (vide = les adresses détectées) ;
SOGO_DELAY et SOGO_MIN_GAP : l’attente avant de redémarrer SOGo pour un nouveau domaine et le délai minimal entre deux redémarrages, en secondes (par défaut 180 et 600).

Vos modifications de ce fichier sont conservées quand vous réinstallez ou mettez à jour le Toolkit depuis la section License ; seul BACKUP_DIR change, et uniquement si vous passez --backup-dir. Les choix DNS et Cloudflare sont enregistrés depuis la page, pas dans ce fichier, et sont conservés.

Retirer le Toolkit

sudo ./uninstall.sh --mailcow-dir /opt/mailcow-dockerized

Il arrête et supprime les unités systemd (timers inclus), les réglages, l’agent, la copie conservée du Toolkit et les fichiers web, et nettoie la liste d’exclusion git de mailcow. Le dossier partagé part aussi, avec les identifiants Cloudflare chiffrés et les sauvegardes de zone Cloudflare : téléchargez d’abord les sauvegardes que vous voulez garder. Vos enregistrements DNS dans Cloudflare restent tels quels. Les sauvegardes de mailcow sont conservées. Les tables de Sign-up et Cashier restent dans la base de données de mailcow, et les boîtes aux lettres, domaines et administrateurs de domaine qu’elles ont créés restent dans mailcow. Ajoutez --name si vous avez installé avec un nom. Appuyez d’abord sur Remove from this server dans la section License si vous voulez utiliser la licence sur un autre serveur.

Problèmes courants

Le bouton SOGo bascule toujours ma session administrateur. Aucune adresse webmail n’a été donnée à l’installation, l’adresse webmail a le même nom d’hôte que l’interface, ou la connexion de SOGo en tant que boîte aux lettres n’est pas autorisée (ALLOW_ADMIN_EMAIL_LOGIN=y et la permission Login as mailbox user). Exécutez à nouveau install.sh avec --webmail-url et vérifiez les deux réglages.

La page Updates indique que l’agent hôte n’est pas installé ou ne fonctionne pas. Exécutez à nouveau install.sh ; vérifiez systemctl status mlw-mailcow-agent-default.path.

La page n’affiche que la section License. La licence n’est pas valide : le message en haut indique pourquoi (pas encore de clé, expirée, retirée ou déplacée, ou non vérifiée depuis plus de 7 jours). Dans le dernier cas, vérifiez que le serveur atteint https://medialab.works, puis appuyez sur Check now.

La mise à jour a échoué. La page indique à quelle étape (sauvegarde, update.sh ou vérification des conteneurs) et conserve le journal. Après une sauvegarde échouée, rien n’a été modifié. Après un update.sh ou une vérification des conteneurs en échec, lisez le journal et corrigez la cause comme vous le feriez après avoir exécuté update.sh à la main.

Il y a un ! rouge à côté du menu System. La vérification du reverse DNS a échoué : ouvrez System > DNS & Cloudflare, section Reverse DNS (PTR) of the server, pour voir quelle IP et pourquoi. Définissez le PTR chez votre hébergeur / fournisseur de VPS ou votre FAI, puis appuyez sur Check now.

Cloudflare a refusé les identifiants. Vérifiez les permissions du jeton (Zone > DNS > Edit et Zone > Zone > Read sur toutes les zones) ou, pour le Global API Key, l’e-mail du compte. Le message de Cloudflare est affiché sur la page.

Un domaine affiche « zone missing ». Le domaine n’est pas une zone dans le compte Cloudflare que les identifiants voient. Ajoutez-le dans Cloudflare, ou activez Create the zone in Cloudflare if it does not exist ; le Toolkit réessaie toutes les heures, ou appuyez sur Provision now.

L’enregistrement SPF ou DMARC était « left as it is (existing policy) ». La configuration automatique ne remplace jamais une politique que vous avez déjà. Sélectionnez le domaine, cochez l’enregistrement et utilisez Preview changes for Cloudflare si vous voulez la valeur du Toolkit.

Les boîtes aux lettres d’un nouveau domaine obtiennent « Unauthorized » dans SOGo. SOGo ne connaît pas encore le domaine : la page DNS affiche un avertissement ; attendez quelques minutes le redémarrage automatique ou appuyez sur Restart SOGo.

Je n’ai reçu aucun e-mail. Vérifiez qu’une adresse est enregistrée sous Notifications ; un e-mail est envoyé par nouvelle version, pas chaque jour.