85.1.19. pepsi-stage-list

route mail addressed to a mailing list

Handbuchabschnitt:

1

85.1.19.1.1. Name

pepsi-stage-list - der Mailinglisten-Router der Pepsi-Pipeline.

85.1.19.1.2. Übersicht

pepsi-stage-list [GLOBAL-OPTIONS] worker

85.1.19.1.3. Beschreibung

pepsi-stage-list ist ein Stage-Programm, das von pepsi-dispatch(1) ausgeführt wird. Es betrachtet jeden Umschlagempfänger, entscheidet, ob er eine Mailingliste auf diesem Server benennt, und leitet die Nachricht entsprechend weiter. Es ist die einzige der fünf Listen-Stages, die auf jeder Nachricht läuft, und ist daher absichtlich billig: Es lädt den Umschlag und state, aber nie die Header oder den Nachrichtentext.

Pepsis Mailinglisten-Subsystem ist eine Neuimplementierung von GNU Mailman 3: Das Adressvokabular, das diese Stage erkennt – die Beitragsadresse und die acht Rollen-Subadressen –, stammt von Upstream, Copyright der Free Software Foundation und ihrer Mitwirkenden, damit ein von Mailman migrierender Standort jede Adresse behält, die seine Abonnenten bereits verwenden. Dateien in Pepsi, die aus GNU Mailman stammen, stehen weiterhin unter der GNU General Public License; siehe pepsi-list(1) für die ausführlichere Erklärung und vendor/PEPSI-VENDORING.md für die Liste.

Ein Server, der keine Listen beherbergt, ist davon nicht betroffen. Ohne konfigurierte Listen ist die Routing-Tabelle leer und jede Nachricht wird zu NEXT_STAGE weitergeschaltet; deshalb ist es harmlos, den Abschnitt in eine bestehende Pipeline einzufügen.

85.1.19.1.4. Erkannte Adressen

Für jeden Empfänger prüft die Stage in dieser Reihenfolge:

• die Beitragsadresse <list>@<host>;

• dann die acht Rollen-Subadressen -request, -join, -subscribe, -leave, -unsubscribe, -confirm+<token>, -owner und -bounces (optional mit VERP-Detail, -bounces+alice=example.net).

Beitragsadressen werden vor den Suffixen geprüft, und die Suffixe werden vom längsten zum kürzesten versucht. Beide Reihenfolgen sind wichtig. Eine Liste darf legitim foo-request heißen; würden zuerst die Suffixe geprüft, wäre sie in dem Moment unerreichbar, in dem jemand eine Liste namens foo anlegt, und das Symptom wäre, dass Mail an eine echte Liste stillschweigend in den Befehlspfad gerät. Die Reihenfolge vom längsten Suffix an ist der Grund, warum -unsubscribe nicht als -subscribe mit einem auf -un endenden Stamm gelesen wird.

Warnung

[pepsi] RECIPIENT_DELIMITER auf - zu setzen, zerstört die Listen-Subadressierung vollständig. Jede Subadresse ist <list>-<role>, sodass mit - als Trennzeichen die Basis von announce-owner@ announce ist — die Beitragsadresse —, und Mail, die für die Eigentümer gedacht ist, wird stattdessen an die Liste gesendet. 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.

85.1.19.1.5. Routing

Ein Empfänger, der eine Liste benennt, wird je nach Rolle an eine von drei Stages geleitet:

Rolle	Stage-Option
die Beitragsadresse	POST_STAGE
-bounces	BOUNCE_STAGE
jede andere Rolle	COMMAND_STAGE

-owner geht an die Befehls-Stage, obwohl es keinen Befehl trägt: Sie ist die Stage, die weiß, wie man die Eigentümer einer Liste nachschlägt und wie man eine Auto-Reply-Schleife unterdrückt, und ihr eine vierte eigene Stage zu geben, würde beides duplizieren.

Eine Nachricht, die an eine Liste und an ein gewöhnliches Postfach — oder an zwei Listen — adressiert ist, wird aufgeteilt, eine Zeile je Ziel, jede mit ihren eigenen Empfängern und ihrem eigenen Ausschnitt von state.dsn.rcpt. Die Nicht-Listen-Gruppe bleibt, sofern es eine gibt, auf der ursprünglichen Zeile.

Warnung

BOUNCE_STAGE bedeutet hier das Gegenteil dessen, was es auf jeder anderen Stage in pepsi.conf(5) bedeutet. Auf dieser Stage ist es der Ort, an dem der eingehende Bounce eines anderen verbraucht wird; überall sonst ist es der Ort, an dem Pepsi eine DSN erzeugt. Es auf pepsi-stage-bounce(1) zu richten, beantwortet einen Bounce mit einem Bounce — eine Mailschleife statt einer fehlgeleiteten Nachricht —, und pepsi-setup weist diese Konfiguration zurück.

85.1.19.1.6. Aktualität

Die Routing-Tabelle wird einmal je Worker geladen und aufgefrischt, indem der Dispatcher seine Worker ausmustert, wenn die Datenbank auf dem Kanal pepsi_list_changed eine Änderung ankündigt. Eine Liste, die angelegt wird, während der Dispatcher läuft, empfängt daher ohne Neustart und ohne Zeitfenster veralteter Daten Mail. Die Stage selbst hält keinen Listener: Der Verbindungspool eines Stage-Workers umfasst genau eine Verbindung, und ein Listener im Worker würde sie für immer belegen.

85.1.19.1.7. Fusion

Ein Fusionsnachfolger darf nur dann im Prozess laufen, wenn sein Load durch das erfüllt wird, was der Vorgänger bereits geladen hat. Diese Stage lädt nur Metadaten, kann also ihr eigenes Weiterschalten zu NEXT_STAGE fusionieren — den Nicht-Listen-Pfad, der auf jeder Nachricht läuft —, aber nicht in pepsi-stage-list-post(1) fusionieren, das den Nachrichtentext braucht. Das Routing eines tatsächlichen Listenbeitrags kostet einen gewöhnlichen Stage-Übergang.

85.1.19.1.8. Konfiguration

NEXT_STAGE, POST_STAGE, COMMAND_STAGE und BOUNCE_STAGE, alle vier erforderlich, im eigenen [stage-<name>]-Abschnitt der Stage. Die listenbezogene Konfiguration liegt in der Datenbank, nicht hier; siehe pepsi-list(1).

85.1.19.1.9. State

Eingaben: der Umschlag-rcpt_to.

Ausgaben: ein state.list-Deskriptor auf jeder weitergeleiteten Zeile — die ID der Liste, die Rolle, die Adresse, an der die Nachricht ankam, und welches Detail auch immer die Subadresse trug (ein -confirm-Token, eine -bounces-VERP-Adresse). Absichtlich klein: Alles andere, was die bearbeitende Stage braucht, liest sie aus der Datenbank, was sie ohnehin gleich tut.

Übergänge: schaltet weiter (zu NEXT_STAGE oder zur Stage einer Rolle) und fächert auf, wenn sich die Empfänger aufteilen.

85.1.19.1.10. Befehle

worker

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

85.1.19.1.11. 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.19.1.12. Exit-Status

0

Die Nachricht wurde weitergeleitet.

1

Ein Fehler ist aufgetreten (eine falsch konfigurierte Stage oder ein Datenbankfehler).

85.1.19.1.13. Beispiele

[stage-list]
PROGRAM = pepsi-stage-list
NEXT_STAGE = aliases
POST_STAGE = list-post
COMMAND_STAGE = list-command
BOUNCE_STAGE = list-bounce

85.1.19.1.14. Siehe auch

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

85.1.19.1.15. Fehler

Melden Sie Fehler an den Pepsi-Issue-Tracker.