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 :- La surcharge en base (si elle existe pour cette clé) l’emporte.
- Le fichier TOML sert de repli, et reste la source de vérité pour tout le reste.
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.
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.
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 :
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 estArcSwap, 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 :
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 :
- Messagerie & SMTP :
[smtp], cartes de transport, clés DKIM. - Authentification & sécurité des e-mails :
[mta_sts],[dns],[srs];[smime](verify,revocation,trust_roots,trust_intermediates,sweep_secs: vérification des signatures reçues) ;[pgp_directory](la recherche de clés OpenPGP). - Exploitation :
[backup] strategy(sauvegardes),[telemetry](télémétrie communautaire),[admin] metrics_token_file. - Conformité :
[erasure] ledger_hook(effacements et restaurations). - Anti-spam :
[spam]. - Boîtes & stockage :
[storage]. - Chiffrement au repos :
[storage] encrypted. - TLS & ACME :
[tls]. - Protocoles hérités :
[legacy]. - Filtrage :
[sieve](le script global de l’exploitant). - Multi-tenant :
[auth], les plafonds de capacité[chat]et les surcharges par organisation. - Fédération :
[federation](plus bas). - Chat :
[chat] transcript_policy, qui peut faire transcrire un message vocal par le serveur :"on-demand"(le défaut, le premier membre qui le demande),"always"(à l’ingestion, par un moteur que seule une build étendue porte) ou"never"(ChatMessage/transcriberépondforbidden). - Conformité : les règles de journalisation (stockées en base, gérées par CLI/JMAP, pas en TOML) et la surcharge par organisation
erasure.reversal_ttl_days. - JMAP Core / authentification : les réglages DPoP de
[auth](dpop_nonce_required,dpop_resource = "off" | "monitor" | "require").
[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.
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).
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 :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
- Premier démarrage & assistant de configuration : ce que l’assistant écrit dans ce fichier.
- API d’administration : le point d’accès qui définit les surcharges à l’exécution.
- Exploitation : journaux, sauvegardes et mises à jour.
- Référence du CLI : toutes les sous-commandes
oximail.