RGPD

difuzio est conçu pour faciliter la conformité : traçabilité du consentement, droit à l'effacement, rétention bornée, et localisation maîtrisée des données.

Consentement

Chaque abonné porte la trace de son consentement :

• consent_source : l'origine du consentement (web_form, email_confirm, admin_import, api) ;
• consent_evidence : un texte libre décrivant la preuve (formulaire, date, référence d'import, etc.) ;
• consent_at : la date du consentement ;
• consent_text_ver : la version du texte de consentement que la personne a accepté, recopiée depuis le réglage consent_text_ver de la liste au moment de l'inscription. Elle n'est renseignée que pour les canaux qui la composent : formulaire web (web_form, y compris après approbation d'un modérateur) et confirmation par courriel (email_confirm). Un import ou un ajout forcé la laisse vide : la personne n'a jamais vu ce texte, sa preuve est consent_evidence. Modifier le réglage de la liste ne réécrit jamais les membres déjà inscrits, qui gardent la version qu'ils ont réellement acceptée.

Le double opt-in (politique d'abonnement confirm) produit un consentement email_confirm horodaté, sans intervention. Pour les ajouts par import ou par API, une preuve de consentement est exigée : une demande sans preuve est rejetée (422 côté API). Cela évite d'inscrire des personnes sans base légale.

Droit à l'effacement

CREDENTIALS_DIRECTORY=/etc/difuzio/secrets difuzio erase --config /etc/difuzio/config.yaml \
    --email personne@example.org --confirm

Le drapeau --confirm est obligatoire (opération irréversible), et --config également : le corps des messages est stocké hors de la base (storage.blob_dir), et seul le fichier de configuration en donne le chemin. La commande refuse de s'exécuter avec --dsn seul plutôt que de vider les lignes en laissant les corps sur disque.

La commande efface les données personnelles table par table :

• suppression dure des abonnements (members), des rebonds (bounces), des demandes d'abonnement en attente, des tokens, des compteurs de débit, et du compte utilisateur le cas échéant ;
• purge du brut des messages postés par la personne : la ligne messages est pseudonymisée et l'objet correspondant est délié sur disque. Les chemins sont relevés dans la transaction et les fichiers supprimés après validation ; si un fichier ne peut pas être supprimé, la commande remonte une erreur au lieu d'annoncer un effacement complet ;
• l'audit_log est conservé (obligation légale, Art. 17(3)) mais le label est remplacé par un hash et l'adresse IP est mise à NULL : la traçabilité des actions subsiste sans réidentifier la personne.

La commande affiche un rapport du nombre de lignes traitées par table :

erased personne@example.org: members=3 messages=12 (raw objects unlinked=12)
bounces=1 pending=0 tokens=2 rate=0 users=1 (audit_log 5 hashed)

Un échec partiel est remonté, jamais silencieux : si une étape échoue, l'erreur est journalisée et signalée.

Rétention

difuzio borne la conservation des données techniques :

• copies sortantes terminales : purgées au-delà de worker.outq_retention_days (3 jours par défaut) ;
• jobs entrants : worker.inbound_retention_days (au moins 7 jours, pour couvrir la déduplication LMTP face à la file MTA amont) ;
• tokens expirés ou consommés : purgés périodiquement ;
• éléments de modération et demandes d'abonnement : expirés au-delà de leur fenêtre ;
• clés d'idempotence (idempotency_keys) : purgées au-delà de 24 h ;
• file de livraison des webhooks (webhook_deliveries) : effacée en cascade à la suppression du webhook.

Les tables techniques send_events (marqueur d'envoi terminé) et digest_state (filigrane de digest par liste) ne portent pas de PII directe (identifiants internes). L'effacement RGPD d'une personne (erase) reste exhaustif.

Côté journaux applicatifs, aligner la rétention (journald / logrotate) sur 90 jours, ces journaux pouvant contenir des adresses email (voir Exploitation).

Localisation et sous-traitants

Toutes les données applicatives résident dans la base que vous opérez (MariaDB, ou le fichier SQLite de la variante "light"). Les flux sortants de données personnelles sont : la remise du courrier au relais submission (votre MTA) puis aux destinataires, et, si vous en configurez, les webhooks (chaque événement signé est POSTé vers l'URL que vous enregistrez -- à documenter dans votre registre de traitement). difuzio n'envoie aucune donnée à un service tiers de lui-même.

Accès aux données

• l'accès aux archives d'une liste est borné par archive-access (public / members / owners) ;
• la visibilité de la liste des abonnés est bornée par les rôles (voir Utilisateurs et rôles).