85.1.22. pepsi-stage-list-command

subscribe, unsubscribe and confirm by e-mail

Handbuchabschnitt:

1

85.1.22.1.1. Name

pepsi-stage-list-command - die Mailinglisten-Befehls-Stage der Pepsi-Pipeline.

85.1.22.1.2. Übersicht

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

85.1.22.1.3. Beschreibung

pepsi-stage-list-command ist ein Stage-Programm, das von pepsi-dispatch(1) ausgeführt wird. Es behandelt alles, was eine Mailingliste per Mail tut und kein Beitrag ist: die sieben E-Mail-Befehle, beide Abonnement-Abläufe und die Weiterleitung von -owner.

Der Satz, der die ganze Stage bestimmt:

Der einzige Weg, der eine Adresse hinzufügt, ohne dass diese Adresse beweist, dass sie dabei sein will, ist ein ausdrückliches pre_verified und pre_confirmed von einem authentifizierten REST-Client oder der CLI.

Nichts in dieser Stage kann eines der beiden Flags setzen. Eine Nachricht ist kein authentifizierter Client, daher fordert ein join stets die genannte Adresse zur Bestätigung auf oder wird abgelehnt.

85.1.22.1.4. Adressen

Sieben, und die ersten fünf werden überhaupt nicht geparst:

Adresse	Was geschieht
<list>-join,	ein synthetisches join; Betreff und Text werden
<list>-subscribe	nie gelesen, und es wird keine Ergebnismail gesendet
<list>-leave,	ein synthetisches leave, ebenso
<list>-unsubscribe
<list>-confirm+<token>	ein synthetisches confirm, wobei das Token aus der Adresse und nie aus der Nachricht genommen wird
<list>-request	Betreff und Text werden geparst
<list>-owner	überhaupt kein Befehl: an jeden Verwalter und Moderator weitergeleitet

-owner-Mail erreicht den Parser nie, was dem Verhalten von Upstream entspricht und wichtig ist: Eine Nachricht an die Verwalter, deren Betreff zufällig unsubscribe lautet, muss einen Menschen erreichen und darf keinen Befehl ausführen.

85.1.22.1.5. Befehle

confirm	Eine ausstehende Anfrage mit ihrem Token bestätigen.
echo	Die Argumente zurückgeben, zum Testen.
end	Die Befehlsverarbeitung beenden (Alias: stop).
help	Die Befehlsliste oder die Hilfe zu einem Befehl anzeigen.
join	Abonnieren (Alias: subscribe).
leave	Abbestellen (Alias: unsubscribe).
who	Die Mitgliederliste anzeigen, sofern Sie sie sehen dürfen.

Drei davon tragen eine Sicherheitsentscheidung statt einer Formatierungsentscheidung:

• ``confirm`` entfernt Duplikate von Tokens, die in derselben Nachricht bereits bestätigt wurden — ein Mailprogramm, das das Original zitiert, erzeugt das Token zweimal — und beendet die Verarbeitung immer. Ein Token, das nicht passt, erhält dieselbe Antwort wie eines, das abgelaufen ist, weil ihre Unterscheidung ein Orakel dafür wäre, welche Tokens existieren.

• ``leave`` nimmt überhaupt keine Argumente. join address= kostet die genannte Adresse eine Bestätigungsnachricht und abonniert niemanden; ein entsprechendes leave address= würde es einem gefälschten From: erlauben, einen Fremden direkt abzumelden. Die eigene Adresse des Absenders muss zusätzlich verifiziert sein.

• ``who`` ist an member_roster_visibility gebunden, und eine unberechtigte Anfrage wird abgelehnt, statt mit einer leeren Liste beantwortet — eine leere Antwort ist nicht von einer Liste ohne Mitglieder zu unterscheiden, was einem Adresssammler sagt, dass sich ein weiterer Versuch bei der Adresse lohnt.

85.1.22.1.6. Parsen

Die Nachsichtsregeln von Upstream, nachgebildet, weil es zwanzig Jahre an Anleitungen der Art „senden Sie das Wort HELP an …“ gibt:

1. Ein Adressbefehl gewinnt unbedingt (siehe die Tabelle oben).

2. Der Subject: ist die erste Befehlszeile, RFC-2047-dekodiert und dann auf ASCII gezwungen.

3. Der Text trägt nur den ersten ``text/plain``-Teil bei, und davon nur die ersten MAX_COMMAND_LINES Zeilen. Eine Nachricht ohne Klartextteil trägt nichts bei: Befehle aus HTML auszuführen ist eine Stelle, an der Hilfsbereitschaft eine Sicherheitsentscheidung ist.

4. Es gibt keinerlei Behandlung von Zitaten, Signaturen oder --.

5. Jedes Token wird in Kleinbuchstaben umgewandelt; Leerzeilen werden stillschweigend übersprungen.

6. Ein unbekanntes erstes Wort wird nach dem Weglassen von genau einem Wort erneut versucht. Das ist der gesamte Re:-Mechanismus, und er ist bewusst kein allgemeiner Präfix-Entferner — Fwd: help me würde dann help ausführen.

7. Ein Befehl, der die Verarbeitung beendet, beendet den Lauf; der Rest wird als unverarbeitet gemeldet.

8. Vor alldem wird eine Nachricht, die Precedence: bulk, junk oder list ohne X-Ack: yes trägt, stillschweigend verworfen.

Zwei davon sehen wie Fehler aus und sind keine. Die Wiederholung in Regel 6 lässt ein Wort weg und nicht mehr. Und die Obergrenze in Regel 3 zählt Zeilen, nicht Befehle, sodass elf Leerzeilen gefolgt von help nichts ausführen und das help als ignoriert melden — das Anheben von MAX_COMMAND_LINES ist die Lösung für „mein Mailprogramm hat einen Header-Block vor meinen Befehl gesetzt“, nicht eine Zitaterkennung.

85.1.22.1.7. Die Antwort

Eine Ergebnis-Mail in der Form von Upstream: eine Einleitung, die Angaben zur ursprünglichen Nachricht, die Ergebnisse, die nicht verarbeiteten und die ignorierten Zeilen sowie „- Done.“

Die ursprüngliche Nachricht wird nie angehängt. Das From: einer Befehlsnachricht ist fälschbar, sodass eine Ergebnis-Mail an eine Adresse geht, die möglicherweise gar nichts gesendet hat; die ursprüngliche Nachricht anzuhängen, würde diese Stage zu einem Backscatter-Verstärker machen.

85.1.22.1.8. Bestätigungstoken

Ein Token besteht aus 256 Bit Zufall in Base32. Es ist zugleich die Subadresse -confirm+<token> und das letzte Pfadsegment der Bestätigungs-URL, sodass wer eines errät, das Abonnement eines anderen abschließt.

Seine Lebensdauer hängt davon ab, auf wen gewartet wird: Ein Token, das einem Moderator gehört, lebt 180 Tage, alle anderen leben drei. Ein Moderator kann im Urlaub sein, und eine Abonnementanfrage, die nach drei Tagen abliefe, ginge stillschweigend verloren, statt entschieden zu werden.

Abgelaufene Token werden von pepsi-list tasks --once entfernt, das ein systemd-Timer ausführt; siehe pepsi-list(1). Das Löschen eines Tokens verwirft seinen Workflow-Zustand mit, und genau das lässt eine wiedereingespielte Bestätigung nichts finden.

85.1.22.1.9. Konfiguration

RESPONSE_STAGE (erforderlich)

Wohin Antworten und Bestätigungshinweise eingespeist werden. Das Signier-Ende der Pipeline, nicht die Listen-Zustell-Stage: pepsi-stage-list-deliver(1) nimmt nur die Kopie eines Mitglieds aus dem Fan-out an und lässt alles andere fehlschlagen, sodass ein dorthin gesendeter Hinweis nie hinausgeht. pepsi-setup(1) weist den falschen Wert zurück.

NEXT_STAGE (erforderlich)

Wohin -owner-Mail geht, nachdem sie an die Eigentümer der Liste umadressiert wurde. pepsi-setup weist einen Wert zurück, der zurück auf den Router zeigt, was die Weiterleitung erneut routen und eine Schleife erzeugen würde.

MAX_COMMAND_LINES (Standard 10)

Wie viele Zeilen des Nachrichtentexts der Parser liest — Upstreams [mailman] email_commands_max_lines. Zählt Zeilen, nicht Befehle.

85.1.22.1.10. State

Eingaben: state.list.id und state.list.role (geschrieben von pepsi-stage-list(1)) sowie state.list.token für eine -confirm-Adresse.

Ausgaben: keine. Alles, was diese Stage ändert, ist eine Datenbankzeile.

Übergänge: beendet (jeder Befehlspfad) oder schaltet zu NEXT_STAGE weiter (die -owner-Weiterleitung).

85.1.22.1.11. Befehle

worker

Läuft als persistenter pepsi-dispatch(1)-Worker, der Nachrichten-IDs von der Standardeingabe liest.

85.1.22.1.12. Globale Optionen

Die übliche Gruppe — -c/–config, -L/–log, -v/–verbose, -h/–help und -V/–version —, die sich wie bei jedem Pepsi-Programm verhält; siehe pepsi-config(1).

85.1.22.1.13. Fehler und Wiederholungen

Eine Nachricht, die eine nicht mehr existierende Liste nennt, wird dem Absender über die BOUNCE_STAGE der Stage gemeldet (eine DSN pro Empfänger, die besagt, dass die Mailingliste nicht mehr existiert), oder sie schlägt fehl, wenn die Stage keine hat; eine Null-Absender-Nachricht wird stattdessen verworfen. Eine Nachricht, die der MIME-Parser ablehnt, schlägt sofort fehl. Jeder andere Fehler ist ein Fehler des Hosts und wird mit Backoff bis MAX_LIFETIME wiederholt (siehe pepsi-dispatch(1)).

Der Anspruch auf die Karenzzeit für die Ergebnis-Mail wird festgehalten, bevor list_command_commit die Befehle und die Mail festschreibt, und ist daher an das Warteschlangen-Token der Nachricht gebunden: Eine Nachricht, die wiederholt wird, nachdem dieses Festschreiben fehlschlug, darf ihre Ergebnisse erneut senden, statt zu hören, sie sei heute bereits beantwortet worden.

85.1.22.1.14. Exit-Status

0

Die Nachricht wurde verarbeitet.

1

Der Worker konnte nicht laufen (seine Datenbank ließ sich nicht öffnen, oder Standardein-/-ausgabe schlug fehl). Der Grund wird in das Log geschrieben.

85.1.22.1.15. Beispiele

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

85.1.22.1.16. Siehe auch

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

Melden Sie Fehler an den Pepsi-Issue-Tracker.