71. pepsi-stage-list

Détermine quels destinataires d’enveloppe désignent une liste de diffusion et les route selon leur rôle.

71.1. Rôle

pepsi-stage-list est le routeur de listes de diffusion. Pour chaque destinataire d’enveloppe, l’étape demande si l’adresse désigne une liste de ce serveur et, si oui, laquelle des neuf adresses d’une liste elle est ; le message est alors routé vers l’étape qui traite ce rôle. C’est la seule des cinq étapes de liste qui s’exécute sur chaque message, et elle est donc délibérément peu coûteuse : elle charge l’enveloppe et state, jamais les en-têtes ni le corps, et sur un serveur qui n’héberge aucune liste chaque message passe intact à NEXT_STAGE. Référence : pepsi-stage-list(1).

Ce sous-système est une réimplémentation de GNU Mailman 3 ; voir Listes de diffusion, qui nomme ce qui a été repris d’amont.

71.2. Fonctionnalités

  • Neuf adresses par liste. L’adresse d’envoi <list>@<host> et les huit sous-adresses de rôle -request, -join, -subscribe, -leave, -unsubscribe, -confirm+<token>, -owner et -bounces (qui peut porter un détail VERP, -bounces+alice=example.net).

  • L’adresse d’envoi d’abord, puis les suffixes du plus long au plus court. Les deux ordres portent le mécanisme. Une liste peut légitimement s’appeler foo-request, et tester les suffixes d’abord la rendrait inatteignable dès que quelqu’un créerait une liste nommée foo – le symptôme étant que le courrier destiné à une vraie liste entre silencieusement dans le chemin des commandes. Le plus long d’abord est la raison pour laquelle -unsubscribe n’est pas lu comme -subscribe sur un radical terminé par -un.

  • Trois destinations selon le rôle. L’adresse d’envoi va vers POST_STAGE, -bounces vers BOUNCE_STAGE, et tout autre rôle – -owner compris – vers COMMAND_STAGE, c’est-à-dire l’étape qui sait déjà trouver les propriétaires d’une liste et supprimer une boucle de réponse automatique.

  • Les destinataires mixtes sont scindés. Un message adressé à une liste et à une boîte ordinaire, ou à deux listes, devient un enregistrement par destination, chacun avec ses propres destinataires et sa propre tranche de state.dsn.rcpt. Le groupe qui n’est pas une liste reste sur l’enregistrement d’origine.

  • Aucune fenêtre d’obsolescence. La table de routage est chargée une fois par worker et rafraîchie par la mise hors service des workers que le répartiteur opère lorsque la base annonce un changement sur le canal pepsi_list_changed ; une liste créée pendant que le répartiteur tourne reçoit donc du courrier sans redémarrage. L’étape ne tient aucun listener propre : le pool d’un worker est exactement une connexion, et un listener l’occuperait indéfiniment.

71.3. Deux avertissements

Avertissement

BOUNCE_STAGE sur cette étape signifie l”inverse de ce qu’il signifie partout ailleurs dans Configuration. Ici, c’est là qu’un message de rejet entrant, émis par quelqu’un d’autre, est consommé ; partout ailleurs, c’est là que Pepsi génère une notification d’état de remise. Le pointer vers pepsi-stage-bounce répond à un rejet par un rejet – une boucle de courrier, et non un message mal routé – et pepsi-setup refuse cette configuration.

Avertissement

Mettre [pepsi] RECIPIENT_DELIMITER à - détruit entièrement le sous-adressage des listes : chaque sous-adresse s’écrit <list>-<role>, la base de announce-owner@ devient donc announce, et le courrier destiné aux propriétaires est envoyé à la liste. Cette même option est le délimiteur que l’éclatement écrit dans chaque expéditeur d’enveloppe VERP et dans l’adresse -confirm+<token>, de sorte que le routeur découpe toujours ce que les listes ont écrit.

71.4. Fusion

Un successeur fusionné ne s’exécute dans le même processus que si son Load est couvert par ce que le prédécesseur a chargé. Cette étape ne charge que des métadonnées : elle peut donc fusionner son propre passage à NEXT_STAGE – le chemin de ce qui n’est pas une liste, celui qui s’exécute sur chaque message – mais elle ne peut pas fusionner vers pepsi-stage-list-post, qui a besoin du corps. Router un vrai message de liste coûte donc une transition d’étape ordinaire.

71.5. Configuration

[stage-<name>] : PROGRAM = pepsi-stage-list, ainsi que NEXT_STAGE, POST_STAGE, COMMAND_STAGE et BOUNCE_STAGE, tous obligatoires. La configuration par liste réside dans la base et non dans le fichier ; voir pepsi-list et Listes de diffusion.

71.6. State

  • Entrées : le rcpt_to de l’enveloppe.

  • Sorties : un descripteur state.list sur chaque enregistrement routé – l’identifiant de liste, le rôle, l’adresse à laquelle le message est arrivé, et ce que portait la sous-adresse (un jeton -confirm, une adresse VERP -bounces). Délibérément minimal : tout le reste, une étape de travail le lit dans la base, ce qu’elle va faire de toute façon.

  • Transitions : passage à l’étape suivante (NEXT_STAGE ou l’étape d’un rôle) et éclatement lorsque les destinataires sont scindés.

71.7. Voir aussi

Listes de diffusion, pepsi-stage-list-post, pepsi-stage-list-command, pepsi-stage-list-bounce, pepsi-list, pepsi-stage-list(1).