74. pepsi-stage-list-command

Abonnieren, abmelden und bestätigen per E-Mail; Weiterleitung von `-owner`-Post.

74.1. Aufgabe

pepsi-stage-list-command behandelt alles, was eine Mailingliste per Post tut und was keine Listennachricht ist: die sieben E-Mail-Befehle, beide Abonnementabläufe und die -owner-Weiterleitung. Referenz: pepsi-stage-list-command(1).

Ein Satz bestimmt die ganze Stage:

Der einzige Weg, auf dem eine Adresse hinzugefügt wird, ohne dass diese Adresse belegt hat, dass sie dort sein will, ist ein ausdrückliches pre_verified und pre_confirmed von einem authentifizierten REST-Client oder von der Kommandozeile.

Nichts in dieser Stage kann eines der beiden Flags setzen. Eine Nachricht ist kein authentifizierter Client, ein join bittet daher stets die genannte Adresse um Bestätigung oder verweigert.

Dieses Subsystem ist eine Neuimplementierung von GNU Mailman 3; siehe Mailinglisten, wo benannt ist, was von upstream übernommen wurde.

74.2. Adressen

Sieben, und die ersten fünf werden überhaupt nicht geparst: -join/-subscribe werden zu einem synthetischen join (Betreff und Nachrichtentext werden nie gelesen, und es wird keine Ergebnismail gesendet), -leave/-unsubscribe ebenso zu einem synthetischen leave, und -confirm+<token> zu einem synthetischen confirm, dessen Token aus der Adresse und niemals aus der Nachricht stammt. -request ist die eine, deren Betreff und Nachrichtentext geparst werden. -owner ist überhaupt kein Befehl: sie wird an alle Verwalter und Moderatoren weitergeleitet und erreicht den Parser nie — was das Verhalten von upstream ist und darauf ankommt, denn eine Nachricht an die Verwalter, deren Betreff zufällig unsubscribe lautet, muss einen Menschen erreichen und keinen Befehl ausführen.

74.3. Befehle

confirm, echo, end (Alias stop), help, join (Alias subscribe), leave (Alias unsubscribe) und who. Drei davon tragen eine Sicherheitsentscheidung und keine Formatierungsfrage.

• ``confirm`` entfernt Token, 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 ein abgelaufenes, denn sie zu unterscheiden wäre ein Orakel dafür, welche Token es gibt.

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

• ``who`` hängt an member_roster_visibility, und eine unbefugte Anfrage wird verweigert und nicht mit einer leeren Liste beantwortet – eine leere Antwort ist von einer Liste ohne Mitglieder nicht zu unterscheiden, und das sagt einem Adresssammler, dass die Adresse einen weiteren Versuch wert ist.

74.4. Parsen

Die Kulanzregeln von upstream, nachgebildet, weil es zwanzig Jahre Anleitungen der Form „senden Sie das Wort HELP an …“ gibt. Ein Adressbefehl gewinnt unbedingt. Der Subject: ist die erste Befehlszeile, nach RFC 2047 dekodiert und dann auf ASCII gezwungen. Der Nachrichtentext 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, denn Befehle aus HTML auszuführen ist eine Stelle, an der Hilfsbereitschaft eine Sicherheitsentscheidung ist. Es gibt überhaupt keine Behandlung von Zitaten, Signaturen oder --; jedes Token wird kleingeschrieben; leere Zeilen werden übersprungen. Ein unbekanntes erstes Wort wird nach dem Weglassen von genau einem Wort erneut versucht, und das ist der ganze Re:-Mechanismus und absichtlich kein allgemeiner Präfixentferner (Fwd: help me würde sonst help ausführen). Ein Befehl, der beendet, schließt den Durchlauf ab, und der Rest wird als unverarbeitet gemeldet. Vor allem dem wird eine Nachricht mit Precedence: bulk|junk|list ohne X-Ack: yes stillschweigend verworfen.

Zwei davon sehen wie Fehler aus und sind keine: der erneute Versuch lässt ein Wort weg und nicht mehr, und die Obergrenze zählt Zeilen und nicht Befehle – elf leere Zeilen, gefolgt von help, führen also nichts aus und melden das help als übergangen. MAX_COMMAND_LINES zu erhöhen ist die Lösung für „mein Mailprogramm hat einen Headerblock vor meinen Befehl gesetzt“ und nicht Zitaterkennung.

74.5. Die Antwort

Eine Ergebnismail in der Gestalt von upstream: eine Vorrede, die Angaben zur ursprünglichen Nachricht, die Ergebnisse, die unverarbeiteten und übergangenen Zeilen und „- Done.“

Die ursprüngliche Nachricht wird nie beigefügt. Das From: einer Befehlsnachricht ist fälschbar, eine Ergebnismail geht also an eine Adresse, die möglicherweise nichts gesendet hat; das Original beizufügen würde diese Stage zu einem Backscatter-Verstärker machen.

74.6. Bestätigungstoken

Ein Token sind 256 Bit Zufall in Base32. Es ist gleichzeitig die Subadresse -confirm+<token> und das letzte Pfadsegment der Bestätigungs-URL; eines zu erraten heißt also, jemandes Abonnement abzuschließen.

Seine Lebensdauer richtet sich danach, auf wen gewartet wird: ein Token, das einem Moderator gehört, lebt 180 Tage, alles andere drei. Ein Moderator kann im Urlaub sein, und eine Abonnementanfrage, die nach drei Tagen verfällt, wäre stillschweigend verloren statt entschieden. Abgelaufene Token räumt pepsi-list tasks --once weg, was ein systemd-Timer ausführt; siehe pepsi-list. Ein Token zu löschen verwirft den zugehörigen Ablaufzustand mit, und genau das lässt eine wiederholte Bestätigung nichts mehr finden.

74.7. Konfiguration

[stage-<name>]: PROGRAM = pepsi-stage-list-command, RESPONSE_STAGE (erforderlich — das Signaturende und nicht die Listenzustellstage, die nur die Kopie eines Mitglieds aus dem Fan-out annimmt und eine Benachrichtigung verschlucken würde), NEXT_STAGE (erforderlich — wohin -owner-Post nach der Umadressierung geht; nie der Listenrouter) und MAX_COMMAND_LINES (Standardwert 10). pepsi-setup prüft beide Ziele.

74.8. State

• Eingaben: state.list – die Listen-ID, die von der Adresse benannte Rolle und ein etwaiges -confirm-Token –, geschrieben von pepsi-stage-list.

• Ausgaben: eingespeiste Antwort- und Benachrichtigungsnachrichten; die Befehlsnachricht selbst wird verbraucht.

• Übergänge: Abschließen (eine Befehlsnachricht wird beantwortet, nicht weitergeleitet) oder Weiterschalten für die -owner-Weiterleitung.

74.9. Siehe auch

Mailinglisten, pepsi-stage-list, pepsi-stage-list-post, pepsi-list, pepsi-stage-list-command(1).