85.1.35. pepsi-stage-route

route each recipient to a next hop by their domain

Handbuchabschnitt:

1

85.1.35.1.1. Name

pepsi-stage-route - die Empfängerdomain-Routing-Stage der Pepsi-Pipeline.

85.1.35.1.2. Übersicht

pepsi-stage-route [GLOBAL-OPTIONS] worker

85.1.35.1.3. Beschreibung

pepsi-stage-route ist ein Stage-Programm, das von pepsi-dispatch(1) als persistenter Worker ausgeführt wird, der Nachrichten-IDs von der Standardeingabe liest. Es lädt diesen pepsi.workqueue-Datensatz (und weigert sich zu handeln, sofern sein status nicht running ist), liest seinen [stage-<stage>]-Abschnitt und wählt für jeden Umschlagempfänger eine nächste Stage anhand der Domain dieses Empfängers.

Es existiert für eine einzige Installationsform: ein Gateway, das vor einem anderen Mailsystem sitzt, etwa Microsoft Exchange oder Exchange Online. Ein solches Gateway hat bei jeder eingehenden Nachricht eine Routing-Entscheidung zu treffen — gehört dieser Empfänger zu dem System hinter mir oder ins Internet? —, und sie falsch zu treffen ist kein Zustellfehler, sondern eine Mail-Schleife. Die Domains hinter dem Gateway sind genau die Domains, deren öffentlicher MX das Gateway ist, sodass eine davon einem Direkt-zum-MX-Relay zu übergeben die Nachricht schnurstracks in unseren eigenen Ingress zurückschickt, der sie annimmt, wieder hinausroutet und das wiederholt, bis MAX_HOP_COUNT es stoppt.

Die Stage schreibt die Nachricht nie um, stellt nie zu, erzeugt nie einen Bounce und verwirft nie eine. Die einzige Spalte, die sie bewegt, ist stage, sodass state — einschließlich state.dsn — exakt erhalten bleibt. Weder die Header noch der Nachrichtentext werden geladen.

Anders als bei den übrigen Nur-Metadaten-Stages ist FUSION = yes für sie nicht der Standardwert. Eine fusionierte Stage läuft im Worker-Prozess ihres Vorgängers, und die Empfängerauffächerung dieser Stage weigert sich zu laufen, solange die Inhaltsänderungen eines Vorgängers noch nicht committet sind; statt dieses Zusammenspiel zu einer Laufzeitüberraschung zu machen, wird die Stage immer regulär vom Dispatcher zugeteilt. Siehe pepsi-dispatch(1).

85.1.35.1.4. Routing

Für jeden Empfänger, in dieser Reihenfolge:

1. die ausdrücklichen ROUTES-Regeln, in konfigurierter Reihenfolge — die erste, deren Domainmuster passt, gewinnt;

2. die Menge der verwalteten Domains (MANAGED_DOMAINS, Standardwert [pepsi-ingress] ACCEPTED_DOMAINS) — ein Empfänger an einer dieser Domains geht zu MANAGED_STAGE, sofern diese gesetzt ist;

3. andernfalls NEXT_STAGE.

Ausdrückliche Regeln werden zuerst herangezogen, damit eine Ausnahme ausdrückbar ist: Eine Subdomain einer bedienten Domain kann anderswohin geschickt werden als zu dem System hinter dem Gateway, ohne die Elterndomain aus MANAGED_DOMAINS zu entfernen, was auch dazu führen würde, dass Ingress keine Mail mehr dafür annimmt.

Domainmuster werden ohne Rücksicht auf Groß-/Kleinschreibung verglichen und dürfen * enthalten, das auf eine beliebige Folge von Zeichen passt. Es sind Globs, keine regulären Ausdrücke, und sie sind an beiden Enden verankert: *.example.org passt auf mail.example.org, aber weder auf example.org selbst noch auf mail.example.org.evil.test. Ein Muster, das wie ein regulärer Ausdruck aussieht, wird zur Konfigurationszeit abgelehnt, statt stillschweigend auf nichts zu passen.

MANAGED_DOMAINS fällt auf das zurück, was Ingress annimmt, statt den Operator es wiederholen zu lassen: Eine Routing-Tabelle, die von ACCEPTED_DOMAINS abgedriftet ist, ist genau eine Domain, deren Mail auf die falsche Seite des Gateways geht. Die resultierende Menge darf nicht leer sein: pepsi-setup(1) lehnt eine Route-Stage ohne verwaltete Domains ab, da sie weder die beiden Seiten unterscheiden noch auf die unten beschriebene Schleife prüfen könnte.

85.1.35.1.5. Empfängerauffächerung

Empfänger, die zur selben Stage routen, reisen gemeinsam. Wenn sie auseinandergehen, wird die Nachricht geteilt: Dieser Datensatz behält die erste Gruppe, und jede andere Gruppe wird zu einem Geschwister-pending-Datensatz an ihrem eigenen Ziel, alles in einem Datenbankaufruf. Jedes Geschwister trägt nur seine eigenen Empfänger, und das state.dsn.rcpt jedes Datensatzes wird passend zu seinem rcpt_to zerteilt, sodass ein späterer Bounce oder Zustellbericht weiterhin die richtigen Adressen beschreibt.

Die Gruppierung erfolgt in der Reihenfolge des ersten Auftretens, sodass eine wiederholte Nachricht dieselben Empfänger auf demselben Datensatz behält.

85.1.35.1.6. Schleifenverhinderung

pepsi-setup(1) lehnt eine Konfiguration ab, in der eine Nachricht für eine bediente Domain ein Direkt-zum-MX-Relay (pepsi-stage-relay-to-internet(1)) erreichen könnte. Es geht von jeder Stage aus vorwärts, die ein verwalteter Empfänger erreichen kann, und folgt jeder Option, die die Nachricht selbst weiterschickt: NEXT_STAGE, den Zielen weiterer Routing-Stages, TRUE_STAGE und FALSE_STAGE von pepsi-stage-if(1), ACCEPT_STAGE und QUARANTINE_STAGE von pepsi-stage-milter(1), QUARANTINE_STAGE von pepsi-stage-decrypt(1), SECURE_LINK_STAGE von pepsi-stage-encrypt(1), UNCHALLENGEABLE_STAGE von pepsi-stage-secretary(1) und BOUNCE_TARGET_STAGE von pepsi-stage-anti-spam(1).

Drei Arten von Zielen werden bewusst nicht verfolgt. BOUNCE_STAGE und die Optionen, die einen fehlgeschlagenen Empfänger zu einem Bericht leiten (REJECT_STAGE von pepsi-stage-milter(1), QUOTA_LIMIT_STAGE, SIEVE_REJECT_STAGE, NOTIFY_STAGE und UNKNOWN_MAILBOX_STAGE der lokalen Zustell-Stages): Was dorthin gelangt, wird zu einer DSN mit Null-Absender über eine bereits fehlgeschlagene Zustellung, nicht zu der Nachricht, die die Pipeline weiter durchläuft, und eine DSN erreicht legitimerweise ein Relay. RESPONSE_STAGE und seine Verwandten, die eine neue Nachricht an jemand anderen injizieren. Und die Ziele, die die Nachricht an neue Empfänger umadressieren, die die Pipeline neu routet — RESTART_STAGE von pepsi-stage-dot-forward(1) sowie POST_STAGE, COMMAND_STAGE und DELIVERY_STAGE der Mailinglisten-Stages.

Getrennt davon lehnt pepsi-setup(1) einen [pepsi-stage-relay-to-smarthost-mta-*]-Abschnitt ab, dessen HOST dieser Host ist (sein [pepsi-ingress] HOSTNAME, localhost oder eine Loopback-Adresse) und dessen PORT einer ist, an den ein Ingress-Listener gebunden ist. Beide Hälften sind erforderlich, denn jede allein ist eine legitime Konfiguration.

Es sind Ablehnungen und keine Warnungen. Eine Schleife endet erst, wenn der MAX_HOP_COUNT-Schutz der Relay-Stages greift, Dutzende Kopien später, und der Bounce, den dieser Schutz dann erzeugt, ist selbst zurück in die Schleife adressiert.

85.1.35.1.7. Konfiguration

Die Optionen stehen im eigenen [stage-<name>]-Abschnitt der Stage (PROGRAM = pepsi-stage-route): ROUTES, MANAGED_DOMAINS, MANAGED_STAGE und die erforderliche NEXT_STAGE, dazu RECIPIENT_CHECK (none, probe oder map) mit PROBE_HOST, PROBE_PORT, PROBE_TLS, PROBE_TIMEOUT und RECIPIENT_MAP. Die letzte Gruppe wird nicht von der Stage gelesen: Sie teilt pepsi-ingress(1) mit, wie es das Backend fragen kann, ob eine Adresse existiert, sodass eine unbekannte bereits zum RCPT-Zeitpunkt abgelehnt wird, statt später vom Backend gebounct zu werden. Alle sind in pepsi.conf(5) dokumentiert.

85.1.35.1.8. State

Eingaben: die Umschlagempfänger (rcpt_to). Kein Mitglied von state wird gelesen.

Ausgaben: keine — state wird nie verändert, sondern nur je Empfängergruppe zerteilt, wenn eine Nachricht geteilt wird. Das State-Layout wird in pepsi.state(7) beschrieben.

Übergänge: schaltet zu der Stage weiter, die die Domain jedes Empfängers auswählt, und teilt die Nachricht in Geschwister-pending-Datensätze auf, wenn die Empfänger uneins sind. Die Stage pausiert nie, lässt eine Nachricht nie fehlschlagen, leitet nie um und schließt nie ab.

85.1.35.1.9. Befehle

worker

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

85.1.35.1.10. Globale Optionen

-c FILE, –config FILE

Liest die Konfiguration aus FILE, statt die Standardorte zu durchsuchen.

-L LOGLEVEL, –log LOGLEVEL

Setzt die Log-Ausführlichkeit (Standardwert info).

-v, –verbose

Zeigt Log-Meldungen aus allen Quellen.

-h, –help; -V, –version

Gibt eine Verwendungsübersicht / die Version aus und beendet sich.

85.1.35.1.11. Exit-Status

0

Die Nachricht wurde geroutet (weitergeschaltet und zuvor geteilt, falls ihre Empfänger auseinandergingen).

1

Ein Fehler ist aufgetreten (Nachricht nicht gefunden oder nicht running, fehlkonfigurierte Stage — z. B. ein fehlendes NEXT_STAGE — oder ein Datenbankfehler). Der Grund wird in das Journal geschrieben.

78

Der Worker hat den Start verweigert: Sein Abschnitt lässt sich nicht parsen. Der Dispatcher reiht wieder ein, was er übergeben hatte, und versucht die Stage später erneut. Ein Datenbankfehler während des Aufteilens einer Nachricht wird wie jeder andere Fehler dieses Hosts wiederholt (siehe pepsi-dispatch(1)); eine Wiederholung findet den Datensatz bereits auf die verbliebenen Empfänger reduziert vor und routet sie für sich allein.

85.1.35.1.12. Beispiele

Eine einzelne Nachricht routen (sie muss running sein):

echo 42 | pepsi-stage-route -c /etc/pepsi/pepsi.conf worker

Die Gateway-Topologie in zwei Optionen — Mail für die Domains, die dieser Host bedient, geht zu Exchange, alles andere hinaus ins Internet:

[stage-route]
PROGRAM = pepsi-stage-route
MANAGED_STAGE = exchange
NEXT_STAGE = internet

Dasselbe, mit einer ausgenommenen Alt-Subdomain und einer Partnerdomain, die ihren eigenen nächsten Hop bekommt:

[stage-route]
PROGRAM = pepsi-stage-route
ROUTES = legacy.example.org=maildir partner.example=partner-relay
MANAGED_STAGE = exchange
NEXT_STAGE = internet

85.1.35.1.13. Siehe auch

pepsi-config(1), pepsi-stage-if(1), pepsi-stage-relay-to-smarthost(1), pepsi-stage-relay-to-internet(1), pepsi-dispatch(1), pepsi.conf(5), pepsi.state(7), pepsi-setup(1)

85.1.35.1.14. Fehler

Melden Sie Fehler an den Pepsi-Issue-Tracker.