74. pepsi-stage-list-command

S’abonner, se désabonner et confirmer par e-mail ; transfert du courrier `-owner`.

74.1. Rôle

pepsi-stage-list-command traite tout ce qu’une liste de diffusion fait par courrier et qui n’est pas un message de liste : les sept commandes par e-mail, les deux flux d’abonnement et le transfert -owner. Référence : pepsi-stage-list-command(1).

Une phrase gouverne toute l’étape :

Le seul chemin qui ajoute une adresse sans que cette adresse ait prouvé qu’elle veut y être est un pre_verified et pre_confirmed explicite, émis par un client REST authentifié ou par la ligne de commande.

Rien dans cette étape ne peut poser l’un ou l’autre de ces indicateurs. Un message n’est pas un client authentifié : un join demande donc toujours confirmation à l’adresse nommée, ou refuse.

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.

74.2. Adresses

Sept, et les cinq premières ne sont pas analysées du tout : -join/-subscribe deviennent un join synthétique (l’objet et le corps ne sont jamais lus, et aucun courrier de résultats n’est envoyé), -leave/-unsubscribe de même un leave synthétique, et -confirm+<token> un confirm synthétique dont le jeton est pris dans l”adresse et jamais dans le message. -request est celle dont l’objet et le corps sont analysés. -owner n’est pas une commande du tout : elle est transférée à tous les propriétaires et modérateurs et n’atteint jamais l’analyseur — c’est le comportement d’amont et il importe, car un message aux propriétaires dont l’objet se lit par hasard unsubscribe doit atteindre un humain et non exécuter une commande.

74.3. Commandes

confirm, echo, end (alias stop), help, join (alias subscribe), leave (alias unsubscribe) et who. Trois d’entre elles portent une décision de sécurité et non de mise en forme.

• ``confirm`` élimine les jetons déjà confirmés dans le même message – un client de messagerie qui cite l’original produit le jeton deux fois – et arrête toujours le traitement. Un jeton qui ne correspond pas reçoit la même réponse qu’un jeton expiré, car les distinguer serait un oracle indiquant quels jetons existent.

• ``leave`` ne prend aucun argument. join address= coûte à l’adresse nommée un message de confirmation et n’abonne personne ; un leave address= équivalent permettrait à un From: falsifié de désabonner un inconnu sans plus. L’adresse propre de l’expéditeur doit en outre être vérifiée.

• ``who`` dépend de member_roster_visibility, et une demande non autorisée est refusée et non satisfaite par une liste vide – une réponse vide est indiscernable d’une liste sans membres, ce qui indique à un collecteur d’adresses que l’adresse vaut un nouvel essai.

74.4. Analyse

Les règles de tolérance d’amont, reproduites parce qu’il existe vingt ans d’instructions du type « envoyez le mot HELP à… ». Une commande d’adresse l’emporte d’emblée. Le Subject: est la première ligne de commande, décodée selon la RFC 2047 puis ramenée à l’ASCII. Le corps ne contribue que par sa première partie ``text/plain``, et seulement par ses MAX_COMMAND_LINES premières lignes – un message sans partie en texte brut ne contribue en rien, car exécuter des commandes depuis du HTML est un endroit où se montrer serviable est une décision de sécurité. Il n’y a aucun traitement des citations, des signatures ni des -- ; chaque jeton est mis en minuscules ; les lignes vides sont ignorées. Un premier mot inconnu est réessayé après avoir retiré exactement un mot, ce qui constitue tout le mécanisme Re: et n’est délibérément pas un retrait générique de préfixe (Fwd: help me exécuterait sinon help). Une commande qui arrête achève la passe, et le reste est signalé comme non traité. Avant tout cela, un message portant Precedence: bulk|junk|list sans X-Ack: yes est rejeté silencieusement.

Deux de ces règles ressemblent à des bogues et n’en sont pas : le nouvel essai retire un mot et pas davantage, et le plafond compte des lignes et non des commandes – onze lignes vides suivies de help n’exécutent donc rien et signalent le help comme ignoré. Augmenter MAX_COMMAND_LINES est le remède à « mon client de messagerie a mis un bloc d’en-têtes devant ma commande », pas une détection des citations.

74.5. La réponse

Un courrier de résultats à la forme d’amont : un préambule, les détails du message d’origine, les résultats, les lignes non traitées et ignorées, puis « - Done. »

Le message d’origine n’est jamais joint. Le From: d’un message de commande est falsifiable : un courrier de résultats part donc vers une adresse qui n’a peut-être rien envoyé, et joindre l’original ferait de cette étape un amplificateur de rétrodiffusion.

74.6. Jetons de confirmation

Un jeton, ce sont 256 bits d’aléa en base32. Il est aussi la sous-adresse -confirm+<token> et le dernier segment de chemin de l’URL de confirmation : en deviner un revient donc à achever l’abonnement de quelqu’un d’autre.

Sa durée de vie dépend de qui l’on attend : un jeton détenu par un modérateur vit 180 jours, tout le reste trois. Un modérateur peut être en congé, et une demande d’abonnement expirée en trois jours serait perdue en silence au lieu d’être tranchée. Les jetons expirés sont balayés par pepsi-list tasks --once, qu’une minuterie systemd exécute ; voir pepsi-list. Supprimer un jeton emporte avec lui l’état de son flux, et c’est ce qui fait qu’une confirmation rejouée ne trouve rien.

74.7. Configuration

[stage-<name>] : PROGRAM = pepsi-stage-list-command, RESPONSE_STAGE (obligatoire — la queue de signature, et non l’étape de remise de liste, qui n’accepte que la copie d’un membre issue de l’éclatement et avalerait une notification), NEXT_STAGE (obligatoire — où va le courrier -owner une fois réadressé ; jamais le routeur de listes) et MAX_COMMAND_LINES (10 par défaut). pepsi-setup vérifie les deux cibles.

74.8. State

• Entrées : state.list – l’identifiant de liste, le rôle que l’adresse désignait et un éventuel jeton -confirm –, écrit par pepsi-stage-list.

• Sorties : des messages de réponse et de notification injectés ; le message de commande lui-même est consommé.

• Transitions : achèvement (un message de commande reçoit une réponse, il n’est pas transféré) ou passage à l’étape suivante pour le transfert -owner.

74.9. Voir aussi

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