Fonctionnalités

difuzio couvre la chaîne complète d'une liste de diffusion : recevoir, décider, transformer, distribuer, puis traiter ce qui revient. Cette page décrit ce qui est réellement implémenté et vérifié par la suite de tests du projet.

Réception du courrier

Le courrier entre par LMTP depuis un serveur de messagerie frontal, ou par relève IMAP d'une boîte hébergée.

Un classificateur d'adresses reconnaît la grammaire des adresses de service : message pour la liste, abonnement, désabonnement, contact des propriétaires, rebond VERP, plainte FBL. La règle est celle du suffixe réservé et de la plus longue liste correspondante, de sorte qu'une liste nommée annonces-tech et une liste annonces cohabitent sans ambiguïté.

Politiques de liste

Chaque liste décide qui peut lui écrire : ouverte à tous, réservée aux abonnés, modérée, ou réservée aux propriétaires. S'ajoutent la modération du premier message d'un nouvel abonné, la suspension temporaire de la liste, et une politique de pièces jointes.

Les demandes en attente de modération sont visibles dans la console, traitables en ligne ou par la ligne de commande, et chaque décision laisse une trace dans le journal d'audit.

Transformation des messages

Avant la distribution, le pipeline applique ce que la liste demande : étiquette dans le sujet, pied de page, en-têtes List-* complets, désabonnement en un clic selon le RFC 8058, identifiant de retour d'expérience pour les grandes messageries.

Deux comportements méritent d'être connus, parce qu'ils changent ce que reçoivent les abonnés :

• Transmission à l'identique quand c'est possible. Si aucune réécriture n'est demandée, le message est transmis octet pour octet et la signature DKIM de son auteur reste valide. Beaucoup de gestionnaires de listes re-sérialisent le message dans tous les cas, ce qui casse la signature et fait apparaître un dkim=fail chez les destinataires.
• Alignement DMARC maîtrisé. Quand le domaine de l'auteur publie une politique stricte, l'adresse d'expédition est réécrite au nom de la liste, avec un Reply-To qui préserve la conversation. Dès qu'un champ signé est touché, la signature de l'auteur est retirée plutôt que laissée invalide.

Abonnements et consentement

L'abonnement se fait par courriel ou depuis les pages publiques de la liste. Dans les deux cas, la confirmation est demandée à l'adresse concernée, avec un jeton à usage unique et de durée limitée. Un formulaire web anonyme ne prouve rien : la double confirmation y est donc imposée, même sur une liste ouverte.

Sont également prévus l'import CSV en masse, les modes de remise (message par message ou résumé périodique), la désactivation automatique d'une adresse qui rebondit, le retrait par le gestionnaire, et le désabonnement en un clic depuis le bouton du client de messagerie.

Les courriers que difuzio rédige lui-même - confirmation, bienvenue, adieu, lien de connexion - partent en texte et en HTML, dans la langue du domaine, avec une mise en page pensée pour les clients de messagerie réels.

Délivrabilité et réputation

• VERP. Chaque copie part avec une adresse de retour propre à un abonné, signée et auto-portante : un rebond est attribué à une personne et une seule, sans table de correspondance à maintenir.
• Rebonds. Les avis de non-remise sont analysés, classés en durs et temporaires, dédoublonnés, et cumulés sur une fenêtre glissante. Au seuil, l'adresse est désactivée ; une réactivation remet le compteur à zéro.
• Plaintes. Les retours des grandes messageries au format ARF sont ingérés et comptabilisés comme le signal le plus fort qui soit.
• Coupe-circuit. Au-delà d'un taux de plaintes ou de rebonds durs, la liste est suspendue automatiquement. La reprise est manuelle : une liste qui brûle votre réputation ne doit pas repartir toute seule.
• Débit adaptatif. L'envoi ralentit et réaccélère par pool selon ce que répondent les serveurs distants.

Console web et pages publiques

La console d'administration couvre les domaines, les listes, les membres, la modération, les clés d'API et l'audit, avec des tableaux de bord adaptés au rôle de la personne connectée.

Les pages publiques d'une liste - aide, formulaire d'abonnement, archives - sont servies par le même service. Les archives masquent les adresses, limitent les requêtes par IP et se déclarent aux robots d'indexation selon le réglage de la liste. Sessions, jetons anti-CSRF et assainissement des contenus font partie du socle, pas d'une option.

API REST et webhooks

L'API /api/v1 est authentifiée par clé, décrite par un document OpenAPI 3.1 servi par l'application elle-même, et vérifiée en intégration continue contre une référence versionnée. Elle expose les domaines, les listes, les membres, la modération et les envois.

Un en-tête d'idempotence protège les créations rejouées. Les webhooks sortants sont signés en HMAC, livrés au moins une fois avec réessais, et le client HTTP refuse les adresses internes pour ne pas devenir un relais vers votre réseau privé.

Isolation et rôles

Une installation héberge plusieurs domaines sans qu'ils se voient. Les rôles vont du super-administrateur au modérateur, en passant par l'administrateur de domaine et le propriétaire de liste. Toute lecture est filtrée par la portée de la personne connectée, et ce qui est hors de portée répond "introuvable" plutôt qu'"interdit" : c'est la seule façon de ne pas révéler l'existence d'une liste d'un autre client.

Conformité et données personnelles

L'effacement d'une personne parcourt toutes les tables, y compris les traces indirectes, et supprime les corps de messages concernés sur le disque, pas seulement leurs métadonnées. La preuve de consentement est enregistrée à l'abonnement. Les archives ont une durée de conservation par liste, appliquée automatiquement.

Exploitation

Trois processus partagent la même configuration : l'interface web et l'API, la réception du courrier, et le travailleur qui traite les files et les tâches périodiques. On lance plusieurs travailleurs pour le débit.

• Sondes /healthz et /readyz, métriques Prometheus sur /metrics.
• Unités systemd durcies et paquets Debian pour les deux backends.
• Une commande doctor qui vérifie la base et l'état du schéma, check-dns pour SPF, DKIM et DMARC, mta-config qui imprime les lignes Postfix à recopier.
• Migrations de schéma appliquées au démarrage, journal d'audit de chaque décision sensible, et la règle de fond du projet : aucune erreur silencieuse.

Ce que difuzio ne fait pas

Autant le dire ici plutôt que de le découvrir en production.

• La signature DKIM du domaine de liste est apposée par le serveur de messagerie frontal, pas par difuzio. Sans elle, le désabonnement en un clic n'est pas honoré par les grandes messageries.
• L'analyse antivirus et antispam entrante relève également du serveur frontal.
• En profil boîte externe, les rebonds ne sont pas traités automatiquement : l'enveloppe SMTP d'origine est perdue, une adresse morte se retire à la main.

Pour aller plus loin

Le manuel d'exploitation détaille chacun de ces points, configuration à l'appui : documentation d'administration.