85.1.22. pepsi-stage-list-command

subscribe, unsubscribe and confirm by e-mail

Section du manuel:

1

85.1.22.1.1. Nom

pepsi-stage-list-command - l’étape de commandes des listes de diffusion du pipeline Pepsi.

85.1.22.1.2. Synopsis

pepsi-stage-list-command [GLOBAL-OPTIONS] worker

85.1.22.1.3. Description

pepsi-stage-list-command est un programme d’étape exécuté par pepsi-dispatch(1). Il traite tout ce qu’une liste de diffusion fait par courrier et qui n’est pas une contribution : les sept commandes par e-mail, les deux flux d’abonnement et le transfert -owner.

La phrase qui 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.

85.1.22.1.4. Adresses

Sept, et les cinq premières ne sont pas analysées du tout :

Adresse

Ce qui se passe

<list>-join,

un join synthétique ; le Subject et le corps ne sont

<list>-subscribe

jamais lus, et aucun courrier de résultats n’est envoyé

<list>-leave,

un leave synthétique, de même

<list>-unsubscribe

<list>-confirm+<token>

un confirm synthétique, le jeton étant pris dans l”adresse et jamais dans le message

<list>-request

le Subject et le corps sont analysés

<list>-owner

pas du tout une commande : transféré à chaque propriétaire et modérateur

Le courrier -owner n’atteint jamais l’analyseur, ce qui est le comportement d’amont et a son importance : un message aux propriétaires dont le Subject se trouve être unsubscribe doit atteindre un humain, pas exécuter une commande.

85.1.22.1.5. Commandes

confirm

Confirmer une demande en attente à l’aide de son jeton.

echo

Renvoyer les arguments en écho, pour les tests.

end

Arrêter le traitement des commandes (alias : stop).

help

Afficher la liste des commandes, ou l’aide d’une commande.

join

S’abonner (alias : subscribe).

leave

Se désabonner (alias : unsubscribe).

who

Afficher la liste des membres, si vous êtes autorisé à la voir.

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.

85.1.22.1.6. Analyse

Les règles de tolérance d’amont, reproduites parce qu’il existe vingt ans d’instructions du type « envoyez le mot HELP à… » :

  1. Une commande d’adresse l’emporte d’emblée (voir le tableau ci-dessus).

  2. Le Subject: est la première ligne de commande, décodée selon la RFC 2047 puis ramenée à l’ASCII.

  3. 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 rien : exécuter des commandes tirées du HTML est un domaine où se montrer serviable est une décision de sécurité.

  4. Il n’y a aucun traitement des citations, des signatures ni de --.

  5. Chaque jeton est mis en minuscules ; les lignes vides sont sautées en silence.

  6. Un premier mot inconnu est réessayé après avoir retiré exactement un mot. C’est là tout le mécanisme de Re:, et ce n’est délibérément pas un suppresseur de préfixes général — Fwd: help me exécuterait alors help.

  7. Une commande qui s’arrête met fin à l’exécution ; le reste est signalé comme non traité.

  8. Avant tout cela, un message portant Precedence: bulk, junk ou list sans X-Ack: yes est écarté en silence.

Deux de ces règles ressemblent à des bogues et n’en sont pas. Le nouvel essai de la règle 6 retire un mot et pas davantage. Et le plafond de la règle 3 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.

85.1.22.1.7. 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.

85.1.22.1.8. 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(1). Supprimer un jeton supprime avec lui l’état de son flux, ce qui fait qu’une confirmation rejouée ne trouve rien.

85.1.22.1.9. Configuration

RESPONSE_STAGE (obligatoire)

L’endroit où les réponses et les avis de confirmation sont injectés. La queue de signature, et non l’étape de remise de liste : pepsi-stage-list-deliver(1) n’accepte que la copie d’un membre issue de l’éclatement et fait échouer tout le reste, de sorte qu’un avis envoyé là ne part jamais. pepsi-setup(1) refuse la mauvaise valeur.

NEXT_STAGE (obligatoire)

L’endroit où va le courrier -owner une fois réadressé aux propriétaires de la liste. pepsi-setup refuse une valeur qui pointe de nouveau vers le routeur, ce qui réacheminerait le transfert et bouclerait.

MAX_COMMAND_LINES (par défaut 10)

Le nombre de lignes du corps que lit l’analyseur — le [mailman] email_commands_max_lines d’amont. Compte des lignes, et non des commandes.

85.1.22.1.10. État

Entrées : state.list.id et state.list.role (écrits par pepsi-stage-list(1)), et state.list.token pour une adresse -confirm.

Sorties : aucune. Tout ce que cette étape modifie est un enregistrement de la base de données.

Transitions : achèvement (tous les chemins de commande) ou passage à NEXT_STAGE (le transfert -owner).

85.1.22.1.11. Commandes

worker

Exécuté comme un worker persistant de pepsi-dispatch(1), lisant les identifiants de message sur l’entrée standard.

85.1.22.1.12. Options globales

L’ensemble habituel — -c/–config, -L/–log, -v/–verbose, -h/–help et -V/–version — qui se comporte comme pour tout programme Pepsi ; voir pepsi-config(1).

85.1.22.1.13. Erreurs et réessais

Un message qui nomme une liste qui n’existe plus est signalé à l’expéditeur via le BOUNCE_STAGE de l’étape (un DSN par destinataire, indiquant que la liste de diffusion n’existe plus), ou mis en échec lorsque l’étape n’en a pas ; un message à expéditeur nul est au contraire abandonné. Un message que l’analyseur MIME refuse est mis en échec immédiatement. Toute autre erreur est une défaillance de l’hôte et est réessayée avec un back-off jusqu’à MAX_LIFETIME (voir pepsi-dispatch(1)).

La réservation du délai de grâce pour le courrier de résultats est enregistrée avant que list_command_commit ne valide les commandes et le courrier ; elle est donc indexée sur le jeton de file du message : un message réessayé après l’échec de cette validation peut renvoyer ses résultats plutôt que de s’entendre dire qu’il a déjà reçu une réponse aujourd’hui.

85.1.22.1.14. Code de sortie

0

Le message a été traité.

1

Le worker n’a pas pu s’exécuter (sa base de données n’a pas pu être ouverte, ou l’entrée/sortie standard a échoué). La raison est écrite dans le journal.

85.1.22.1.15. Exemples

[stage-list-command]
PROGRAM = pepsi-stage-list-command
RESPONSE_STAGE = dkim-sign
NEXT_STAGE = local
MAX_COMMAND_LINES = 10

85.1.22.1.16. Voir aussi

pepsi-list(1), pepsi-stage-list(1), pepsi-stage-list-post(1), pepsi-dispatch(1), pepsi.conf(5), pepsi.state(7), pepsi-setup(1)

85.1.22.1.17. Bogues

Signalez les bogues au gestionnaire de tickets de Pepsi.