58. pepsi-stage-route

Jeden Empfänger zum nächsten Hop schicken, den seine Domain auswählt.

58.1. Rolle

pepsi-stage-route trifft die eine Routing-Entscheidung, die ein Gateway vor einem anderen Mailsystem bei jeder eingehenden Nachricht hat: Gehört dieser Empfänger zu dem System hinter mir oder ins Internet? Es wählt je Umschlagempfänger eine nächste Stage anhand der Domain dieses Empfängers und teilt die Nachricht, wenn die Empfänger uneins sind. Es bewegt nur die stage-Spalte — es schreibt eine Nachricht nie um, stellt sie nie zu, bounct oder verwirft sie nie, und state (einschließlich state.dsn) bleibt erhalten. Referenz: pepsi-stage-route(1).

Diese Entscheidung 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. Siehe Microsoft Exchange als Gateway für die Installation, für die es diese Stage gibt.

58.2. Funktionen

  • Standardmäßig verwaltete Domains. MANAGED_DOMAINS fällt auf [pepsi-ingress] ACCEPTED_DOMAINS zurück, sodass die Menge der als „hinter dem Gateway“ behandelten Domains nicht von der Menge abdriften kann, die Ingress tatsächlich annimmt. Mit gesetztem MANAGED_STAGE besteht die gesamte Gateway-Topologie aus zwei Optionen.

  • Ausdrückliche Regeln für Ausnahmen. ROUTES nimmt durch Leerraum oder Kommata getrennte <domain>=<stage>-Paare, die vor der verwalteten Menge herangezogen werden, sodass eine Subdomain anderswohin gehen kann, ohne ihre Elterndomain aus MANAGED_DOMAINS zu entfernen (was auch dazu führen würde, dass Ingress sie nicht mehr annimmt).

  • Glob-Muster, keine regulären Ausdrücke. * passt auf eine beliebige Folge von Zeichen, und der Treffer ist an beiden Enden verankert: *.example.org passt auf mail.example.org, aber weder auf example.org 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.

  • Empfängerauffächerung je Gruppe. Auseinandergehende Empfänger werden in einem Datenbankaufruf zu Geschwister-pending-Datensätzen, von denen jeder nur seine eigenen Empfänger trägt, mit state.dsn.rcpt passend zu rcpt_to zerteilt.

  • Deterministische Gruppierung. Gruppen werden in der Reihenfolge des ersten Auftretens gebildet, sodass eine wiederholte Nachricht dieselben Empfänger auf demselben Datensatz behält.

  • Nur Metadaten. Weder die Header noch der Nachrichtentext werden geladen.

Bemerkung

Anders als die übrigen Nur-Metadaten-Stages hat diese nicht den Standardwert FUSION = yes. Auf dem Papier ist sie ein Kandidat — sie ist in das vereinheitlichte Binärprogramm eingefaltet und lädt keinen Nachrichteninhalt —, aber eine fusionierte Stage läuft im Worker ihres Vorgängers, und die Empfängerauffächerung dieser Stage weigert sich zu laufen, solange nicht committete Inhaltsänderungen eines Vorgängers ausstehen. Statt dieses Zusammenspiel zu einer Laufzeitüberraschung zu machen, wird die Stage schlicht normal dispatcht.

58.3. Schleifenverhinderung

pepsi-setup lehnt ab — warnt nicht bloß vor — zwei Konfigurationen:

  • eine, in der eine Nachricht für eine bediente Domain pepsi-stage-relay-to-internet erreichen könnte; ermittelt, indem von jeder Stage aus, die ein verwalteter Empfänger erreichen kann, entlang jeder Option vorwärts gegangen wird, die die Nachricht selbst weiterschickt — NEXT_STAGE, Routenziele, TRUE_STAGE und FALSE_STAGE von pepsi-stage-if, ACCEPT_STAGE/QUARANTINE_STAGE eines Milters, QUARANTINE_STAGE von decrypt, SECURE_LINK_STAGE von encrypt, UNCHALLENGEABLE_STAGE des Sekretärs und BOUNCE_TARGET_STAGE der Paywall. BOUNCE_STAGE und die anderen Fehlerrouten (REJECT_STAGE eines Milters, die Quota-, Sieve-, Benachrichtigungs- und Unbekanntes-Postfach-Ziele der lokalen Zustell-Stages) werden nicht verfolgt: Was dorthin gelangt, wird zu einer DSN mit Null-Absender über eine bereits fehlgeschlagene Zustellung und erreicht legitimerweise ein Relay. Ebenso wenig Ziele nach Art von RESPONSE_STAGE (eine neue Nachricht an jemand anderen), ein RESTART_STAGE von ~/.forward oder die Ziele der Mailinglisten-Stages, die die Nachricht an neue Empfänger umadressieren.

  • ein [pepsi-stage-relay-to-smarthost-mta-*]-Abschnitt, dessen HOST dieser Host ist und dessen PORT einer ist, an den ein Ingress-Listener gebunden ist. Beide Hälften sind erforderlich — ein Standort darf legitimerweise ein unabhängiges Relay auf demselben Host betreiben oder auf Port 25 eine andere Maschine erreichen.

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

58.4. Konfiguration

Option

Bedeutung

ROUTES

Durch Leerraum/Kommata getrennte <domain-pattern>=<stage>-Paare, zuerst und der Reihe nach herangezogen. Optional.

MANAGED_DOMAINS

Die Domains hinter diesem Gateway. Standardwert ist [pepsi-ingress] ACCEPTED_DOMAINS; mindestens eine ist erforderlich.

MANAGED_STAGE

Wohin ein Empfänger an einer verwalteten Domain geht. Optional; ohne diese Option nehmen verwaltete Empfänger NEXT_STAGE, von dem pepsi-setup dann nachweisen muss, dass es keine Schleife ist.

NEXT_STAGE

Wohin jeder andere Empfänger geht. Erforderlich — die Stage stellt nie zu, bounct nie und verwirft nie, sodass jeder Empfänger irgendwohin muss.

58.5. Platzierung

Auf dem eingehenden Pfad, nach Authentifizierung und Entschlüsselung und vor den Relay-Stages — typischerweise arc → decrypt → aliases → route, wobei MANAGED_STAGE die Smarthost-Stage benennt, die zu Exchange weiterleitet, und NEXT_STAGE die Direkt-zum-MX-Stage.

58.6. Siehe auch