Conformité : journalisation & effacement

​

Journalisation du courrier

​

Les règles

• 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 : 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

oximail journaling list    <tenant>
oximail journaling add     <tenant> ...      # direction, correspondance, destination
oximail journaling remove  <tenant> <rule-id>
oximail journaling enable  <tenant> <rule-id>
oximail journaling disable <tenant> <rule-id>

​

Effacement de compte (RGPD art. 17 / DSAR)

enqueued → agency-frozen → residue-redacted → identity-stripped → data-swept → completed

• 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@<domaine>.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é

• 7 jours par défaut, ancrés au moment de la mise en file ; surcharge par organisation erasure.reversal_ttl_days.
• oximail erasure undo <job-id> fusionne chaque delta dans la carte actuelle sous comparaison-et-échange : une modification intermédiaire du propriétaire n’est jamais écrasée.
• --grantee <principal> 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

oximail account delete --account jane@example.com --dsar TICKET-4711 --yes
# ... des mois plus tard, pour l'auditeur :
oximail erasure prove --dsar TICKET-4711

​

Le journal d’audit

• 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