Skip to main content
Une fois le binaire installé, oximail setup met le serveur en route. L’assistant génère la configuration, la clé DKIM, la première organisation et le compte administrateur, écrit une unité systemd, démarre le service, séquestre la clé du serveur et vérifie le tout par une ronde doctor. L’assistant est le chemin recommandé pour un premier démarrage. Chaque action peut aussi être lancée depuis un fichier de setup ou comme sous-commande distincte pour les déploiements automatisés.
Cette page décrit ce que fait réellement l’assistant dans OxiMail v0.30.0, étape par étape, dans l’ordre d’exécution. Lorsqu’une étape est conditionnelle ou facultative, c’est précisé. Les étapes que l’assistant ne fait pas sont listées à la fin.

​
Lancer l’assistant

Par défaut, l’assistant lit et écrit la configuration du serveur dans /etc/oximail/oximail.toml. Il doit ouvrir des ports privilégiés et écrire dans /etc/oximail et /var/lib/oximail. Lancez-le donc en tant que root. Options : Codes de sortie : 0 terminé, 1 terminé mais la vérification a signalé un point dégradé, 2 échec franc (vérification en échec, ou refus avant toute écriture), 130 annulé par l’opérateur (Échap puis Quit, Ctrl-C, ou refus d’écraser une configuration existante), 143 arrêté par SIGTERM. Une exécution annulée ne sort jamais en 0 : oximail setup … && systemctl start oximail s’arrête là. L’assistant prend tout l’écran sur un terminal capable (un terminal aux deux bouts, TERM défini et différent de dumb, au moins 80×24) : un dialogue par question, les étapes listées à gauche, les sondes, la revue et la sortie du moteur dans le corps. Échap demande s’il faut quitter, et quitter est propre : rien n’est écrit avant que la revue soit confirmée, et le terminal est rendu à chaque sortie. Tout ce qu’imprime l’assistant plein écran va aussi dans /var/log/oximail-setup.log (dans le répertoire temporaire quand ce fichier ne peut pas s’ouvrir) : rien de ce que l’écran a montré n’est perdu quand il se ferme. Tant que l’écran est ouvert, tout autre texte écrit sur le terminal (une commande que l’assistant lance, un avis d’une autre partie du programme) va dans le même panneau et le même journal, jamais par-dessus l’écran. --no-tui est la sortie de secours devant un TERM qui promet plus que le terminal ne sait faire ; --config-file et les sous-commandes tournent toujours en ligne. Si /etc/oximail/oximail.toml existe déjà, l’assistant prévient et demande s’il faut l’écraser. Si vous refusez, le setup est annulé et la configuration existante est conservée.

​
Déroulé interactif (serveur principal)

L’assistant avance par étapes : Checks, Identity, Topology, Configuration, Review, Apply, Start, Recovery, Doctor, Import. Toutes les questions viennent avant la revue ; rien n’est écrit tant que la revue n’est pas confirmée.

​
Contrôles de la machine et préalables

L’assistant commence par mesurer la machine et l’affiche : la distribution, si systemd est le système d’init, la mémoire, l’espace libre sur le volume de /var/lib/oximail, l’architecture. Ce sont des recommandations, jamais un refus : une distribution hors de celles qui sont testées (Debian 12 et 13, Ubuntu 24.04), moins de 2 Gio de mémoire ou moins de 10 Gio libres s’affichent comme des avertissements. Ensuite, avant l’un ou l’autre chemin (interactif ou --config-file), et avant d’écrire quoi que ce soit, il fait trois contrôles préalables. Un essai à blanc ne mesure rien, donc ne bloque rien.
  • L’horloge. Il lit l’état de l’horloge du noyau et refuse quand aucune source de temps ne la discipline : un serveur de courrier dont l’heure est fausse échoue en silence et tard (signatures DKIM entrantes refusées comme datées du futur, renouvellements ACME et validité TLS cassés, fenêtres de jetons et de fail2ban qui expirent de travers). Dans un conteneur, la correction se fait sur l’hôte (chrony sur l’hyperviseur) ; un timedatectl qui affiche NTP service: inactive dans le conteneur est attendu. oximail setup --accept-unmanaged-clock continue malgré tout et consigne l’acquittement dans l’état de l’assistant.
  • Le volume. Il remonte la pile device-mapper sous le chemin des données et refuse un volume nu : depuis ADR-148, la base, les blobs et l’index de recherche sont écrits en clair, et le volume chiffré est la seule protection au repos. Il continue si le volume est chiffré, continue sans rien affirmer s’il ne peut pas mesurer, et sinon imprime la configuration de référence en six points et s’arrête. oximail setup --accept-bare-volume lève le refus en connaissance de cause : le consentement est écrit sous la forme [security] storage_encryption_attested = true, et doctor continue de mesurer.
  • Le résolveur. Le serveur pose toutes ses questions DNS à unbound sur 127.0.0.1 et ne croit une réponse DNSSEC qu’une fois ce résolveur prouvé. L’assistant fait passer la sonde du serveur lui-même : l’identité que l’installation a écrite dans la configuration d’unbound, la racine validée, une zone non signée qui ne l’est pas, les zones qui ne valident pas refusées, les dénis d’existence prouvés. Si elle échoue, l’assistant refuse : DANE serait aveugle (voir authentification du courrier). Le serveur lui-même ne refuse jamais de démarrer pour une raison de résolveur, mais tant que sa propre sonde n’a pas prouvé le résolveur, il ne croit aucune réponse DNSSEC et retient le courrier vers les domaines DANE. Il n’y a pas de « continuer quand même ». Sous Debian, l’assistant propose de l’installer : apt-get update, unbound avec son ancre de confiance racine (dns-root-data), et la configuration qui porte l’identité de la machine (un unbound déjà en service garde sa propre configuration, le fichier s’ajoute à côté). Il vérifie ensuite le résolveur (actif, à l’écoute sur la boucle locale, ancre de confiance présente, sonde réussie) avant de toucher à /etc/resolv.conf, et ordonne oximail.service après unbound.service. Le serveur ne lit jamais /etc/resolv.conf ; les autres programmes de la machine le lisent. L’assistant le réécrit pour ne nommer que 127.0.0.1, en gardant l’ancien contenu à côté, là où la réécriture tient : un fichier ordinaire, le lien de systemd-resolved, ou un conteneur Proxmox une fois /etc/.pve-ignore.resolv.conf écrit par l’assistant. Sous resolvconf, NetworkManager ou cloud-init, qui régénèrent le fichier, il le laisse et imprime l’étape qui revient à ce gestionnaire. Une exécution avec --config-file n’installe qu’avec oximail setup --install-resolver. Sur un hôte sans apt-get, setup imprime la configuration unbound que la sonde reconnaît et l’endroit où la poser (le fichier, son include, /etc/resolv.conf, puis oximail resolver check), en gardant une identité déjà écrite. La configuration écrite par setup désactive le NSEC agressif (aggressive-nsec: no). Activé, il laissait un refus mis en cache avant la publication d’un enregistrement cacher cet enregistrement pendant tout le TTL négatif de la zone (1800 s chez Cloudflare), au-delà du plafond de cinq minutes. Une box installée par un binaire antérieur garde son ancien texte : oximail doctor le signale (resolver_config), et oximail resolver ensure nomme la première ligne qui diffère, puis avec --apply réécrit le fichier (identité gardée), le vérifie et redémarre unbound (sortie 0 à jour ou réécrit, 1 réécriture en attente, 2 échec ; --json).

​
Identité et topologie

  1. Domaine de messagerie principal (par exemple example.com), c’est-à-dire la partie domaine de vos adresses.
  2. Nom d’hôte du serveur de messagerie (par défaut mail.<domaine>). Les deux noms sont contrôlés à la saisie : lettres, chiffres et tirets seulement (pas de tiret en début ni en fin d’étiquette), étiquettes de 1 à 63 caractères, 253 au total, deux étiquettes au moins. Ils sont mis en minuscules et le point final est retiré ; un nom internationalisé est converti dans sa forme ASCII (bücher.example devient xn--bcher-kva.example). Un fichier de réponses et oximail setup dns suivent les mêmes règles.
  3. Mode de déploiement : Primary mail server (serveur principal), Backup MX (MX secondaire) ou Smarthost relay (dedicated hub) (hub de relais dédié). Le MX secondaire et le hub smarthost ont chacun leur propre déroulé, décrit plus bas.
  4. Topologie de déploiement : Direct (OxiMail gère le TLS sur le port 443) ou Behind reverse proxy (derrière un proxy inverse comme Caddy ou Nginx). L’option proxy demande aussi un port local de base (par défaut 8080 ; l’écouteur de défi ACME d’OxiMail écoute sur ce port + 1, et un port mal saisi est redemandé, jamais remplacé par un défaut) et le groupe système du proxy inverse (proposé : caddy, sinon www-data). Le proxy atteint la surface web d’OxiMail par un socket Unix que seul ce groupe peut ouvrir, jamais par un port TCP. Sur un port de loopback, chaque processus de la machine pouvait revendiquer une adresse client dans X-Forwarded-For, faire bannir quelqu’un par fail2ban ou obtenir une exemption trusted_ips.

​
Configuration

  1. Jeton d’API Cloudflare (laissez vide pour configurer le DNS à la main).
  2. Adresse de l’administrateur (par défaut admin@<domaine>) et, pour un déploiement direct, adresse ACME (Let’s Encrypt) (par défaut l’adresse de l’administrateur). Derrière un proxy inverse, l’adresse ACME n’est pas demandée (c’est admin@<domaine>), mais ACME reste actif : OxiMail commande le certificat des ports mail, et le proxy lui relaie le challenge HTTP-01.
  3. Mode d’envoi sortant : Direct ou Par un relais. L’assistant mesure d’abord ce qu’affronterait une remise directe : si le port 25 sortant est ouvert, le DNS inverse de l’IP publique (absent, non confirmé dans l’autre sens, ou nom par défaut d’un hébergeur compte comme faible), et si l’IP figure déjà sur une liste noire publique. Il recommande le relais dès que l’un des trois joue contre la remise directe (la plupart des clouds bloquent le port). Le port 25 sortant est affiché pour l’IPv4 et pour l’IPv6 séparément, avec le DNS inverse de l’adresse IPv6 : le courrier sort d’abord en IPv4, et en IPv6 seulement vers une destination qui n’a pas d’IPv4. Quand la sortie IPv4 de la box est une adresse NAT partagée qui n’est pas la sienne (voir l’étape DNS), le relais est recommandé : aucun enregistrement SPF ne peut autoriser cette adresse. Voir Relais sortant & smarthost pour tout le parcours relais, y compris le préflight de sortie pour repasser en direct plus tard. Cette question concerne le côté leaf (envoyer via un relais) ; elle est sautée sur le déroulé hub smarthost, les deux bouts d’un relais ne se confondant jamais.
  4. Fuseau horaire par défaut de l’organisation (un nom IANA). C’est le dernier étage de la chaîne de repli du calendrier (fuseau de l’événement → fuseau de l’utilisateur → fuseau de l’organisation → UTC) : les événements flottants se résolvent en heure locale plutôt qu’en UTC. Pour un serveur principal, la question est posée une seule fois, après le pays d’établissement : la valeur proposée est le fuseau du système hôte quand il est précis, sinon celui de ce pays (un serveur loué dit souvent UTC), sinon UTC ; un fuseau inconnu est redemandé. Pour un relais, elle est posée ici, avec le fuseau de l’hôte par défaut. Modifiable ensuite avec oximail tenant update --default-timezone.
  5. Origines du webmail sur un autre hôte (vide si aucune), écrites dans [server] allowed_origins.
  6. Rapports : Send reports? [y]es / [c]rashes only / [n]o / [d]etails, sans réponse présélectionnée : Entrée seule repose la question, d montre ce qui est envoyé. La réponse est enregistrée avant l’écriture de la configuration ; voir la télémétrie communautaire.
  7. Comment le serveur sera sauvegardé : Hypervisor snapshot (le défaut), oximail backup planifié, ou Later. Rien ici n’organise une sauvegarde ; la réponse s’écrit en [backup] strategy (hypervisor-snapshot, oximail-backup ou none), et oximail doctor signale un échec tant qu’aucun plan n’est déclaré, ou tant qu’un oximail backup planifié n’a pas tourné (sauvegardes).
Une extension que porte le binaire peut demander sa propre section d’oximail.toml : l’assistant la pose après ces questions, la montre dans la revue, et elle s’écrit avec le fichier du cœur.

​
Revue

L’assistant sonde les ports que cette configuration ouvrira (voir la vérification des ports plus bas), puis montre toute la configuration telle qu’un fichier de setup la porterait, secrets nommés mais jamais affichés, et propose trois choix : appliquer, enregistrer les réponses en setup.toml, puis appliquer (le fichier, en mode 0600, ne porte aucun secret : rejouez-le avec oximail setup --config-file une fois en place les références *_file qu’il nomme), ou abandonner, ce qui ne laisse rien d’écrit.

​
Étape : vérification des ports

L’assistant tente d’ouvrir chaque port requis en local et affiche OK ou FAIL avec la raison (permission refusée, port déjà utilisé, ouverture impossible). Les ports requis sont : Si vous avez choisi le proxy inverse, les ports 80 et 443 sont ignorés (le proxy les gère). Des ports bloqués n’arrêtent pas l’assistant, mais le serveur peut ne pas fonctionner tant qu’ils ne sont pas ouverts dans votre pare-feu. Un port déjà occupé nomme le processus qui le tient et son unité systemd, avec la commande qui le libère, et la revue présélectionne alors abandonner ; les ports que tient le service OxiMail lui-même, lors d’une nouvelle exécution, ne sont pas signalés comme bloqués.

​
Étape : répertoires de données

L’assistant crée /var/lib/oximail, /var/lib/oximail/blobs, /etc/oximail, /etc/oximail/dkim et /etc/oximail/tls. Il n’y a pas de /var/log/oximail : les journaux du serveur partent sur la sortie standard et sont captés par journald.

​
Étape : DNS

L’assistant établit quelles adresses publiques sont celles du serveur, puis contrôle les enregistrements DNS du domaine et affiche un rapport réussite/échec.
  • IPv6 : une adresse IPv6 globale est portée par la box elle-même ; elle est prise telle que détectée.
  • IPv4 : l’adresse vue de l’extérieur n’est celle du serveur que si elle est sur l’une de ses interfaces, ou si une redirection vers la box est prouvée. Deux preuves, toutes deux en lecture seule : une connexion à cette adresse sur le port 25 revient à la box avec un jeton à usage unique (boucle NAT), ou la table UPnP du routeur envoie le port 25 à la box. Rien n’est jamais écrit sur le routeur. Sans preuve, l’assistant demande si le routeur redirige les ports du courrier vers cette machine, « non » par défaut. Pour une sortie partagée (un NAT utilisé par d’autres services), ni enregistrement A ni ip4: dans le SPF ne sont publiés : le serveur est publié et autorisé en IPv6 seulement.
  • Si aucune adresse ne peut être détectée, l’assistant vous demande d’en saisir une.
  • Avec un jeton Cloudflare, il peut créer les enregistrements manquants via l’API Cloudflare : A, MX (priorité 10), SPF, DMARC, MTA-STS (TXT et CNAME), TLS-RPT, les CNAME autoconfig et autodiscover, un enregistrement CAA qui limite l’émission de certificats à Let’s Encrypt, et des enregistrements SRV pour l’autoconfiguration des clients (_autodiscover, _imaps, _submission, _caldavs, _carddavs). Si un enregistrement MX en conflit existe, il demande avant de le remplacer. Un enregistrement SPF ou DMARC déjà publié n’est jamais doublé (deux SPF font échouer le contrôle de tous les destinataires) : un enregistrement identique est laissé, un enregistrement différent est affiché. Pour le SPF, l’assistant propose un seul enregistrement qui garde vos mécanismes et votre all et ajoute ceux de ce serveur, et ne le publie que si vous acceptez ; un DMARC n’est remplacé que si vous acceptez. Il revérifie ensuite le DNS, après avoir vidé le cache du résolveur local pour la zone (unbound-control flush_zone). La vérification faite avant la publication avait mis en cache « ce nom n’existe pas », et la revérification puis la vérification de fin d’installation déclaraient absents, jusqu’à cinq minutes, les enregistrements qui venaient d’être publiés. Le jeton est aussi écrit dans /etc/oximail/cloudflare.token (mode 0600, propriété de l’utilisateur du service), et la configuration reçoit [dns] provider = "cloudflare" avec ce fichier et l’identifiant de zone, résolu par l’API : le serveur republie ainsi les enregistrements TLSA de DANE à chaque émission et chaque renouvellement du certificat.
  • Sans jeton, il affiche les résultats du contrôle et vous indique de créer les enregistrements vous-même ; le résumé final rappelle de publier les enregistrements TLSA après chaque certificat (oximail dane publish).

​
Étape : DKIM

L’assistant génère une paire de clés DKIM RSA (sélecteur default) dans /etc/oximail/dkim/<domaine>.default.key et affiche l’enregistrement DNS à publier. Si un jeton Cloudflare a été fourni, il publie aussi l’enregistrement TXT DKIM sur default._domainkey.<domaine> (en supprimant d’abord tout enregistrement obsolète pour ce sélecteur). La clé publiée est au format SPKI (v=DKIM1; k=rsa; p=...).
La publication DKIM via Cloudflare n’a lieu qu’à l’intérieur de l’assistant complet. Les domaines ajoutés plus tard, ou les installations sans jeton Cloudflare, n’ont aucun enregistrement TXT DKIM publié automatiquement. Générez et publiez ces enregistrements à la main (voir la section Génération de clé DKIM plus bas).

​
Étape : fichier de configuration

La réponse aux rapports est enregistrée d’abord, dans le marqueur de consentement à côté de l’identifiant d’installation (/var/lib/oximail/.telemetry_consent.json). L’assistant écrit ensuite /etc/oximail/oximail.toml pour un serveur principal. Contenu principal :
  • [server] : nom d’hôte, URL de base, adresses d’écoute (direct : 0.0.0.0:443 et 0.0.0.0:80 ; proxy : bind = "unix:/run/oximail-http/jmap.sock" et http_bind = "127.0.0.1:<port + 1>" pour le défi ACME, sans trusted_proxies, puisque le pair sur le socket est le proxy et que son X-Forwarded-For est le client), et la surface d’administration sur 127.0.0.1:9090.
  • [storage] : SQLite dans /var/lib/oximail/data.db, blobs dans /var/lib/oximail/blobs (SQLite ordinaire ; la protection au repos est celle du volume).
  • [security] storage_encryption_attested = true seulement si vous avez lancé setup --accept-bare-volume : l’assistant mesure le volume sous le chemin des données et refuse un volume nu sans ce consentement.
  • [auth] default_tenant = "default".
  • [mode] role = "primary".
  • [smtp] : ports d’écoute et un bloc [[smtp.dkim_keys]] pour le couple domaine/sélecteur.
  • [tls] : ACME activé dans les deux topologies (derrière un proxy, pour les ports mail ; le proxy garde le certificat des noms web). Sur une box directe, acme_domains porte le nom d’hôte, avec en dessous les noms mta-sts., autoconfig. et autodiscover. en commentaire : une commande ACME échoue en bloc sur un nom qui ne résout pas encore.
  • [legacy] : IMAP, CalDAV et CardDAV activés.
  • [spam], [security] (fail2ban et IP de confiance), [rate_limit] et [logging] (JSON vers journald).
  • [metrics] dnsbl_self_ips avec l’IP publique que l’assistant a détectée, pour que doctor surveille l’adresse d’envoi sur les listes noires.
  • [dns] (avec un jeton Cloudflare, ci-dessus).
  • [admin] metrics_token_file = "/etc/oximail/metrics.token" : l’assistant crée un jeton aléatoire pour /metrics, si bien que le jeton d’administration n’ouvre plus les métriques (exploitation).
  • [backup] strategy, le plan déclaré.
  • [telemetry] enabled, à false si vous avez répondu non ; les commentaires renvoient à la page publique qui liste chaque champ du rapport et à oximail telemetry purge.
Pour un déploiement derrière un proxy inverse, l’assistant affiche un extrait de Caddyfile prêt à l’emploi (le chemin de défi ACME vers 127.0.0.1:<port + 1>, tout le reste vers unix//run/oximail-http/jmap.sock) et précise que les ports SMTP (25, 587, 465) et IMAP (993) écoutent en direct et ne passent pas par le proxy. Il dit aussi ce qu’est le proxy : il termine le TLS des noms qu’il sert et lit le trafic web en clair. Si une autre entité l’exploite, cette entité est un sous-traitant des données qu’il transporte. L’extrait fait passer tout le trafic vers OxiMail, à la seule exception du chemin de défi HTTP d’ACME. Une liste blanche de routes est volontairement écartée : une famille de routes oubliée casse en silence la découverte des clients ou le DAV. Quand le webmail est servi depuis une autre origine, l’assistant remplit aussi [server] allowed_origins ; le CORS est traité par OxiMail lui-même, jamais par le proxy (une interception globale des OPTIONS au proxy casse en silence la découverte des clients DAV). Pour ajuster ces valeurs ensuite, voir Configuration.

​
Étape : organisation et compte administrateur

L’assistant crée la première organisation (un tenant au sens du stockage : id default, nom Default, domaine déduit de l’adresse de l’administrateur), puis le compte administrateur. La création est idempotente : si elle existe déjà, l’assistant le signale et continue. Le mot de passe administrateur est demandé, avec confirmation. Il doit faire au moins 8 caractères et contenir une majuscule, une minuscule et un chiffre ; la saisie se répète tant que le mot de passe est trop faible. Le compte est créé avec le rôle admin et la langue fr, et l’organisation reçoit le fuseau demandé plus haut.
Tant qu’aucune organisation n’existe, le serveur démarre en mode assistant web (“no tenants”). L’assistant en ligne de commande crée toujours le tenant default avant le compte administrateur, donc un oximail setup terminé vous permet de vous connecter directement.

​
Étape : unité systemd

L’assistant écrit /etc/systemd/system/oximail.service. L’unité lance oximail serve --config /etc/oximail/oximail.toml, redémarre en cas d’échec, relève la limite de descripteurs de fichiers et envoie la sortie vers journald sous l’identifiant oximail. S’il ne peut pas écrire le fichier (pas root), il affiche le contenu de l’unité pour que vous l’installiez à la main. Voir Installation pour le détail de l’unité. Derrière un proxy, il écrit aussi /etc/tmpfiles.d/oximail-http.conf et crée tout de suite /run/oximail-http (setgid, groupe du proxy ; tmpfiles le recrée à chaque démarrage), et le ReadWritePaths de l’unité gagne ce répertoire. Un groupe qui n’existe pas fait échouer systemd-tmpfiles : l’assistant le dit, avec la ligne à corriger. Il écrit aussi oximail-health.service et oximail-health.timer, qui enregistrent la ronde doctor toutes les 15 minutes, et affiche la commande qui les active (systemctl enable --now oximail-health.timer) ; voir la ronde doctor. L’unité est écrite après l’étape organisation et administrateur, parce que cette étape crée la base et la clé serveur enveloppée, et que l’unité ne déclare LoadCredentialEncrypted= que pour une clé qui existe : écrite plus tôt, elle n’avait pas la directive et le service ne pouvait pas désenvelopper sa propre clé. L’utilisateur du service est créé avant le premier fichier qui lui est confié, et les données lui sont remises en dernier (data.db* en mode 0600), une fois tout écrit : une installation neuve démarre. L’assistant n’annonce « owner oximail » qu’une fois cette remise réussie.

​
Étape : démarrage du service

L’assistant exécute systemctl daemon-reload, systemctl enable oximail et systemctl start oximail, puis attend au plus 90 secondes que systemd donne le service actif et que le port 443 réponde (le certificat ACME est provisionné dans ce délai). Quand le service ne tourne pas, il le dit avec l’état que systemd rapporte et cite la dernière ligne d’erreur de l’unité ; il n’accuse ACME que si le service tourne et que le port 443 attend encore. Sur une box directe, il active ensuite dans acme_domains chacun des noms mta-sts., autoconfig. et autodiscover. qui résout déjà vers la box (l’étape DNS les a publiés quelques minutes plus tôt) et fait réémettre le certificat : le serveur en marche tient le port 80, il est donc redémarré et commande lui-même les noms, en gardant le certificat qu’il sert si cette commande échoue ; l’assistant attend le nouveau certificat 90 secondes au plus et dit ce qui s’est passé. Un serveur arrêté laisse le port à oximail cert renew --apply. Les noms qui attendent encore le DNS restent en commentaire, et le résumé les nomme. Le démarrage est un systemctl restart : relancé sur une box déjà installée, le service prend la configuration qui vient d’être écrite. Les ports qu’il tient ne sont pas signalés comme bloqués, et l’étape de topologie reconnaît son propre service sur le port 443 au lieu de supposer un reverse proxy.

​
Étape : vérification

Il se connecte aux ports 25, 587, 993 et 443, contrôle le point d’accès JMAP sur https://<nom-d-hote>/.well-known/jmap (un code 401 compte comme disponible) et confirme la présence du répertoire DKIM et du fichier de configuration. Une vérification en échec n’arrête pas l’exécution : les étapes de récupération, de doctor et d’import ont lieu, le résumé dit que la vérification a échoué, et l’exécution sort avec son code à la fin.

​
Étape : récupération

Le serveur vient de créer sa clé racine ; l’assistant la séquestre. Il montre la clé de secours une seule fois (en plein écran sur un terminal capable, jamais écrite dans le journal de l’assistant), vous demande de la retaper, ce qui prouve qu’elle a été notée et constitue l’exercice de récupération dont doctor suit l’âge, et termine par la commande scp qui emporte le blob de séquestre hors de la box. Une clé fausse est redemandée. La copie en clair de la clé, qui attendait le séquestre, n’est supprimée qu’une fois la clé retapée ; partir garde le séquestre et cette copie, dit que la clé n’a pas été confirmée et nomme oximail key purge-pending, qui vérifie la clé puis supprime la copie. oximail key escrow --guided rejoue la même cérémonie sur une box installée sans elle, et oximail doctor signale en échec un serveur sans séquestre (chiffrement au repos).

​
Étape : doctor

Le dernier contrôle est une ronde oximail doctor complète avec --reachability : les noms web et leurs certificats, cette box sur les listes noires, et le reste de la ronde, affichés en lignes avec leur décompte.

​
Étape : import facultatif de données

Enfin, l’assistant propose d’importer du courrier existant. Choix possibles : Skip (ignorer), From IMAP server (Dovecot, Exchange, Gmail, tout serveur IMAP4), From Stalwart (JMAP API) ou From mbox/Maildir files. Chaque choix demande les informations de connexion correspondantes. Cette étape a lieu après que le serveur est déjà configuré et démarré, donc un import en échec ne casse pas l’installation. Vous pouvez réessayer à tout moment avec oximail migrate. Voir Migration pour le flux d’import autonome.

​
Le résumé

L’assistant termine par ce qui survit à l’écran : l’URL de connexion (https://<nom-d-hote>/auth/login), le chemin de la configuration, la commande des journaux, l’issue de l’étape de récupération, les noms de certificat activés ou encore en attente, et ce qui reste à faire : DANE (automatique avec le fournisseur Cloudflare, oximail dane publish sinon), le point de métriques et le fichier de son jeton pour Prometheus, oximail doctor --reachability avec le décompte de la ronde, et le plan de sauvegarde (pour un instantané de l’hyperviseur, le hook vzdump qui confirme chaque passage par oximail backup mark --source hypervisor --apply). Ses dernières lignes disent comment un appareil reçoit ses réglages. Sur un iPhone, un iPad ou un Mac, ouvrez https://<hostname>/apple/mobileconfig?email=<adresse> et installez le profil que sert le serveur, prérempli avec l’adresse de l’administrateur (l’adresse est encodée en pourcentage dans le lien, car un + se lirait comme un espace ; le profil n’est pas signé). Thunderbird et Outlook n’ont besoin que de l’adresse : ils trouvent les réglages eux-mêmes par autoconfig et autodiscover (autodécouverte).

​
Déroulé MX secondaire

Si vous choisissez Backup MX comme mode de déploiement, l’assistant lance un déroulé dédié, par le même moteur qu’un fichier de setup. Il demande le nom d’hôte du MX principal (par défaut mail.<domaine>), les domaines de relais supplémentaires, le mode de transfert (queue pour accepter en local et réessayer vers le principal, avec rapports DSN en cas de rejet définitif ; ou proxy pour relayer en temps réel et propager la réponse du principal, avec repli sur queue si le principal est injoignable), l’adresse de l’administrateur, un jeton Cloudflare et la question des rapports. Après la revue, il crée le compte administrateur, écrit une configuration role = "backup", installe l’unité systemd, crée éventuellement ses enregistrements DNS par Cloudflare (son MX à côté de celui du principal, priorité 20, et ses A et AAAA, chacun lu d’abord et jamais doublé), et vérifie le port 25 et la configuration. Un MX secondaire ne signe rien pour le domaine et n’oriente aucun client vers lui-même. Le déroulé n’a donc aucune étape DKIM et ne publie aucun SRV client : la clé DKIM du domaine et ses enregistrements _imaps / _submission sont ceux du principal. Un assistant antérieur générait une clé au sélecteur default et, avec un jeton Cloudflare, remplaçait par elle la clé publique du principal : chaque message signé par le principal échouait alors au DKIM. Sans jeton, les instructions imprimées listent les mêmes enregistrements (MX, A, AAAA) et disent pourquoi il n’y en a pas d’autres.

​
Déroulé smarthost

Si vous choisissez Smarthost relay (dedicated hub), l’assistant exécute le même déroulé que le serveur principal avec des ajustements ciblés : un smarthost est un MTA sortant complet, pas un mode d’installation séparé (il n’y a délibérément aucun chemin de démarrage dédié). Ce qui change :
  • L’assistant demande la ou les IP d’egress du hub (séparées par des virgules). Seuls des littéraux IP sont acceptés : ils alimentent l’auto-surveillance DNSBL et l’enregistrement SPF publié, où un nom d’hôte ou une faute de frappe casserait silencieusement le SPF de tous les clients.
  • La configuration générée déclare role = "smarthost" sous [mode]. Le rôle ferme les surfaces boîtes aux lettres et n’ajoute aucun chemin de démarrage propre ; à chaque démarrage, le serveur avertit (via un signal d’audit de démarrage que votre supervision peut alerter) si [legacy] est encore actif ou si l’auto-surveillance DNSBL est vide. Un serveur combiné boîtes + hub reste en role = "primary".
  • Les surfaces boîtes aux lettres sont désactivées ([legacy] enabled = false) et [metrics] dnsbl_self_ips est rempli avec les IP d’egress.
  • L’enregistrement SPF du hub que les clients incluront (spf.<domaine> TXT "v=spf1 ip4:… -all") est publié via Cloudflare si vous avez fourni un jeton, ou imprimé pour publication manuelle. Ce nom appartient au hub : il est lu d’abord, un enregistrement identique est laissé, un v=spf1 différent est remplacé, et un second n’est jamais ajouté (deux SPF au même nom sont une permerror pour chaque domaine qui l’inclut).
  • Aucun compte relais n’est créé. Les clients relais entrent uniquement par des jetons frappés ; l’assistant imprime la commande oximail account relay mint-token comme étape suivante. Voir Relais sortant & smarthost pour tout le parcours hub.

​
Configuration non interactive

Pour des installations automatisées, écrivez un fichier TOML de setup et passez-le avec --config-file :
L’arborescence source livre config/setup.example.toml, la référence de chaque clé que le fichier accepte, avec son sens ; une clé inconnue est refusée. Le fichier comporte une section [server] (domain, hostname, éventuellement deploy_mode = "primary", "backup" ou "smarthost", topology = "direct" ou "proxy", proxy_port, proxy_group (le groupe système du proxy inverse, détecté en son absence), webmail_origins, public_ipv4 = "auto" | "forwarded" | "none" pour une box derrière un NAT, et le telemetry = "yes" | "crashes" | "no" obligatoire), ainsi que des sections facultatives [dns] (cloudflare_api_token_file ou cloudflare_api_token_env, cloudflare_zone_id, replace_existing_mx, replace_existing_spf, replace_existing_dmarc), [tls] (acme_email), [admin] (email plus password_file ou password_env, et un default_timezone optionnel), [relay] ou [relay_enrolment] pour un leaf qui envoie par un relais, [backup_plan] (strategy), [import] (source = "imap" | "jmap" | "mbox" | "skip" avec les champs de connexion correspondants), pour le mode secondaire, [backup] (primary_hostname, accepted_domains, mode, config_output_path) et, pour le déroulé smarthost, [smarthost] (egress_ips = ["203.0.113.25", …], validées comme littéraux IP, refus bruyant sinon). La section d’une extension se donne en [extension.<table>]. Un fichier de setup versionné ne porte aucun secret : un [admin] password, un [dns] cloudflare_api_token, un [relay] password ou un [relay_enrolment] token écrit en clair est refusé avant toute écriture. Une question à laquelle le fichier ne répond pas est refusée par son nom, jamais posée sur un tube : un fichier sans [server] telemetry arrête l’exécution et nomme la clé, de même qu’une box derrière un NAT dont le fichier laisse public_ipv4 sur "auto" quand rien ne prouve la redirection. Un cloudflare_api_token_file que le service ne peut pas lire (sous /root, /home ou /tmp, que son bac à sable masque, ou illisible pour l’utilisateur oximail) n’est pas écrit dans la configuration du serveur : le jeton est copié dans /etc/oximail/cloudflare.token (0600, propriétaire oximail), et l’exécution le dit. L’exécution démarre le service, puis le vérifie, comme l’assistant interactif. Avec --no-start, elle écrit tout, ne démarre rien et saute la vérification, en le disant. Les mêmes étapes s’exécutent sans question. S’il n’y a pas de section [admin], l’assistant ne crée pas le compte administrateur et vous indique d’en créer un avec oximail account create. Les mots de passe passés en mode non interactif sont quand même contrôlés en force, et un mot de passe trop faible interrompt l’exécution. Personne n’est là pour recevoir une clé de secours : le séquestre n’est donc pas créé, l’exécution le dit en dernier mot, et oximail doctor signale un échec tant que oximail key escrow --guided n’a pas tourné. Utilisez --dry-run avec l’une de ces commandes pour prévisualiser la configuration générée et les actions, sans rien écrire, démarrer ni vérifier.

​
Sous-commandes de setup individuelles

Chaque étape de l’assistant est aussi une sous-commande autonome sous oximail setup, pratique pour rejouer un seul morceau :
Toutes acceptent --dry-run. oximail setup dns tourne aussi sans terminal : un script, un agent ou un ssh sans tty peut republier les enregistrements d’une box. Des options répondent à chaque question qu’il peut poser : --replace-mx, --replace-spf (le SPF existant est fusionné quand c’est possible, vos mécanismes gardés), --replace-dmarc, et --public-ipv4 (auto mesure et demande quand rien ne prouve que l’adresse est celle de la box, ce qui est refusé sans terminal ; forwarded dit que le routeur renvoie ici les ports mail ; none publie en IPv6 seulement). Une IPv4 publique non tranchée arrête l’exécution avant toute lecture ou publication, en nommant l’option. Une question de remplacement à laquelle aucune option n’a répondu garde l’enregistrement existant et est nommée à la fin. Relancé sur une zone déjà configurée, il ne double rien. Il lit d’abord la zone et ne crée un enregistrement que là où la zone n’en a aucun de son espèce : un second TXT _mta-sts (qui laisse le domaine sans politique MTA-STS, RFC 8461 §3.1) ou un second enregistrement TLS-RPT ne peuvent plus apparaître, et un enregistrement MTA-STS est gardé quel que soit son id. Des MX qui désignent un autre serveur et que vous gardez sont les seuls MX du domaine : celui de ce serveur ne s’y ajoute pas. C’est la zone qui décide, pas les vérifications, car une vérification lit le cache d’un résolveur qui peut être en retard sur un enregistrement tout juste publié. --dry-run lit la zone et liste chaque enregistrement : à créer, déjà là, ou différent et gardé. L’exécution se termine en nommant les vérifications qui échouent encore. Codes de sortie : 0 fait, 1 il reste quelque chose (un enregistrement gardé faute de son option, une vérification en échec), 2 l’IPv4 publique non tranchée.

​
Génération de clé DKIM

Il existe aussi une commande DKIM de premier niveau (distincte de oximail setup dkim), celle qui est citée dans le démarrage rapide :
Cette commande génère la paire de clés dans /etc/oximail/dkim/ et affiche l’enregistrement DNS DKIM à publier. Elle ne publie pas l’enregistrement sur Cloudflare : seul l’assistant complet le fait, et seulement si un jeton est fourni. Publiez vous-même la valeur affichée v=DKIM1; k=rsa; p=... sur <sélecteur>._domainkey.<domaine>.

​
Démarrer et vérifier à la main

Si vous avez sauté l’étape de démarrage de l’assistant, ou installé l’unité à la main :
Relancez les contrôles de l’assistant à tout moment :

​
Ce que l’assistant ne fait pas

  • Il n’installe pas le binaire. Mettez d’abord oximail sur l’hôte ; voir Installation.
  • Il ne publie pas le DNS sans Cloudflare. Sans jeton Cloudflare, il affiche les enregistrements (ou les résultats du contrôle) à ajouter chez votre fournisseur.
  • Il ne publie pas le DKIM en dehors de l’assistant complet. Les commandes autonomes setup-dkim et setup dkim génèrent et affichent l’enregistrement, mais ne le poussent pas vers le DNS.
  • Il ne configure pas le DKIM ed25519. Seules des clés RSA-2048 sont générées et chargées à l’exécution.
  • Il ne gère pas votre pare-feu. La vérification des ports se contente de signaler les ports bloqués ; leur ouverture dans le pare-feu du VPS ou le groupe de sécurité reste manuelle.
  • Il n’organise pas la sauvegarde. Il enregistre le plan que vous déclarez ; l’hyperviseur ou un oximail backup planifié prend les copies, et doctor vérifie qu’elles ont lieu.
  • Il ne crée pas d’organisations ni de comptes supplémentaires. Il provisionne exactement un tenant default et un compte administrateur. Ajoutez-en d’autres avec oximail tenant create et oximail account create.

​
Étapes suivantes