38. pepsi-stage-relay-to-internet

Direkte Zustellung an den MX mit MTA-STS.

38.1. Rolle

pepsi-stage-relay-to-internet stellt eine Nachricht direkt an die Mail-Exchanger der Empfängerdomain zu und führt seine eigene MX-Entdeckung und TLS-Richtliniendurchsetzung durch. Es ist eine der beiden austauschbaren Zustell-Stages. Referenz: pepsi-stage-relay-to-internet(1).

38.2. Funktionen

38.2.1. MX-Entdeckung (RFC 5321 / RFC 7505)

  • Eigene MX-Abfrage, Hosts in aufsteigender Präferenz versucht (gleiche Präferenz in zufälliger Reihenfolge); eine Domain ohne MX fällt auf ihre Adress-Einträge zurück (impliziter MX, RFC 5321 §5.1).

  • Null-MX (RFC 7505, 0 .) und eine nicht existierende Domain sind dauerhafte Fehler, nie Wiederholungen.

  • Happy-Eyeballs-Adressauswahl über A/AAAA, mit ADDRESS_FAMILY geschnitten; aufgelöste Adressen werden pro Adresse (mit Verbindungs-Gesundheit) in der pepsi.dns_address-Tabelle zwischengespeichert, sodass eine funktionierende Adresse bevorzugt wird, bis ihr DNS-TTL abläuft.

38.2.2. Transportsicherheit (RFC 8461 / RFC 6125)

  • MTA-STS-Entdeckung und -Durchsetzung (RFC 8461) (sofern nicht MTA_STS = no): Eine enforce-Richtlinie beschränkt die Zustellung auf gelistete MX-Hosts über STARTTLS mit einem für den Host gültigen Zertifikat (RFC 6125). Eine testing-Richtlinie wird auf dieselbe Weise validiert und das Ergebnis für TLS Reporting festgehalten, doch ein Fehlschlag fällt auf opportunistisches STARTTLS über alle MX-Hosts zurück; ohne Richtlinie verwendet die Zustellung opportunistisches STARTTLS. Richtlinienabfragen sind nur fail-open, wenn nichts zwischengespeichert ist. Der mta-sts-Unterbefehl gibt die anwendbare Richtlinie aus.

  • DANE/TLSA (RFC 7672), pro MX-Host: DANE = off | warn | strict, Standardwert warn. Wenn brauchbare TLSA-Einträge vorliegen und das MX-RRset DNSSEC-gesichert ist (Pepsi liest das AD-Bit des Resolvers; es validiert DNSSEC nicht selbst), haben sie für diese Verbindung Vorrang vor MTA-STS — außer dass der Modus warn die PKIX-Validierung einer enforce-MTA-STS-Richtlinie nie ersetzt. Eine Abweichung bei einem brauchbaren Eintrag schiebt die Zustellung unter strict auf und warnt unter warn nur. Ein Host, dessen TLSA-Einträge allesamt unbrauchbar sind, muss dennoch STARTTLS anbieten (RFC 7672 §2.2).

38.2.3. Zustellung, Wiederholung und Bounce

  • Sendet mit dem eigenen Umschlagabsender der Nachricht (Null-Absender bei Bounces), ein Empfänger pro Versuch: Ein Datensatz mit mehreren Empfängern wird zuerst in einen Datensatz je Empfänger aufgeteilt.

  • Bei Erfolg schließt es den Datensatz ab (oder schaltet zu NEXT_STAGE weiter).

  • Exponentieller Backoff bei vorübergehendem Fehler (RETRY_INITIAL/RETRY_MAX_INTERVAL/RETRY_FACTOR); nach MAX_LIFETIME wird ein vorübergehender Fehler dauerhaft.

  • Schleifenerkennung über MAX_HOP_COUNT Received:-Header.

  • Ein dauerhafter Fehler einer gewöhnlichen Nachricht routet zu BOUNCE_STAGE (oder markiert den Datensatz als failed); ein dauerhafter Fehler eines Bounces wird nie erneut gebounct — eine Kopie geht an POSTMASTER, falls gesetzt, sonst wird sie verworfen.

38.2.4. DSN-Propagierung und -Erzeugung (RFC 3461)

  • Propagiert RET/ENVID/NOTIFY/ORCPT an den MX nur, wenn er DSN ankündigt.

  • Bei dauerhaftem Fehler übergibt es das NOTIFY/ORCPT/ENVID des Empfängers an die Bounce-Stage, sodass eine Failure-DSN nur dann erzeugt wird, wenn angefordert.

  • Success-DSN (Action: delivered) bei ORIGINATE_SUCCESS_DSN + NOTIFY=SUCCESS; Delay-DSN (Action: delayed, einmal), wenn DELAY_DSN_AFTER abläuft und NOTIFY=DELAY.

38.2.5. Inhaltsanpassung (RFC 6152 / RFC 6531)

  • Passt die Nachricht an die Erweiterungen an, die der MX ankündigt: kündigt BODY=8BITMIME / SMTPUTF8 erneut an, wenn unterstützt, andernfalls stuft es den Nachrichtentext (RFC 2045) und die UTF-8-Header (RFC 2047) herab. Eine Nicht-ASCII-Adresse, die einem Nicht-SMTPUTF8-Hop gegenüber nicht darstellbar ist, wird gebounct, und ebenso ein Nachrichtentext, der nach der Herabstufung immer noch 8-Bit ist — RFC 6152 §3 erlaubt keinen Versuch, ihn zu senden.

38.3. Konfiguration

[stage-<name>] mit PROGRAM = pepsi-stage-relay-to-internet: SERVER_NAME (erforderlich), NEXT_STAGE/BOUNCE_STAGE, POSTMASTER, die Timeouts (CONNECT_TIMEOUT/COMMAND_TIMEOUT/DATA_TIMEOUT), die Wiederholungsrichtlinie (RETRY_INITIAL/RETRY_MAX_INTERVAL/RETRY_FACTOR/MAX_LIFETIME/ DELAY_DSN_AFTER), MAX_HOP_COUNT, DNS (DNS_SERVERS/DNS_TIMEOUT), MTA-STS (MTA_STS/MTA_STS_TIMEOUT), DANE und ADDRESS_FAMILY. Dauern müssen h/m/s-Einheiten verwenden. Vollständige Referenz: pepsi-stage-relay-to-internet(1).

38.4. State

  • Eingaben: state.dsn (Propagierung + Berichts-Abriegelung) und state.origin (8BITMIME/SMTPUTF8-Hinweise).

  • Ausgaben: attempts/last_error/delay_sent bei Pause; ein state.bounce-Objekt (permanent/success/delay) beim Routen zur oder Einreihen für die Bounce-Stage; last_error bei terminalem fail. state.dsn und state.origin bleiben erhalten.

38.5. Siehe auch

pepsi-stage-relay-to-smarthost, pepsi-stage-bounce, Unterstützte Funktionen, pepsi-stage-relay-to-internet(1).