Skip to main content
Une instance OxiMail stocke tout à trois endroits, tous sous votre contrôle : Plus /etc/oximail/ : la configuration, les clés DKIM, et le matériel de clés sans lequel les deux stockages de données ne sont que du chiffré. Les trois emplacements de données plus /etc/oximail forment la surface de sauvegarde complète (exploitation).

​
Comment le courrier est rangé

Un message est stocké une fois, sous deux formes (ADR-009) : les octets bruts RFC 5322 comme blob, et les métadonnées analysées (en-têtes, structure, hasAttachment, aperçu, fil) comme lignes. Rien n’est ré-analysé à la lecture. Les blobs sont adressés par le SHA-256 de leur clair : une pièce jointe envoyée à dix collègues est stockée une fois par organisation. La déduplication opère sous le niveau des boîtes, et deux copies d’un message dans deux boîtes sont toujours deux lignes de métadonnées pointant vers un blob (jamais de déduplication au niveau du message : cette classe de bug est exclue par construction). Le répertoire de blobs est cloisonné par organisation et par compte ({tenant}/{compte}/..., avec une zone réservée _tenant/ pour le contenu d’organisation) : c’est ce qui rend la crypto-suppression par compte et l’isolation par organisation physiques plutôt que logiques.

​
Les dossiers

Les dossiers sont des Mailboxes JMAP avec les rôles RFC 8621 (inbox, sent, drafts, trash, junk, archive), provisionnés par compte dans la langue du compte. La hiérarchie, les compteurs par dossier et le partage (shareWith) sont des données. La passerelle IMAP montre le même arbre. Les dossiers en double laissés par d’anciens imports se réparent avec oximail account dedupe-folders (migration).

​
Corbeille, restauration et rétention

La destruction est en deux temps avec une corbeille visible (ADR-035) : un objet détruit atterrit dans deleted_items et peut être restauré. C’est ce qui soutient les corbeilles de tous les clients et la récupération des ressources DAV détruites. Indépendamment de la corbeille utilisateur, deux fenêtres de rétention comptent en exploitation :
  • change_log : 90 jours. L’historique de synchronisation incrémentale (/changes, sync-collection) est élagué au-delà de 90 jours ; un client absent plus longtemps fait une resynchronisation complète au lieu d’une incrémentale. C’est voulu : le journal de changements est un mécanisme de synchronisation, pas une piste d’audit.
  • audit_log : des années. La piste d’audit administrative a son propre horizon long, avec un worker de rétention qui l’applique (conformité).
Le ramasse-miettes des blobs supprime les blobs que plus aucune ligne ne référence, avec un suivi de références qui inclut les détenteurs non évidents comme l’historique d’édition : le GC n’orpheline jamais un contenu que quelque chose peut encore afficher.

​
Les quotas

  • Par compte : oximail account quota --account <email> --mb <n> (0 = pas de limite par compte). Exposé aux clients via Quota/get.
  • Par collection : des plafonds de volume (ADR-072) bornent la croissance de chaque collection.
  • Les plafonds de capacité du chat sont à part (multi-tenant).

​
L’index de recherche est jetable

L’index Tantivy ne porte aucune donnée primaire. S’il est perdu, corrompu, ou si vous changez son stockage, reconstruisez-le :
La réindexation fait passer chaque message par la même extraction qu’à l’ingestion ; une file d’arrière-plan fait converger le travail. À noter : l’index est le seul stockage dont le contenu n’est pas chiffré par compte (il doit être découpé en jetons côté serveur pour être interrogeable), et c’est pourquoi l’effacement de compte le balaie explicitement.

​
Maintenance de la base

Aucune planifiée, et c’est voulu. Le checkpoint du WAL est automatique (borné vers 64 Mio, checkpoint à l’arrêt), les statistiques du planificateur de requêtes sont rafraîchies après les migrations, et le pool de connexions n’a pas besoin de réglage en dessous de quelques centaines d’utilisateurs simultanés ([storage] pool_size, 32 par défaut, à augmenter sur une machine chargée en lecture). L’histoire opérationnelle de la base tient en trois points : garder de l’espace disque, garder des sauvegardes, et laisser le serveur tourner. oximail sql existe comme échappatoire gardée pour les scénarios de support ; l’inspection au quotidien passe par les verbes CLI (oximail mailbox, oximail email) et par les vues de données par compte de l’API d’administration.