Skip to main content
Cette page explique le modèle de configuration d’OxiMail : d’où viennent les paramètres, ce qui doit figurer dans le fichier par rapport à ce qui peut changer en cours d’exécution, et comment un changement à l’exécution prend effet. C’est la page centrale vers laquelle pointent les sections de configuration de chaque fonctionnalité. Pour la liste exhaustive des clés d’un domaine précis, consultez l’exemple de configuration et la page d’administration correspondante.

Le modèle : base TOML, surcharges en base

OxiMail ne stocke pas toute sa configuration en base de données. Il lit un fichier TOML au démarrage comme base, puis applique par-dessus des surcharges optionnelles par organisation stockées en base, pour le réglage en cours d’exécution sans redémarrage. C’est l’ADR-007. L’ordre de recherche d’un paramètre est le suivant :
  1. La surcharge en base (si elle existe pour cette clé) l’emporte.
  2. Le fichier TOML sert de repli, et reste la source de vérité pour tout le reste.
La raison est l’exploitabilité. Un fichier TOML peut se lire avec cat, se versionner dans git, se copier avec scp et s’éditer en SSH. Une configuration entièrement en base ne le permet pas, et elle crée un problème de poule et d’oeuf : la base doit être configurée avant de pouvoir lire la configuration qui configure la base. OxiMail garde le fichier comme base de référence et n’utilise la base que pour les surcharges à l’exécution.
Le fichier TOML reste toujours la source de vérité pour le démarrage et la reprise après incident. Si vous perdez les surcharges en base, le serveur démarre quand même à partir du fichier. L’inverse n’est pas vrai.

Paramètres de démarrage et paramètres d’exécution

Tous les paramètres ne peuvent pas être une surcharge en base. Tout ce dont OxiMail a besoin avant l’ouverture de la base doit venir du fichier. C’est la règle de la poule et de l’oeuf :
Ne jamais mettre la configuration de démarrage uniquement en base.
Paramètres de démarrage (TOML uniquement), nécessaires avant d’ouvrir le stockage et de se mettre à l’écoute, ou pour le faire :
  • [storage] sqlite_path, blob_path, search_path, encrypted : où et comment vit la base elle-même.
  • [server] bind, http_bind, admin_bind, hostname, base_url : les sockets d’écoute et l’identité du serveur.
  • [smtp] bind, submission_bind, smtps_bind, hostname : les sockets d’écoute SMTP.
  • [auth] default_tenant.
Ces paramètres décrivent la façon dont le processus démarre. En faire une surcharge en base n’aurait aucun sens, car le serveur ne peut pas lire la base tant qu’ils n’ont pas déjà été appliqués. Paramètres d’exécution (surchargables), ce que vous pouvez vouloir ajuster sur un serveur en marche. L’ensemble est fermé et le serveur le publie : auth.session_lifetime_secs, auth.refresh_reuse_leeway_secs, erasure.reversal_ttl_days, blob_gc.derived_sweep, retention.trash_days (par locataire, dès 1 jour) et les plafonds rate_limit.* (HTTP par IP et par compte, connexions par compte, budgets des surfaces anonymes, soumission SMTP par locataire, entrant par IP, destinataires de relais par jour, destinataires sortants par heure). retention.chat_days et calendar.working_hours_enforce en font partie aussi, tout comme les six horizons de corbeille, drive., calendar., contacts., tasks., notes. et chat.trash_retention_days (par locataire ; absent veut dire la valeur de l’instance, 0 veut dire pas de purge, voir les horizons par locataire). Les seuils fail2ban et les options [spam] ne sont pas surchargeables : ils demandent un redémarrage. Voir Définir une surcharge à l’exécution.
Quelques paramètres sont volontairement réglables au redémarrage seulement, même s’ils ressemblent à des réglages d’exécution. Par exemple, le secret SRS ([srs] secret_key_file) est lu une fois au démarrage et ne se recharge pas à chaud, donc sa rotation impose un redémarrage. Quand une section est réglable au redémarrage seulement, sa page d’administration le précise.

Les secrets vivent hors du TOML

Le fichier de configuration est suivi, sauvegardé, copié en .bak-* par le rail de déploiement et cité en clair dans journald. Aucun secret n’y figure : chaque secret est un fichier sidecar que le TOML désigne, une ligne, mode 0600, propriété de l’utilisateur du service ; illisible ou vide est fatal au démarrage. Les clés de sidecar sont [[smtp.dkim_keys]] key_path, [[smtp.transport_maps]] auth_password_file, [dns] cloudflare_api_token_file, [dns] rfc2136_tsig_key_file, [admin] metrics_token_file, [srs] secret_key_file et previous_secret_key_file, et [meet] turn_shared_secret_file. Le serveur refuse de démarrer sur un [srs] secret_key, previous_secret_key, [meet] turn_shared_secret ou [dns] rfc2136_tsig_key écrit en ligne, et le refus nomme le geste à faire. Avant de mettre en place un binaire qui porte ce refus, lancez sur chaque box :
Le verbe écrit chaque valeur dans un sidecar 0600 à côté du TOML (srs.secret, srs.previous.secret, turn.secret, rfc2136.tsig), le confie à l’utilisateur du service, sauvegarde le TOML en oximail.toml.pre-externalize-<ts>, ne réécrit que les lignes concernées sous leur forme _file, puis rejoue tous les validateurs de démarrage sur le résultat. Un sidecar existant qui porte une autre valeur n’est jamais écrasé. oximail doctor vérifie ensuite que l’utilisateur du service peut lire chaque sidecar.

Rechargement à chaud

Les surcharges à l’exécution sont conçues pour prendre effet sans redémarrer le processus. Le mécanisme est ArcSwap, un échange atomique de pointeur sans verrou (ADR-016) : le composant conserve un Arc vers son état courant, et un rechargement échange atomiquement un nouvel Arc. Les lecteurs ne sont jamais bloqués. Les requêtes en cours se terminent sur l’ancienne valeur, et toute lecture suivante voit la nouvelle. Ce mécanisme sert aux composants rechargeables à chaud : les certificats TLS (pour qu’un renouvellement ACME s’applique sans redémarrage), la liste de blocage anti-spam, les surcharges de configuration à l’exécution et les scripts Sieve compilés. Comme les lectures ne sont jamais verrouillées, le rechargement à chaud n’a aucun coût mesurable sur le chemin des requêtes : un renouvellement ou une surcharge est un simple échange de pointeur, et les rechargements sont rares.

Définir une surcharge à l’exécution

Les surcharges à l’exécution sont stockées par organisation (un tenant au sens du stockage) et définies via l’API REST d’administration. Voir l’API d’administration pour l’authentification (chaque point d’accès d’administration exige le jeton porteur d’administration configuré sous [admin] token). Pour définir une ou plusieurs surcharges, envoyez PUT /admin/v1/config avec un corps JSON dont l’objet overrides associe chaque clé de configuration à sa nouvelle valeur :
Chaque paire clé/valeur est écrite dans le magasin de surcharges du locataire par défaut ; PUT /admin/v1/tenants/{id}/config prend le même corps pour un autre locataire (API d’administration). Les valeurs conservent leur type JSON (un nombre reste un nombre, une chaîne reste une chaîne). Une clé hors de l’ensemble publié est refusée avec unknownKeys et la liste knownKeys, jamais stockée : une faute de frappe ne devient pas un réglage silencieux. Une valeur que le serveur ne lirait pas telle qu’écrite (un horizon de corbeille hors de 0 à 36500, par exemple) est refusée avec details, et rien de la requête n’est écrit. GET /admin/v1/config renvoie les surcharges en vigueur et knownKeys. Depuis la CLI, oximail config get-override|list-overrides|set-override|clear-override lisent et écrivent par locataire (--tenant-id), simulation par défaut, --apply écrit (CLI) ; set-override refuse les valeurs que ce point d’accès refuse, simulation comprise, avec les mêmes details et une sortie 2.

Le fichier de configuration et sa structure

Le serveur lit /etc/oximail/oximail.toml par défaut. Les sous-commandes du CLI et la commande serve acceptent --config <chemin> pour pointer ailleurs. L’assistant de configuration écrit ce fichier pour vous au premier démarrage ; cette page sert à l’ajuster ensuite. Un fichier annoté représentatif ressemble à ceci. Il n’est pas exhaustif. Il montre la structure et les sections les plus courantes. Voir les pages d’administration de chaque fonctionnalité pour l’ensemble des clés de chaque domaine.

Les vraies sections de premier niveau

Les sections que lit le serveur sont : [server], [storage], [auth], [mode], [smtp] (avec les tableaux [[smtp.dkim_keys]], [[smtp.transport_maps]] et [[smtp.egress_pool]], ce dernier dans l’envoi en masse), [tls], [spam], [security], [rate_limit] (avec la table [rate_limit.destination_domains]), [dmarc_reports], [feedback_reports], [complaint_feedback] (envoi en masse), [contacts], [quota], [branding], [rights], [logging], [admin], [telemetry], [backup], [erasure], [geocode], [image_proxy], [pgp_directory], [legacy], [passkey], [mta_sts], [dns], [sieve], [distribution_groups], [scheduler], [chat], [calendar], [drive], [tasks], [notes], [meet], [srs], [metrics], [push], [bimi], [smime] et [federation]. Une clé inconnue dans l’une d’elles fait refuser le fichier ; une section hors de cette liste est journalisée comme configuration morte au démarrage, sauf si une extension que porte le binaire la revendique. Les pages de chaque fonctionnalité documentent les clés de chacune :

[bimi] : logos de marque des expéditeurs externes

Depuis le 2026-09-20, le serveur résout le logo de marque d’un expéditeur externe dont le message a passé DMARC sous une politique contraignante et dont le domaine publie un indicateur de marque adossé à un certificat de marque que le serveur valide lui-même (chaîne vers un jeu de racines embarqué, listes de révocation, transparence des certificats). Le logo arrive aux clients par la même propriété brandLogoBlobId qui porte déjà le logo de votre organisation pour les expéditeurs internes ; ceux-ci gardent le vôtre. À côté, brandMarkType nomme le type de certificat derrière un logo externe (registered_mark ou government_mark pour un certificat de marque vérifiée, VMC ; prior_use_mark, modified_registered_mark ou provisional_mark pour un certificat de marque commune, CMC ; null pour votre propre logo), ce qui permet à un client de n’afficher le signe « marque vérifiée » que pour un VMC. Un en-tête BIMI-Selector n’est honoré que si la signature DKIM alignée DMARC qui a passé le couvre ; un domaine expéditeur résout au plus huit sélecteurs par jour.
Par organisation, la clé de surcharge bimi.external_resolution_enabled (allumée par défaut) éteint la fonction pour cette organisation seulement : ses messages ne sont plus résolus ET ses liens déjà écrits ne sont plus servis. oximail doctor rend compte de la base de confiance (bimi_trust : chaque racine, AC émettrice ou clé de journal qui cesse d’être utilisable sous 90 jours est nommée) et des caches (bimi_cache). Un fichier de confiance que vous nommez et qui ne se charge pas est fatal au démarrage : la base embarquée ne lui est jamais substituée en silence. Le résolveur travaille à l’ingestion : les messages déjà en boîte quand il a démarré n’ont pas de logo. oximail bimi backfill --account <email> rapporte, par domaine expéditeur, les messages de ce compte qui qualifieraient (mêmes portes que le chemin vivant, aucune requête réseau) ; --apply les résout et les lie. Un compte par passage.

[federation] : la porte qu’appellent les organisations appairées

Désactivée tant que la section n’est pas écrite ; une fois écrite, enabled est obligatoire : une section [federation] sans elle est refusée, jamais lue comme désactivée. Activée, elle monte /jmap/federation (le temps occupé et les dossiers du Drive partagés pour les organisations appairées), et endpoint et tls_pins sont ce que oximail federation identity lit à l’autre administrateur (fédération).
Avec enabled = true, le serveur refuse de démarrer sans point d’entrée en /jmap/federation, avec un réglage de cache hors de ses bornes, ou quand l’adresse enregistrée d’un pair tombe dans [security] trusted_ips. check-config n’exécute pas ces vérifications ; doctor rapporte les bornes du cache (federation_content_cache).

Valider une configuration avant le déploiement

OxiMail échoue de façon visible sur une mauvaise configuration : plutôt que de démarrer dans un état à moitié cassé, il refuse de démarrer et indique ce qui ne va pas. Vous pouvez exécuter les mêmes validateurs à l’avance, sans démarrer le serveur :
Cela détecte par exemple un serveur primaire sans clé de signature DKIM, dane_enabled activé sans fournisseur DNS, et des clés DKIM antérieures à la v0.30 encore présentes dans le fichier. Voir la Référence du CLI pour la liste complète des commandes et Exploitation pour le travail au quotidien.

Étapes suivantes