Les journaux
Le serveur écrit sur stdout et journald capture ; il n’y a pas de/var/log/oximail :
tracing structurés (account_id, tenant_id, method, error), et les messages décrivent ce qui s’est réellement passé, pas ce qui était prévu : une règle dure du projet. Le contexte de diagnostic est volontairement attribuable : une session IMAP qui sonde un dossier inexistant journalise le compte et l’adresse du pair, un SQLITE_BUSY nomme la table et l’opération concernées.
Les journaux de poignée de main TLS
Les quatre écouteurs qui terminent TLS (IMAPS, IMAP STARTTLS, SMTPS, SMTP STARTTLS) séparent deux événements qui partageaient jusqu’ici un unique avertissement :- Un pair parti avant d’avoir rien négocié. Un contrôle de disponibilité TCP, un scan de port, un client qui renonce. Ce n’est pas un échec et ce n’est plus journalisé comme tel : la ligne descend d’un niveau, garde son pair et son texte d’erreur, et
RUST_LOG=debugen restitue toujours chaque octet. - Un vrai échec de négociation. Aucune suite de chiffrement ni aucun groupe en commun, un message malformé, une alerte reçue, un certificat refusé. Cela reste un avertissement, parce que c’en est un.
reason stable. Accrochez votre supervision à ce champ plutôt qu’au texte du message.
Ce qui justifie la distinction : une instance de production émettait 480 de ces avertissements par jour pour une seule sonde de supervision qui ouvrait le 993 toutes les trois minutes et raccrochait. Un avertissement qui se déclenche 480 fois par jour de façon parfaitement inoffensive n’est pas une gêne esthétique : il entraîne à ignorer la catégorie entière, et un vrai échec de poignée de main s’y cache ensuite, même port, même message, même niveau. Cela compte surtout juste après un changement des groupes négociés, dont le mode de panne est exactement une poignée de main qui cesse d’aboutir avec un client incompatible.
Les deux branches de délai explicite (120 s en IMAPS, 30 s en STARTTLS) restent des avertissements : un pair qui tient une connexion deux minutes sans conclure est rare et mérite réellement un coup d’œil.
Les métriques
Un point Prometheus est servi sur la surface d’administration à/metrics (authentifié par bearer, comme le reste de l’API d’administration). Les jauges qui méritent une alerte :
Les métriques par organisation peuvent gagner une étiquette
domain (config [metrics]) ; laissez-la désactivée sauf besoin précis, le coût en cardinalité est réel.
Les workers d’arrière-plan
Le binaire exécute sa maintenance lui-même ; il n’y a aucun cron externe à installer :- Worker de la file de remise : réessais sortants avec backoff, génération de DSN (couche SMTP).
- Worker d’index de recherche : groupe les commits Tantivy ; valide au repos de la file.
- Worker de checkpoint WAL : publie les jauges de taille, fait un checkpoint
TRUNCATEau-delà de 64 Mio. - Nettoyage fail2ban : expire les bannissements toutes les quelques minutes.
- Worker de réindexation : fait converger la file de réindexation ; les conditions terminales résolvent les entrées au lieu de réessayer sans fin.
- Revérification des domaines de relais : recontrôle les preuves DNS toutes les six heures, suspend en mode fermé sur un retrait avéré.
- Maintenance des effacements : adopte et reprend les travaux d’effacement dont le pilote est mort ; balayage des orphelins au démarrage.
- Rétention d’audit : purge les lignes d’audit au-delà de l’horizon.
- Ordonnanceurs d’alertes : déclenchent les rappels d’agenda et de tâches.
Les sauvegardes
/etc/oximail, qui porte la configuration, les clés DKIM et le matériel de clés : sans lui, les blobs ne sont que du chiffré). verify-backup contrôle l’intégrité d’une sauvegarde avant d’en avoir besoin. Testez une restauration sur une machine de test, pas pendant un incident.
oximail backup --tenant <id> restreint une sauvegarde à une seule organisation. Deux propriétés de ce mode méritent d’être connues, car toutes deux ont été un temps discrètement fausses :
- Il emporte les blobs de pièces jointes de l’organisation, et pas seulement ses lignes. Une archive par organisation dont les messages se restaurent sans leurs pièces jointes se vérifie sans erreur tout en étant irrestaurable au seul sens qui compte.
- L’ensemble des tables filtrées est dérivé du schéma et gardé par un test, non tenu à la main. Une liste manuelle devient périmée dès qu’une table est ajoutée, et la panne est silencieuse dans le mauvais sens : des lignes appartenant à d’autres organisations voyagent dans un export censé n’en concerner qu’une.
Les mises à jour
Une mise à jour est un remplacement de binaire ; il n’y a aucune étape de migration à lancer :oximail status, oximail health et oximail doctor offrent des contrôles locaux (processus, ports, configuration, stockage) sans l’aller-retour HTTP.
Les copies locales ont une politique de rétention, et le déploiement l’applique. Une fois le remplacement vérifié actif, les deux binaires .bak les plus récents survivent et tout instantané de base de plus de 14 jours part, y compris les copies posées à la main. Un hôte dont le remplacement a échoué garde tout, car c’est son matériel de retour arrière. Deux choses que ce n’est pas : ce n’est pas votre sauvegarde (la couche durable reste les sauvegardes hors machine), et cela ne supprime jamais une copie de base en clair. Les copies antérieures au chiffrement annulent la posture at-rest pour leur contenu ; les absorber en silence masquerait la faute au lieu de la faire remonter. Sans gestion, l’accumulation est discrète : une machine avait amassé 85 Go de binaires de retour arrière, et un MX de secours était à 89 % de disque.
L’arrêt propre
systemctl stop (SIGTERM) déclenche un drainage : les workers terminent leurs éléments en cours dans un budget borné, l’index de recherche est vidé, et le WAL reçoit un checkpoint. Les redémarrages se terminent normalement dans le temps dont les workers ont réellement besoin, c’est-à-dire quasi instantanément. Un avertissement « drain cap reached » dans les journaux signale un worker vraiment lent et mérite une enquête.
L’exploitation de la sécurité
La défense en trois couches (nftables côté noyau, limitation de débit et fail2ban dans le binaire, supervision) est décrite dans le modèle de sécurité ; la surface opérationnelle est :[security] trusted_ips (CIDR accepté) contourne le limiteur de débit et fail2ban pour votre propre infrastructure. N’installez pas le démon fail2ban à côté d’OxiMail : le serveur suit lui-même ses échecs d’authentification sur tous les protocoles, avec la vraie IP cliente même derrière un proxy.
Quand quelque chose ne va pas
journalctl -u oximail --since -1h: l’échec est bruyant par conception ; cherchez les lignes de niveauerroravec leurs champs de contexte.oximail doctor: diagnostics de configuration, de stockage et de ports./metrics: une file grossit, un worker est bloqué, une jauge est périmée ?- Pour les problèmes de remise, la liste de contrôle DNS et la CLI de file (
oximail queue ...) viennent ensuite.
Si du courrier légitime part en spam, regardez l’horloge.
oximail doctor rend compte de la santé de l’horloge, et c’est la deuxième chose à examiner après le DNS. Une signature DKIM entrante qui porte un horodatage est refusée si elle arrive plus de 300 secondes dans notre futur : une machine dont l’horloge retarde se met donc à refuser les signatures de courriers parfaitement valides, qui scorent alors en spam. Le symptôme ressemble à un problème de DNS ou de DKIM, et jamais à une horloge. Notez que l’exposition est unidirectionnelle : nos propres signatures sortantes ne portent pas d’horodatage, un destinataire n’a donc rien de nous à juger, et personne ne vient jamais s’en plaindre.