71. pepsi-stage-list

Entscheidet, welche Umschlagempfänger eine Mailingliste benennen, und routet sie nach Rolle.

71.1. Aufgabe

pepsi-stage-list ist der Mailinglisten-Router. Für jeden Umschlagempfänger fragt die Stage, ob die Adresse eine Liste auf diesem Server benennt, und wenn ja, welche der neun Adressen einer Liste es ist; die Nachricht wird dann an die Stage geroutet, die diese Rolle behandelt. Sie ist die einzige der fünf Listen-Stages, die bei jeder Nachricht läuft, und daher absichtlich günstig: sie lädt den Umschlag und state, niemals die Header oder den Nachrichtentext, und auf einem Server ohne Listen schaltet jede Nachricht unverändert zu NEXT_STAGE weiter. Referenz: pepsi-stage-list(1).

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

71.2. Funktionen

  • Neun Adressen pro Liste. Die Absendeadresse <list>@<host> und die acht Rollen-Subadressen -request, -join, -subscribe, -leave, -unsubscribe, -confirm+<token>, -owner und -bounces (die VERP-Angaben tragen kann, -bounces+alice=example.net).

  • Zuerst die Absendeadresse, dann die Suffixe, längste zuerst. Beide Reihenfolgen sind tragend. Eine Liste darf durchaus foo-request heißen, und würde man zuerst die Suffixe prüfen, wäre sie unerreichbar, sobald jemand eine Liste namens foo anlegt – mit dem Symptom, dass Post an eine echte Liste stillschweigend in den Befehlspfad gerät. Längste zuerst ist der Grund, weshalb -unsubscribe nicht als -subscribe an einem auf -un endenden Stamm gelesen wird.

  • Drei Ziele nach Rolle. Die Absendeadresse geht an POST_STAGE, -bounces an BOUNCE_STAGE, und jede andere Rolle – -owner eingeschlossen – an COMMAND_STAGE, also an die Stage, die schon weiß, wie man die Verwalter einer Liste findet und eine Autoreply-Schleife unterdrückt.

  • Gemischte Empfänger werden aufgeteilt. Eine Nachricht, die an eine Liste und an ein gewöhnliches Postfach oder an zwei Listen adressiert ist, wird zu einem Datensatz pro Ziel, jeder mit seinen eigenen Empfängern und seinem eigenen Ausschnitt aus state.dsn.rcpt. Die Gruppe, die keine Liste ist, bleibt auf dem ursprünglichen Datensatz.

  • Kein Zeitfenster für Veralten. Die Routing-Tabelle wird einmal pro Worker geladen und dadurch aktualisiert, dass der Dispatcher seine Worker außer Dienst stellt, wenn die Datenbank eine Änderung über den Kanal pepsi_list_changed ankündigt; eine während des laufenden Dispatchers angelegte Liste empfängt daher ohne Neustart Post. Die Stage hält keinen eigenen Listener: der Pool eines Workers ist genau eine Verbindung, und ein Listener würde sie für immer belegen.

71.3. Zwei Warnungen

Warnung

BOUNCE_STAGE bedeutet bei dieser Stage das Gegenteil von dem, was es überall sonst in Konfiguration bedeutet. Hier ist es die Stelle, an der ein eingehender Bounce eines anderen verbraucht wird; überall sonst ist es die Stelle, an der Pepsi eine Zustellungsstatusbenachrichtigung erzeugt. Zeigt die Option auf pepsi-stage-bounce, wird ein Bounce mit einem Bounce beantwortet – eine Mailschleife und keine fehlgeleitete Nachricht – und pepsi-setup verweigert diese Konfiguration.

Warnung

[pepsi] RECIPIENT_DELIMITER auf - zu setzen zerstört die Listen-Subadressierung vollständig: jede Subadresse lautet <list>-<role>, die Basis von announce-owner@ wird damit announce, und Post, die für die Verwalter gedacht war, wird stattdessen an die Liste geschickt. Dieselbe Option ist das Trennzeichen, das das Fan-out in jeden VERP-Umschlagabsender und in die -confirm+<token>-Adresse schreibt, sodass der Router immer das auftrennt, was die Listen geschrieben haben.

71.4. Fusion

Ein Fusionsnachfolger läuft nur dann im selben Prozess, wenn sein Load durch das gedeckt ist, was der Vorgänger geladen hat. Diese Stage lädt nur Metadaten und kann daher ihr eigenes Weiterschalten zu NEXT_STAGE fusionieren – den Pfad für alles, was keine Liste ist, also den, der bei jeder Nachricht läuft –, aber sie kann nicht in pepsi-stage-list-post hineinfusionieren, das den Nachrichtentext braucht. Das Routen einer echten Listennachricht kostet daher einen gewöhnlichen Stage-Übergang.

71.5. Konfiguration

[stage-<name>]: PROGRAM = pepsi-stage-list sowie NEXT_STAGE, POST_STAGE, COMMAND_STAGE und BOUNCE_STAGE, alle erforderlich. Die Konfiguration je Liste liegt in der Datenbank und nicht in der Datei; siehe pepsi-list und Mailinglisten.

71.6. State

  • Eingaben: das rcpt_to des Umschlags.

  • Ausgaben: ein state.list-Deskriptor auf jedem gerouteten Datensatz – die Listen-ID, die Rolle, die Adresse, an der die Nachricht eintraf, und was die Subadresse sonst trug (ein -confirm-Token, eine -bounces-VERP-Adresse). Absichtlich klein: alles Weitere liest eine Worker-Stage aus der Datenbank, was sie ohnehin gleich tun wird.

  • Übergänge: Weiterschalten (zu NEXT_STAGE oder zur Stage einer Rolle) und ein Fan-out, wenn die Empfänger aufgeteilt werden.

71.7. Siehe auch

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