85.1.11. pepsi-stage-relay-to-smarthost

relay a message through an upstream smarthost

Handbuchabschnitt:

1

85.1.11.1.1. Name

pepsi-stage-relay-to-smarthost - die Smarthost-Zustell-Stage der Pepsi-Pipeline.

85.1.11.1.2. Übersicht

pepsi-stage-relay-to-smarthost [GLOBAL-OPTIONS] worker

85.1.11.1.3. Beschreibung

pepsi-stage-relay-to-smarthost 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 leitet die Nachricht an einen konfigurierten vorgelagerten MTA (Smarthost) weiter. Wie bei pepsi-stage-relay-to-internet(1) wird ein Datensatz mit mehreren Empfängern zuerst in einen Datensatz je Empfänger aufgeteilt, und eine Nachricht mit mehr als MAX_HOP_COUNT Received:-Header-Feldern schlägt als Mailschleife dauerhaft fehl.

Die Domain des Empfängers wählt den Smarthost: den Abschnitt [pepsi-stage-relay-to-smarthost-mta-<name>], dessen DOMAINS sie auflistet, oder den Catch-All-MTA (CATCH_ALL = yes). Eine Domain darf nur von einem MTA aufgeführt werden, und höchstens ein MTA darf der Catch-All sein. Diese MTA-Abschnitte werden von allen Egress-Stages geteilt (siehe pepsi.conf(5)). Die Nachricht wird mit ihrem eigenen Umschlagabsender gesendet, unter Verwendung des konfigurierten Transports des MTA (MODE = plain/tls/starttls, Standardwert starttls), seiner Zertifikatsverifikation und seiner Authentifizierung.

Bei Erfolg wird der Datensatz entfernt (oder, falls die Stage NEXT_STAGE setzt, weitergeschaltet). Ein vorübergehender Fehler pausiert die Nachricht mit einem exponentiellen Backoff (von pepsi-dispatch(1) erneut eingereiht, wenn ihr timeout abläuft); nach MAX_LIFETIME wird der Fehler als dauerhaft behandelt. Ein dauerhafter Fehler — einschließlich eines Empfängers ohne passenden MTA — wird zum BOUNCE_STAGE der Stage geroutet (oder, ohne ein solches, wird der Datensatz als failed markiert). Ein dauerhafter Fehler eines Bounces (Null-Absender) wird verworfen, statt erneut einen Bounce zu erzeugen. pepsi-setup(1) lehnt eine Stage ganz ohne [pepsi-stage-relay-to-smarthost-mta-*]-Abschnitt ab (sie würde jede Nachricht bouncen) und warnt, wenn kein MTA CATCH_ALL setzt, unter Nennung der gerouteten Domains.

Anders als pepsi-stage-relay-to-internet(1) führt pepsi-stage-relay-to-smarthost keine MX-Ermittlung durch und verwendet nie DNS-gelerntes MTA-STS: Es spricht nur mit den in der Konfiguration benannten Smarthosts.

DSN (RFC 3461): Kündigt der Smarthost die Erweiterung DSN an, werden die vom Ursprung angeforderten Parameter (RET/ENVID bei MAIL FROM und das NOTIFY/ORCPT des Empfängers bei RCPT TO, aus dem state.dsn des Datensatzes gelesen) an ihn propagiert; kündigt er DSN nicht an, werden sie weggelassen. Bei einem dauerhaften Fehler werden das NOTIFY/ORCPT des Empfängers und das ENVID an die Bounce-Stage übergeben, sodass eine Failure-DSN nur dann erzeugt wird, wenn der Absender eine angefordert hat. Diese Stage bewahrt state.dsn.

Wenn das globale [pepsi]-ORIGINATE_SUCCESS_DSN aktiviert ist und der Empfänger einer erfolgreichen Zustellung NOTIFY=SUCCESS angefordert hat, wird die Nachricht (nach der Zustellung) zu BOUNCE_STAGE geroutet, das einen positiven (Action: delivered-)Bericht an den Absender ausgibt. Mit ausgeschaltetem Flag oder ohne eine SUCCESS-Anforderung wird eine erfolgreiche Zustellung einfach abgeschlossen.

Wenn DELAY_DSN_AFTER gesetzt ist und eine noch nicht zugestellte Nachricht mindestens so lange eingereiht war, wird dem Absender eine einmalige „verzögerte“ (Action: delayed-)DSN gesendet — aber nur, wenn der Absender NOTIFY=DELAY angefordert hat (Delay hat keinen impliziten Standardwert). Die ursprüngliche Nachricht wird weiterhin wiederholt; die Warnung ist eine separate Nachricht, die durch BOUNCE_STAGE geroutet und höchstens einmal gesendet wird.

Inhalts-Herabstufung (RFC 6152 / RFC 6531): Die Nachricht wird an die Erweiterungen angepasst, die der Smarthost tatsächlich ankündigt. Ist der Nachrichtentext 8-bittig und unterstützt der Smarthost 8BITMIME, trägt der Umschlag BODY=8BITMIME; tut er es nicht, wird jeder 8-Bit-MIME-Blattteil mit einem 7-Bit-Content-Transfer-Encoding umkodiert (Quoted-Printable für text/*, sonst Base64) — nach dem Befund der Oktette, nicht nach der deklarierten Kodierung — und das Ergebnis erneut geprüft, wobei ein Nachrichtentext, der weiterhin 8-Bit-Oktette trägt, ein dauerhafter Fehler (554) ist statt einer unter Verletzung von RFC 6152 §3 gesendeten Nachricht. Benötigt die Nachricht SMTPUTF8 und unterstützt der Smarthost es, trägt der Umschlag SMTPUTF8; tut er es nicht, werden UTF-8-Header-Felder überall dort als RFC-2047-Encoded-Words umgeschrieben, wo §5 eines erlaubt, Nicht-ASCII-Parameter von Content-Type und Content-Disposition jedes MIME-Teils erhalten die Form von RFC 2231 (filename*=UTF-8''…), ein Nicht-ASCII-boundary= wird in seinem ganzen Multipart durch eine frische ASCII-Begrenzung ersetzt, und für eine Nachricht mit einer Nicht-ASCII-Adresse wird ein Bounce erzeugt. Das Umkodieren eines Nachrichtentexts zerstört jede den Nachrichtentext abdeckende Signatur, die bereits auf der Nachricht liegt (der DKIM-Body-Hash des Urhebers und die ARC-Message-Signature); siehe pepsi-stage-relay-to-internet(1).

Herkunftsnachweis: Ist der gemeinsame Abschnitt [pepsi-origin] konfiguriert (standardmäßig an), stempelt diese Stage jede ausgehende Nachricht mit einem Pepsi-Origin-Header und hält ihre Nonce fest, genau wie pepsi-stage-relay-to-internet(1) es tut (der Smarthost reicht den Header an den schließlichen MX durch), sodass ein Bounce, der für über den Smarthost weitergeleitete Mail zurückkehrt, von pepsi-stage-anti-spam(1) verifiziert werden kann. Siehe diese Stage und pepsi.conf(5) für Details. Ohne den Abschnitt wird kein Header hinzugefügt. Wie dort hält eine Nonce, die sich nicht festhalten lässt, die Nachricht für eine Wiederholung zurück.

Die Konfiguration, die eine Zustellung liest — dieser Abschnitt, [pepsi-tlsrpt], [pepsi-origin] und [pepsi] —, wird beim Start eines Workers geprüft; ein Abschnitt, der sich nicht parsen lässt, hindert die Worker am Start (die Warteschlange wird angehalten, und das Journal sagt, warum), statt jede Nachricht fehlschlagen zu lassen. Nachdem der Smarthost eine Nachricht angenommen hat, wird nichts mehr aus der Konfiguration gelesen, sodass eine angenommene Nachricht nie wegen eines Konfigurationsfehlers wiederholt wird.

SMTP TLS Reporting (RFC 8460): Wenn [pepsi-tlsrpt] SEND_REPORTS gesetzt ist, wird jede TLS-Sitzung zum Smarthost (nach bestem Bemühen) als Aggregat-Zähler in pepsi.tls_session festgehalten — ein Erfolg oder ein klassifizierter TLS-Fehler — geschlüsselt nach der angewandten Richtlinie (tlsa, wenn DANE den Smarthost authentifizierte, sonst no-policy-found) und dem Smarthost-Host. pepsi-tlsrpt(1) stellt diese zu täglichen Berichten zusammen; das Festhalten wird für eine Berichtsnachricht selbst übersprungen (state.tlsrpt).

85.1.11.1.4. Konfiguration

Die Pipeline-Verdrahtung und die Betriebsoptionen (SERVER_NAME, die Verbindungs-Timeouts, der Zeitplan für Wiederholung und Backoff sowie MAX_LIFETIME, DELAY_DSN_AFTER, MAX_HOP_COUNT, ADDRESS_FAMILY und die DANE-DNS-Einstellungen) liegen im eigenen Abschnitt [stage-<name>] der Stage (PROGRAM = pepsi-stage-relay-to-smarthost); die vorgelagerten Smarthosts werden einmal in den gemeinsamen Abschnitten [pepsi-stage-relay-to-smarthost-mta-<name>] definiert (HOST und PORT, beide erforderlich, MODE, TLS_VERIFY/TLS_CA/DANE, die AUTH-Zugangsdaten, HELO_NAME, ein eigenes ADDRESS_FAMILY — das auf das der Stage zurückfällt — sowie DOMAINS/CATCH_ALL, von denen mindestens eines erforderlich ist). Alle sind in pepsi.conf(5) dokumentiert.

85.1.11.1.5. Authentifizierung

Beim Weiterleiten über einen Smarthost weist Pepsi seine eigene Identität gegenüber diesem vorgelagerten MTA per SMTP AUTH (RFC 4954) nach, je Smarthost mit der Option AUTH in [pepsi-stage-relay-to-smarthost-mta-<name>] konfiguriert. Die unterstützten Mechanismen sind:

  • none (Standardwert) — keine Client-Authentifizierung.

  • plain — SASL PLAIN (RFC 4616): USERNAME/PASSWORD werden base64-kodiert gesendet.

  • login — SASL LOGIN: der veraltete zweistufige Benutzer/Passwort-Austausch, den manche älteren Smarthosts verwenden.

  • cram-md5 — SASL CRAM-MD5 (RFC 2195): ein Challenge/Response, in dem Pepsi die Kenntnis des PASSWORD per HMAC-MD5 über die Challenge des Servers nachweist, sodass das Passwort selbst nie gesendet wird. Schwächer als SCRAM (kein Salting, keine gegenseitige Authentifizierung, MD5) — bevorzugen Sie scram-*, wo verfügbar.

  • digest-md5 — SASL DIGEST-MD5 (RFC 2831): ein gesalzenes Challenge/Response, das auch den Server gegenüber Pepsi per rspauth authentifiziert (eine Nichtübereinstimmung bricht den Austausch ab). Veraltet — RFC 6331 überführte DIGEST-MD5 in den Status „Historic“; es wird nur für alte Smarthosts bereitgestellt, die nichts Besseres anbieten, und Pepsi gibt eine Warnung aus (sowohl von pepsi-setup(1) zur Konfigurationszeit als auch bei der ersten Verwendung im Journal des Relays). Es wird von auto nie ausgewählt. Bevorzugen Sie scram-* oder cram-md5.

  • scram-sha-1 / scram-sha-256 — SASL SCRAM-SHA-1 / SCRAM-SHA-256 (RFC 5802 / RFC 7677): ein gesalzenes Challenge/Response, das, anders als cram-md5, auch den Server gegenüber Pepsi authentifiziert — der Austausch bricht ab, wenn die Signatur des Servers nicht gegen das PASSWORD verifiziert oder wenn der Server das Login akzeptiert, ohne seine server-final-Signatur überhaupt zurückzugeben (sodass ein Peer der gegenseitigen Authentifizierung nicht entgehen kann, indem er vorzeitig mit 235 antwortet). SCRAM-SHA-256 wird bevorzugt. USERNAME/PASSWORD werden mit SASLprep (RFC 4013) normalisiert.

  • scram-sha-1-plus / scram-sha-256-plus — die Channel-Binding--PLUS-Varianten der obigen, die den SASL-Austausch mit tls-server-end-point an den zugrunde liegenden TLS-Kanal binden (RFC 5929; ein Hash des Server-Zertifikats). Dies erkennt einen Man-in-the-Middle, der TLS terminiert und neu erzeugt. Erfordert einen verschlüsselnden MODE (andernfalls gibt es keinen zu bindenden Kanal), und der Smarthost muss den -PLUS-Mechanismus ankündigen.

  • auto — handelt den stärksten Passwort-Mechanismus aus, den der Smarthost in seinem EHLO ankündigt, aus demselben USERNAME/PASSWORD. Präferenzreihenfolge: SCRAM-SHA-256-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1-PLUS > SCRAM-SHA-1 > CRAM-MD5 > LOGIN > PLAIN (die -PLUS-Varianten werden nur auf einer TLS-Sitzung gewählt). Die empfohlene Einstellung, wenn Sie keinen bestimmten Mechanismus festlegen müssen.

  • external — SASL EXTERNAL (RFC 4422 App. A): Der Smarthost authentifiziert Pepsi anhand des TLS-Client-Zertifikats, das Pepsi während des (Mutual-TLS-)Handshakes vorlegt, sodass kein Passwort gesendet wird. Erfordert konfiguriertes TLS_CLIENT_CERT / TLS_CLIENT_KEY (siehe Mutual TLS unten). Ein optionales USERNAME wird als SASL-Autorisierungsidentität gesendet; bei Weglassen leitet der Smarthost die Identität aus dem Zertifikat ab.

  • oauth — SASL-OAuth-2.0-Bearer-Token, von großen Anbietern wie Gmail und Microsoft 365 verlangt. Der konkrete Mechanismus wird automatisch aus dem EHLO des Smarthosts gewählt, wobei das standardisierte OAUTHBEARER (RFC 7628) bevorzugt und ersatzweise das De-facto-XOAUTH2 verwendet wird. USERNAME ist die im SASL-Austausch gesendete Kontoadresse und TOKEN_FILE der Pfad zu einer Datei, die das aktuelle OAuth-2.0-Zugriffstoken enthält (führender/nachgestellter Leerraum wird entfernt). Die Datei wird bei jeder Zustellung neu gelesen, sodass ein externer Refresher ein abgelaufenes Token ersetzen kann, ohne Pepsi neu zu starten.

    Zugriffstokens sind kurzlebig (typischerweise etwa eine Stunde). Die Relay-Stage liest das Token nur; das Aktuellhalten von TOKEN_FILE ist eine externe Aufgabe. Pepsi liefert pepsi-helper-token-refresh(1) dafür — einen Dienst, der frische Tokens vom Token-Endpunkt des Anbieters bezieht und die Datei umschreibt —, aber er ist optional und nicht Teil von pepsi.target; ein Standort kann jedes Äquivalent verwenden (einen Cron-Job, einen Cloud-Agenten). Eine Zustellung, die versucht wird, während das Token fehlt, leer, abgelaufen oder anderweitig abgelehnt ist, wird als vorübergehender Fehler behandelt, sodass die Nachricht eingereiht bleibt und wiederholt wird, sobald ein frisches Token vorhanden ist, statt dass ein Bounce erzeugt wird.

    Damit der Relay-Worker (als pepsi ausgeführt) ein vom Refresher geschriebenes Token lesen kann, wird das Stage-Binärprogramm SGID auf die Gruppe pepsi-token installiert (Modus 2550, Eigentümer pepsi:pepsi-token, sodass nur das Konto des Dispatchers und root es ausführen können), und die Token-Dateien sind für sie gruppenlesbar (Modus 0640 im SGID-Verzeichnis /var/pepsi/tokens). Siehe das Handbuchkapitel Die Pipeline erweitern für den vollständigen Refresh-Vertrag und dafür, wie Sie Ihren eigenen Refresher einsetzen.

  • ntlm — der De-facto-Microsoft-Mechanismus NTLM (kein RFC), für ältere Exchange-/Office-365-Hybrid-Installationen. Nur NTLMv2 ist implementiert (NTLMv1 ist kryptografisch gebrochen und wird nie gesendet). Weil Pepsi NTLM stets nur über TLS ausführt, trägt die Antwort immer Extended Protection for Authentication (EPA): die AV-Paare MsvAvChannelBindings (tls-server-end-point, RFC 5929) und MsvAvTargetName (das SPN smtp/<host>) plus den Message-Integrity-Code, sodass sie sich gegenüber EPA-durchsetzenden Servern authentifiziert. Das erforderliche NT_DOMAIN ist die Windows-Domain und das optionale NT_WORKSTATION ein kosmetischer Client-Name; USERNAME/PASSWORD sind die Zugangsdaten des Kontos. NTLM ist schwach (es verwendet nur den NT-Hash) und authentifiziert den Server nicht gegenüber Pepsi — bevorzugen Sie gssapi, scram-* oder oauth, wo der Smarthost sie unterstützt. pepsi-setup warnt, wenn es konfiguriert ist.

  • gssapi — SASL GSSAPI / Kerberos (RFC 4752), für kerberisierte Smarthosts (typischerweise ein On-Premise-Exchange in einem Active-Directory-Realm). Die Authentifizierung verwendet ein Kerberos-Service-Ticket für SERVICE_NAME (einen host-basierten Dienstnamen, Standardwert smtp@<HOST>), das aus einem Kerberos-Credential-Cache bezogen wird; nach dem GSS-Token-Austausch wird die SASL-Sicherheitsschicht auf keine Sicherheitsschicht ausgehandelt (die Sitzung ist bereits durch TLS geschützt). Es wird kein Passwort konfiguriert.

    Pepsi liest den Credential-Cache nur und hält nie den langfristigen Kerberos-Schlüssel: Ein externer Prozess — ein Keytab plus k5start/cron — muss ein Ticket-Granting-Ticket aktuell halten. Der Cache ist das umgebende KRB5CCNAME (in der Dienstumgebung des Dispatchers gesetzt), sofern nicht die Option KRB5CCNAME je MTA es überschreibt. Damit der Relay-Worker (als pepsi ausgeführt) einen vom Refresher geschriebenen Cache lesen kann, legen Sie einen FILE:-Cache im SGID-Verzeichnis /var/pepsi/krb5 ab (Gruppe pepsi-token, auf die das Stage-Binärprogramm für OAuth/mTLS ohnehin SGID läuft). Eine Zustellung, die versucht wird, während der Cache fehlt oder das Ticket abgelaufen ist, ist ein vorübergehender Fehler (die Nachricht bleibt eingereiht, wie bei oauth). Siehe das Handbuchkapitel Die Pipeline erweitern für den Refresh-Vertrag.

Alle passwortbasierten Mechanismen (plain, login, cram-md5, digest-md5, die scram-*-Familie, auto und ntlm) sowie oauth und gssapi senden oder leiten ein Credential (oder einen Sicherheitskontext) ab, daher bietet Pepsi sie erst an, wenn die Sitzung verschlüsselt ist (verwenden Sie MODE = tls oder starttls); jeder wird abgelehnt, wenn der Smarthost den entsprechenden AUTH-Mechanismus nicht ankündigt. Die Challenge-Response-Mechanismen (cram-md5, digest-md5, scram-*, ntlm) übertragen das Passwort selbst nie, aber Pepsi verlangt dennoch TLS für sie. external und gssapi senden kein Passwort über SMTP — das Credential ist das TLS-Client-Zertifikat oder ein Kerberos-Ticket —, erfordern aber ebenfalls eine verschlüsselte Sitzung. Für ntlm und gssapi wird ein Smarthost mit MODE = plain zur Konfigurationszeit abgelehnt.

Ein Smarthost, der das Credential ablehnt (535/534/504), ist — wie eine fehlgeschlagene Server-Verifikation bei digest-md5 oder scram-* — ein vorübergehender Fehler: Die Nachricht bleibt eingereiht und wird wiederholt, genau wie bei einem fehlenden Kerberos-Ticket. Falsch ist in diesem Fall die lokale Konfiguration — ein gewechseltes Passwort, ein gesperrtes Konto, ein Mechanismus, den der Smarthost nicht implementiert —, sodass ein Bounce die gesamte ausgehende Warteschlange an die eigenen Benutzer des Standorts zurückgeben würde, während der Operator sie noch in Ordnung bringen kann. Beobachten Sie das Journal (oder pepsi-status(1)) auf wiederholte AUTH-Fehler; pepsi-setup --wizard prüft ein Credential gegen den Smarthost, während es eingegeben wird.

85.1.11.1.6. Mutual TLS

Unabhängig von (oder zusammen mit) AUTH kann ein Smarthost so konfiguriert werden, dass er während des TLS-Handshakes ein Client-Zertifikat vorlegt (Mutual TLS):

  • TLS_CLIENT_CERT — Pfad zur vorzulegenden PEM-Zertifikatskette.

  • TLS_CLIENT_KEY — Pfad zum passenden privaten PEM-Schlüssel.

Beide müssen zusammen gesetzt werden, und nur mit einem verschlüsselnden MODE (tls oder starttls). Das Zertifikat wird bei jeder Verbindung vorgelegt und jedes Mal frisch geladen, sodass ein erneuertes Zertifikat ohne Neustart von Pepsi übernommen wird. Es gilt für PKIX-, TLS_VERIFY = no- und DANE-Sitzungen gleichermaßen (das Client-Zertifikat ist orthogonal dazu, wie das Server-Zertifikat validiert wird).

Das Zertifikat allein genügt vielen Smarthosts (Mutual TLS auf Transportebene, mit AUTH = none). Das Setzen von AUTH = external gibt zusätzlich SMTP AUTH EXTERNAL aus, sodass der Smarthost die SMTP-Sitzung an das vorgelegte Zertifikat bindet; es kann auch mit AUTH = plain/oauth kombiniert werden, wenn ein Smarthost sowohl ein Client-Zertifikat als auch ein Passwort/Token will.

Der private Schlüssel ist geheimes Material. Wie bei den OAuth-Token-Dateien liest der Relay-Worker (als pepsi ausgeführt) ihn über die SGID-Gruppe pepsi-token: Legen Sie bei einer Debian-Installation Zertifikat und Schlüssel in /var/pepsi/tls (als SGID pepsi-token erstellt), sodass der Schlüssel die Gruppe pepsi-token erbt und für die Stage lesbar ist. Halten Sie den Schlüssel im Modus 0640 (oder enger) und niemals für alle lesbar.

85.1.11.1.7. State

Eingaben (aus dem state des Datensatzes gelesen; alle optional):

  • state.dsn — die RFC-3461-Parameter; an den Smarthost propagiert, wenn er DSN ankündigt, und herangezogen, um über Failure-/Success-/Delay-Berichte zu entscheiden.

  • state.origin — die 8BITMIME/SMTPUTF8-Hinweise, die von der Inhalts-Herabstufung verwendet werden.

Ausgaben (in das state des Datensatzes zusammengeführt):

  • Bei einem vorübergehenden Fehler (pause): attempts, last_error und, sobald eine Delay-DSN ausgegeben wurde, delay_sent.

  • Bei einem dauerhaften Fehler mit einem BOUNCE_STAGE (reroute) oder bei einer Delay-Warnung (einem eingereihten Klon): ein state.bounce-Objekt (kind = permanent oder delay). Für einen Fehler auf SMTP-Ebene hält es außerdem die strukturierten Detailangaben zum nächsten Hop fest — remote_mta (der Smarthost), smtp_code, enhanced_status, phase und reply_text — sodass der Bounce genau angeben kann, warum der Smarthost die Nachricht abgelehnt hat.

  • Bei einem erfolgreichen Relay mit ORIGINATE_SUCCESS_DSN und NOTIFY=SUCCESS: ein state.bounce-Objekt mit kind = success.

  • Bei einem dauerhaften Fehler ohne BOUNCE_STAGE (fail): last_error.

state.dsn und state.origin bleiben immer erhalten. Das State-Layout wird vollständig in pepsi.state(7) beschrieben.

Übergänge (der Wiederholungszeitplan ist RETRY_INITIAL / RETRY_FACTOR / RETRY_MAX_INTERVAL, begrenzt durch MAX_LIFETIME):

  • erfolgreiches Relay → abschließen (der Datensatz wird gelöscht) oder zu NEXT_STAGE weiterschalten, falls eines gesetzt ist; mit [pepsi] ORIGINATE_SUCCESS_DSN und einem Empfänger, der NOTIFY=SUCCESS angefordert hat, leitet es stattdessen zu BOUNCE_STAGE um, um eine positive (Action: delivered-)DSN auszugeben;

  • vorübergehender Fehler → pausieren für das nächste Wiederholungsintervall;

  • noch eingereiht über DELAY_DSN_AFTER hinaus mit einem NOTIFY=DELAY-Empfänger → einen einmaligen Delay-DSN-Klon bei BOUNCE_STAGE einreihen (das Original bleibt eingereiht);

  • dauerhafter Fehler (einschließlich eines Empfängers ohne passenden MTA) oder MAX_LIFETIME erschöpft → umleiten zu BOUNCE_STAGE oder fehlschlagen (terminal failed), wenn kein BOUNCE_STAGE konfiguriert ist;

  • für einen unzustellbaren Bounce (Null-Absender) wird nie erneut ein Bounce erzeugt — er wird einfach verworfen (diese Stage hat keine Postmaster-Doppel-Bounce-Kopie).

85.1.11.1.8. Befehle

worker

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

85.1.11.1.9. 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.11.1.10. Exit-Status

Das Ergebnis jeder Nachricht wird pepsi-dispatch(1) auf der Statuszeile des Workers gemeldet, nicht als Exit-Status.

0

Der Worker lief, bis seine Standardeingabe geschlossen wurde.

1

Ein fataler Fehler ist aufgetreten (unlesbare Konfiguration, die Datenbank konnte nicht geöffnet werden, oder Standardeingabe/-ausgabe ist fehlgeschlagen). Der Grund wird in das Journal geschrieben.

85.1.11.1.11. Beispiele

Die Egress-Stage auf Nachricht 42 ausführen (sie muss running sein):

echo 42 | pepsi-stage-relay-to-smarthost -c /etc/pepsi/pepsi.conf worker

85.1.11.1.12. Siehe auch

pepsi-config(1), pepsi-stage-bounce(1), pepsi-stage-dkim-sign(1), pepsi-stage-relay-to-internet(1), pepsi-dispatch(1), pepsi.conf(5), pepsi.state(7), pepsi-setup(1)

85.1.11.1.13. Fehler

Melden Sie Fehler an den Pepsi-Issue-Tracker.