Listes

Une liste appartient à un domaine et porte ses propres réglages (politiques de post, d'abonnement, d'archives). Chaque liste a un ou plusieurs propriétaires (list_owner) et, éventuellement, des modérateurs (moderator).

Types de liste

À la création, une liste a un type (lists.list_type) :

discussion : liste d'échange où les abonnés peuvent poster et se répondre.
newsletter : lettre d'information où seuls les émetteurs autorisés diffusent.

Le type oriente les valeurs par défaut, mais le comportement réel est piloté par les politiques ci-dessous.

Créer une liste

Le propriétaire doit déjà exister comme utilisateur actif (voir Utilisateurs et rôles).

CREDENTIALS_DIRECTORY=/etc/difuzio/secrets difuzio create-list --config /etc/difuzio/config.yaml \
    --domain lists.example.org \
    --name announce \
    --owner proprio@example.org \
    --display-name "Annonces" \
    --type newsletter

--domain, --name, --owner sont obligatoires.
--name est la partie locale de l'adresse (la liste sera announce@lists.example.org).
--owner est l'email d'un utilisateur actif existant ; il reçoit le rôle list_owner sur la liste.
--type vaut discussion (défaut) ou newsletter.

La création est atomique : la liste, ses réglages par défaut et l'octroi du rôle propriétaire sont écrits dans une seule transaction.

Lister les listes

difuzio lists --config /etc/difuzio/config.yaml [--domain lists.example.org]

Affiche un tableau des listes existantes : id, nom, domaine, type, statut et suspension d'envoi éventuelle (avec sa raison). Sans --domain, toutes les listes de tous les domaines sont affichées :

ID     LIST                           DOMAIN                    TYPE        STATUS   SUSPENDED
1      announce                       lists.example.org         newsletter  active   -
2      debat                          lists.example.org         discussion  active   yes (manual)

Via l'API, le même inventaire est disponible par GET /api/v1/domains/{domaine}/lists (voir API REST).

Politiques d'une liste

CREDENTIALS_DIRECTORY=/etc/difuzio/secrets difuzio set-policy --config /etc/difuzio/config.yaml \
    --domain lists.example.org --list announce \
    --post-policy members \
    --subscribe-policy confirm \
    --archive-access members \
    --reply-to list \
    --from-munging auto

Seuls les drapeaux fournis sont modifiés ; les autres réglages restent inchangés.

`--post-policy` : qui peut poster

open : tout le monde peut poster.
members : seuls les abonnés actifs.
moderated : tout post est mis en attente de modération.
owner : seuls les propriétaires (typique d'une newsletter).

`--subscribe-policy` : comment on s'abonne

open : abonnement immédiat.
confirm : double opt-in (un email de confirmation est envoyé, voir guide de l'abonné).
moderated : l'abonnement est mis en attente de validation par un modérateur.
closed : aucun abonnement par les canaux publics (seul un admin peut ajouter).

`--archive-access` : qui voit les archives

public : tout le monde. Les archives sont alors servies sans authentification sur /p/archives/<id> et annoncées dans l'en-tête List-Archive des messages. Les adresses électroniques y sont tronquées à l'affichage, les pièces jointes ne sont pas publiées, les pages portent un X-Robots-Tag: noindex et sont exclues par robots.txt, et leur consultation est limitée par adresse IP.
members : les abonnés. Aucune page publique n'est exposée et List-Archive n'est pas émis.
owners : les propriétaires uniquement, mêmes conséquences que members.

`--reply-to` : positionnement du Reply-To

sender : les réponses vont à l'auteur.
list : les réponses vont à la liste.
both : auteur et liste.

`--from-munging` : réécriture de l'en-tête From

Contre le rejet DMARC des domaines stricts (voir Délivrabilité) :

auto : munging appliqué seulement quand le domaine de l'auteur publie une politique DMARC stricte (recommandé).
always : munging systématique.
never : jamais de munging.

Modes de livraison des abonnés

Chaque abonné a un mode de livraison : regular (chaque message), nomail (abonné mais ne reçoit rien) ou digest (résumé périodique groupé). Le mode se règle en CLI :

difuzio set-delivery-mode --domain lists.example.org --list announce \
    --email abonne@example.org --mode digest

Le mode digest est opérationnel : une tâche du worker compile périodiquement (au plus une fois par heure et par liste) les nouveaux messages distribués et les envoie groupés aux abonnés en mode digest. Les abonnés digest et nomail sont exclus du fan-out individuel. Via l'API, le même réglage passe par PATCH .../members/{member}.

Textes de bienvenue et d'adieu

Deux réglages par liste insèrent vos propres paragraphes dans les courriers envoyés aux abonnés :

welcome_text : ajouté au mail de bienvenue, quand l'abonnement devient actif ;
goodbye_text : ajouté au mail d'adieu, quand l'abonnement est clos.

Les lignes vides séparent les paragraphes ; le texte est inséré comme du texte, jamais interprété comme du HTML. Le détail des cas d'envoi (et des cas où ces courriers ne partent volontairement pas, comme un import de masse ou un désabonnement en un clic) est dans Mails transactionnels.

Réglages non exposés en CLI

D'autres réglages existent au niveau des données mais ne sont pas réglables par une option de set-policy :

modération du premier post d'un nouvel abonné (moderate_first_post) ;
politique de pièces jointes (allow / strip / reject) ;
visibilité de la liste des membres (public / members / owners).

Ces champs sont posés à leurs valeurs par défaut à la création. Leur réglage fin relève d'une évolution prévue (CLI ou interface web).

Comptes de messagerie du fournisseur (profil boîte externe)

Cette section résume le réglage côté liste. L'installation complète de ce profil est décrite dans Comptes de messagerie externes.

Quand difuzio n'a pas de serveur mail à lui et relaie par la boîte d'un hébergeur, chaque liste peut porter ses propres identifiants :

Réception (IMAP) : la boîte relevée périodiquement. Tout message qu'elle contient est un envoi pour cette liste.
Envoi (SMTP) : le compte utilisé pour authentifier les envois de la liste. Il sert aux hébergeurs qui exigent que l'expéditeur corresponde au compte authentifié, OVH en particulier.

Ces deux comptes se saisissent dans la console, sur la fiche de la liste, section "Comptes de messagerie du fournisseur". Le bouton "Tester la connexion" ouvre une vraie session (connexion, TLS, authentification, ouverture du dossier pour l'IMAP) sans envoyer ni relever le moindre message, et affiche le message d'erreur de l'hébergeur en cas de refus. La fiche conserve ensuite la date du dernier succès et la dernière erreur, ce qui distingue "jamais utilisé" de "mot de passe expiré".

Points à connaître :

Le mot de passe n'est jamais réaffiché : il est chiffré à l'enregistrement et aucune réponse de l'API ne le renvoie. Sur une modification, laisser le champ vide conserve le mot de passe déjà enregistré, ce qui permet de corriger un port ou un dossier sans l'avoir sous la main.
Un administrateur de domaine (ou un super_admin) saisit ces comptes. Le propriétaire de la liste voit leur état sans pouvoir les changer : le serveur d'où part le courrier est une décision d'infrastructure.
Une modification est prise en compte sans redémarrage : l'envoi suit dans la demi-minute, la réception au cycle de relève suivant.
L'installation doit déclarer la clé de chiffrement security.credential_keyring. Sans elle, la console refuse d'enregistrer un compte et l'indique explicitement ; voir Configuration.
Une liste sans compte fonctionne normalement : elle utilise le serveur mail de l'installation. C'est le cas de tous les déploiements avec MTA local.
La section n'apparaît pas du tout quand l'exploitant a fermé le profil avec policy.external_mailboxes: deny : aucun compte ne peut alors être enregistré sur ce serveur, quel que soit le rôle. Voir Configuration, section policy.

Suspension d'envoi (kill-switch)

Indépendamment des politiques, l'envoi d'une liste peut être suspendu automatiquement par le kill-switch de réputation (taux de plaintes ou de rebonds durs trop élevé) ou manuellement. Voir Modération.