> ## Documentation Index > Fetch the complete documentation index at: https://docs.oximail.ch/llms.txt > Use this file to discover all available pages before exploring further. # Conformité : journalisation & effacement > Les deux primitives de conformité pour les organisations réglementées : la journalisation du courrier (obligation d'archivage) et l'effacement de compte en machine à phases durable et prouvable (RGPD art. 17 / DSAR). Les organisations réglementées (finance, santé, juridique, secteur public) font face à deux obligations qui tirent en sens opposés : **garder une trace** des communications professionnelles, et **effacer les données d'une personne** sur demande, de façon prouvable. OxiMail livre les deux comme des fonctions de premier rang du serveur : une journalisation du courrier par organisation, et un moteur d'effacement de compte qui s'exécute comme une machine à phases durable et laisse un enregistrement de complétion non identifiant, présentable des mois plus tard. Cette page décrit ce que fait le serveur, pas ce que votre régulateur exige. Faites correspondre ces mécanismes à vos propres obligations légales (RGPD, nLPD suisse, règles sectorielles) avec votre conseil juridique. ## Journalisation du courrier La journalisation copie en silence le courrier correspondant vers une **boîte journal** ou un **archiveur externe**, par organisation. C'est l'équivalent des fonctions Postfix `always_bcc` / `sender_bcc_maps` / `recipient_bcc_maps`, traité comme des données plutôt que comme des éditions de fichier de configuration. L'usage typique est une obligation d'archivage (art. 30 RGPD) ou une règle sectorielle. **Désactivée par défaut.** Pas de règles, pas de journalisation : rien n'est copié tant qu'un administrateur n'a pas créé de règle. ### Les règles Une règle de journalisation a trois dimensions : | Dimension | Valeurs | Signification | | ------------------ | --------------------------------- | -------------------------------------------------------------------------- | | **Direction** | `inbound`, `outbound`, `both` | Le flux de courrier que la règle observe. | | **Correspondance** | `always`, `sender`, `recipient` | Tout, ou seulement le courrier venant de / allant vers une adresse donnée. | | **Destination** | une boîte, ou une adresse externe | Où part la copie. | Les deux formes de destination diffèrent par la garde du contenu : * **Boîte** : la copie est réingérée dans une boîte journal locale. Elle est donc chiffrée au repos comme tout le reste du courrier et reste dans le périmètre de stockage de l'organisation. * **Externe** : une copie est relayée vers un archiveur externe (un service d'archivage dédié ou un autre serveur que vous exploitez). ### Invariants * **Le trafic de relais n'est jamais journalisé.** Le courrier relayé pour les comptes `service` conserve la [promesse de rétention éphémère](./outbound-relay) : un smarthost n'archive pas le courrier de ses clients. * **Une copie journal n'est jamais rejournalisée.** Un en-tête `X-Oximail-Journaled` protège les deux formes de destination, y compris à travers un aller-retour externe. Les règles ne peuvent donc pas créer de boucle de courrier. * **Les destinations sont isolées par organisation.** Une règle ne peut viser qu'une boîte de sa propre organisation (l'isolation par tenant de la couche de stockage, ADR-015). * **La journalisation est au mieux, et ne bloque jamais le courrier.** Un échec de journalisation est journalisé bruyamment, mais le message remis ou soumis n'est pas affecté : l'archivage ne doit pas devenir une panne de remise (ADR-017). * **Une évaluation par message.** Le courrier entrant est évalué une fois après la boucle de remise ; le sortant une fois après la mise en file d'une soumission non relayée. ### Gérer les règles Par la CLI : ```bash theme={null} oximail journaling list oximail journaling add ... # direction, correspondance, destination oximail journaling remove oximail journaling enable oximail journaling disable ``` Ou en JMAP, pour l'outillage d'administration : `JournalingRule/get` et `JournalingRule/set` sous la capacité `urn:oximail:params:jmap:v2:admin` (réservée aux administrateurs). ## Effacement de compte (RGPD art. 17 / DSAR) Supprimer un compte n'est pas un `DELETE` : c'est une opération en plusieurs étapes à portée juridique, et un crash ou une relance opérateur ne doit jamais la laisser à moitié faite ni l'exécuter deux fois. OxiMail exécute chaque effacement de compte comme une **machine à phases enregistrée en base** : ```text theme={null} enqueued → agency-frozen → residue-redacted → identity-stripped → data-swept → completed ``` Les propriétés qui la rendent digne de confiance : * **Au plus un effacement vivant par compte, par construction.** Un index unique partiel rend impossible un second effacement concurrent du même compte, à travers les processus : une suppression par l'API d'administration et une suppression CLI sur la même machine ne peuvent pas se courir dessus. * **Durable et reprenable.** Chaque phase enregistre sa progression. Un pilote qui meurt en vol (crash, timeout de proxy) laisse un travail qu'un worker de maintenance adopte et reprend, grâce à un bail avec battement de cœur ; un balayage au démarrage rattrape les orphelins. La passe est découplée de la connexion HTTP qui l'a demandée : un timeout de proxy ne peut pas l'annuler. * **Visible quand ça coince.** Un travail garé sur un échec durable apparaît dans `oximail erasure list --stuck` et dans la métrique `oximail_erasure_jobs_stuck` : un effacement mis en file atteint un état terminal ou se signale comme bloqué, jamais à moitié fait en silence. * **Des adaptateurs minces.** L'API d'administration et la CLI pilotent la même orchestration ; il n'existe qu'un seul moteur d'effacement. ### Ce que fait chaque phase 1. **Gel de l'agence.** Avant tout effacement, le compte perd sa capacité à *produire* de nouvelles données : il est désactivé, ses tokens sont révoqués, la soumission SMTP répond `550`, les réponses automatiques d'absence sont supprimées, et ses envois planifiés ou en fenêtre d'annulation sont annulés à la source. L'effacement **refuse ensuite d'avancer tant qu'il reste une entrée sortante non remise dans la file** (échec bruyant ; la file se vide dans la limite de la durée de vie des réessais, ou un opérateur annule les entrées via l'API de file). Chaque chemin qui émet du courrier au nom d'un compte est nommé dans un registre avec la garde qui l'arrête, sous le contrôle d'un audit de source (ADR-118). 2. **Caviardage des résidus.** Les copies du courrier que le partant a *envoyé* à ses collègues continuent de le nommer dans les boîtes des survivants, dans les colonnes structurées et dans les en-têtes bruts du message. La passe réécrit ces copies par le chemin d'ingestion normal : les en-têtes d'identité se replient sur une sentinelle non routable (`former-user@.invalid`), les colonnes d'adresses sont caviardées en tenant compte de la structure (un destinataire homonyme n'est jamais touché), et le **corps du message n'est pas modifié** : c'est la correspondance des destinataires. Les jetons dans les Message-ID, les propres enregistrements À/Cc des survivants et les apparitions limitées aux en-têtes de trace sont documentés hors périmètre. 3. **Retrait de l'identité.** Les principals d'annuaire du sujet sont nettoyés de leurs données personnelles et conservés comme **pierres tombales** : des ancres de graphe qui empêchent l'historique de chat et de notifications d'être réattribué en silence, sans porter aucune identité. Chaque droit du partant est retiré de chaque carte `shareWith` (chaque propriétaire survivant reçoit un changement enregistré pour se resynchroniser), les instantanés d'acteur dans les notifications des survivants perdent nom et adresse, et un principal en pierre tombale est refusé comme nouveau bénéficiaire : un repartage ne peut pas défaire le retrait. Les principals de ressource et de lieu que le partant avait simplement *créés* (salles de réunion) survivent intacts : ils appartiennent à l'organisation. 4. **Balayage des données.** Les lignes du compte sont supprimées table par table, ses documents sont retirés de l'index de recherche plein texte (l'index n'a pas de chiffrement à révoquer, il est donc balayé explicitement), et ses blobs sont crypto-effacés par la suppression des clés du compte. Le balayage échoue bruyamment sur une vraie erreur au lieu de déclarer un succès par-dessus des lignes survivantes. 5. **Complétion.** Un unique enregistrement durable et **non identifiant** est écrit : des compteurs de résultat plus une référence de ticket DSAR optionnelle, rattachés à la pierre tombale d'identité. Tout texte d'erreur sur la ligne du travail est effacé à l'état terminal, pour qu'aucun message d'échec ne puisse transporter une adresse personnelle dans l'enregistrement durable. ### Le tampon de réversibilité L'effacement est volontairement difficile à défaire, mais une erreur d'opérateur (mauvais compte) exige un chemin de récupération honnête. Pendant le retrait d'identité, le delta de clés de chaque droit de partage retiré (les seuls bits du partant, objet par objet, jamais la carte entière) est capturé **chiffré avec la clé maîtresse de l'organisation** dans un tampon de réversibilité à durée de vie annoncée : * **7 jours** par défaut, ancrés au moment de la mise en file ; surcharge par organisation `erasure.reversal_ttl_days`. * `oximail erasure undo ` fusionne chaque delta dans la carte *actuelle* sous comparaison-et-échange : une modification intermédiaire du propriétaire n'est jamais écrasée. * `--grantee ` restaure les droits sur un **autre principal vivant** : après un effacement terminé, c'est la vraie récupération. On reprovisionne la personne, puis on réattribue à sa nouvelle identité (validé, provenance auditée). * Passé l'échéance, la restauration est refusée côté serveur, même si les lignes existent encore physiquement ; un faucheur supprime les lignes expirées sans condition. ### Prouver que c'est fait Donnez une référence DSAR à l'effacement au moment de la suppression, et résolvez-la plus tard : ```bash theme={null} oximail account delete --account jane@example.com --dsar TICKET-4711 --yes # ... des mois plus tard, pour l'auditeur : oximail erasure prove --dsar TICKET-4711 ``` `prove` résout la référence vers l'enregistrement de complétion non identifiant : la preuve durable que l'effacement de l'art. 17 a été exécuté (responsabilité de l'art. 5, §2). Le code de sortie `1` signifie qu'aucun enregistrement n'existe. ### Le journal d'audit Le `audit_log` est en ajout seul, avec un horizon de rétention long, et l'effacement doit l'atteindre aussi, sans toucher à la responsabilité : * Un **worker de rétention** purge les lignes au-delà de l'horizon configuré. L'horizon a une source de vérité unique, partagée avec la capacité `auditLogRetentionDays` que le serveur annonce : les deux ne peuvent pas diverger. Une jauge de dernier balayage alimente une alerte de fraîcheur. * L'effacement de compte **désidentifie** les lignes d'audit qu'il doit conserver : le fait survit (action, résultat, ressource, horodatage) tandis que l'identité est nettoyée (IP cliente, user agent, clés de détail identifiantes). L'identifiant de principal reste comme ancre de la pierre tombale. *Effacer l'identité, garder le fait.* ## Aide-mémoire CLI | Commande | Rôle | | -------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | `oximail journaling list\|add\|remove\|enable\|disable ` | Gérer les règles de journalisation. | | `oximail account delete --account [--dsar ] --yes` | Mettre un effacement en file (avec référence DSAR optionnelle). | | `oximail erasure list [--stuck]` | Lister les travaux d'effacement ; `--stuck` ne montre que les travaux garés. | | `oximail erasure undo [--object-id ] [--grantee ] [--dry-run]` | Restaurer les droits de partage retirés, depuis le tampon de réversibilité. | | `oximail erasure prove --dsar ` | Résoudre une référence DSAR vers son enregistrement de complétion. | Voir la [référence CLI](./cli) pour chaque option, et [Exploitation](./operations) pour les métriques et les workers concernés.