28. pepsi-ingress

Der eingehende SMTP-Server (MTA) und der Einstiegspunkt der Pipeline.

28.1. Rolle

pepsi-ingress betreibt den SMTP-Server, der Mail empfängt, sie an der Grenze authentifiziert und jede angenommene Nachricht als einen pepsi.workqueue-Datensatz bei stage = init speichert, bevor er den Dispatcher benachrichtigt. Es ist die einzige Komponente, die mit externen sendenden Clients spricht; alles Nachgelagerte operiert auf dem gespeicherten Datensatz. Die vollständige Optionsreferenz ist pepsi-ingress(1) / pepsi.conf(5).

28.2. Funktionen

28.2.1. Empfang (RFC 5321)

  • SMTP/ESMTP-Server mit Transport pro Listener: Klartext, STARTTLS-Upgrade (RFC 3207) und implizites TLS (RFC 8314); Listener binden TCP-, UNIX- oder systemd-aktivierte Sockets.

  • Nachrichtentexte über DATA oder CHUNKING/BDAT (RFC 3030).

  • Kündigt SIZE (das MAX_MESSAGE_SIZE → 552 durchsetzt), PIPELINING, ENHANCEDSTATUSCODES, 8BITMIME (RFC 6152), SMTPUTF8 (RFC 6531) und DSN (RFC 3461) an.

  • Nimmt Mail nur für ACCEPTED_DOMAINS an (andere → 550 Relaying); nimmt das domainlose <Postmaster> immer an (RFC 5321 §4.5.1).

  • Dauerhafte Annahme: gibt 250 erst zurück, nachdem der Datensatz committet wurde; ein Datenbankausfall ergibt ein vorübergehendes 451.

  • Die Verbindungsnebenläufigkeit ist durch MAX_CONNECTIONS und ein MAX_OPEN_SOCKETS-Dateideskriptor-Budget begrenzt; eine Ratenbegrenzung pro Quelle (CONN_RATE_PER_SECOND) und, unter Druck, die Verdrängung der am längsten untätigen Verbindung im gierigsten Quellbereich schützen vor Verbindungsmissbrauch.

  • Lese-Timeouts pro Befehl (COMMAND_TIMEOUT/DATA_TIMEOUT, RFC 5321 §4.5.3.2) schließen langsame oder ins Stocken geratene Sitzungen, einschließlich eines hängenden STARTTLS-Handshakes.

  • Nachsichtige Zeilenlängen. Die Grenzen aus RFC 5321 §4.5.3.1.4/§4.5.3.1.6 (512-Oktett-Befehlszeilen, 1000-Oktett-Textzeilen) binden Sender; gemäß dem Hinweis desselben Abschnitts, dass Empfänger liberal sein sollen, nimmt Ingress längere Zeilen an. Die internen MAX_CMD_LINE/MAX_DATA_LINE-Obergrenzen sind nur Speichererschöpfungs-Schutz — eine Zeile ohne Terminator, die über die Obergrenze wächst, lässt die Verbindung fallen — keine Konformitätsdurchsetzung.

28.2.2. Trace-Header

  • Stellt vor der Authentifizierung einen Received:-Header gemäß RFC 5321 §4.4 voran (sodass die ARC-Versiegelung ihn abdeckt) und hält den Client (HELO/EHLO, Reverse-DNS, IP), diesen Server, den Übertragungstyp SMTP/ESMTP/ESMTPS/ESMTPA/ ESMTPSA (RFC 3848) und die Zeit fest; bei Einzelempfänger-Transaktionen wird eine for-Klausel hinzugefügt. Bei einer verschlüsselten Sitzung werden die ausgehandelte TLS-Version und -Chiffre als (version=… cipher=…)-Kommentar nach dem ESMTPS-Schlüsselwort angehängt (RFC 8314 §4.3).

28.2.3. Authentifizierung (an der Grenze festgehalten)

  • SPF (RFC 7208), DKIM-Verifikation (RFC 6376 / RFC 8463) und DMARC (RFC 7489), plus iprev/FCrDNS (RFC 8601).

  • Stellt einen Authentication-Results-Header (RFC 8601) mit dem Ingress-HOSTNAME als authserv-id voran; die Urteile werden außerdem unter state.auth (spf/dkim/dmarc/arc) gespeichert.

  • Fail-open: Nur ein eindeutiger DMARC-Fehlschlag unter DMARC_ENFORCE lehnt ab (550); DNS-/Parse-Fehler werden festgehalten und die Mail angenommen.

  • Die ARC-Verifikation/-Versiegelung wird hier nicht durchgeführt — das ist die pepsi-stage-arc-Stage, sodass Ingress keine ARC-Schlüssel hält. Ingress hält den Sitzungskontext, den die ARC-Stage benötigt, unter state.origin fest.

28.2.4. Submission (RFC 6409)

  • Ein Listener mit SUBMISSION = yes macht die Client-Authentifizierung verpflichtend und wendet die Submission-Korrekturen an (ein fehlendes Date:/Message-ID: wird ergänzt). Eines von vier Verfahren authentifiziert eine Sitzung: eine Gegenstellenadresse in MYNETWORKS, die Peer-Zugangsdaten eines UNIX-Sockets (AUTH_PEERCRED, der Standardwert bei einem UNIX-Listener und auf TCP abgelehnt), ein SASL-AUTH-Austausch (SASL_TYPE = dovecot, nur über TLS angeboten) oder ein festgelegtes TLS-Client-Zertifikat (TLS_AUTH_CLIENT). Eine authentifizierte Sitzung wird mit state.local_origin = true festgehalten; USERNAME_MAP entscheidet, unter welchen Adressen die authentifizierte Identität senden darf.

  • Submission erfordert einen TLS-geschützten MODE, außer auf einem lokalen UNIX-Domain-Socket, wo der Kernel die Identität liefert und es keinen Transport zu schützen gibt.

  • Der lokale Submission-Socket, den pepsi-sendmail verwendet, braucht überhaupt keinen Listener-Abschnitt: Ingress synthetisiert einen für [pepsi-sendmail] SOCKET, sofern nicht bereits ein ausdrücklicher Abschnitt diesen Pfad bedient. SOCKET = none ist der einzige Schalter, der ihn abschaltet; ihn nicht binden zu können ist fatal.

28.2.5. Postfach-Quota

  • Ist eine Postfach-Quota-Richtlinie in Kraft, so wird ein Empfänger, dessen gemessene Belegung über seiner Grenze liegt, bei RCPT abgewiesen (452 4.2.2 oder 552 5.2.2, gemäß [pepsi] MAILBOX_OVER_QUOTA). Ingress liest pepsi.mailbox_quota ausschließlich und weist nur aufgrund einer Messung ab, die jünger als MAILBOX_QUOTA_MAX_AGE ist; jede Ungewissheit (kein Datensatz, eine veraltete oder fehlende Messung, ein Datenbankfehler) nimmt an. MAILBOX_QUOTA_RCPT_CHECK = no (Standardwert yes) verlagert die gesamte Durchsetzung auf den Zeitpunkt der Zustellung. Siehe pepsi-quota.

28.2.6. DSN-Aufnahme (RFC 3461)

  • Validiert und speichert RET/ENVID (MAIL FROM) und NOTIFY/ORCPT (RCPT TO) unter state.dsn; fehlerhafte Werte werden mit 501 abgelehnt.

28.2.7. Internationalisierte / 8-Bit-Aufnahme

  • Nimmt rohe 8-Bit-Nachrichtentexte und UTF-8-Header/-Umschlag an; hält die BODY=-Deklaration unter state.origin.body_8bit fest. BINARYMIME wird abgelehnt (501). Das erneute Ankündigen/Herabstufen pro Hop geschieht später in den Relay-Stages.

28.2.8. SRS-Rückwärts-Dekodierung

  • Ein Empfänger in SRS_DOMAIN, dessen Local-Part ein gültiges SRS-Token ist, wird zum ursprünglichen Absender dekodiert und dorthin zum Relay angenommen (auch außerhalb bedienter Domains — der HMAC autorisiert es); ein gefälschtes/abgelaufenes Token wird abgelehnt (550). So kehren Bounces zu den ursprünglichen Absendern zurück. Siehe pepsi-stage-srs.

28.2.9. Speicherung und Benachrichtigung

  • Speichert die Nachricht aufgeteilt in headers- und body-Spalten, mit dem Umschlag, geparstem From:/Subject: und den Urteilen; fügt bei stage = init / status = pending ein.

  • Weckt den Dispatcher außerhalb des Bandes und zusammengefasst, höchstens einmal je DISPATCH_WAKE_INTERVAL (Standardwert 5 ms), nachdem der Datensatz committet wurde. Die Zulassungstransaktion selbst trägt kein NOTIFY: PostgreSQL hält von dem Moment an, in dem eine Transaktion eine Benachrichtigung einreiht, bis zu deren Commit eine datenbankweite Sperre, sodass ein benachrichtigendes Einfügen keinen Gruppen-Commit erlaubt. Ein verlorenes Wecken kostet nur die Latenz eines POLL_INTERVAL des Dispatchers.

28.3. Konfiguration

Gelesen aus [pepsi-ingress] (Annahmerichtlinie, Grenzen, Timeouts, DNS), den [pepsi-ingress-listener-*]-Sockets (Transport und Client-Authentifizierung, je Listener) sowie den gemeinsamen Abschnitten [pepsi-postgres], [pepsi], [pepsi-sendmail] und [pepsi-srs]. Die Konfigurations-Überlagerung aus der Datenbank wird darüber angewendet. Vollständige Referenz: pepsi.conf(5) und Konfiguration.

28.4. Ausgaben an die Pipeline

Sät das state des Datensatzes mit origin (SMTP-Herkunft), auth (den SPF/DKIM/DMARC-Urteilen), local_origin, spam = false für eine Nachricht, deren einziger Empfänger <Postmaster> ist, und, falls angefordert, dsn (RFC-3461-Parameter). Siehe Architektur für das State-Modell.

28.5. Siehe auch

pepsi-dispatch, pepsi-stage-arc, pepsi-stage-srs, Unterstützte Funktionen, pepsi-ingress(1), pepsi.conf(5).