85.2.1. pepsi.conf

configuration file for the Pepsi pipeline

Handbuchabschnitt:

5

85.2.1.1.1. Name

pepsi.conf - von allen Pepsi-Komponenten geteilte Konfigurationsdatei.

85.2.1.1.2. Beschreibung

Jede Pepsi-Komponente — pepsi-ingress(1), pepsi-dispatch(1), jedes pepsi-stage-*-Programm, pepsi-httpd(1), pepsi-queue(1), pepsi-tlsrpt(1), pepsi-setup(1) und die übrigen — liest die gleiche Konfigurationsdatei im INI-Stil, konventionell pepsi.conf. Das Format wird mit den GNU-Taler-Komponenten geteilt, auf denen Pepsi aufbaut.

Weil es eine Datei gibt, wird jede Einstellung einmal dokumentiert, unter dem Abschnitt, der sie besitzt. Eine Komponente liest nur die für sie relevanten Abschnitte: Die gemeinsamen Abschnitte [pepsi] und [pepsi-postgres] werden von allem gelesen; die [stage-<name>]-Pipeline-Abschnitte vom Dispatcher und den Stage-Programmen; komponentenspezifische Abschnitte ([pepsi-ingress], [pepsi-httpd], [pepsi-dispatch], [pepsi-payments], [pepsi-tlsrpt] …) von der jeweils benannten Komponente.

Eine Option, die nichts liest, wird ignoriert, sodass eine falsch geschriebene stillschweigend ihren Standardwert annimmt; pepsi-setup(1) warnt vor jeder solchen Option in einem Abschnitt, den es kennt, und nennt die nächstliegende echte Option.

Umbenannte Optionen. Wenn ein Release eine Option umbenennt, funktioniert der alte Name noch mindestens ein weiteres Release lang: Jedes Programm liest ihn unter dem neuen Namen und protokolliert eine entsprechende Warnung, und pepsi-setup(1) warnt ebenfalls. Sind beide Namen gesetzt, gewinnt der neue. NEWS führt jede Umbenennung auf.

85.2.1.1.3. Dateiformat

Eine Konfigurationsdatei ist eine Folge von [SECTION]-Kopfzeilen, jeweils gefolgt von OPTION = VALUE-Zuweisungen:

[pepsi-ingress]
HOSTNAME = mail.example.org
ACCEPTED_DOMAINS = example.org example.com

Abschnitts- und Optionsnamen sind unabhängig von der Groß-/Kleinschreibung und werden konventionell in Großbuchstaben geschrieben. Leerzeilen werden ignoriert. Ein # oder % am Zeilenanfang leitet einen Kommentar ein. Ein Wert kann in doppelte Anführungszeichen gesetzt werden, um führende oder nachgestellte Leerzeichen zu erhalten.

85.2.1.1.3.1. Direktiven

@inline@ FILE

Bindet eine andere Konfigurationsdatei ein, relativ zur aktuellen Datei aufgelöst.

@inline-matching@ GLOB

Bindet jede Datei ein, die auf das Shell-Glob GLOB passt.

@inline-secret@ SECTION FILE

Führt den Abschnitt SECTION aus FILE (typischerweise eine modusbeschränkte Datei mit Zugangsdaten) in die Konfiguration zusammen. Eine Datei, die nicht gelesen werden kann, wird mit einer Warnung ignoriert. Dies hält Geheimnisse aus der für alle lesbaren Hauptdatei heraus.

Eine Direktive ist eine Zeile auf oberster Ebene: Wie @inline@ beendet sie den Abschnitt, in dem sie steht. Schreiben Sie sie hinter die letzte Option des Abschnitts, den sie versorgt — eine darunter platzierte Option gehört zu keinem Abschnitt, und die gesamte Datei lässt sich dann nicht mehr laden (Expected section header or directive). Aus diesem Grund gibt pepsi-setup(1) seine Direktiven stets als Letztes innerhalb eines Abschnitts aus:

[pepsi-srs]
SRS_DOMAIN = srs.example.org
MAX_AGE_DAYS = 21
@inline-secret@ pepsi-srs secrets.d/pepsi-ingress.secret

Da ein nicht lesbares Fragment nur eine Warnung auslöst, wirkt eine Option, die es hätte liefern sollen, schlicht wie nicht gesetzt — ein Rechteproblem wird von demjenigen gemeldet, der den Wert benötigt, typischerweise als „… is not configured“. Pepsi erkennt diesen Fall und sagt es ausdrücklich, unter Nennung des Fragments, seines Eigentümers und seines Modus; führen Sie pepsi-setup run als root aus, um jedes Fragment dem Konto zu geben, das es liest.

85.2.1.1.3.2. Wertersetzung

Als Pfade gelesene Optionen durchlaufen eine $-Expansion: $VAR und ${VAR} werden durch den Wert von VAR aus dem [PATHS]-Abschnitt oder, andernfalls, der Umgebung ersetzt. Die Form ${VAR:-default} liefert einen Ersatzwert. Der [PATHS]-Abschnitt ist mit den üblichen Installationsverzeichnissen (PREFIX, BINDIR, DATADIR und so weiter) vorbefüllt.

85.2.1.1.3.3. Werttypen

Boolescher Wert

YES oder NO (unabhängig von der Groß-/Kleinschreibung).

Zahl

Eine dezimale Ganzzahl. Einige als solche dokumentierte Optionen nehmen stattdessen einen gebrochenen Wert an, und jede sagt das dort, wo sie beschrieben wird (die Verbindungsraten-Optionen des Ingress und das RETRY_FACTOR der Relay-Stages).

Dauer

Eine Zeitspanne wie 5 s oder 2 h. Siehe den Vorbehalt unten.

Pfad

Ein Dateisystempfad, der wie oben beschrieben einer $-Expansion unterliegt.

Unix-Modus

Ein in Oktal geschriebenes Dateirecht, z. B. 660.

Warnung

duration-Werte werden von jiff::SignedDuration geparst, das nur Stunden/Minuten/Sekunden und kleinere Einheiten akzeptiert. Eine Kalendereinheit wie 5 d oder 2 weeks lässt sich nicht parsen. Für Zeitfenster von einem Tag oder länger schreiben Sie das Äquivalent in Stunden (120 h) oder verwenden, wo vorhanden, eine ganzzahlige Option (z. B. [pepsi-srs] MAX_AGE_DAYS).

85.2.1.1.4. Die Datenbank-Überlagerung

Diese Datei ist die Basisschicht. Darüber liest jede Komponente eine Menge administrativ verwalteter Überschreibungen aus der Tabelle pepsi.config_override des geteilten Schemas, sodass eine Installation ohne Dateibearbeitung und, für die Stage-Abschnitte, ohne Neustart umkonfiguriert werden kann. Ohne Datensätze in jener Tabelle verhält sich eine Installation genau so, wie diese Datei es sagt; jede Überschreibung zu löschen führt sie in diesen Zustand zurück.

Die Geltungsbereichskette, niedrigste Präzedenz zuerst:

1. diese Datei;

2. Datenbank-Geltungsbereich global;

3. Datenbank-Geltungsbereich domain:DOMAIN;

4. Datenbank-Geltungsbereich address:ADDRESS;

5. die Tabelle pepsi.settings je Adresse (pepsi-settings(1)).

Höhere Schichten überschreiben niedrigere Option für Option, nie Abschnitt für Abschnitt: Eine Option, die keine Schicht erwähnt, behält den hier geschriebenen Wert. Die Adresse, gegen die ein domain:/address:-Geltungsbereich abgeglichen wird, ist der Umschlagabsender für eine lokal stammende Nachricht, sonst jeder Umschlagempfänger.

Die letzte Schicht ist eine andere Tabelle mit einer anderen Schreibautorität. pepsi.settings wird von den Kontoinhabern selbst per E-Mail geschrieben, innerhalb der EDITABLE_STAGES-Positivliste; config_override definiert die Pipeline und ist nur über die PostgreSQL-Rolle pepsi-config beschreibbar. pepsi-setup(1) gewährt dieser Rolle INSERT/UPDATE/DELETE auf der Tabelle, entzieht sie jedem Dienstkonto und verifiziert beides nach jeder Installation gegen die laufende Datenbank: Ein Stage-Worker parst berufsmäßig feindliche Mail und darf nicht die Konfiguration umschreiben können, die die Stage definiert, in der er läuft.

85.2.1.1.4.1. Abschnitte, die nie aus der Datenbank gelesen werden

Eine Überschreibung, die eine davon benennt, wird zur Laufzeit ignoriert und beim Schreiben abgelehnt:

[pepsi], [pepsi-postgres], [PATHS]

Gelesen, bevor eine Datenbankverbindung existieren kann — und [pepsi] hält zusätzlich die nur für Administratoren bestimmte kryptographische Richtlinie.

[pepsi-httpd], [pepsi-httpd-listener-*], [pepsi-httpd-cert-*]

Der Server, der die Konfigurationsoberfläche bedient, muss immer starten können.

[pepsi-ingress-listener-*]

Lauschende Sockets werden beim Start gebunden, oft unter Socket-Aktivierung und bevor Privilegien abgegeben werden.

[pepsi-secure-link]

Sein PEPPER ist das serverseitige Geheimnis, das eine gestohlene Datenbank nutzlos macht; eine Datenbank, die es ersetzen könnte, könnte also dafür sorgen, dass die nächste gespeicherte Nachricht eine ist, die ein Angreifer öffnen kann. Der Rest des Abschnitts fährt einfach mit.

[pepsi-admin]

Entscheidet, wer den Server verwalten darf und wie die administrative Oberfläche die Datenbank erreicht; eine Meinung der Datenbank darüber wäre ein Weg, sich selbst die Konsole zu gewähren.

[pepsi-crypto], [pepsi-srs], [pepsi-origin]

Jeder enthält einen serverseitigen Schlüssel, der gerade deshalb existiert, damit die Datenbank allein nicht genügt: die Schlüsselverschlüsselungsschlüssel (und welcher davon neue private Schlüssel einhüllt), den SRS-Schlüssel, der das Relaying an jede beliebige Adresse autorisiert, und den Herkunftsnachweis-Schlüssel, gegen den ein zurückkehrender Bounce oder eine Zahlungsaufforderung geprüft wird. Eine Datenbank, die einen davon ersetzen könnte, könnte dafür sorgen, dass der nächste eingehüllte Schlüssel einer ist, den ein Angreifer öffnen kann, oder dass ein gefälschter Bounce weitergeleitet oder bezahlt wird. Der Rest jedes Abschnitts wird mitgeschützt.

[pepsi-wizard]

Überhaupt keine Konfiguration, sondern die Aufzeichnung von pepsi-setup(1) über die Antworten, die ihm gegeben wurden, und die die Browser-Konsole als Entwurfs-Datensätze in eben dieser Tabelle zwischenlagert. Zur Laufzeit liest sie niemand, also liefert die Datenbank sie auch nie.

Zwei weitere Regeln gelten in jedem anderen Abschnitt:

• Keine Zugangsdaten werden je in der Datenbank gespeichert. Eine Option, deren Name sie als solche kennzeichnet – sie enthält PASS (PASSWORD, PASSPHRASE, API_PASS), SECRET, TOKEN, CREDENTIAL, CLIENT_ID oder PEPPER, dieselbe Regel, die einen Wert überall maskiert, wo eine Konfiguration angezeigt wird –, wird beim Schreiben verweigert und zur Laufzeit ignoriert, in jedem Abschnitt. Das schließt die Datei ein, aus der Zugangsdaten gelesen werden, und den Endpunkt, an den sie gesendet werden (SECRET_FILE, TOKEN_FILE, TOKEN_ENDPOINT): Eine Datenbank, die diese setzen kann, kann die Zugangsdaten umleiten. Zugangsdaten liegen in dieser Datei oder ihren secrets.d-Fragmenten, jeweils nur für das Konto lesbar, das sie braucht.

• Die Geltungsbereiche domain: und address: nehmen nur [stage-*] -Abschnitte an. Diese Schichten werden von einer Stage je Nachricht für den Abschnitt konsultiert, den sie gerade ausführt; nichts liest einen anderen Abschnitt je Domain oder je Adresse, daher wird eine solche Überschreibung verweigert, statt gespeichert und nie gelesen zu werden.

Folglich ist einen Submission-Port hinzuzufügen, das TLS-Material eines Listeners, die Datenbankverbindung oder die Krypto-Richtlinie zu ändern eine Texteditor-und-Neustart-Operation, und keine administrative Oberfläche kann es tun. [pepsi-ingress] DB_POOL_SIZE und [pepsi-dispatch] DB_POOL_SIZE sind aus demselben Bootstrap-Grund nur in der Datei: Der Pool muss existieren, bevor die Überlagerung gelesen werden kann.

85.2.1.1.4.2. Hot Reload

Jeder Schreibvorgang auf der Tabelle löst eine config_changed-Benachrichtigung aus.

Jede [stage-*]-Änderung wird ohne Neustart angewandt, und das gilt für beide Hälften der Pipeline. Auf die Benachrichtigung hin baut pepsi-dispatch(1) seine eigene Stage-Tabelle aus der Überlagerung neu auf — sodass eine Stage im laufenden Betrieb hinzugefügt, geändert oder entfernt werden kann und ein geändertes PROGRAM/PARALLELISM/ MAX_MESSAGES/QUEUE_LIMIT wirksam wird — und es setzt seine Stage-Worker außer Dienst, sodass die Nachfolger die Überlagerung neu lesen. Keine Nachricht wird unterbrochen: Ein Worker bekommt keine weitere Arbeit mehr, und sein Platz wird aufgegeben, sobald seine laufenden Nachrichten zurückgemeldet haben.

Das eine, was ein Neuladen nicht tut, ist nach einer Pipeline zu routen, die die Worker nicht mehr teilen. Ein neu geladener Stage-Graph, der sich nicht parsen lässt, beendet den Dispatcher (Exit EX_CONFIG, über das gewöhnliche Herunterfahren, sodass nichts liegen bleibt), statt die vorherige Tabelle stehen zu lassen.

Jeder andere Abschnitt wird beim Start einmal von der Komponente gelesen, der er gehört, und braucht daher einen Neustart dieser Komponente — einschließlich der eigenen Optionen von [pepsi-dispatch], die bewusst nicht neu geladen werden. pepsi-config set gibt aus, welcher Fall zutrifft.

Eine Komponente, die eine Benachrichtigung verpasst, liest die Überlagerung erneut, wenn ihr Datenbank-Listener sich neu verbindet, sodass eine verlorene Benachrichtigung Latenz kostet, nicht Korrektheit.

Geheimnisse werden nie in der Datenbank gespeichert: Das Overlay verweigert Zugangsdaten (siehe oben), und die @inline-secret@-Referenz liegt in dieser Datei. Jedes Fragment bleibt im Besitz des einzigen Lesers, der es braucht.

Ein defekter Wert in der Datenbank kann kein Programm am Start hindern: Eine Überlagerung, die nicht gelesen werden kann oder keine brauchbare Konfiguration ergibt, wird lautstark protokolliert, und diese Datei wird unverändert verwendet.

Siehe pepsi-config(1) für set/unset/list, für dump --origin (das jeden effektiven Wert mit der Schicht annotiert, aus der er stammt) und für den verschlüsselten export/import dieser Datei und ihrer secrets.d-Fragmente.

85.2.1.1.5. Der Abschnitt [pepsi]

Übergreifende Identitäts- und Richtlinien-Einstellungen, die von den Pepsi-Werkzeugen geteilt werden. Dieser Abschnitt wird nie aus der Datenbank-Überlagerung gelesen.

KEY_DIR = PATH

Verzeichnis, unterhalb dessen domainweise Signierschlüssel gespeichert werden. Jede Domain erhält ein Unterverzeichnis (Modus 0700), das dkim.rsa.key und dkim.ed25519.key (Modus 0600) enthält. Optional; Standardwert ist /var/pepsi/keys.

DKIM_SELECTOR = NAME

Basis-DKIM-Selektor. Der RSA-Schlüssel wird als TXT-Eintrag unter <NAME>._domainkey.<domain> veröffentlicht und der Ed25519-Schlüssel unter <NAME>-ed25519._domainkey.<domain>. Optional; Standardwert ist pepsi.

DKIM_ALGORITHMS = LISTE

Die DKIM-Signaturen, die pepsi-stage-dkim-sign(1) hinzufügt: eine durch Leerzeichen oder Kommas getrennte Liste aus rsa und ed25519. Optional; Standardwert sind beide. Gmail, Microsoft 365 und Yahoo verifizieren keine Ed25519-Signaturen (RFC 8463); sie ignorieren sie, und Googles DMARC-Aggregatberichte führen den Ed25519-Selektor als fail. Das ist harmlos — DMARC braucht ein ausgerichtetes Bestehen, und die RSA-Signatur liefert es —, aber rsa allein beseitigt das Rauschen. rsa wegzulassen ist erlaubt, und pepsi-setup(1) warnt davor: Diese Empfänger sähen dann überhaupt keine verifizierbare Signatur. pepsi-setup veröffentlicht und prüft nur die verwendeten Selektoren (dazu denjenigen, den das ARC-Siegel braucht, wenn dies die ARC_DOMAIN ist); beide Schlüsseldateien werden unabhängig davon erzeugt.

ARC_DOMAIN = DOMAIN

Domain, deren Identität pepsi-stage-arc(1) verwendet, um eingehende Mail per ARC zu versiegeln (RFC 8617). Die Versiegelung verwendet den DKIM-Schlüssel dieser Domain wieder, sodass pepsi-setup(1) sie zur Menge der Domains hinzufügt, für die es Schlüssel und DKIM-DNS-Einträge erzeugt; ARC benötigt keinen separaten Eintrag. Optional; wenn nicht gesetzt, werden Authentifizierungsergebnisse festgehalten, aber nicht versiegelt.

ARC_ALGORITHM = rsa | ed25519

Algorithmus, der das einzelne ARC-Siegel signiert (ARC erlaubt nur eines je Hop, anders als DKIM, das standardmäßig mit beiden signiert wird — siehe DKIM_ALGORITHMS). Optional; Standardwert ist rsa für die breiteste Interoperabilität.

ORIGINATE_SUCCESS_DSN = yes | no

Ob Pepsi eine positive (Action: delivered-)Zustellungsstatusbenachrichtigung erzeugen darf, wenn eine Zustellung gelingt und der Absender NOTIFY=SUCCESS angefordert hat. Optional; Standardwert ist no — Pepsi gibt normalerweise nur Failure-Bounces aus. Bei yes routen die Zustell-Stages (pepsi-stage-relay-to-internet(1), pepsi-stage-relay-to-smarthost(1), pepsi-stage-relay-to-maildir(1), pepsi-stage-relay-to-lmtp(1)) und pepsi-stage-discard(1) eine erfolgreiche Zustellung zu ihrem BOUNCE_STAGE (bei LMTP zu dessen NOTIFY_STAGE), um den Bericht auszugeben.

Sie regelt nur SUCCESS-Berichte. DELAY-Berichte haben ihren eigenen, stageweisen Schalter (das DELAY_DSN_AFTER einer Zustell-Stage, standardmäßig nicht gesetzt), und FAILURE-Bounces brauchen überhaupt keinen Schalter — sie sind der Standardwert, wenn das NOTIFY eines Empfängers nichts sagt. SUCCESS und DELAY werden gleichermaßen nur ausgegeben, wenn das NOTIFY des Absenders sie namentlich angefordert hat; keiner von beiden hat einen impliziten Standardwert.

MAILBOX_QUOTA = SIZE

Standardgrenze dafür, wie viel Mail ein lokales Konto halten darf, angewandt von pepsi-stage-relay-to-maildir(1). Eine schlichte Byte-Zahl oder ein K/M/G/T-Suffix in Potenzen von 1024 (2G, 500M, 1048576), oder none. Optional; Standardwert ist none — keine Quota. Die Grenze eines einzelnen Kontos wird mit pepsi-quota(1) set gesetzt, was dies überschreibt; die kerneleigene Grenze verschärft, was auch immer gilt.

Die Quota umfasst den gesamten Maildir++-Baum — die INBOX plus jeden Ordner (.Sent, .Trash, …) —, denn das ist es, was der Benutzer sein Postfach nennt, und nur die INBOX zu zählen ließe jeden unbegrenzt Mail einen Drag-and-drop davon entfernt parken.

MAILBOX_QUOTA_COUNT = N

Standardgrenze für die Anzahl der Nachrichten, die ein Konto halten darf; 0 oder abwesend für keine. Eine sehr große Zahl sehr kleiner Nachrichten ist ihr eigener Denial-of-Service gegen ein Postfach, den eine Byte-Grenze allein nicht verhindert.

MAILBOX_OVER_QUOTA = defer | bounce

Was mit einem Empfänger geschieht, dessen Postfach voll ist. Optional; Standardwert ist defer.

defer hält die Nachricht in der Warteschlange und wiederholt sie bis zum MAX_LIFETIME der Zustell-Stage, erzeugt dann einen Bounce — dieselbe Behandlung, die ein Kernel-EDQUOT erfährt, und sie gibt dem Konto Zeit, Platz zu schaffen. bounce weist sofort mit einem RFC-3463-5.2.2 ab und routet den Empfänger zum QUOTA_LIMIT_STAGE der Zustell-Stage, sodass der Absender nicht tagelang wartet.

Dieselbe Wahl bestimmt die Antwort, die pepsi-ingress(1) gibt, wenn es einen Empfänger mit erschöpfter Quota bei RCPT abweist: 452 4.2.2 für defer, 552 5.2.2 für bounce.

MAILBOX_QUOTA_MAX_AGE = DURATION

Wie lange einer Postfachmessung für eine Abweisung zur RCPT-Zeit vertraut werden darf. Optional; Standardwert ist 15 m. Einheiten sind h/m/s.

pepsi-ingress(1) weist einen Empfänger mit erschöpfter Quota nur auf einer Messung ab, die jünger als dies ist, nie auf der laufenden Nutzungsschätzung. Das ist eine Korrektheitsgrenze, keine Leistungsgrenze: Die Schätzung wächst nur (nichts sagt Pepsi, wann ein Benutzer Mail über IMAP löscht), sodass eine Abweisung darauf ein Postfach schlösse, dessen Eigentümer es inzwischen geleert hat — dauerhaft, denn wenn jede Nachricht abgewiesen wird, liefe keine Zustellung mehr, die neu misst. Diese Grenze und pepsi-quota(1) reconcile sind das, was das verhindert.

MAILBOX_QUOTA_RCPT_CHECK = yes | no

Ob pepsi-ingress(1) die Quota-Tabelle zur RCPT-Zeit heranzieht. Optional; Standardwert ist yes. Dort abzuweisen kostet eine indizierte Abfrage und spart einen Bounce: Der sendende MTA ist noch in der Leitung, sodass er seinem Benutzer Bescheid gibt und Pepsi kein Backscatter an einen möglicherweise gefälschten Umschlagabsender erzeugt. Es auszuschalten verlagert die gesamte Durchsetzung auf die Zustellzeit.

MAILBOX_HELPER = PATH

Der privilegierte Helper, den pepsi-quota(1) ausführt, um ein Postfach zu messen — für seinen measure-Unterbefehl und seinen reconcile-Durchlauf. Optional; Standardwert ist pepsi-helper-maildir-writer, aufgelöst auf dem PATH des aufrufenden Prozesses.

Es ist dasselbe Binärprogramm, das die Stage für die lokale Zustellung verwendet, in seinem measure-Modus aufgerufen: Ein Maildir ist 0700, daher ist dies der eine Prozess, der zum Benutzer werden und es lesen kann. Setzen Sie dies nur, wenn der Helper nicht unter seinem Namen auf dem PATH von pepsi-quota liegt — vor allem bei einer Quellcode-Installation mit --prefix. Halten Sie es mit der eigenen HELPER-Option der Zustell-Stage in deren [stage-<name>]-Abschnitt im Gleichschritt (siehe pepsi-stage-relay-to-maildir(1)): Die beiden benennen dasselbe Programm für zwei Aufrufer, und nur die der Stage gilt je Stage.

MAILBOX_FS_QUOTA = yes | no

Ob das Dateisystem, das die Home-Verzeichnisse hält, Platten-Quotas des Kernels durchsetzt, in welchem Fall Pepsi zusätzlich quotactl(2) heranzieht und die Kernel-Grenze die effektive verschärfen lässt. Optional; Standardwert ist no.

Normalerweise für Sie gesetzt. Dies ist eine Tatsache über die Mounts des Hosts, keine Vorliebe, sodass pepsi-setup(1) danach sondiert und die Antwort ohne Nachfrage festhält. Ein expliziter Wert wird nie überschrieben. Schalten Sie es ein, wo es zutrifft: Die Buchführung des Kernels ist die einzige der drei Schichten, an der der Kontoinhaber nicht manipulieren kann (die Maildir++-Datei maildirsize liegt in seinem eigenen Verzeichnis), und sie zählt alles, was ihm auf jenem Dateisystem gehört, statt nur seine Mail.

RECIPIENT_DELIMITER = CHARACTER | none

Der standortweite Subadress-Trenner (alice+lists ist Konto alice). Optional; Standardwert ist +. Ein [stage-<name>]-Abschnitt darf ihn für seine eigenen Zustellentscheidungen überschreiben, aber setzen Sie ihn vorzugsweise hier: pepsi-ingress(1) verwendet diesen Wert, um zu ermitteln, wessen Postfach-Quota ein Empfänger zuzuordnen ist, und hat keinen Stage-Abschnitt zu lesen, sodass eine abweichende Stage sub-adressierte Mail der Abweisung zur RCPT-Zeit entkommen lässt. pepsi-setup(1) warnt, wenn eine das tut.

Mailinglisten verwenden diesen Wert, und nur diesen, für jede Subadresse, die sie schreiben und lesen: den VERP-Umschlagabsender jeder Kopie (announce-bounces+alice=example.net@…), den Absender einer Bounce-Probe, die -confirm+token-Adresse und den Router von pepsi-stage-list(1), der sie bei ihrer Rückkehr erkennt. none belässt Listen bei +, da ein VERP-Absender nicht ohne Trennzeichen geschrieben werden kann.

MAX_QUEUE_ROWS = N | none

Zulassungskontrolle der Warteschlange: die höchste Zahl von Nachrichten (pepsi.workqueue-Datensätzen), die die Warteschlange halten darf, bevor pepsi-ingress(1) keine Mail mehr annimmt. Optional; Standardwert 1000000; none (oder 0) für keine Grenze. Ein Datensatz ist eine Empfängergruppe, also ist dies die Zahl, die der Fan-out einer Mailingliste oder die Aufteilung einer Relay-Stage in einen Datensatz pro Empfänger vervielfacht.

An der Grenze antwortet pepsi-ingress(1) bei RCPT, bei DATA/dem ersten BDAT-Chunk und nach dem Ende der Daten mit 452 4.3.1. Das ist eine vorübergehende Ablehnung: Der sendende MTA behält die Nachricht und versucht es erneut, während sich die bereits vorhandene Warteschlange leert. pepsi-stage-list-post(1) hält einen Fan-out für QUEUE_THROTTLE_DELAY zurück, statt seinen nächsten Stapel auszugeben. Bereits Eingereihtes ist nicht betroffen: Bounces, DSNs und automatische Antworten, die die Pipeline selbst erzeugt, werden nie abgelehnt.

MAX_QUEUE_BYTES = SIZE | none

Die höchste Zahl von Oktetten, die die Warteschlange halten darf: jeder eingereihte Header-Block plus jeder eingereihte Nachrichtentext, wobei jeder Nachrichtentext einmal gezählt wird, gleich wie viele Empfänger-Datensätze ihn teilen (er wird einmal gespeichert — siehe GESPEICHERTE DATEN unten). Eine reine Byte-Zahl oder ein Suffix K/M/G/T wie bei MAILBOX_QUOTA. Optional; Standardwert none. Nach dem Ende der Daten bezieht die Prüfung die Größe der angebotenen Nachricht ein, sodass eine einzelne übergroße Nachricht aus eigenem Grund abgelehnt wird. Ablehnungen erfolgen wie bei MAX_QUEUE_ROWS.

MIN_FREE_SPACE = SIZE | none

Der freie Platz, der auf dem Dateisystem, das FREE_SPACE_PATH enthält, verbleiben muss, damit Mail angenommen wird; eine Nachricht wird abgelehnt, wenn ihre Annahme weniger übrig ließe. Optional; Standardwert 1G; none schaltet die Messung ab. Dies ist die Grenze, die sieht, was nicht die Warteschlange ist – Write-Ahead-Log, andere Datenbanken, Logs –, und PostgreSQL läuft nicht eingeschränkt weiter, wenn sein Dateisystem voll wird: Es hält an, und mit ihm jede Stage, die Konsole und der Submission-Socket. Ablehnungen erfolgen wie bei MAX_QUEUE_ROWS.

FREE_SPACE_PATH = PATH

Wo MIN_FREE_SPACE gemessen wird (statvfs(3), der für einen unprivilegierten Schreiber verfügbare Platz). Optional; Standardwert /var/lib/postgresql, das Elternverzeichnis der Datenverzeichnisse der Debian-Cluster – ein Datenverzeichnis selbst ist 0700 postgres, aber statvfs muss einen Pfad nur erreichen, und sein Elternverzeichnis liegt in einem Standardlayout auf demselben Dateisystem. Setzen Sie es auf das Datenverzeichnis (oder dessen Einhängepunkt), wenn PostgreSQL seine Daten anderswo hält. Liegt die Datenbank auf einem anderen Host, existiert der Standardpfad meist nicht und die Messung ist stillschweigend aus; ein hier gesetzter Pfad, der sich nicht messen lässt, wird einmal protokolliert, und die Grenze wird dann nicht durchgesetzt.

QUEUE_CHECK_INTERVAL = DURATION

Wie lange eine Messung der Warteschlange wiederverwendet wird. Optional; Standardwert 10 s. Eine Messung sind zwei sequenzielle Scans (die Funktion pepsi.queue_usage()), daher nimmt jeder Prozess höchstens eine je Intervall vor, und jedes RCPT dazwischen wird aus dem zwischengespeicherten Wert beantwortet; die Grenzen sind also bis auf die Zulassungen eines Intervalls ungenau. Eine fehlgeschlagene Messung lässt Mail zu (und wird protokolliert) – ein Schluckauf der Datenbank darf nicht selbst zum Ausfall werden, und ein Einfügen, das sich tatsächlich nicht speichern lässt, antwortet weiterhin mit 451.

QUEUE_THROTTLE_DELAY = DURATION

Wie lange pepsi-stage-list-post(1) einen Fan-out zurückhält, für den es die Warteschlange voll vorfand, bevor es erneut nachsieht. Optional; Standardwert 60 s.

MAIL_LOG = off | summary | full

Ob eine Aufzeichnung je Nachricht geführt wird. Optional; Standardwert ist off.

Pepsi löscht den Datensatz einer Nachricht, wenn die Pipeline mit ihr fertig ist, sodass es normalerweise kein Erfolgsjournal je Nachricht gibt: Eine gewöhnliche Installation sammelt keine Aufzeichnung der Korrespondenz ihrer Benutzer an und kann nicht gezwungen werden, eine herauszugeben, die sie nicht hat.

Diese Option zu setzen ändert das. summary schreibt einen pepsi.mail_log-Datensatz, wenn eine Nachricht die Pipeline verlässt: mit dem Umschlagabsender und den Empfängern, der Richtung (outbound für lokal eingelieferte Mail, sonst inbound), der Stage, an der sie endete, dem Ergebnis (completed/failed) und dem, was die Pipeline über sie entschieden hat (eine geschlossene Liste von state-Schlüsseln: das Authentifizierungsurteil, die Spam- und die Bezahlt-Entscheidung, etwaige Fehlerdetails des nächsten Hops sowie die Krypto- und Sprachbefunde). full hält zusätzlich die Subject:-Zeile fest. Nachrichteninhalt wird bei keiner Einstellung je aufgezeichnet.

Warnung

Dies einzuschalten bedeutet, dass die Installation eine Aufzeichnung darüber führt, wer mit wem korrespondiert. Manche Installationen brauchen diesen Nachweis wirklich; vergewissern Sie sich, dass Ihre dazugehört und dass es dort, wo Sie tätig sind, rechtmäßig ist, ihn aufzubewahren.

Datensätze sind über GET /api/v1/mail-log für einen Prinzipal lesbar, der logs:read hält, sind für jede mailverarbeitende Komponente nur anfügbar und werden nach [pepsi-admin] MAIL_LOG_RETENTION_DAYS Tagen beschnitten. Der Schreibvorgang läuft auf derselben Anweisung mit wie das Terminal, das die Nachricht entfernt oder fehlschlagen lässt, sodass das Aktivieren des Journals keinen zusätzlichen Datenbank-Round-Trip kostet. Siehe das Kapitel „Die administrative API“ des Handbuchs.

ALLOW_FUSION = yes | no

Ob Stage-Fusion erlaubt ist. Wenn eine Stage zu einem Nachfolger weiterschaltet, der mit FUSION = yes markiert ist (siehe die stageweise Option unten), dessen PROGRAM in dasselbe vereinheitlichte pepsi-Binärprogramm eingefaltet ist und der keine Nachrichtenspalte benötigt, die der Vorgänger nicht bereits geladen hat, führt der Vorgänger den Rumpf des Nachfolgers in seinem eigenen Worker-Prozess aus — überspringt sowohl das weiterschaltende UPDATE als auch das ladende SELECT des Nachfolgers und meldet dem Dispatcher einen einzigen Abschluss für die gesamte fusionierte Kette. Optional; Standardwert ist yes. Setzen Sie es auf no, um jeden Stage-Übergang zurück durch die Datenbank und den Dispatcher zu zwingen (der Kosten-Benchmark je Stage tut dies, damit jede Stage als eigener, vom Dispatcher gestarteter Worker gemessen wird). Fusion ist ohnehin in einem programmweisen (multibin-)Build inaktiv, wo ein Nachfolger immer ein separater Prozess ist. Siehe pepsi-dispatch(1) für das vollständige Modell.

MTA_STS_MODE = enforce | testing | none

Modus der für unsere Domains veröffentlichten MTA-STS-Richtlinie. enforce und testing veranlassen pepsi-setup(1), einen _mta-sts.<domain>-TXT-Eintrag auszugeben (und pepsi-httpd(1), die zugehörige Richtliniendatei anzubieten); none schaltet das Veröffentlichen von MTA-STS ab. Optional; Standard enforce. Welche Hosts die Richtlinie erlaubt, ist MTA_STS_MX.

MTA_STS_MX = EINTRAG[, EINTRAG…]

Die als mx:-Zeilen in der MTA-STS-Richtlinie veröffentlichten Hosts – jeder MX, an den ein Absender zustellen darf, RFC 8461 §3.2 (mx „must appear at least once and may appear more than once“). Jeder EINTRAG ist entweder

HOST

ein Hostmuster, das für jede bediente Domain gilt, oder

DOMAIN:HOST

ein Hostmuster, das für genau diese eine bediente Domain gilt.

Die mx-Menge einer Domain sind die unqualifizierten Einträge plus die mit ihrem eigenen Namen qualifizierten; qualifizierte Einträge ergänzen die gemeinsame Menge, statt sie zu ersetzen, ein Betrieb, dessen Domains einen primären MX teilen, schreibt ihn also einmal und kann ihn nicht dadurch verlieren, dass er den Backup einer Domain qualifiziert. Ein Hostmuster darf eine einzelne führende Label-Wildcard verwenden (*.example.net), und : ist als Trenner eindeutig, weil ein Hostname keinen enthalten kann.

Die Richtlinie ist daher je Domain, und genau das braucht ein Rechner, der mehrere Domains bedient: die MX-Einträge jeder Domain benennen ihre eigenen Hosts, und es gibt keinen Grund, weshalb diese übereinstimmen sollten. Die Richtlinie jeder Domain erhält ihre eigene id in ihrem eigenen _mta-sts.<domain>-TXT-Eintrag, Absender speichern sie also unabhängig zwischen:

MTA_STS_MX = example.org:mx.example.org, example.net:mail.example.net

Optional. Fehlt die Option ganz, benennt die Richtlinie jeder Domain das [pepsi-ingress] HOSTNAME. Dieser Rückfall ist ein letztes Mittel und keine gute Voreinstellung: HOSTNAME ist der EHLO-Begrüßungsname, der kein Name sein muss, auf den irgendein MX-Eintrag zeigt – und wenn er es nicht ist, sagt eine enforce-Richtlinie jedem konformen Absender, überhaupt nicht an die Domain zuzustellen. Setzen Sie diese Option also auf die Hosts, die Ihre MX-Einträge tatsächlich benennen. Der Assistent von pepsi-setup(1) liest sie aus dem DNS und schreibt die Option für Sie, und jeder pepsi-setup run prüft die aufgelöste Menge erneut gegen lebende MX-Einträge und gibt die zu setzende Option aus, wenn sie nicht übereinstimmen (siehe pepsi-setup(1), MTA-STS-Gegenprüfungen).

Unter dem Standardmodus enforce sagt eine Richtlinie, die einen Host auslässt, jedem konformen Absender, dass er dorthin nicht zustellen darf; ein aus dieser Liste weggelassener Backup-MX empfängt also keine Post, solange der primäre ausgefallen ist.

Jeder genannte Host muss außerdem ein TLS-Zertifikat vorlegen, das für seinen eigenen Namen gültig ist (RFC 8461 §4.1), und pepsi-setup(1) stellt das bereit: die hier aufgeführten Hosts werden Subject Alternative Names auf dem Zertifikat der Ingress-Listener, das beim nächsten pepsi-setup run über certbot geweitet wird, falls es sie noch nicht abdeckt. Ein Zertifikat und nicht eines je Host, weil pepsi-ingress(1) je Listener ein einziges Zertifikat ausliefert und nicht nach SNI auswählt. Ein Wildcard-Eintrag ist die Ausnahme: HTTP-01 kann keinen beschaffen, dieses Zertifikat muss daher mit TLS_CERT/TLS_KEY bereitgestellt werden.

MTA_STS_MAX_AGE = SECONDS

Das in der MTA-STS-Richtlinie veröffentlichte max_age (wie lange Absender sie zwischenspeichern dürfen). Optional; Standardwert ist 604800 (eine Woche). RFC 8461 §3.2 begrenzt es auf 1..``31557600``, und ein Wert außerhalb davon wird zurückgewiesen — insbesondere 0, das eine sofort ablaufende Richtlinie veröffentlichen und damit MTA-STS abschalten würde, während es aussähe, als wäre es konfiguriert.

TEMPLATE_DIR = PATH

Verzeichnis, das die zur Laufzeit expandierten Nachrichtenvorlagen (<name>.<lang>.body) enthält — zum Beispiel die Zahlungsaufforderungs-Antwort von pepsi-stage-anti-spam(1) und den BOUNCE_MESSAGE-Body von pepsi-stage-bounce(1). Optional; Standardwert ist ${DATADIR}/templates, wo make install die mitgelieferten Vorlagen ablegt. ${DATADIR} wird aus dem Installationspräfix des laufenden Binärprogramms aufgelöst, sodass der Standardwert für eine --prefix=/usr-Installation /usr/share/pepsi/templates ist und jedem anderen Präfix folgt; setzen Sie diese Option nur, wenn die Vorlagen dort liegen, wo das Präfix es nicht impliziert.

LOG_JSON = yes | no

Gibt das Journal als strukturierte JSON-Zeilen (ein JSON-Objekt pro Eintrag) auf der Standardfehlerausgabe aus, statt im standardmäßigen menschenlesbaren Textformat, sodass ein Log-Aggregator wie Loki es ohne zusätzliches Parsen aufnehmen kann. Gilt für jedes Pepsi-Binärprogramm. Optional; Standardwert ist no (Text). Die -L/--log-Log-Stufen-Option und -v/--verbose gelten in beiden Formaten.

LOG = error | warn | info | debug | trace

Standardmäßige maximale Log-Stufe für jedes Pepsi-Binärprogramm. Weil alle Komponenten — einschließlich der Stage-Worker, die der Dispatcher startet (die kein eigenes Kommandozeilen-Log-Flag erhalten) — dieselbe Konfiguration laden, ist dies die einzige Stellschraube, die das Logging über die gesamte Pipeline auf einmal senkt oder anhebt; sie ist zum Beispiel das, was die Benchmark-Skripte auf warn setzen, damit das Logging je Nachricht ihre Messungen nicht verzerrt. Optional; Standardwert ist info. Das -L/--log-Flag überschreibt sie, wenn angegeben, für diesen einen Prozess.

PUBLIC_RESOLVERS = IP … | none

Die öffentlichen rekursiven Resolver, über die pepsi-setup(1) die DNS-Einträge, von denen dieser Host abhängt, so erneut prüft, wie das Internet sie sieht: den Reverse-DNS jeder PUBLIC_IP, die MX- und TXT-Einträge jeder bedienten Domain und die Adressen des Ingress-HOSTNAME (siehe DNS, wie das Internet es sieht in pepsi-setup(1)). Eine durch Leerzeichen oder Kommas getrennte Liste von IP-Adressen. Optional; Standardwert sind Google (8.8.8.8, 2001:4860:4860::8888), Cloudflare (1.1.1.1, 2606:4700:4700::1111) und Quad9 (9.9.9.9, 2620:fe::fe). none schaltet die Prüfung ab.

Eine Abfrage von diesem Host aus kann eine Zone nicht sehen, die nur das Netz dieses Hosts erreicht — ein Nameserver hinter NAT, dessen Port 53 nicht weitergeleitet wird, sieht von innen gesund aus —, und deshalb gibt es die Prüfung. Die Namen, die sie an diese Resolver sendet, sind solche, die dieser Host für jedermann zur Abfrage veröffentlicht; setzen Sie trotzdem none, wenn Sie lieber keinen fremden Resolver befragen lassen wollen, und prüfen Sie stattdessen von einem Rechner außerhalb Ihres Netzes. Nur von pepsi-setup gelesen.

SHARE_TELEMETRY = yes | no

Ob diese Installation anonyme Funktionsnutzungs-Telemetrie mit dem Pepsi-Projekt teilt. Opt-in: optional, Standardwert no, sodass eine Installation, die es nie setzt, nichts teilt. Auf yes gesetzt erzeugt pepsi-setup(1) eine zufällige SYSTEM_ID (unten), und der pepsi-telemetry-client(1)-Daemon aggregiert Funktionsnutzungs-Ereignisse von den Stage-Workern und pepsi-ingress(1) und übermittelt funktionsweise Zähler an TELEMETRY_SERVER unter dieser anonymen ID (keine Adressen, Nachrichtendaten, Hostnamen oder IP-Adressen). Auf no belassen bleibt ein laufender Daemon ruhend (kein Socket, nichts wird übermittelt), es wird keine SYSTEM_ID erzeugt, und die In-Process-Telemetrie-Aufrufe sind No-Ops, die keinen Socket öffnen. Ein nicht parsbarer Wert wird als no gelesen. Wer diese Option in der Datei ändert, benachrichtigt den Daemon (telemetry_changed); außerdem liest er die Datei jede Minute neu. Die Setup-Konsole im Browser kann sie nur einschalten, solange der Daemon mit einer SYSTEM_ID läuft.

SYSTEM_ID = 64-HEX

Anonymer 256-Bit-Bezeichner (64 Hexadezimalzeichen), der mit jedem Telemetriebericht übermittelt wird. Von pepsi-setup(1) erzeugt und hier geschrieben, erst wenn SHARE_TELEMETRY eingeschaltet wurde — für eine Installation, die nicht zugestimmt hat, wird nie einer geprägt; von pepsi-telemetry-client(1) benötigt. Ein Operator kann bei ausgeschalteter Telemetrie von Hand einen hinzufügen; das ist es, was der Browser-Konsole erlaubt, das Einschalten der Telemetrie anzubieten; ein Speichern in der Konsole behält ihn bei. Verwenden Sie ihn nicht über Installationen hinweg wieder.

TELEMETRY_SERVER = HOST | URL

Der zentrale Telemetrie-Collector. Optional; Standardwert ist telemetry.pepsi.taler.net. pepsi-telemetry-client(1) übermittelt an https://<server>/telemetry/{usage,features}; ein Wert mit einem expliziten scheme:// wird wörtlich beachtet (z. B. http://localhost:18080 für lokales Testen).

Die folgenden CRYPTO_*-Optionen regeln die Ende-zu-Ende-Nachrichtenkryptographie (OpenPGP und S/MIME) — nicht die DKIM/ARC-Schlüssel oben. Sie sind bewusst Systemadministrator-Einstellungen und stehen in [pepsi] statt in einem [stage-*]-Abschnitt, was sie strukturell außer Reichweite der Überschreibungsschicht je Adresse bringt (pepsi.settings überschreibt nur Stage-Abschnitte) und daher von pepsi-stage-edit-settings(1): Algorithmuswahl, Herabstufungserlaubnis, Annahme schwacher Digests und Mindestschlüsselgrößen sind Sicherheitsentscheidungen mit sicherem Standardwert, keine Vorlieben je Benutzer. Jede ist optional; eine Installation ohne Ende-zu-Ende-Kryptographie kann sie alle ignorieren. Der Schlüsselspeicher, in dem jene Schlüssel liegen, wird in [pepsi-crypto] (unten) konfiguriert und mit pepsi-keys(1) verwaltet.

CRYPTO_ALLOW_DOWNGRADE = no | negotiate | yes

Ob Pepsi einen herabgestuften Container ausgeben darf (S/MIME-AES-256-CBC-EnvelopedData, OpenPGP-SEIPDv1-mit-MDC) und 3DES bei der Entschlüsselung annehmen darf. Optional; der einkompilierte Wert ist negotiate, was nur herabstuft, wenn der eigene Schlüssel des Empfängers beweist, dass er es nicht besser kann — was zählt, denn ein großer Teil der installierten Basis kann eine RFC-9580-AEAD-Nachricht überhaupt nicht lesen. Das Lesen von SEIPDv1 und AES-CBC ist immer erlaubt und wird von dieser Option nicht beschränkt.

Eine installierte Pepsi liefert yes aus, aus ${DATADIR}/config.d/thunderbird.conf, sodass der effektive Standardwert auf einem paketierten System S/MIME-AES-256-CBC-EnvelopedData ist. Thunderbird 140.12.0esr kann unsere AES-256-GCM-AuthEnvelopedData nicht lesen und scheitert stillschweigend — kein Fehler, ein leerer Klartext —, sodass eine auf dem einkompilierten Standardwert belassene Installation der größten S/MIME-Client-Population, die es gibt, leere Mail schickte. Diese Datei zu löschen stellt AEAD in einem Schritt wieder her, und CRYPTO_ALLOW_DOWNGRADE = negotiate in pepsi.conf tut dasselbe, ohne sie zu löschen (pepsi.conf wird nach config.d geparst). Die Messung ist pepsi-crypto/tests/thunderbird.rs; die Client-Matrix steht im Interoperabilitätskapitel des Handbuchs.

yes vergröbert OpenPGP nicht: Die Verschlüsselungs-Stage fordert den Container auto an, den sowohl negotiate als auch yes je Empfänger auflösen — AEAD für ein Zertifikat, das SEIPDv2 ankündigt, SEIPDv1+MDC nur für eines, das es nicht tut. Der Unterschied zwischen den beiden Werten ist der S/MIME-Container und die Annahme einer eingehenden 3DES-S/MIME-Nachricht, die unter keiner Einstellung je ausgegeben wird. Eingehendes OpenPGP-3DES wird unter negotiate ebenso wie unter yes angenommen und nur unter no abgelehnt: Ein OpenPGP-Zertifikat gibt seine eigenen Chiffrierfähigkeiten an, sodass negotiate etwas hat, womit es aushandeln kann, während X.509 keine ankündigt und daher die strengere Regel bekommt.

pepsi-setup schreibt diese Option nicht. Der Assistent lässt sie bewusst aus der erzeugten pepsi.conf heraus — alles, was er dort schriebe, überschriebe die paketierte Datei —, sodass eine bewusste Überschreibung durch Bearbeiten von pepsi.conf von Hand oder mit pepsi-setup --wizard --expert=CRYPTO_ALLOW_DOWNGRADE erfolgt.

CRYPTO_ALLOW_WEAK_DIGESTS = yes | no

SHA-1- und MD5-Signaturen bei der Verifikation annehmen. Optional; Standardwert ist no. Eine Signatur unter einem schwachen Digest wird als solche gemeldet, nie stillschweigend als gültig gezählt.

CRYPTO_MIN_RSA_BITS = BITS

Kleinster RSA-Modulus, der bei eingehender Verifikation und ausgehender Verschlüsselung angenommen wird. Optional; Standardwert ist 2048. Werte unter 1024 werden rundweg abgelehnt.

CRYPTO_GENERATE_RSA_BITS = BITS

Modulusgröße, die verwendet wird, wenn diese Installation einen RSA-Schlüssel erzeugt. Optional; Standardwert 2048. Er darf nicht unter CRYPTO_MIN_RSA_BITS liegen — eine Installation darf keine Schlüssel erzeugen, die sie dann ablehnt — und die OpenPGP-Schlüsselerzeugung akzeptiert nur 2048, 3072 oder 4096.

CRYPTO_INLINE_PGP = accept | reject

Wie inline (nicht MIME) eingebettetes PGP zu behandeln ist. Optional; Standardwert accept, denn echte Absender geben es weiterhin aus. Pepsi erzeugt es nie.

CRYPTO_OPENPGP_ALGORITHM = ed25519 | rsa

Algorithmus, der beim Erzeugen einer neuen OpenPGP-Identität verwendet wird. Optional; Standardwert ed25519 — die Erzeugung ist augenblicklich, was zählt, weil eine Identität womöglich erzeugt werden muss, während eine Nachricht wartet. rsa verwendet CRYPTO_GENERATE_RSA_BITS.

CRYPTO_SMIME_ALGORITHM = rsa | p256 | p384

Algorithmus, der beim Erzeugen einer neuen S/MIME-Identität verwendet wird. Optional; Standardwert rsa (mit CRYPTO_GENERATE_RSA_BITS); p256 und p384 sind ECDSA/ECDH über der entsprechenden NIST-Kurve.

CRYPTO_SMIME_SHARED_KEY = yes | no

Ein S/MIME-Zertifikat ausstellen, das sowohl digitalSignature als auch keyEncipherment trägt, statt eines getrennten Signier- und Verschlüsselungszertifikats. Optional; Standardwert no.

Der Standardwert trennt sie, weil ein getrenntes Signierzertifikat bei Ablauf oder Widerruf zerstört werden kann — nichts Legitimes signiert je alte Mail neu, sodass ein ausgemusterter Signierschlüssel reine Fälschungshaftung ist —, während die Entschlüsselungshälfte behalten wird, damit archiviertes und unterwegs befindliches Chiffrat lesbar bleibt. Dies einzuschalten halbiert die Zertifikate, die ein Operator je Identität kauft, und gibt das auf: Ein gemeinsamer Schlüssel folgt der Entschlüsselungsregel, sodass das Widerrufen eines kompromittierten Signierschlüssels auch die Fähigkeit beendet, an diesem Zertifikat neue verschlüsselte Mail zu empfangen.

Die Option entscheidet nur, wie neu erzeugte Identitäten aussehen. Beide Gestalten werden dauerhaft unterstützt und können für eine Adresse nebeneinander bestehen, sodass jede Abfrage nach Fähigkeit statt nach Gestalt auflöst. Zusammen mit einem Elliptische-Kurven-CRYPTO_SMIME_ALGORITHM wird sie von pepsi-setup(1) abgelehnt: Ein EC-Schlüssel, der sowohl ECDSA als auch ECDH macht, ist algorithmusübergreifende Schlüsselwiederverwendung, die mehrere S/MIME-Clients ablehnen.

85.2.1.1.6. Der Abschnitt [pepsi-postgres]

Gemeinsame Datenbank-Verbindungseinstellungen. Jede Pepsi-Komponente verbindet sich mit der gleichen Datenbank und dem gemeinsamen pepsi-Schema, daher liegen diese Einstellungen in einem Abschnitt, statt pro Komponente wiederholt zu werden.

Bemerkung

Verbindungsbudget. Jeder Pepsi-Prozess öffnet seinen eigenen Verbindungspool. Die Stage-Worker und die Operator-CLIs erledigen ihre Datenbankarbeit streng seriell, sodass sie jeweils eine einzige Verbindung verwenden — und weil der Dispatcher bis zu einen Worker-Prozess pro Stage-Slot betreibt (die Summe der PARALLELISM der Stages), ist diese Regel von einer Verbindung pro Worker das, was den Großteil der Verbindungszahl vorhersagbar und minimal hält. Die nebenläufigen Komponenten halten einen kleinen begrenzten Pool, der durch ihre eigene DB_POOL_SIZE-Option dimensioniert wird: der pepsi-dispatch(1)-Koordinator (Standardwert 8, für die nebenläufige Ergebnisverarbeitung der vielen Worker) und die Server pepsi-ingress(1) und pepsi-httpd(1) (Standardwert je 1). Achten Sie beim Tuning darauf, dass Σ PARALLELISM (eine Verbindung pro lebendem Worker) + der Dispatcher-Pool + die Pools der beiden Server unter dem max_connections des Servers bleibt. Das QUEUE_LIMIT einer Stage geht nicht in dieses Budget ein: Mehr Nachrichten auf einen Worker zu pipelinen erhöht seine Zahl in Bearbeitung, nicht die Anzahl der Worker-Prozesse (oder Verbindungen), sodass es die sichere Stellschraube für den Durchsatz ist, wenn max_connections die bindende Beschränkung ist.

CONFIG

(Zeichenkette, erforderlich) PostgreSQL-Verbindungszeichenfolge oder -URI, z. B. postgres:///pepsi. Der Server setzt den Schema-Suchpfad auf pepsi und verwendet READ COMMITTED-Transaktionen (höchstens ein Schreiber berührt jemals einen gegebenen Warteschlangen-Datensatz, sodass serialisierbare Isolation unnötig ist).

Diese Datei ist für alle lesbar, daher darf die Zeichenfolge kein Passwort enthalten; jede Komponente verweigert mit einem solchen den Start.

Lokale Datenbank (die kanonische Einrichtung). Jede Komponente verbindet sich über den UNIX-Socket als die Rolle, die nach ihrem eigenen Systemkonto benannt ist (pepsi, pepsi-ingress, pepsi-httpd, pepsi-crypto, …), und die Peer-Authentifizierung von PostgreSQL prüft die UID. Nirgends existiert ein Passwort, und die Datenbankrechte jeder Rolle sind die Privilegiengrenze zwischen den Komponenten.

Entfernte Datenbank (empfohlene Einrichtung). Behalten Sie dasselbe Modell bei: eine Rolle pro Konto, jede mit eigenen Zugangsdaten, die kein anderes Konto lesen kann. Der Platzhalter {role} in der Verbindungszeichenfolge wird beim Verbindungsaufbau einer Komponente durch die Rolle ersetzt, als die sie sich verbindet, sodass eine Zeichenfolge für jede Rolle eine andere Datei benennt. Mit Client-Zertifikaten (die pg_hba.conf der Datenbank verwendet cert):

CONFIG = postgres://db.example.org/pepsi?sslmode=verify-full&sslcert=/etc/pepsi/postgres/{role}.crt&sslkey=/etc/pepsi/postgres/{role}.key

oder mit Passwörtern, eine libpq-Passwortdatei (.pgpass-Format, z. B. die einzelne Zeile *:*:*:*:<password>) pro Rolle:

CONFIG = postgres://db.example.org/pepsi?sslmode=verify-full&passfile=/etc/pepsi/postgres/{role}.pgpass

Jede Schlüssel- oder Passwortdatei gehört dem Konto ihrer Rolle und hat den Modus 0600 oder 0400; eine Passwortdatei, die jemand anderes lesen kann, wird abgelehnt, wie libpq sie ablehnt, und pepsi-setup run meldet jede Rolle, deren Konto auf dem Host existiert, deren Datei aber fehlt, einem anderen Konto gehört oder für andere offen ist. Lassen Sie den Benutzernamen in der Zeichenfolge weg (oder schreiben Sie dort {role}): Jede Komponente liefert ihren eigenen. Weil die Datei beim Öffnen der Verbindung gelesen wird, und zwar von dem Konto, das sie öffnet, liest eine setuid-Stage wie pepsi-stage-encrypt die pepsi-crypto-Datei, und der Dispatcher, der sie gestartet hat, kann das nicht. Die Zeichenfolge selbst enthält dann kein Geheimnis und bleibt in dieser Datei.

Überschreibung per Umgebung. Die Umgebungsvariable PEPSI_POSTGRES_CONFIG ersetzt, wenn sie gesetzt und nicht leer ist, diese Option und darf ein Passwort enthalten. Jede mitgelieferte systemd-Unit liest sie aus EnvironmentFile=-/etc/pepsi/postgres.env (das vorangestellte - macht die Datei optional; halten Sie sie root-eigen mit 0600, da systemd sie vor dem Start des Dienstes als root liest). Die setuid- und setgid-Programme behalten die Variable nur, wenn root oder das Dispatcher-Konto pepsi sie gestartet hat, sodass die Stages die Datenbank des Dispatchers erreichen, während ein gewöhnlicher Benutzer ein privilegiertes Programm nicht auf eine andere richten kann. Ein Passwort darin ist ein Passwort für jede Rolle, was die Trennung zwischen den Komponenten aufgibt; bevorzugen Sie die Dateien pro Rolle oben und verwenden Sie die Variable für das, was sich zwischen Hosts unterscheidet. Ist sie gesetzt, darf CONFIG entfallen; ein Passwort in CONFIG wird auch dann abgelehnt. Ein aus einer Shell ausgeführtes Werkzeug (pepsi-setup run, pepsi-queue, …) braucht die Variable auf dieselbe Weise exportiert, z. B. set -a; . /etc/pepsi/postgres.env; set +a.

SQL_DIR

(Pfad, optional) Verzeichnis, das die SQL-Migrationsdateien enthält. Nur pepsi-setup(1) liest dies, beim Installieren des Schemas; die bedienenden Komponenten ignorieren es. Standardwert ist ${DATADIR}/sql (d. h. <install-prefix>/share/pepsi/sql, wo make install die Dateien ablegt). Überschreiben Sie es, wenn Sie aus einem Quellcode-Checkout ausführen.

WORKER_SYNCHRONOUS_COMMIT

(boolesch, optional) Ob die Datenbankverbindung eines Stage-Workers PostgreSQLs synchronous_commit angeschaltet lässt. Standardwert ist no.

Ist es aus, kehrt das COMMIT eines Workers zurück, bevor der Write-Ahead-Log-Eintrag stabilen Speicher erreicht hat, was die Schreibvorgänge der Pipeline gruppiert committen lässt, statt dass jeder sein eigenes Flush bezahlt. Sonst ändert sich nichts: Isolation, Atomarität und Sichtbarkeit sind unberührt, und ein Absturz kann nie eine teilweise Transaktion offenlegen. Verloren gehen können die letzten paar hundert Millisekunden Dauerhaftigkeit — und das nur für Stage-Übergänge, nie für die Annahme einer Nachricht, denn pepsi-ingress(1) committet immer synchron. Ein 250 bedeutet weiterhin, dass die Nachricht auf der Platte ist.

Einen Stage-Übergang an einen Maschinenabsturz zu verlieren bedeutet, dass die Nachricht noch an der vorherigen Stage vorgefunden wird und ein zweites Mal durch sie läuft — genau das, was ohnehin passiert, wenn ein Worker getötet wird, nachdem er seine Arbeit getan hat, aber bevor er committet. Setzen Sie dies auf yes, wenn eine Stage in Ihrer Pipeline Seiteneffekte hat, die auch über einen Stromausfall hinweg nicht wiederholt werden dürfen, und nehmen Sie die Durchsatzkosten in Kauf.

85.2.1.1.7. Der Abschnitt [pepsi-srs]

Die Sender-Rewriting-Scheme-Parameter, geteilt von pepsi-stage-srs(1) (die Vorwärts-Umschreibung) und pepsi-ingress(1) (die Rückwärts-Dekodierung zur RCPT-Zeit), sodass Geheimnis und Domain in beiden Richtungen übereinstimmen. Das Weglassen des Abschnitts deaktiviert SRS: Die Stage verweigert die Ausführung, und Ingress behandelt SRS-aussehende Empfänger als gewöhnliche Adressen.

SRS_DOMAIN

(Zeichenkette, erforderlich, um SRS zu aktivieren) Domain, unter der umgeschriebene Umschlagabsender liegen. Sie muss eine Domain sein, die Sie kontrollieren: ihr MX muss auf das Pepsi-Ingress zeigen (damit Bounces zurückkommen) und ihr SPF muss Pepsis Sende-IPs autorisieren. pepsi-setup(1) stellt Schlüssel und DNS dafür bereit. Der MX ist die Hälfte, die es nicht bereitstellen kann – wohin die Post einer Domain geroutet wird, ist Ihre Entscheidung –, es prüft daher stattdessen: läuft eine Stage mit pepsi-stage-srs(1), wird eine SRS_DOMAIN ohne MX und ohne Adresseintrag bei jedem Lauf gemeldet, denn eine SRS-Adresse ist ein Rückweg, und eine Domain, die nicht empfangen kann, verwirft jeden Bounce für die Post, die dieser Rechner weiterleitet. Sie muss keine eigene Subdomain sein; eine Domain, für die Sie schon Post annehmen, funktioniert und braucht überhaupt keine neuen Einträge (pepsi-ingress(1) dekodiert einen SRS-Local-Part, bevor es ein Postfach nachschlägt, gewöhnliche Adressen dort sind also unberührt).

SECRET_FILE / SECRET

(erforderlich, wenn SRS_DOMAIN gesetzt ist) Das Geheimnis, das den HMAC schlüsselt, der SRS-Adressen signiert, angegeben als Dateipfad (bevorzugt; speichern Sie es mit Modus 0600) oder inline. Es muss über die Zeit stabil bleiben — ein Tage später zurückgesendeter Bounce muss sich weiterhin verifizieren lassen — und über alle Instanzen hinweg identisch sein.

MAX_AGE_DAYS

(ganzzahlig, optional) Wie viele Tage eine umgeschriebene Adresse für zurückkehrende Bounces gültig bleibt (SRS-Zeitstempel sind taggenau). Standardwert 21. Begrenzt auf 1..``1021``: Der Tageszähler läuft nach 1024 Tagen über, sodass ein Fenster von dieser Größe oder darüber jeden Zeitstempel verifizieren ließe und den Ablauf gänzlich abschaltete.

Die Signatur in einer umgeschriebenen Adresse ist 8 Base32-Zeichen lang — 40 Bit —, und keine kürzere wird je akzeptiert. Eine gültige Signatur ist nicht leicht zu fälschen: pepsi-ingress(1) behandelt einen verifizierten SRS-Empfänger als Autorisierung, an die dekodierte Adresse weiterzuleiten, auch wenn deren Domain keine ist, die diese Installation bedient, sodass ein gefälschtes Token ein offenes Relay und beliebiges Backscatter unter dem Namen dieses Hosts bedeutet. Es gibt keine Option, eine schmalere Signatur zu akzeptieren: Sie ließe die Installation nur so stark wie den schmaleren MAC, solange sie gesetzt wäre. Die Obergrenze fehlgeschlagener SRS-Empfänger je Verbindung (pepsi-ingress(1) verwirft eine Verbindung nach dreien mit 421) begrenzt die Online-Suche gesondert; keine der beiden Grenzen ersetzt die andere.

85.2.1.1.8. Der Abschnitt [pepsi-origin]

Schlüsselmaterial für den Herkunftsnachweis, geteilt von beiden Relay-Stages (pepsi-stage-relay-to-internet(1) und pepsi-stage-relay-to-smarthost(1), die den Pepsi-Origin-Header auf ausgehende Mail stempeln und ihre Nonce festhalten) und pepsi-stage-anti-spam(1) (das den Header auf einem zurückkehrenden Bounce verifiziert). Die Funktion ist standardmäßig an: Wenn kein Geheimnis konfiguriert ist, erzeugt pepsi-setup(1) beim ersten Lauf ein zufälliges (sofern [pepsi-ingress] HOSTNAME gesetzt ist). Das Geheimnis wird nicht inline in dieser für alle lesbaren Datei gespeichert; es wird in ein secrets.d/pepsi-origin.secret-Fragment neben der Konfiguration geschrieben (im Besitz des pepsi-Dispatcher-Kontos, Modus 0640) und mit einer @inline-secret@-Direktive in diesen Abschnitt eingezogen. Ein erneuter Lauf von Setup verwendet das vorhandene Fragment wieder, statt den Schlüssel zu rotieren. ENABLED = no deaktiviert die Funktion — ausgehende Mail ist ungestempelt und jeder Bounce ist dann nicht verifizierbar (geroutet gemäß dem BOUNCE_TARGET_STAGE der Stage, sonst weitergeleitet). Das Entfernen des Abschnitts tut das nicht: Der nächste Lauf von pepsi-setup(1) würde ein neues Geheimnis bereitstellen.

ENABLED

(boolesch, optional) Standardwert YES. NO schaltet den Herkunftsnachweis für jede Komponente ab, die diesen Abschnitt liest, gleich welches Geheimnis konfiguriert ist, und hält pepsi-setup(1) davon ab, eines zu erzeugen. Ein vorhandenes Geheimnis-Fragment bleibt bestehen, sodass ein Wiedereinschalten mit demselben Schlüssel fortfährt.

Der Header trägt die Version, unser HOSTNAME (die [pepsi-ingress]-Option), das Ursprungs-Absenderkonto, eine 128-Bit-Nonce und einen Zeitstempel sowie einen HMAC-SHA256 über sie alle. Jede gestempelte Nonce wird für zwei Wochen in pepsi.origin_nonce festgehalten; einem Bounce wird nur vertraut, wenn der MAC seines eingebetteten Headers verifiziert und seine Nonce noch verfolgt wird. Siehe pepsi-stage-anti-spam(1).

SECRET_FILE / SECRET

Das Geheimnis, das den HMAC schlüsselt, angegeben als Dateipfad (bevorzugt; speichern Sie es mit Modus 0600) oder inline. Wie das SRS-Geheimnis muss es über die Zeit stabil bleiben — ein Tage später zurückgesendeter Bounce muss sich weiterhin verifizieren lassen — und über alle Instanzen hinweg identisch sein. Wenn keines gesetzt ist, richtet pepsi-setup(1) ein zufälliges SECRET in einem secrets.d/pepsi-origin.secret-Fragment ein, das per @inline-secret@ referenziert wird (siehe oben), und hält es so aus der für alle lesbaren Hauptkonfiguration heraus. Die Funktion erfordert [pepsi-ingress] HOSTNAME (in den MAC eingebunden).

85.2.1.1.9. Der Abschnitt [pepsi-crypto]

Verwahrung und Lebenszyklus des Ende-zu-Ende-Schlüsselspeichers — der von pepsi-keys(1) verwalteten Tabellen pepsi.crypto_identity, pepsi.peer_key und pepsi.ca_trust. Wie die CRYPTO_*-Optionen von [pepsi] oben ist dies nur für Administratoren, aber es geht um Speicherung statt um kryptographische Stärke. Lassen Sie den ganzen Abschnitt weg, wenn die Installation keine Ende-zu-Ende-Kryptographie betreibt; sobald er irgendetwas sagt, besteht pepsi-setup(1) auf einem brauchbaren KEY_WRAP_SECRET, denn ein Schlüsselspeicher, der keine Schlüssel speichern kann, ist ein Konfigurationsfehler und keine Wahl.

Privates Schlüsselmaterial wird in der Datenbank gehalten, mit AES-256-GCM unter einem aus KEY_WRAP_SECRET abgeleiteten Schlüsselverschlüsselungsschlüssel (KEK) versiegelt. Die Datenbank allein liefert daher nie einen privaten Schlüssel: Ein Dump, ein Replikat oder ein Sicherungsband erzeugt Chiffrat, und der Schlüssel, der es öffnet, ist ein separates, von Dateirechten bewachtes Artefakt. Die andere Hälfte der Grenze ist eine Datenbankberechtigung — crypto_identity.private_wrapped ist allein der Rolle pepsi-crypto gewährt; siehe pepsi-setup(1).

KEY_WRAP_SECRET

(Zeichenkette, erforderlich, sobald der Abschnitt existiert) Der Schlüsselverschlüsselungsschlüssel (KEK), der privates Schlüsselmaterial im Ruhezustand verpackt. Halten Sie ihn aus dieser für alle lesbaren Datei heraus: Legen Sie ihn in ein secrets.d/pepsi-crypto.secret-Fragment und referenzieren Sie ihn mit einer @inline-secret@-Direktive, genau wie die SRS- und Herkunftsnachweis-Geheimnisse behandelt werden. Jedes run von pepsi-setup(1) setzt Modus 0640 auf jenem Fragment erneut durch und übergibt es dem pepsi-crypto-Konto. Weniger als 16 Zeichen werden abgelehnt.

Sichern Sie ihn getrennt von der Datenbank. Geht er verloren, ist jeder gespeicherte private Schlüssel weg: Postfächer enthalten Klartext, sodass niemandes Mail unlesbar wird, aber unterwegs befindliches und archiviertes Chiffrat ist verloren, jede veröffentlichte Identität ist ungültig, und die Organisation muss neue Schlüssel ausstellen.

KEY_WRAP_KEY_ID

(Zeichenkette, optional) Bezeichner des Schlüsselverschlüsselungsschlüssels (KEK), unter dem neues Material verpackt wird. Standardwert k1. Muss eine nicht leere Folge aus ASCII-Buchstaben, Ziffern und Unterstrichen sein, denn er wird in den Optionsnamen KEY_WRAP_SECRET_<ID> eingesetzt, aus dem ein ausgemusterter Schlüssel gelesen wird. Jeder Datensatz hält die ID fest, die ihn versiegelt hat, was die Rotation inkrementell statt zu einem Stichtag macht.

KEY_WRAP_SECRET_<ID>

(Zeichenkette, optional) Ein ausgemusterter Schlüsselverschlüsselungsschlüssel (KEK), aufbewahrt, bis jeder darunter verpackte Datensatz rotiert wurde. <ID> ist die von ihm benannte wrap_key_id, großgeschrieben (also KEY_WRAP_SECRET_K0 für Schlüssel k0). Zwischen dem Einführen eines neuen Schlüssels und dem Ausführen von pepsi-keys wrap rotate arbeitet die Installation weiter: Neues Material wird unter dem neuen Schlüssel versiegelt, während sich altes Material weiterhin unter diesem öffnen lässt. Entfernen Sie ihn, sobald die Rotation meldet, dass alles neu verpackt ist.

AUTO_CREATE_IDENTITY

(boolesch, optional) Ob für eine bediente Adresse automatisch eine Identität erzeugt werden darf. Standardwert YES. pepsi-stage-encrypt(1) ist es, das danach handelt, und nur für eine Adresse in einer Domain aus [pepsi-ingress] ACCEPTED_DOMAINS, die noch keine crypto_identity-Zeile irgendeiner Art hat (ein widerrufener Schlüssel oder der eigene registrierte Schlüssel des Benutzers zählt), unter CRYPTO_OPENPGP_ALGORITHM / CRYPTO_SMIME_ALGORITHM und IDENTITY_VALIDITY_DAYS. Wann es greift, hängt von ENABLE_PEP dieser Stage ab:

• ENABLE_PEP = yes (der Standardwert): eifrig, bei der ersten lokal eingelieferten Nachricht des Absenders, ob sie Schutz angefordert hat oder nicht. Jeder Absender einer bedienten Domain hat daher am Ende einen eingehüllten privaten Schlüssel auf diesem Server, und der WKD der Installation liefert dessen öffentliche Hälfte aus.

• ENABLE_PEP = no: bei Bedarf, das erste Mal, wenn ein lokaler Absender ausdrücklich Schutz anfordert (zum Signieren oder nur zum Verschlüsseln), oder bei jeder Nachricht unter SIGN = always dieser Stage; nie bloß deshalb, weil eine Adresse in einem Umschlag auftauchte, sodass ein Benutzer, der die Funktion nie nutzt, nie Schlüsselmaterial hat.

Diese Option ist das Veto des Operators über beides: Sie liegt in einem nur für Administratoren zugänglichen Abschnitt, sodass keine adressbezogene pepsi.settings-Überschreibung die automatische Erzeugung wieder einschalten kann. Ist sie aus, wird jede Identität auf Anforderung erzeugt – mit pepsi-keys(1), der Web-Konsole oder dem E-Mail-Befehl generate.

Weil der Auslöser auf dem ausgehenden Pfad liegt, bleibt eine Adresse, die nur empfängt, schlüssellos und wird nie veröffentlicht — Außenstehende haben daher nichts, womit sie an sie verschlüsseln könnten. Richten Sie solche Adressen vorab mit pepsi-keys identity generate ein.

IDENTITY_VALIDITY_DAYS

(Zahl, optional) Lebensdauer einer erzeugten Identität, in Tagen. Standardwert 730 (zwei Jahre); muss positiv sein. Eine ganzzahlige Anzahl von Tagen statt einer duration, weil der Parser Kalendereinheiten ablehnt (siehe die Warnung am Anfang dieser Seite). pepsi-keys identity generate --days überschreibt sie für eine Identität.

LOCAL_DOMAINS, TARGETS, RECIPIENT_DELIMITER

(Zeichenkette, optional) Welchen Domains und Konten eine Adresse zugerechnet wird, wenn entschieden wird, wem eine Identität gehört, ob nun pepsi-keys(1), der Setup-Applier oder pepsi-stage-encrypt(1) sie erzeugt — dieselben Optionsnamen, Bedeutungen und Standardwerte wie die Optionen der lokalen Zustell-Stages (pepsi-stage-relay-to-maildir(1)). LOCAL_DOMAINS fällt auf [pepsi-ingress] ACCEPTED_DOMAINS zurück, TARGETS auf den UID_MIN..``UID_MAX``-Bereich aus /etc/login.defs und RECIPIENT_DELIMITER auf +. Eine Adresse, die zu einem lokalen Konto auflöst, bekommt diesen Login bei ihrer Identität festgehalten und darf von diesem Benutzer verwaltet werden; eine, die es nicht tut (eine Rollenadresse, eine gehostete Domain), ist nur für Operatoren.

85.2.1.1.10. Der Abschnitt [pepsi-keydiscovery]

Wie Pepsi den öffentlichen Schlüssel oder das Zertifikat eines Korrespondenten findet — die Eingabe für pepsi.peer_key, im Unterschied zu [pepsi-crypto] oben, das die Verwahrung unseres eigenen Schlüsselmaterials betrifft. Gelesen von den pepsi-keydisc(1)-Entdeckungsdiensten, von pepsi-keys(1) (dessen peer refresh --address dieselbe Auffächerung in einem Prozess ausführt) und von jeder Stage, die eine Nachricht an einem Schlüssel parken muss, den sie noch nicht hat.

Der ganze Abschnitt ist optional: ohne ihn läuft die Entdeckung mit der Standard-Quellenmenge.

Die Entdeckung ist asynchron. Eine Stage, die einen Schlüssel braucht, den sie nicht im Cache hat, betreibt keine eigene Netz-E/A — sie schreibt ihre Arbeit fest, pausiert die Nachricht und reiht eine Anfrage in pepsi.key_request ein, und ein Entdeckungsdienst beantwortet die Anfrage und gibt jede an dieser Adresse geparkte Nachricht frei. Siehe pepsi-keydisc(1) für die Dienstseite und pepsi.state(7) für den keydisc-Schlüssel, den eine geparkte Nachricht trägt.

SOURCES

(Zeichenkette, optional) Welche Entdeckungsmethoden diese Installation betreibt, als komma- oder leerraumgetrennte Liste aus dane, wkd-advanced, wkd-direct, ldap und vks (wkd wird für wkd-advanced angenommen, hkp für vks; Duplikate werden ignoriert). Standardwert dane wkd-advanced wkd-direct vks — ldap fehlt bewusst, da es feature-gebunden und bis zur Konfiguration nutzlos ist.

Diese Liste ist auch die Liste, auf die die Abbruchregel wartet, was zwei Folgen hat. Eine pepsi-keydisc@<method>-Instanz, deren Methode nicht aufgeführt ist, verweigert den Start; und eine aufgeführte Methode ohne laufende Instanz kostet jede Anfrage lediglich das volle TIMEOUT, bevor sie sich erledigt. Halten Sie die Liste und die laufenden Units im Gleichschritt: pepsi.target startet genau die vier Standardmethoden, lassen Sie die Option also ungesetzt, sofern Sie nicht auch Instanzen maskieren oder starten. inbound und gossip (und ihre Aliasse harvested/autocrypt und autocrypt-gossip) werden abgelehnt: Einen Schlüssel aus einer Nachricht zu lernen ist kein Dienst – es läuft inline in pepsi-stage-autocrypt-learn(1) aus Material, das ohnehin in der Nachricht steckt –, sodass nie etwas darauf antworten würde. Eine leere Liste wird ebenfalls zurückgewiesen; entfernen Sie die Option, um den Standardwert zu nehmen.

MIN_TRUST

(Zeichenkette, optional) Die Vertrauensuntergrenze — ein Schlüssel aus einer schlechter eingestuften Quelle wird nicht verwendet. Nach seiner Quelle benannt: manual (auch api oder operator), dane, wkd-advanced (auch wkd), wkd-direct, ldap, vks (auch hkp), harvested (auch inbound oder autocrypt) oder gossip (auch autocrypt-gossip, any, none). Standardwert any — alles annehmen.

Eine weitere Schreibweise, owner-confirmed (owner_confirmed), benennt eine Sprosse danach, was der Nachweis ist, statt nach der Methode, die ihn erbracht hat: Sie löst sich zu vks auf, der schwächsten Sprosse, bei der jemand, der die Kontrolle über das Postfach oder die Domain nachweisen konnte, den Schlüssel absichtlich veröffentlicht hat. Es gibt sie, damit das Einfügen einer Sprosse zwischen vks und harvested diese Linie nicht stillschweigend verschieben kann. Sie ist außerdem der Standardwert von [stage-encrypt] GOSSIP_MIN_TRUST.

Die Alternative dazu, an einen Schlüssel mit Vertrauen beim ersten Gebrauch zu verschlüsseln, ist kein besserer Schlüssel, sondern Klartext. Sie anzuheben ist die Art, wie eine Installation sagt, dass sie lieber nichts sendet, als an einen unauthentifizierten Schlüssel zu senden. Die Einstufung leistet auch beim Standardwert noch Arbeit: Sie entscheidet Konflikte, und sie wird je Schlüssel festgehalten.

any/none benennen die unterste Sprosse, welche das gerade auch sei, während jede andere Schreibweise genau einen Rang benennt. Der Unterschied zählt für die beiden, die sich ähneln: harvested ist Rang 7 — was ein Korrespondent über seine eigene Adresse gesagt hat, in einem Autocrypt:-Header oder einem beigefügten Schlüssel — und gossip ist Rang 8, die Einführung eines anderen durch einen Korrespondenten (Autocrypt Level 1 §5.3). MIN_TRUST = harvested ist also die nützliche mittlere Einstellung: opportunistische Verschlüsselung behalten, Einführungen durch Dritte ablehnen. Gegossipte Schlüssel werden so oder so gespeichert; die Untergrenze entscheidet nur, ob sie verwendet werden dürfen.

Die Untergrenze gilt nicht für eine Adresse, für die diese Installation eine Identität hält. Unser eigener Schlüssel ist kein entdeckter Schlüssel: Er greift der Abfrage vor, sodass kein peer_key-Datensatz für diese Adresse herangezogen wird, welchen Rang er auch hat, und keine Untergrenze ihn ausschließen kann. own (auch local) wird der Vollständigkeit halber als Schreibweise angenommen — jeder Rang hat einen Namen, und state.crypto stellt diesen dar —, aber als Untergrenze bedeutet es „nur an Adressen verschlüsseln, für die wir unseren eigenen Schlüssel halten“, d. h. kein externer Korrespondent bekommt je Chiffrat. Siehe pepsi-stage-encrypt(1) und pepsi-stage-decrypt(1).

TIMEOUT

(Dauer, optional) Frist der gesamten Anfrage: wie lange eine Anfrage ausstehen darf, bevor sie sich mit dem erledigt, was gefunden wurde. Standardwert 60 s. Verwendet nur h/m/s-Einheiten (siehe die Anmerkung zu Dauern oben).

INBOUND_TIMEOUT

(Dauer, optional) Dieselbe Frist für eine auf dem eingehenden Pfad geparkte Nachricht — die auf den Schlüssel wartet, der eine Signatur prüft —, standardmäßig TIMEOUT. Sie ist gerade deshalb getrennt, damit sie für sich gesenkt werden kann: Ein eingehendes Parken verzögert genau die Mail, auf die jemand wartet, sodass ein Operator, der es spürt, dies auf Sekunden senken kann, ohne die ausgehende Frist zu verkürzen. pepsi-setup(1) warnt oberhalb von fünf Minuten.

RANK_GRACE

(Dauer, optional) Der Regler zwischen Tempo und Gründlichkeit. Wenn eine Abfrage gelingt, wird jeder noch laufenden Methode, die besser rangiert, RANK_GRACE × (um wie viele Ränge sie besser ist) an zusätzlicher Zeit gewährt; läuft die ab, gewinnt die beste vorliegende Antwort. Standardwert 5 s, sodass ein Rang höher 5 s und drei Ränge höher 15 s bekommt.

Eine Stellschraube, die den ganzen Bereich aufspannt: 0 bedeutet, dass die erste brauchbare Antwort rundweg gewinnt; der Standardwert liegt dort, wo ein langsamer WKD-Server eine Nachricht nicht hinter einem bereits eingetroffenen Keyserver-Treffer festhalten kann, eine fast ebenso schnelle bessere Quelle aber noch gewinnen darf; ein Wert auf oder über TIMEOUT bedeutet, dass auf jede Methode gewartet wird und die Einstufung vollständig gilt (pepsi-setup(1) merkt diesen Fall an, statt ihn als Fehler zu behandeln — er ist eine legitime Wahl).

METHOD_TIMEOUT

(Dauer, optional) Die eigene Netzfrist einer Methode, die Verbindungsaufbau, Handschlag und jeden Lesevorgang abdeckt. Standardwert 15 s. Sie über TIMEOUT zu setzen macht eine langsame Methode unfähig, innerhalb der Frist der gesamten Anfrage fertig zu werden, wovor pepsi-setup(1) warnt.

CACHE_TTL

(Dauer, optional) Wie lange ein gespeicherter Schlüssel verwendet wird, bevor pepsi-keys peer refresh ihn erneut prüft (er wird zum refresh_after des Datensatzes). Standardwert 24 h.

NEGATIVE_TTL

(Dauer, optional) Wie lange ein autoritatives „diese Adresse hat keinen Schlüssel“ erinnert wird. Standardwert 24 h. Solange der Eintrag frisch ist, nimmt eine Nachricht für diese Adresse sofort den Kein-Schlüssel-Pfad und parkt nie: 60 s zu pausieren, um eine bekannte Antwort neu zu lernen, verzögert nur jede Nachricht an diesen Korrespondenten. Die in Kauf genommenen Kosten sind, dass ein vor fünf Minuten veröffentlichter Schlüssel unsichtbar bleibt, bis der Eintrag ausaltert — senken Sie dies, wenn das mehr zählt als die Verzögerung.

ERROR_TTL

(Dauer, optional) Dasselbe, nachdem eine Methode gescheitert ist, statt „hier ist nichts“ zu antworten. Standardwert 1 h: „der Server war unten“ ist es wert, früher erneut versucht zu werden als „es gibt keinen Schlüssel“.

MAX_RESPONSE_BYTES

(Zahl, optional) Obergrenze für den abgeholten Body einer WKD- oder VKS-Antwort, während des Streamens statt danach durchgesetzt, sodass ein 10 MB großer Body die Obergrenze und nicht 10 MB kostet. Standardwert 262144 (256 KiB). Muss größer als null sein.

VKS_SERVERS

(Zeichenkette, optional) Abzufragende verifizierende Keyserver, der Reihe nach, als komma- oder leerraumgetrennte Liste. Standardwert https://keys.openpgp.org. Jeder Eintrag muss eine https://-URL sein — ein über einen unauthentifizierten Kanal abgeholter Schlüssel ist kein Schlüssel, dem zu glauben es einen Grund gäbe — und ein abschließender / wird entfernt.

ALLOW_DOMAINS, DENY_DOMAINS

(Zeichenkette, optional) Abfragerichtlinie für Empfängerdomains, komma- oder leerraumgetrennt und am Domainteil ohne Beachtung der Groß-/Kleinschreibung abgeglichen. Ein nicht leeres ALLOW_DOMAINS ist ausschließend (nur jene Domains werden je abgefragt); DENY_DOMAINS gewinnt immer darüber. Beide sind standardmäßig leer, sodass jede Domain abgefragt werden darf. Eine Adresse ohne @ wird nie abgefragt.

Dies ist die Privatsphären-Steuerung auf der Empfängerseite, und sie ist die des Operators. Der Schalter je Benutzer unten ist die Absenderseite; die beiden sind nicht austauschbar.

LDAP_URL, LDAP_BASE, LDAP_FILTER, LDAP_ATTRIBUTE, LDAP_BIND_DN, LDAP_BIND_PASSWORD

(Zeichenkette, optional) Das Verzeichnis, das pepsi-keydisc@ldap abfragt. LDAP_URL muss eine ldap://- oder ldaps://-URL sein und ist, zusammen mit LDAP_BASE, erforderlich, sobald ldap in SOURCES steht. LDAP_FILTER ist standardmäßig (mail={address}) und muss den Platzhalter {address} enthalten (die Adresse wird vor dem Einsetzen nach RFC 4515 escaped, sodass ein Local-Part, der * oder ( enthält, nicht zu Filtersyntax werden kann); LDAP_ATTRIBUTE ist standardmäßig userCertificate;binary. Ein abwesendes LDAP_BIND_DN bedeutet einen anonymen Bind; ein vorhandenes verlangt eine ldaps://-URL, denn ein einfacher Bind sendet das Passwort wörtlich, und die Abfrage wird abgelehnt, statt im Klartext ausgeführt zu werden (dieselbe Regel, die die LMTP- und SMTP-Clients auf AUTH anwenden).

Die LDAP-Unterstützung ist ein Compile-Zeit-Cargo-Feature. Auf einem Build ohne es wird ldap in SOURCES von pepsi-setup(1) abgelehnt, und die pepsi-keydisc@ldap-Instanz verweigert den Start.

85.2.1.1.10.1. Der Schalter je Absender: [stage-encrypt] DISCOVERY

Eine Stage, die den Schlüsselspeicher verbraucht, liest eine eigene Option, in ihrem [stage-<name>]-Abschnitt, sodass sie über die pepsi.settings-Schicht je Adresse überschrieben werden kann (pepsi-settings(1)):

DISCOVERY

(boolesch, optional) Ob ein Cache-Fehltreffer eine Netz-Abfrage auslösen darf. Standardwert YES. Mit NO werden die zwischengespeicherten Schlüssel weiterhin verwendet, aber ein Fehltreffer geht direkt auf den Kein-Schlüssel-Pfad der Stage, statt die Nachricht zu parken — es gäbe nichts, worauf zu warten wäre.

Wichtig

Was die Überschreibung je Adresse tatsächlich bedeutet. Die Einstellungsschicht löst eine ausgehende Nachricht über ihren Umschlagabsender auf, sodass eine Überschreibung von DISCOVERY für eine Adresse bedeutet: „die Mail dieses Benutzers löst nie eine Abfrage aus“ — nicht „schlage diesen Korrespondenten nie nach“. Die Unterdrückung auf der Empfängerseite ist ALLOW_DOMAINS/DENY_DOMAINS des Operators oben; es gibt bewusst keine Empfänger-Sperrliste je Adresse, die eine eigene Spalte und eine zweite Liste bräuchte, um mit dieser konsistent zu bleiben.

DISCOVERY wird von pepsi-stage-encrypt(1) und pepsi-stage-decrypt(1) aus dem effektiven Abschnitt jener Stage gelesen, sodass eine pepsi.settings-Überschreibung greift. Ihre übrigen Optionen sind unter pepsi-stage-encrypt-Optionen und pepsi-stage-decrypt-Optionen dokumentiert.

85.2.1.1.11. Der Abschnitt [pepsi-keys]

Das Spiegelbild des Abschnitts oben: wie andere Leute die Schlüssel unserer Benutzer finden. Gelesen von pepsi-keys(1) und von pepsi-stage-vks-confirm(1). Der ganze Abschnitt ist optional, und eine Konfiguration, die ihn weglässt, veröffentlicht nichts bei irgendeinem Keyserver.

Die Web-Key-Directory-Veröffentlichung braucht überhaupt keine Optionen. Sie folgt dem published-Flag jeder Identität (standardmäßig an, mit pepsi-keys identity unpublish gelöscht) und wird von pepsi-httpd(1) von unserer eigenen Domain bedient, sodass sie bei der nächsten Anfrage wirksam wird und durch Löschen des Flags rückgängig gemacht wird. Was dieser Abschnitt konfiguriert, ist der andere Kanal, der sich ganz anders verhält: Ein Keyserver nimmt einen Schlüssel dauerhaft an — ihm kann später gesagt werden, dass der Schlüssel widerrufen ist, nie, ihn zu vergessen.

VKS_PUBLISH

(boolesch, optional) Ob eine von Hand erzeugte oder importierte Identität (pepsi-keys identity generate/import, generate der Web-Konsole oder der API, der E-Mail-Befehl generate) mit angefordertem Keyserver-Upload beginnt (crypto_identity.vks_wanted). Standardwert NO.

Jede Identität hält fest, ob ihr Upload angefordert wurde, und die Wiederholungsaufgabe (pepsi-keys identity publish --retry) lädt genau die veröffentlichten, aktiven OpenPGP-Identitäten hoch, bei denen vks_wanted gesetzt ist, und wiederholt es, bis sie verifiziert sind. Sie wird von dieser Option nicht beschränkt. Zwei Folgen:

• automatisch erzeugte Schlüssel ([stage-encrypt] ENABLE_PEP) und aus der eigenen Mail eines Benutzers registrierte MUA-Schlüssel werden nie ungefragt hochgeladen, gleich was hier steht – Autocrypt und der eigene WKD der Installation sind der Weg, auf dem sie gefunden werden;

• die ausdrückliche Upload-Anforderung eines Benutzers (pepsi-keys identity publish <ID> --vks, Upload to the key server in der Web-Konsole, PATCH /api/v1/identities/{id} mit vks_wanted oder der E-Mail-Befehl publish) wird befolgt, gleich was hier steht.

„Nicht hochgeladen“ ist daher ein festgehaltener Zustand und kein Fehlen, und pepsi-keys identity show gibt ihn aus. Ein Hochladen lässt sich nicht zurücknehmen, weshalb der Standardwert für von Hand erzeugte Schlüssel eine Entscheidung des Operators bleibt.

VKS_SERVER

(Zeichenkette, optional) Der Keyserver, zu dem Uploads gehen; nur https://, und eine Klartext-URL wird abgelehnt statt herabgestuft. Standardwert ist der erste [pepsi-keydiscovery] VKS_SERVERS-Eintrag, sodass eine Installation, die bereits einen Keyserver zum Lesen gewählt hat, ihn nicht zweimal benennt.

Ein Server, keine Liste: Denselben Schlüssel bei mehreren zu veröffentlichen vervielfacht eine unumkehrbare Handlung, und jeder einzelne muss dann mit Widerrufen aktuell gehalten werden.

Sein Host ist außerdem der Standard-VKS_HOST von pepsi-stage-vks-confirm(1) — der eine Host, von dem jene Stage eine Verifikationsmail annimmt und zu dem sie einem Link folgt.

VKS_MAX_ATTEMPTS

(ganzzahlig, optional) Wie viele Versuche eine Identität bekommt, bevor pepsi-keys identity publish --retry sie in Ruhe lässt. Standardwert 5. Der Datensatz behält seinen letzten Fehler, sodass eine aufgegebene Identität sagt, warum.

VKS_RETRY_INTERVAL

(Dauer, optional) Mindestabstand zwischen Versuchen für eine Identität. Standardwert 6 h. Kalendereinheiten werden abgelehnt: 6 h parst, 1 d nicht.

VKS_BATCH

(ganzzahlig, optional) An wie vielen Identitäten ein --retry-Lauf arbeitet, sodass ein erster Lauf über eine große Installation nicht ein einziger enormer Ausbruch bei einem Dritten ist. Standardwert 50.

85.2.1.1.12. Der Abschnitt [pepsi-ingress]

Globale Optionen, die die Nachrichtenannahme regeln, von pepsi-ingress(1) gelesen.

HOSTNAME

(Zeichenkette, erforderlich) Hostname, der in der SMTP-Begrüßung und der EHLO-Antwort angekündigt wird, z. B. mail.example.org.

ACCEPTED_DOMAINS

(Zeichenkette, erforderlich) Durch Leerraum oder Komma getrennte Liste von Domains, für die Mail angenommen wird. Empfänger in jeder anderen Domain werden als Relaying mit einer 550-Antwort abgelehnt. Der Abgleich ist unabhängig von der Groß-/Kleinschreibung. Mindestens eine Domain muss angegeben werden.

USERNAME_MAP

(Pfad, optional) Datei, die jede SASL-Authentifizierungs-ID auf die E-Mail-Adressen abbildet, die sie als Umschlagabsender und From:-Identität verwenden darf (RFC 6409 §6/§8.1). Jede nicht leere Zeile, die kein Kommentar ist, lautet username: addr… — ein # beginnt einen Kommentar, der Schlüssel ist der SASL-Benutzername, und der Wert ist die durch Leerraum/Komma getrennte Liste erlaubter Adressen (die leer sein darf). Ein mit Adressen aufgeführter Benutzername darf genau diese (die erste konkrete ist die kanonische Identität, die für die Sender:-Korrektur verwendet wird); eine Adresse darf ein *-Wildcard wie *@example.org sein (jede Adresse bei der Domain) oder ein bloßes * (jede Adresse). Einem ohne Adressen aufgeführten Benutzernamen wird jede Adresse verweigert (sein AUTH wird abgelehnt, obwohl die Zugangsdaten gültig sind); ein nicht aufgeführter Benutzername fällt auf den Standardwert username@HOSTNAME zurück. Die Datei wird neu gelesen, wann immer ihre Änderungszeit sich ändert (bei jeder Authentifizierung geprüft); eine fehlende/nicht lesbare Datei wird als leer behandelt. Wenn nicht gesetzt, wird jeder authentifizierte Benutzer auf seinen Standardwert username@HOSTNAME abgebildet. Siehe pepsi-ingress(1).

POSTMASTER

(Zeichenkette, optional) Routbare Adresse, in die das domainlose reservierte Postfach <Postmaster> umgeschrieben wird. RFC 5321 §4.5.1 verlangt, dass <Postmaster> (ohne Domain) unabhängig von ACCEPTED_DOMAINS angenommen wird; bei Annahme schreibt Pepsi es in diese Adresse um, sodass die normale Pipeline (Aliase, lokale Zustellung, Relay) es routen kann. Wenn nicht gesetzt, wird es in postmaster@HOSTNAME umgeschrieben — fügen Sie einen Alias für diese Adresse in einer ALIASES-Map von pepsi-stage-aliases hinzu, um Postmaster-Mail an eine echte Person zuzustellen, oder setzen Sie POSTMASTER direkt auf diese Person. Siehe pepsi-ingress(1).

MAX_MESSAGE_SIZE

(Zahl, optional) Maximal akzeptierte Nachrichtentext-Größe in Bytes — die Größe der DATA-Nutzlast. Der Wert wird über die ESMTP-SIZE-Erweiterung angekündigt; Nachrichten, die ihn überschreiten, werden mit 552 abgelehnt. Standardwert ist 26214400 (25 MiB).

MAX_CONNECTIONS

(Zahl, optional) Maximale Anzahl gleichzeitig über alle Listener bedienter SMTP-Verbindungen. Die effektive Zulassungsobergrenze ist die kleinere von diesem und MAX_OPEN_SOCKETS. Standardwert ist 1024.

DB_POOL_SIZE

(Zahl, optional) Maximale Anzahl von PostgreSQL-Verbindungen im Ingress-Datenbankpool. Ingress bedient viele SMTP-Sitzungen gleichzeitig, von denen jede kurz workqueue_add aufruft, sodass es anders als die Einzelverbindungs-Stage-Worker mehr als eine verwenden kann. Standardwert ist 1; erhöhen Sie es nur, wenn die eingehende Annahme an der einzelnen Verbindung einen Engpass hat, und halten Sie die Summe der Pools jeder Komponente unter dem max_connections von PostgreSQL.

MAX_OPEN_SOCKETS

(Zahl, optional) Harte Obergrenze gleichzeitig offener Client-Verbindungen, die vor Dateideskriptor-Erschöpfung schützt. Wenn nicht gesetzt, wird sie aus dem weichen RLIMIT_NOFILE des Prozesses minus RESERVED_SOCKETS abgeleitet. Wenn die Obergrenze erreicht ist und eine neue Verbindung eintrifft, schafft der Server Platz, indem er die am längsten untätige Verbindung im Quellbereich (einer IPv4-Adresse oder einem IPv6-/32) schließt, deren gesamte Leerlaufzeit am größten ist (ein 421, dann schließen).

RESERVED_SOCKETS

(Zahl, optional) Dateideskriptoren, die vom aus RLIMIT_NOFILE abgeleiteten Budget zurückgehalten werden (für den Datenbankpool, Listener, stdio und DNS-Sockets). Standardwert ist 64. Wird ignoriert, wenn MAX_OPEN_SOCKETS gesetzt ist.

CONN_RATE_PER_SECOND

(Zahl, optional) Token-Bucket-Nachfüllrate, die akzeptierte neue Verbindungen pro Quellbereich begrenzt, in Verbindungen pro Sekunde. Eine Verbindung über der Rate wird mit 421 abgelehnt und geschlossen, ohne einen Slot zu belegen. Standardwert ist 1. Ein gebrochener Wert wird angenommen (0.2 ist eine Verbindung alle fünf Sekunden). Lokale (UNIX-Socket-)Verbindungen werden nie ratenbegrenzt.

CONN_RATE_BURST

(Zahl, optional) Token-Bucket-Burst-Zugeständnis pro Quellbereich, ebenfalls gebrochen. Standardwert ist 1.

MAX_CONNECTIONS_PER_IP

(Zahl, optional) Gleichzeitige Verbindungen, die ein Quellbereich (eine IPv4-Adresse oder ein IPv6-/32) halten darf. Eine Verbindung darüber hinaus wird wie eine ratenbegrenzte abgelehnt. Standardwert 16; 0 schaltet die Obergrenze ab.

MAX_LOCAL_CONNECTIONS

(Zahl, optional) Gleichzeitige Verbindungen, die alle UNIX-Socket-Peers zusammen halten dürfen. Lokale Verbindungen sind von der Ratenbegrenzung ausgenommen und werden nie verdrängt; dies ist also das, was lokale Einlieferer davon abhält, jeden Platz zu belegen. Standardwert 32; 0 begrenzt sie nur durch MAX_CONNECTIONS.

MAX_MESSAGES_PER_SESSION

(Zahl, optional) Mail-Transaktionen, die eine Sitzung beginnen darf; das nächste MAIL wird mit 421 beantwortet und die Sitzung geschlossen. Standardwert 100; 0 ist unbegrenzt.

VERIFY_RECIPIENTS

(``auto`` oder ``off``, optional) Ob eine Adresse an einer bedienten Domain, die nichts auf diesem Host annehmen würde, zum RCPT-Zeitpunkt mit 550 5.1.1 abgelehnt wird. Standardwert auto. Der sendende MTA benachrichtigt dann sofort seinen eigenen Benutzer. Angenommen würde die Nachricht später an ihren Umschlagabsender gebounct — den Spam fälscht, sodass der Bounce einen unbeteiligten Dritten trifft (Backscatter) und diesen Host auf Blocklisten bringt.

Nichts muss von Hand aufgeführt werden. Für jede bediente Domain werden die Quellen, die für eine Adresse bürgen können, aus den [stage-*]-Abschnitten abgeleitet:

• die lokalen Konten, die eine pepsi-stage-relay-to-maildir(1) oder pepsi-stage-dot-forward(1) für ihre LOCAL_DOMAINS auflöst, TARGETS und RECIPIENT_DELIMITER eingeschlossen;

• der MDA hinter einer pepsi-stage-relay-to-lmtp(1), für deren LOCAL_DOMAINS mit RCPT TO und ohne Nachricht gefragt;

• das Backend hinter einer pepsi-stage-route(1), wie deren RECIPIENT_CHECK es vorgibt;

• jede Map einer pepsi-stage-aliases(1), mit dem eigenen Abgleich der Stage;

• die Mailinglisten, wenn ein pepsi-stage-list(1)-Router konfiguriert ist;

• postmaster@ und abuse@ sowie die Steueradressen der Stages, die eine beantworten (pepsi@, pepsi-keys@, pepsi-wallet@, secretary@).

Eine Adresse, für die irgendeine davon bürgt, wird angenommen. Ebenso jede Adresse an einer Domain, die sich nicht prüfen lässt:

• ein Alias-Catch-All deckt die Domain ab;

• eine Stage führt ein Programm aus, das Pepsi nicht kennt;

• die Domain wird an ein Backend mit RECIPIENT_CHECK = none geroutet;

• die Domain wird von einer Smarthost-Stage weitergeleitet, ohne dass hier etwas ihre Postfächer hält.

Auch jede Unsicherheit nimmt an: eine unlesbare Datei, ein Datenbankfehler, eine Probe, die fehlschlägt oder in ein Timeout läuft. pepsi-setup run gibt das Ergebnis für jede Domain aus. off nimmt wie bisher jede Adresse an einer bedienten Domain an. Beim Start gelesen: Ein geänderter Stage-Graph braucht einen Neustart des Ingress, während Änderungen an einer Alias-Map, einer Empfängerliste oder den Mailinglisten sofort gelten.

MAX_INVALID_RECIPIENTS

(Zahl, optional) Unbekannte Empfänger, die eine Sitzung nennen darf. Beim Erreichen des Limits wird die Sitzung mit 421 geschlossen, was einen Wörterbuchangriff (das Einsammeln gültiger Adressen oder das Bringen des MDA dazu, Rateversuch um Rateversuch zu beantworten) in einen Strom von Verbindungen verwandelt, den die Verbindungslimits bemessen. Standardwert 10; 0 ist unbegrenzt.

MAX_SELF_HOPS

(Zahl, optional) Wie oft eine Nachricht den Ingress dieses Hosts bereits durchlaufen haben darf, bevor sie als Routing-Schleife mit 554 5.4.6 abgelehnt wird. Gezählt aus den Received:-Feldern, die der Ingress selbst schreibt (by HOSTNAME (pepsi-ingress)). Legitime Mail tritt höchstens ein paar Mal erneut ein: Ein Alias auf eine andere bediente Domain, eine ~/.forward oder ein Bericht an einen unserer eigenen Benutzer verlassen jeweils den Host über SMTP und kommen wieder herein. Eine Schleife dagegen liefe sonst bis zum allgemeinen Hop-Limit der Relay-Stages, Dutzende Durchläufe. Standardwert 5; 0 schaltet die Prüfung ab.

AUTH_FAILURES_PER_HOUR

(Zahl, optional) Fehlgeschlagene AUTH-Versuche, die ein Quellbereich pro Stunde über alle seine Sitzungen hinweg machen darf (ein Token-Bucket). Ist er aufgebraucht, wird AUTH aus dem Bereich mit 421 abgelehnt, ohne das SASL-Backend zu befragen, bis sich der Bucket wieder füllt. Standardwert 20; 0 ist unbegrenzt.

LOCAL_MESSAGES_PER_MINUTE

(Zahl, optional) Nachrichten, die eine lokale UID, erkannt über SO_PEERCRED in einer UNIX-Socket-Sitzung, pro Minute über ihre Sitzungen hinweg einliefern darf; ein MAIL über der Rate erhält 451 4.7.1. Standardwert 60; 0 ist unbegrenzt.

LOCAL_MESSAGE_BURST

(Zahl, optional) Der zusätzlich zu LOCAL_MESSAGES_PER_MINUTE erlaubte Burst. Standardwert 120.

COMMAND_TIMEOUT

(Dauer, optional) Längste Zeit, die eine Sitzung auf den nächsten Befehl (oder eine AUTH-Fortsetzung, den Beginn eines DATA/BDAT-Nachrichtentexts oder den Abschluss eines STARTTLS/Implicit-TLS-Handshakes) wartet, bevor die Verbindung mit 421 geschlossen wird (RFC 5321 §4.5.3.2). Standardwert ist 300 s.

DATA_TIMEOUT

(Dauer, optional) Längste Zeit, die eine Sitzung beim Empfangen eines DATA/BDAT-Nachrichtentexts auf den nächsten Block von Nutzlast-Oktetten wartet, bevor sie mit 421 schließt. Standardwert ist 180 s.

DMARC_ENFORCE

(boolesch, optional) Bei YES wird eine Nachricht, deren DMARC-Auswertung fehlschlägt und deren veröffentlichte Richtlinie quarantine oder reject ist, zur SMTP-Zeit (550) abgelehnt. Standardwert ist NO: pepsi-ingress(1) nimmt solche Mail normalerweise an (und pepsi-stage-arc(1) versiegelt das fehlschlagende Ergebnis), damit der nachgelagerte Empfänger entscheiden kann. Andere Authentifizierungsfehler lehnen eine Nachricht nie ab.

DNS_SERVERS

(Zeichenkette, optional) Durch Leerraum oder Komma getrennte Liste von Resolver-IP-Adressen (IPv4 und/oder IPv6), die für die SPF/DKIM/DMARC-Abfragen verwendet werden, auf Port 53 abgefragt. Wenn nicht gesetzt, wird die System-Resolver-Konfiguration (/etc/resolv.conf) verwendet.

DNS_TIMEOUT

(Dauer, optional) Timeout je Einzelabfrage für diese Abfragen. Standardwert ist 5 s. Weil die Verifikation synchron beim Empfang von DATA läuft, verzögert ein langsamer Resolver die 250-Annahme.

Sie gilt nur, wenn DNS_SERVERS die Resolver benennt. Ist DNS_SERVERS nicht gesetzt, wird die Resolver-Konfiguration des Systems als Ganzes verwendet, Zeitüberschreitung eingeschlossen, sodass diese Option keine Wirkung hat und die Zeilen options timeout:/attempts: in /etc/resolv.conf eine Abfrage begrenzen.

MAX_DKIM_SIGNATURES

(Zahl, optional) Wie viele DKIM-Signature-Felder einer eingehenden Nachricht verifiziert werden; diejenigen, deren d= die From:-Domain oder eine Eltern- oder Kind-Domain davon ist, kommen zuerst an die Reihe. Standardwert 10.

VERIFY_TIMEOUT

(Dauer, optional) Frist für die eingehende Verifizierung: SPF und die ausgewählten DKIM-Signaturen werden darunter gleichzeitig geprüft, danach DMARC unter einer zweiten. Eine Prüfung, die sie verpasst, wird nur für diese Prüfung als temperror festgehalten. Standardwert 20 s.

DISPATCH_WAKE_INTERVAL

(Dauer, optional) Mindestabstand zwischen zwei NOTIFYs, die pepsi-dispatch(1) mitteilen, dass neue Mail eingetroffen ist. Standardwert ist 5 ms; 0 schaltet das Zusammenfassen ab und benachrichtigt einmal je angenommener Nachricht.

Ingress benachrichtigt nicht aus der Transaktion heraus, die die Nachricht speichert. PostgreSQL hält von dem Moment an, in dem eine Transaktion eine Benachrichtigung einreiht, bis sie committet, eine datenbankweite Sperre, sodass benachrichtigende Transaktionen nicht gruppiert committen können — unter nebenläufiger Last serialisieren sie sich, und jede bezahlt ihr eigenes Platten-Flush. Zulassungen werden daher außerhalb des Bandes benachrichtigt, einmal je Intervall, nachdem die Datensätze committet sind; weil der Dispatcher jedes Aufwecken mit einem vollständigen Durchsuchen der Warteschlange beantwortet, bedient eine Benachrichtigung beliebig viele neu angenommene Nachrichten.

Die Begrenzung ist nachlaufend: Das erste Aufwecken nach einer Ruhephase wird sofort gesendet, sodass eine einzelne Nachricht überhaupt nicht verzögert wird, und nur Benachrichtigungen dahinter werden zusammengefasst. Dies anzuheben tauscht ein wenig Warteschlangenlatenz im schlechtesten Fall gegen weniger Benachrichtigungen unter anhaltender Last; es gibt selten einen Grund dazu.

Die ARC-Versiegelungsidentität und der -Algorithmus werden im gemeinsamen [pepsi]-Abschnitt (ARC_DOMAIN und ARC_ALGORITHM) oben konfiguriert und von pepsi-stage-arc(1) verwendet, nicht von Ingress.

85.2.1.1.13. Die Abschnitte [pepsi-ingress-listener-*]

Jeder Abschnitt, dessen Name mit pepsi-ingress-listener- beginnt, definiert einen Lausch-Socket. Das Suffix ist ein frei gewählter Name, der in Log-Meldungen verwendet wird, z. B. [pepsi-ingress-listener-mx]. Deklarieren Sie so viele Listener wie nötig.

SERVE

(erforderlich) Die Art des zu bindenden Sockets. Eines von:

tcp

Bindet einen TCP-Socket. Erfordert BIND_TO und PORT.

unix

Bindet einen UNIX-Domain-Socket. Erfordert UNIXPATH; beachtet UNIXPATH_MODE und UNIXPATH_GROUP.

systemd

Übernimmt einen von einem systemd-Elternprozess über Socket-Aktivierung übergebenen Socket; siehe FD_INDEX.

BIND_TO

(Zeichenkette) IP-Adresse, auf der bei SERVE = tcp gelauscht wird, z. B. 0.0.0.0 oder ::. Erforderlich für tcp.

PORT

(Zahl) TCP-Port, auf dem bei SERVE = tcp gelauscht wird. Erforderlich für tcp.

UNIXPATH

(Pfad) Dateisystempfad des Sockets bei SERVE = unix. Erforderlich für unix.

UNIXPATH_MODE

(Unix-Modus, optional) Rechtebits des UNIX-Domain-Sockets, in Oktal. Standardwert ist 660.

UNIXPATH_GROUP

(Zeichenkette, optional) Gruppenname, auf den der UNIX-Domain-Socket nach dem Binden chgrpt wird (der Eigentümer bleibt unverändert). Kombiniert mit dem Standardmodus 0660 lässt dies einen bestimmten Peer den Socket erreichen, während er nicht für alle zugänglich bleibt — verwendet, wenn pepsi-httpd hinter einem Front-Webserver (z. B. www-data) läuft, der per Reverse-Proxy zu ihm weiterleitet. Die Gruppe muss existieren; eine unbekannte Gruppe ist ein Startfehler.

FD_INDEX

(Zahl, optional) Nullbasierter Index des von systemd übergebenen Dateideskriptors, der bei SERVE = systemd übernommen wird. Index 0 ist der erste Deskriptor (SD_LISTEN_FDS_START). Standardwert ist 0.

Es ist eine Position, kein Name: Es zählt ListenStream=-Einträge in der besitzenden .socket-Unit, sodass das Einfügen eines Eintrags jeden Listener danach umnummeriert, während das Anhängen eines nichts umnummeriert. Die Unit und diese Abschnitte sind zwei Hälften einer Aussage, und nichts prüft zur Konfigurationszeit, dass sie übereinstimmen, sodass eine Abweichung dort gemeldet wird, wo die Deskriptoren tatsächlich sind: Der Server protokolliert beim Start eine Warnung, die jeden Index benennt, den kein Listener beansprucht hat. Nehmen Sie sie ernst — ein Socket, auf dem der Server nie annimmt, ist schlimmer als ein fehlender, denn systemd reiht die Verbindung dennoch ein, und der Client blockiert bis zum Ablauf seines eigenen Lese-Timeouts, statt sofort abgewiesen zu werden.

Ein Deskriptor kann ebenso gut ein UNIX-Domain-Socket wie ein TCP-Socket sein; welches von beidem, steht in der Unit, nicht hier. Optionen, die von der Familie des Sockets abhängen, werden daher aufgelöst, sobald der Deskriptor vorliegt, statt beim Parsen: AUTH_PEERCRED muss ausdrücklich angegeben werden (es kann nicht wie bei SERVE = unix erschlossen werden), und ein Klartext-SUBMISSION-Listener, der sich als Erbe eines Netzwerk-Sockets erweist, lässt pepsi-ingress(1) den Start verweigern, statt Zugangsdaten im Klartext zu tragen.

MODE

(optional) Transportsicherheit des Listeners. Eines von:

plain

Nur Klartext; STARTTLS wird nicht angeboten. Dies ist der Standardwert.

tls

Implizites TLS: Die Verbindung wird ab dem ersten Byte in TLS eingehüllt (z. B. der submissions-Port 465). Erfordert TLS_CERT und TLS_KEY.

starttls

Klartext, der mit dem STARTTLS-Befehl aufgewertet werden kann. Erfordert TLS_CERT und TLS_KEY.

TLS_CERT

(Pfad) PEM-Datei, die die Server-Zertifikatskette enthält. Erforderlich, wenn MODE tls oder starttls ist — kann aber weggelassen werden, in welchem Fall pepsi-setup(1) den certbot-Pfad /etc/letsencrypt/live/<HOSTNAME>/fullchain.pem automatisch ausfüllt und das Zertifikat beziehen kann (siehe pepsi-setup(1) und seine –no-certbot-Option).

TLS_KEY

(Pfad) PEM-Datei, die den privaten Schlüssel für TLS_CERT enthält. Erforderlich, wenn MODE tls oder starttls ist; wie TLS_CERT kann sie weggelassen werden, damit pepsi-setup(1) sie automatisch ausfüllt (…/privkey.pem).

MYNETWORKS

(optional) Durch Leerraum/Komma getrennte Liste vertrauenswürdiger IPv4/IPv6-CIDR-Netze (eine bloße Adresse ist ein /32- oder /128-Host). Eine Verbindung von einem dieser Netze wird ohne weiteren Nachweis authentifiziert. Standardmäßig leer.

AUTH_PEERCRED

(optional, Standardwert ``yes`` bei einem ``SERVE = unix``-Listener, sonst ``no``) Authentifiziert den Client anhand der vom Kernel gemeldeten Peer-Zugangsdaten des UNIX-Sockets (SO_PEERCRED): Die Benutzer-ID des verbindenden Prozesses wird über die passwd-Datenbank zu einem Login aufgelöst, und dieses Login wird in USERNAME_MAP genau so nachgeschlagen wie ein SASL-Benutzername. Die Sitzung ist damit authentifiziert und trägt eine Submission-Identität, sodass die Regeln aus RFC 6409 §6/§8.1 gelten — ein lokales Programm kann nur einen Umschlagabsender und ein From: verwenden, auf die sein eigenes Konto abgebildet ist, und ein Konto, das auf keine Adresse abgebildet ist, wird abgelehnt.

Dies ist der Mechanismus hinter pepsi-sendmail(1) und der Grund, warum der Socket gefahrlos für alle beschreibbar sein darf: Ihn öffnen zu können entscheidet nichts darüber, als wer Sie senden dürfen. Anders als MYNETWORKS, das einer Netzwerk-Position vertraut und daher jedem lokalen Prozess erlaubt, als beliebiger Absender zu senden, wird die Identität hier vom Kernel geliefert und kann vom Client nicht gefälscht werden.

Auf einem SERVE = tcp-Listener wird die Option abgelehnt, da es dort keine Peer-Zugangsdaten zu lesen gibt. Setzen Sie sie auf no für einen nicht authentifizierten lokalen Socket (etwa hinter einem Proxy) — ein solcher Listener kann dann aber nicht zugleich ein SUBMISSION-Listener sein, da nichts authentifizieren würde.

Mit SERVE = systemd wird sie angenommen, aber nicht erschlossen und muss daher ausgeschrieben werden: ob der geerbte Deskriptor ein UNIX-Socket oder ein TCP-Socket ist, ist eine Eigenschaft der .socket-Unit und nicht dieser Datei, und die ausgelieferte pepsi-ingress.socket reicht beide Arten durch. Erweist sich der Deskriptor als TCP-Socket, authentifiziert die Option niemanden — SO_PEERCRED hat dort keine Bedeutung, sodass jede Sitzung anonym bleibt —, was die sichere Richtung ist, aber eine stille, sodass pepsi-ingress(1) beim Start warnt und den Listener benennt.

SASL_TYPE

(optional) SASL-Backend für den AUTH-Befehl: none (Standardwert) oder dovecot. AUTH (Mechanismen PLAIN und LOGIN) wird nur auf einer TLS-geschützten Sitzung angeboten und akzeptiert; ein Klartext-AUTH wird mit 504 5.5.4 abgelehnt (RFC 4954 §4 — das 538 von RFC 2554 ist veraltet) und ein AUTH auf einem Listener ohne Backend mit 503 5.5.1. Jeder Wert außer none erfordert MODE tls oder starttls.

SASL_PATH

(Pfad) Pfad des Dovecot-Auth-Client-Sockets. Erforderlich, wenn SASL_TYPE dovecot ist — es gibt keinen Standardwert, und ein Listener, der dovecot verlangt, ohne ihn zu setzen, lässt sich nicht parsen. Der Pfad, den pepsi-setup vorschlägt, /run/dovecot/auth-client-pepsi, ist ein Pepsi-privater Listener statt des geteilten auth-client-Sockets von Dovecot: Letzterer ist 0600 dovecot und für den unprivilegierten pepsi-ingress-Benutzer nicht erreichbar, sodass ein darauf zeigender Submission-Listener ein AUTH bekommt, das immer mit einem Rechtefehler fehlschlägt. pepsi-setup run prüft diesen Socket als Dienstbenutzer und bietet, falls er fehlt oder nicht lesbar ist, an, eine /etc/dovecot/conf.d/10-pepsi.conf zu installieren, die einen dedizierten, pepsi-ingress gehörenden Listener hinzufügt (oder gibt sie aus, damit Sie sie ausrollen).

TLS_AUTH_CLIENT

(optional) Durch Leerraum/Komma getrennte Liste von SHA-256-Hashes (64 Hex-Zeichen) der DER-SubjectPublicKeyInfo autorisierter Client- oder CA-Öffentlicher-Schlüssel. Wenn gesetzt, fordert der Listener ein Client-Zertifikat an: Eine Sitzung ist authentifiziert, wenn der Schlüssel-Hash des vorgelegten Blatts aufgeführt ist oder wenn seine Kette per Signatur bis zu einem gelisteten CA-Schlüssel validiert. Ein nicht erkanntes Zertifikat bricht den Handshake nicht ab. Erfordert MODE tls oder starttls. Berechnen Sie einen Hash mit openssl x509 -in cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256.

SUBMISSION

(optional, Standardwert ``no``) Bei yes ist der Listener ein RFC-6409-Message-Submission-Agent: Die Authentifizierung wird verpflichtend (ein nicht authentifiziertes MAIL FROM wird mit 530 5.7.0 abgelehnt), und jede angenommene Nachricht erhält die Submission-Korrekturen — ein fehlendes Date: und Message-ID: werden ergänzt. Erfordert mindestens einen Authentifizierungsmechanismus (SASL_TYPE, TLS_AUTH_CLIENT, MYNETWORKS oder AUTH_PEERCRED); ein Submission-Listener ohne einen wird abgelehnt. Lassen Sie es für einen MX-Listener (Port 25) aus.

Ein TLS-MODE ist ebenfalls erforderlich, außer auf einem SERVE = unix-Listener: Ein Dateisystem-Socket hat keinen Transportweg, den ein Angreifer beobachten oder in den er sich einklinken könnte, und seine Authentifizierung stammt vom Kernel statt von der Leitung, sodass ein dort verlangtes Zertifikat nichts schützen würde.

Eine durch eines von MYNETWORKS, AUTH_PEERCRED, SASL AUTH oder TLS_AUTH_CLIENT akzeptierte Sitzung wird mit state.local_origin = true festgehalten (sonst false) und darf an jede Domain weiterleiten, nicht nur an die bedienten Domains.

85.2.1.1.14. Die Stage-Pipeline und die Abschnitte [stage-*]

Nach dem Ingress wird eine Nachricht durch eine Kette von Stage-Programmen weitergeschaltet. pepsi-dispatch(1) beansprucht einen pending-Datensatz, setzt ihn auf running und übergibt die Nachrichten-ID einem dauerhaften Worker-Prozess jener Stage — gestartet als PROGRAM [-c FILE] worker und über seine Standardeingabe mit IDs gefüttert, eine je Zeile, die er mit je einer Statuszeile beantwortet —, und das Programm erledigt seine Arbeit und schaltet den Datensatz weiter (oder schließt ihn ab). Es gibt keinen Aufruf mit positionaler ID: Ein PROGRAM, das ein Wrapper-Skript ist, muss daher seine Argumente und seine Standardeingabe weiterreichen. Neue Nachrichten treten bei der Anfangs-Stage [stage-init] ein, die existieren muss.

Jeder Abschnitt, dessen Name mit stage- beginnt, beschreibt eine Stage. Das Suffix ist der Stage-Name, z. B. [stage-init]. Der Stage-Name ist ein vom Operator gewähltes Etikett, unabhängig vom Binärprogramm, das er ausführt.

PROGRAM

(Zeichenkette, erforderlich) Das auszuführende Stage-Binärprogramm, z. B. pepsi-stage-relay-to-smarthost. Es wird auf dem PATH gefunden, sofern nicht als absoluter Pfad angegeben. Dasselbe Binärprogramm kann mehrere Stages bedienen (es liest seine Optionen aus dem Abschnitt, an dem sich die Nachricht gerade befindet).

NEXT_STAGE

(Zeichenkette, optional) Die Stage, zu der eine Nachricht bei Erfolg weiterschaltet. Ohne eine entfernt eine erfolgreiche terminale Stage die Nachricht.

BOUNCE_STAGE

(Zeichenkette, optional) Die Stage, zu der eine Nachricht geroutet wird, damit eine Zustellungsstatusbenachrichtigung erzeugt wird. Für Zustell-Stages (pepsi-stage-relay-to-smarthost(1), pepsi-stage-relay-to-internet(1)) und pepsi-stage-discard(1) erhält sie eine dauerhaft fehlgeschlagene (Nicht-Bounce-)Nachricht für einen Bounce und — wenn [pepsi] ORIGINATE_SUCCESS_DSN aktiviert ist — eine erfolgreich zugestellte Nachricht für einen positiven Bericht. Ohne eine wird eine dauerhaft fehlgeschlagene Nachricht als failed markiert (Zustell-Stages) oder einfach verworfen (pepsi-stage-discard(1)).

PARALLELISM

(Zahl, optional) Obere Schranke für die Anzahl gleichzeitiger Worker-Prozesse, die pepsi-dispatch(1) für diese Stage betreibt. Worker werden bei Bedarf gestartet und im Leerlauf gestoppt, sodass dies eine Obergrenze ist, keine feste Pool-Größe. Jeder Worker hält eine Datenbankverbindung, sodass dies auch den Anteil der Stage am Verbindungsbudget begrenzt (siehe den [pepsi-postgres]-Hinweis oben). Standardwert 4. Der Dispatcher senkt eine Stage vorübergehend unter diesen Wert, wenn die Datenbank meldet, dass ihr Verbindungslimit erschöpft ist (siehe pepsi-dispatch(1)).

MAX_MESSAGES

(Zahl, optional) Anzahl der Nachrichten, die ein Worker dieser Stage verarbeitet, bevor der Dispatcher ihn ausmustert und einen frischen Prozess startet (begrenzt das Speicherwachstum). Standardwert 1000.

QUEUE_LIMIT

(Zahl, optional) Obere Schranke für die Anzahl der Nachrichten, die pepsi-dispatch(1) gleichzeitig an einen einzelnen Worker-Prozess dieser Stage pipelinet. Der Worker verarbeitet sie weiterhin streng einzeln, aber die bereits auf seiner Standardeingabe eingereihten nächsten IDs entfernen einen Koordinator-Round-Trip pro Nachricht, sodass die gesamte in Bearbeitung befindliche Kapazität der Stage QUEUE_LIMIT × PARALLELISM beträgt. Weil die Worker-Anzahl (und damit das Verbindungsbudget) unverändert ist, tauscht eine Erhöhung ein wenig Head-of-Line-Latenz (eine Nachricht kann hinter einem langsameren pipelinten Geschwister auf demselben Worker warten) gegen Durchsatz, ohne mehr Datenbankverbindungen zu verbrauchen; senken Sie es (z. B. auf 1) für eine Stage, deren Arbeit pro Nachricht lang und ungleichmäßig ist, etwa ein Netzwerk-Relay. Standardwert 4.

MAX_LIFETIME

(Dauer, optional) Wie lange eine Nachricht an dieser Stage immer wieder fehlschlagen darf — mit jedem Fehler, den die Stage nicht als permanent markiert, also einem Fehler, an dem der Host schuld ist und nicht die Nachricht, etwa eine unlesbare Resolver-Konfiguration, ein Helper, der sich nicht starten lässt, oder eine Vorlage, die sich nicht lesen lässt —, bevor der Worker aufgibt, gezählt ab dem Zeitpunkt, zu dem die Nachricht eingereiht wurde (bei einer DSN ab dem Zeitpunkt, zu dem pepsi-stage-bounce(1) sie gebaut hat). Bis dahin wird die Nachricht pausiert und erneut versucht, nach einer Minute und dann jedes Mal doppelt so lange, bis zu einer Stunde, mit dem Fehler in state.last_error. Danach wird sie zur BOUNCE_STAGE dieser Stage umgeleitet oder schlägt fehl, wenn es keine gibt (siehe pepsi-dispatch(1)). Die Zustell-Stages und pepsi-stage-milter(1) lesen dieselbe Option für ihre eigenen Wiederholungen. Standardwert 120 h.

FUSION = yes | no

(optional) Ob eine Vorgänger-Stage diese Stage in ihrem eigenen Worker-Prozess ausführen darf, statt den Datensatz pending zu schreiben und zu warten, bis der Dispatcher ihn beansprucht (Stage-Fusion; siehe [pepsi] ALLOW_FUSION oben und pepsi-dispatch(1)). Fusion geschieht nur, wenn sie auch global aktiviert ist, das PROGRAM dieser Stage in das vereinheitlichte pepsi-Binärprogramm eingefaltet ist und diese Stage keine Nachrichtenspalte benötigt, die der Vorgänger nicht bereits geladen hat — sie wird also verweigert (und das Weiterschalten fällt auf einen normalen, vom Dispatcher zugeteilten Hop zurück), wann immer eines davon nicht zutrifft, was stets sicher ist. Standardwert ist yes für die schnellen, nachrichtentextfreien Routing-/Klassifizierungs-Stages — pepsi-stage-if(1), pepsi-stage-discard(1), pepsi-stage-srs(1), pepsi-stage-check-whitelist(1), pepsi-stage-auto-whitelist(1), pepsi-stage-block-language(1), pepsi-stage-list(1) und pepsi-stage-edit-settings(1) (das für jede Nachricht nachrichtentextfrei ist, die keine Steuernachricht ist, also praktisch für alle) — und no für jedes andere Programm. Zwei davon brauchen den Header-Block statt nur des Umschlags — pepsi-stage-block-language(1), dessen ENFORCEMENT = soft-Pfad den Subject: umschreibt, und pepsi-stage-check-whitelist(1), das List-Id: liest —, sodass jede von beiden nur in einen Vorgänger fusioniert, der ihn bereits geladen hatte. Ein Programm hier aufzuführen setzt nur den Standardwert seiner FUSION-Option; ob ein bestimmtes Paar tatsächlich fusionieren darf, wird je Paar zur Laufzeit entschieden.

Die übrigen Optionen in einem [stage-<name>]-Abschnitt hängen von seinem PROGRAM ab. Die untenstehenden Unterabschnitte dokumentieren die Optionen, die jedes Stage-Programm aus seinem eigenen Abschnitt liest; ein Abschnitt liest nur die für sein PROGRAM aufgeführten Schlüssel plus die allgemeinen Schlüssel oben.

Einige Programme sind die Ausnahme und werden nur in ihren eigenen Handbuchseiten dokumentiert, weil ihre Optionsmengen groß sind und sich mit dem Zustellmechanismus ändern, den sie ansteuern: pepsi-stage-relay-to-maildir(1) (dessen SERVER_NAME erforderlich ist — die Stage verweigert ohne ihn den Start — plus HELPER, UNKNOWN_MAILBOX_STAGE, QUOTA_LIMIT_STAGE, die RETRY_*-Familie, MAX_LIFETIME und die Lokalitätsoptionen LOCAL_DOMAINS, TARGETS und RECIPIENT_DELIMITER), pepsi-stage-relay-to-lmtp(1) (SOCKET oder HOST/PORT, TLS, TLS_VERIFY, TLS_CA, TLS_CLIENT_CERT/TLS_CLIENT_KEY, AUTH, USERNAME, PASSWORD, SERVER_NAME, QUOTA_LIMIT_STAGE, SIEVE_REJECT_STAGE, NOTIFY_STAGE und die Timeouts), pepsi-stage-dot-forward(1) (HELPER, RESTART_STAGE, ALLOW_PIPE, ALLOW_FILE und die Lokalitätsoptionen) sowie die Mailinglisten-Stages pepsi-stage-list(1) (POST_STAGE, COMMAND_STAGE), pepsi-stage-list-post(1) (DELIVERY_STAGE, RESPONSE_STAGE, REMOVE_DKIM_HEADERS, SITE_HEADER_MATCH_CHAIN, SENDER_POSTS_PER_HOUR, MAX_HELD_MESSAGES), pepsi-stage-list-deliver(1), pepsi-stage-list-command(1) (RESPONSE_STAGE, MAX_COMMAND_LINES) und pepsi-stage-list-bounce(1) (RESPONSE_STAGE), deren standortweite Optionen weiter unten in [pepsi-list] stehen. Alles auf dieser Seite über [stage-<name>] im Allgemeinen gilt weiterhin für sie. Die gemeinsamen Abschnitte, aus denen diese Programme ebenfalls schöpfen, sind anderswo auf dieser Seite dokumentiert: [pepsi] (Signieridentität), [pepsi-srs] (die SRS-Engine), [pepsi-payments] (das Händler-Backend) und die Smarthost-Abschnitte [pepsi-stage-relay-to-smarthost-mta-*].

85.2.1.1.14.1. pepsi-stage-arc-Optionen

Eine Stage mit PROGRAM = pepsi-stage-arc liest neben einem erforderlichen NEXT_STAGE ihre DNS-Einstellungen und die Signaturparameter des ARC-Sets, das sie hinzufügt (diese gelten für die ARC-Message-Signature; die ARC-Seal wird stets relaxed-kanonisiert über eine feste Header-Menge, gemäß RFC 8617):

DNS_SERVERS

(Zeichenkette, optional) Durch Leerraum/Komma getrennte explizite Resolver (Port 53) für die SPF/DKIM/DMARC/ARC-Abfragen. Wenn nicht gesetzt, wird die System-resolv.conf verwendet.

DNS_TIMEOUT

(Dauer, optional) DNS-Timeout pro Abfrage. Standardwert 5 s.

HEADER_CANONICALIZATION

(``relaxed`` | ``simple``, optional) Header-Kanonisierung der AMS (die linke Hälfte von c=). Standardwert relaxed.

BODY_CANONICALIZATION

(``relaxed`` | ``simple``, optional) Nachrichtentext-Kanonisierung der AMS (die rechte Hälfte von c=). Standardwert relaxed. ARC unterstützt jede Kombination der beiden.

SIGNATURE_EXPIRATION_DAYS

(ganzzahlig, optional) Wenn auf eine positive Anzahl von Tagen gesetzt, trägt die AMS einen Ablauf (x=) so viele Tage nach dem Signieren. Nicht gesetzt (der Standardwert) gibt keinen Ablauf aus. Die ARC-Seal hat in RFC 8617 kein x=-Tag und trägt nie eines, was hier auch stehen mag.

SIGNED_HEADERS

(Zeichenkette, optional) Durch Leerraum/Komma getrennte Liste der Header, die die AMS abdeckt (h=). Muss From enthalten. Standardwert ist die eingebaute Urheber-/MIME-Header-Menge.

Die ARC-Signieridentität, das Schlüsselverzeichnis, der Selektor und der Algorithmus stammen aus dem gemeinsamen [pepsi]-Abschnitt (ARC_DOMAIN, ARC_ALGORITHM, KEY_DIR, DKIM_SELECTOR). Der Hash ist immer SHA-256; der Signaturalgorithmus (a=) ist die einzige [pepsi] ARC_ALGORITHM-Wahl, da ARC eine Signatur pro Hop erlaubt.

85.2.1.1.14.2. pepsi-stage-srs-Optionen

Eine Stage mit PROGRAM = pepsi-stage-srs benötigt nur ein NEXT_STAGE in ihrem eigenen [stage-<name>]-Abschnitt; alle ihre Parameter (SRS_DOMAIN, SECRET/SECRET_FILE, MAX_AGE_DAYS) liegen im oben dokumentierten gemeinsamen [pepsi-srs]-Abschnitt, sodass sie mit der Rückwärts-Dekodierung von Ingress identisch sind.

85.2.1.1.14.3. pepsi-stage-encrypt-Optionen

Eine Stage mit PROGRAM = pepsi-stage-encrypt signiert lokal eingelieferte Mail als ihren From:-Autor und verschlüsselt sie an jeden Empfänger. Sie liest, neben einem erforderlichen NEXT_STAGE und einem optionalen BOUNCE_STAGE:

Warnung

Platzieren Sie diese Stage vor der DKIM-Signier-Stage, nicht danach: … → encrypt → srs → dkim-sign → relay. DKIM muss die Bytes signieren, die tatsächlich übertragen werden, und diese Stage schreibt den Nachrichtentext um. Zuerst zu signieren ergibt Mail, die gültig aussieht und deren Signatur nicht durchgeht — schlimmer als keine Signatur, denn eine defekte ist für einen Empfänger ein stärkeres negatives Signal als eine fehlende. pepsi-setup(1) warnt, wenn es eine DKIM-Signier-Stage findet, die zu dieser führt.

Die Pay-to-Send-Schranke und die Spracherkennung lesen beide den Nachrichtentext und wollen beide Klartext; auf dem ausgehenden Pfad laufen sie vor dieser Stage, weshalb die Verschlüsselung zuletzt kommt.

Jede Option unten ist verhaltensbezogen und ist je Adresse über die pepsi.settings-Tabelle überschreibbar (pepsi-settings(1)), für ausgehende Mail auf den Umschlagabsender geschlüsselt. Die kryptographische Richtlinie — Algorithmen, Herabstufungserlaubnis, Mindestschlüsselgrößen — steht in den CRYPTO_*-Optionen von [pepsi] und in [pepsi-crypto], ist nur für Systemadministratoren und ist von hier aus bewusst nicht erreichbar.

ENABLE_PEP

(boolesch, optional) Verhält sich wie das Projekt pretty Easy privacy (pEp): Jeder lokale Absender an einer bedienten Domain erhält bei seiner ersten Nachricht einen Schlüssel, Mail wird verschlüsselt, wann immer ein Empfängerschlüssel bekannt oder auffindbar ist, und der Schlüssel des Absenders geht mit jeder Nachricht hinaus. Standardwert YES.

Eine Voreinstellung von Standardwerten, kein erzwingender Modus: Sie ändert den Standardwert von SIGN auf encrypted-only und schaltet das eifrige Erzeugen von Schlüsseln ein. Jede ausdrücklich ausgeschriebene Option hat weiterhin Vorrang. Mit ENABLE_PEP = no ist der Standardwert von SIGN opportunistic, und Schlüssel werden nur auf ausdrückliche Anforderung (Signieren oder Verschlüsseln) oder unter SIGN = always erzeugt. Das eifrige Erzeugen benötigt zusätzlich [pepsi-crypto] AUTO_CREATE_IDENTITY (das Veto des Operators, das keine adressbezogene Überschreibung erreicht) und ein KEY_WRAP_SECRET, und es geschieht nur für eine Adresse an einer [pepsi-ingress] ACCEPTED_DOMAINS-Domain, die keinerlei crypto_identity-Zeile hat. Ein Benutzer kann sich mit ENABLE_PEP = no in seiner eigenen pepsi.settings-Überschreibung abmelden, wo EDITABLE_STAGES es erlaubt. Es wird kein pEp-Leitungsformat erzeugt: kein X-pEp-Version-Header, keine pEp-2.x-Verpackung, keine Trustwords und keine Schlüsselsynchronisation. Siehe pepsi-stage-encrypt(1).

SIGN

(``no`` | ``encrypted-only`` | ``opportunistic`` | ``always``, optional) Ob mit dem Schlüssel des From:-Autors signiert wird. Standardwert encrypted-only unter ENABLE_PEP, sonst opportunistic.

encrypted-only signiert nur eine Nachricht, die diese Stage verschlüsselt, und zwar innerhalb des Chiffrats; Klartext-Mail trägt den Schlüssel des Absenders, aber keine Signatur, sodass ein Empfänger, der keine Kryptografie verwendet, nie eine signature.asc sieht. Eine ausdrückliche Anforderung (X-Pepsi-Sign: yes, ein [sign]-Betreff-Schlüsselwort) signiert Klartext dennoch. opportunistic signiert, wenn der Autor brauchbares Material hat, und sendet sonst unsigniert. always signiert auf dieselbe Weise und lässt zusätzlich für einen Autor, der keine hat, eine Identität erzeugen, unter denselben Bedingungen wie das eifrige Erzeugen von ENABLE_PEP (AUTO_CREATE_IDENTITY, ein KEY_WRAP_SECRET, eine bediente Domain, keinerlei Identität), es sei denn, X-Pepsi-Sign: no hat die Signatur abgelehnt. Keines davon ist eine Garantie — ein Autor, den diese Installation nicht bedient, wird unsigniert gesendet statt gebounct. Eine Nachricht, die der einliefernde Client bereits signiert hat, erhält von Pepsi keine zweite Signatur, und eine, die der Client bereits verschlüsselt hat, bleibt vollständig unangetastet.

ENCRYPT

(``no`` | ``opportunistic`` | ``required``, optional) Standardwert opportunistic: an einen Empfänger verschlüsseln, für den wir einen brauchbaren Schlüssel haben, gewöhnliche Mail an einen senden, für den wir keinen haben. required bedeutet, dass ein Empfänger ohne brauchbaren Schlüssel den sicheren Link oder einen Bounce bekommt, nie Klartext.

PREFER

(``openpgp`` | ``smime``, optional) Zu welchem Protokoll gegriffen wird, wenn ein Korrespondent für beide brauchbares Material hat. Standardwert openpgp; pgp wird als Synonym dafür angenommen.

ON_NO_KEY

(``cleartext`` | ``secure-link`` | ``bounce``, optional) Was mit einem Empfänger ohne brauchbaren Schlüssel geschieht. Standardwert aus ENCRYPT: cleartext für no/opportunistic, und für required entweder secure-link (wenn SECURE_LINK_STAGE gesetzt ist) oder bounce. Es ausdrücklich zu setzen überschreibt das — außer dass eine Nachricht, deren eigene Anfrage die Richtlinie auf required angehoben hat, nie auf cleartext zurückfällt.

Vorsicht

ON_NO_KEY = cleartext zusammen mit [pepsi] CRYPTO_ALLOW_DOWNGRADE = no sendet einem Korrespondenten, dessen Schlüssel AES-GCM nicht lesen kann, Klartext — strikt schlimmer als das SEIPDv1+MDC, das die Option vermeiden sollte, und der größte Teil der installierten OpenPGP-Basis (GnuPG 2.4 und älter) ist in dieser Lage. pepsi-setup(1) warnt vor dem Paar. Lassen Sie die Option in Ruhe: Sowohl negotiate (einkompiliert) als auch yes (was config.d ausliefert) stufen herab, statt abzulehnen, und unter negotiate nur, wenn der eigene Schlüssel des Empfängers beweist, dass es sein muss.

ON_OVERSIZE

(``cleartext`` | ``secure-link`` | ``bounce``, optional) Was mit einer Nachricht geschieht, die größer als MAX_SIZE ist. Standardwert genau wie bei ON_NO_KEY, sodass required nicht zu Klartext wird, weil ein Anhang groß war.

MAX_SIZE

(Zahl, optional) Größte Nachricht, in Bytes, die diese Stage verschlüsselt. Standardwert 25000000 (25 MB). Weder der CMS-Builder noch die OpenPGP-Pfade streamen, sodass die ganze Nachricht während der Verschlüsselung resident ist, einmal je Empfänger; eine sichtbare Obergrenze ist das, was die Speicherobergrenze je Worker vorhersagbar hält, statt PARALLELISM Worker je eine mehrere hundert Megabyte große Nachricht halten zu lassen.

MIN_TRUST

(``own`` | ``manual`` | ``dane`` | ``wkd-advanced`` | ``wkd-direct`` | ``ldap`` | ``vks`` | ``owner-confirmed`` | ``harvested`` | ``gossip`` | ``any``, optional) Die am niedrigsten eingestufte Schlüsselquelle, an die diese Stage verschlüsselt. Standardwert ist [pepsi-keydiscovery] MIN_TRUST, sodass eine Installation eine Untergrenze hat, sofern sie nicht bewusst zwei will. Siehe Der Abschnitt [pepsi-keydiscovery] für die Einstufung, dafür, warum die Standarduntergrenze alles annimmt, und für den Unterschied zwischen harvested und gossip.

SUBJECT_KEYWORDS_SIGN, SUBJECT_KEYWORDS_ENCRYPT, SUBJECT_KEYWORDS_BOTH

(kommagetrennte Liste, optional) Schlüsselwörter, die ein Absender irgendwo im Subject platzieren darf, um Schutz zu erbitten. Standardwerte [sign], [encrypt] und [secure]. Ohne Beachtung der Groß-/Kleinschreibung abgeglichen; das getroffene Schlüsselwort wird aus dem ausgehenden Subject entfernt. Ein Verschlüsselungs-Schlüsselwort hebt die Richtlinie für diese Nachricht auf required an — eine bewusste menschliche Bitte als „versuchen und stillschweigend aufgeben“ zu lesen machte die Funktion zur Lüge. Kommas, nicht Leerzeichen, trennen die Liste, denn ein Schlüsselwort darf rechtmäßig ein Leerzeichen enthalten.

STRIP_REQUEST_HEADERS

(boolesch, optional) Jedes X-Pepsi-*-Feld aus der ausgehenden Nachricht entfernen. Standardwert YES. Die zwei Header, auf die diese Stage reagiert (X-Pepsi-Sign, X-Pepsi-Encrypt), werden bedingungslos entfernt, was auch immer dies sagt: Ein Steuerkanal, der auf die Leitung überlebt, ist einer, dem der nächste Hop zu gehorchen aufgetragen werden kann. Diese Option entscheidet nur über das Schicksal der übrigen X-Pepsi-*-Felder, die ein Add-in hinzugefügt haben mag. Pepsi-Origin liegt nicht in diesem Namensraum und wird nie angetastet.

PROTECT_HEADERS

(boolesch, optional) Die RFC-5322-Header-Felder in den geschützten Teil kopieren und den äußeren Subject durch ... ersetzen — was Thunderbird für PGP/MIME implementiert. Standardwert NO: Die Client-Unterstützung ist uneinheitlich, und der Fehlerfall ist eine Nachricht, deren Betreff in einem Client, der nicht hineinsehen kann, ... lautet.

AUTOCRYPT

(boolesch, optional) Den eigenen OpenPGP-Schlüssel des From:-Autors in einem Autocrypt:-Header ankündigen. Standardwert YES, und auf jeder lokal eingelieferten Nachricht — signiert, verschlüsselt oder schlichter Klartext —, denn ein Korrespondent muss den Schlüssel aus gewöhnlicher Mail lernen, bevor es etwas zu verschlüsseln gibt.

Der Schlüssel wird auf die minimale Fünf-Paket-Form von Autocrypt Level 1 §2.1.1 reduziert. Nur OpenPGP wird angekündigt (Autocrypt hat keine S/MIME-Form), nur für eine Identität, die ihr privates Material noch hält, und nie auf einer Nachricht, die bereits ein Autocrypt:-Feld trägt — der eigene Header eines echten Clients benennt den Schlüssel, mit dem er entschlüsseln kann, und ein zweites Feld lässt Level-1-Parser beide verwerfen. prefer-encrypt=mutual wird nur beansprucht, wenn das effektive ENCRYPT required ist; siehe pepsi-stage-encrypt(1).

Nichts wird angekündigt, wenn das öffentliche Gesicht der Adresse der eigene MUA-Schlüssel des Benutzers ist (custody = client), oder bei einer Nachricht, die der Client bereits verschlüsselt hat: Der Mail-Client kündigt seinen eigenen Schlüssel an.

Schalten Sie es aus, um die Schlüsselveröffentlichung auf das Web Key Directory und DNS zu beschränken, was eine vertretbare Wahl für eine Installation ist, die nicht möchte, dass die Schlüssel ihrer Benutzer auf jeder Nachricht mitreisen, die sie senden.

ATTACH_KEYS_AS_FILES

(boolesch, optional) Hängt den öffentlichen Schlüssel des Absenders zusätzlich zum Autocrypt:-Header auch als application/pgp-keys-Datei namens OpenPGP_0x<long key ID>.asc an, auf die klassische OpenPGP-Weise. Standardwert NO, unabhängig von ENABLE_PEP; ein Operator, der nur die Datei will, setzt zusätzlich AUTOCRYPT = no.

Bei einer verschlüsselten Nachricht kommt die Datei in das Chiffrat; bei Klartext wird die Nachricht in ein multipart/mixed verpackt (oder der Schlüssel einem vorhandenen hinzugefügt). Sie wird angehängt, bis jeder Empfänger nachweislich den Schlüssel besitzt – er hat eine an ihn verschlüsselte und von ihm signierte Nachricht zurückgeschickt, festgehalten in pepsi.peer_has_own_key –, und beginnt für einen neuen Schlüssel von vorn. Nie, wenn das öffentliche Gesicht der eigene MUA-Schlüssel des Benutzers ist, nie bei Mail, die der Client verschlüsselt hat, und nicht bei Klartext, den der Client signiert hat.

KEYS_CONTROL_LOCAL_PART

(Zeichenkette, optional) Lokaler Teil der Adresse, unter der ein Benutzer seine eigenen Schlüssel per E-Mail verwaltet: Eine lokal eingelieferte Nachricht, deren einziger Empfänger <KEYS_CONTROL_LOCAL_PART>@<served domain> ist, ist ein Befehl (status, generate, register, publish [FPR], retire FPR im Subject:), der verbraucht und an RESPONSE_STAGE beantwortet wird. Standardwert pepsi-keys; none schaltet diese Schnittstelle ab. Benötigt RESPONSE_STAGE.

RESPONSE_STAGE

(Stage-Name, optional) Wohin die Antworten auf die E-Mail-Schlüsselbefehle und die Hinweise „für Ihre Adresse wurde ein neuer Schlüssel registriert“ als neue Nachrichten mit Null-Absender injiziert werden. Normalerweise die ausgehende DKIM-Signier-Stage, die pepsi-setup –wizard schreibt (dkim-sign). Nicht gesetzt bedeutet keine Hinweise und keine E-Mail-Befehle (Steuermail wird dann wie jede andere Nachricht weitergesendet); pepsi-setup(1) warnt davor, lehnt einen Namen ab, der keine Stage ist, und verlangt die Rückfallvorlagen key-registered.en.body und keys.en.body, wenn die Option gesetzt ist.

AUTOCRYPT_GOSSIP

(boolesch, optional) Die OpenPGP-Schlüssel der anderen Empfänger in Autocrypt-Gossip:-Feldern ankündigen (Autocrypt Level 1 §5.3), sodass zwei Korrespondenten, die einander nie geschrieben haben, einander nach einer Nachricht dennoch verschlüsselt antworten können. Standardwert NO.

Standardmäßig aus, weil es nicht dieselbe Art von Handlung ist wie AUTOCRYPT: Jenes veröffentlicht einen Schlüssel, dessen Eigentümer diese Installation gebeten hat, ihn zu halten, während dieses die Schlüssel Dritter — hier bloß zwischengespeichertes Material — an Korrespondenten weiterverteilt, die nicht danach gefragt haben.

Es gilt nur für eine Nachricht, die diese Stage tatsächlich verschlüsselt, und die Felder gehen in das Chiffrat, nie auf den äußeren Header-Block: Ihr ganzer Zweck ist, die Empfänger einander vorzustellen, ohne die Empfängermenge dem Netz preiszugeben. Es gibt daher kein Gossip beim Klartext-Durchreichen, bei einer signierten, aber unverschlüsselten Nachricht oder bei einem S/MIME-Container (Autocrypt ist über OpenPGP definiert und hat keine S/MIME-Form). Ein Feld wird je eingeführtem Empfänger ausgegeben — anders als bei Autocrypt:, wo ein zweites Feld einen Level-1-Parser die Nachricht verwerfen lässt — und prefer-encrypt erscheint nie, da es die eigene Richtlinie des Absenders angibt und dieses Feld für jemand anderen spricht.

Warnung

Blindkopien werden nie gegossipt. Die angekündigten Adressen werden aus den geparsten To:- und Cc:-Feldern der Nachricht gelesen und aus nichts sonst; die Umschlagempfängerliste wird nur herangezogen, um eine Adresse aus der Menge zu entfernen. Ein Bcc-Empfänger steht auf dem Umschlag und in keinem der beiden Felder, sodass keine Kopie der Nachricht einen Header tragen kann, der ihn benennt — und darauf sollte man sich verlassen, denn ein Gossip-Header für einen blinden Empfänger sagte jedem anderen Empfänger, dass ein verborgener existiert und wer er ist. Das gilt auch, wenn ein Bcc:-Feld von einem defekten einliefernden Client auf der Nachricht belassen wurde, denn das Feld wird nicht gelesen.

Die Umkehrung ist Absicht: Die eigene Kopie eines blinden Empfängers trägt sehr wohl Gossip über die To:/Cc:-Empfänger. Er hat jene Header-Felder wie alle anderen erhalten, sodass es nichts offenlegt, was er nicht ohnehin lesen kann, und es ist das, was ihn verschlüsselt antworten lässt.

Ein Empfänger, für den diese Installation keinen zwischengespeicherten Schlüssel hält, wird schlicht ausgelassen — die Stage betreibt keine Schlüsselentdeckung in seinem Namen und verzögert nie eine Nachricht, um den Schlüssel eines Dritten zu holen. Eine Nachricht mit mehr als 50 sichtbaren Empfängern bekommt überhaupt kein Gossip: In dieser Größe ist sie eine Rundsendung statt eines Gesprächs, jeder eingeführte Schlüssel wird im Chiffrat jedes Empfängers wiederholt, und eine beliebige Teilmenge einzuführen wäre schlimmer, als keine einzuführen.

GOSSIP_MIN_TRUST

(``own`` | ``manual`` | ``dane`` | ``wkd-advanced`` | ``wkd-direct`` | ``ldap`` | ``vks`` | ``owner-confirmed`` | ``harvested`` | ``gossip`` | ``any``, optional) Die am niedrigsten eingestufte Schlüsselquelle, deren Schlüssel in einem Autocrypt-Gossip:-Feld weiterveröffentlicht werden darf. Standardwert owner-confirmed — die schwächste Sprosse, auf der jemand, der zu der Adresse berechtigt ist, einen bewussten Schritt getan hat, den Schlüssel zu veröffentlichen.

Es ist eine echte Verschärfung gegenüber MIN_TRUST, und das mit Absicht: An einen Schlüssel mit Vertrauen beim ersten Gebrauch zu verschlüsseln ist ein guter Tausch, denn die Alternative ist Klartext, aber diesen Schlüssel an Dritte weiterzugeben ist eine andere Handlung. Ein gegossipter Schlüssel wird von jedem, der ihn empfängt, auf einer Sprosse gespeichert, die er nach unserer Aussage beurteilt und nicht danach, wie wir zu ihm gekommen sind, sodass das Weitergeben einer Vermutung sie zu etwas wäscht, das wie Wissen aussieht.

Die tatsächlich angewandte Untergrenze ist die strengere von dieser und MIN_TRUST: Einen Korrespondenten an einen Schlüssel heranzuführen, an den diese Stage selbst nicht verschlüsseln würde, hieße etwas zu empfehlen, das sie abgelehnt hat. Eine der beiden Optionen anzuheben verschärft also das Gossip, eine von beiden zu senken kann es nicht über die andere hinaus lockern, und ein Operator, der MIN_TRUST härtet, muss sich nicht merken, dass eine zweite Option existiert. GOSSIP_MIN_TRUST = any gossipt, woran auch immer verschlüsselt werden darf. Ohne Wirkung, sofern AUTOCRYPT_GOSSIP nicht an ist.

SECURE_LINK_STAGE

(Stage-Name, optional) Wohin ein Empfänger geschickt wird, der den secure-link-Weg nimmt. Erforderlich, wenn ON_NO_KEY/ON_OVERSIZE auf secure-link auflöst.

DISCOVERY

(boolesch, optional) Ob ein Cache-Fehltreffer eine Netzabfrage auslösen darf; dokumentiert unter Der Schalter je Absender: [stage-encrypt] DISCOVERY.

DISCOVERY_TIMEOUT

(zeitlich, optional) Überschreibt [pepsi-keydiscovery] TIMEOUT für die Parkvorgänge, die diese Stage erzeugt. Beachten Sie, dass Section::duration() Kalendereinheiten ablehnt: 90 s und 2 h parsen, 1 d nicht.

Eine Autorenidentität, die diese Stage erzeugt oder registriert, wird über LOCAL_DOMAINS, TARGETS und RECIPIENT_DELIMITER von [pepsi-crypto] einem passwd-Login zugeordnet, so wie pepsi-keys(1) eine zuordnet, sodass die Eigentumsregel von Der Abschnitt [pepsi-crypto] nicht davon abhängt, welches Programm den Schlüssel erzeugt hat. Eine Adresse, die zu keinem lokalen Konto auflöst, ist ein legitimer Zustand (eine Rollenadresse oder eine gehostete Domain), kein Fehlschlag. Ob überhaupt eine Identität erzeugt werden darf, ist [pepsi-crypto] AUTO_CREATE_IDENTITY, und es wird nur für einen Autor in einer [pepsi-ingress] ACCEPTED_DOMAINS-Domain angeboten.

Das Binärprogramm wird setuid pepsi-crypto installiert, Modus 4750 pepsi-crypto:pepsi, denn es muss die eine Datenbankrolle sein, der crypto_identity.private_wrapped gewährt ist — die Peer-Authentifizierung richtet sich nach der effektiven uid — und muss das 0640-Fragment mit dem Schlüsselverschlüsselungsschlüssel (KEK) lesen, das demselben Konto gehört. Siehe pepsi-stage-encrypt(1).

85.2.1.1.14.4. pepsi-stage-decrypt-Optionen

Eine Stage mit PROGRAM = pepsi-stage-decrypt entschlüsselt Mail, die an von diesem Host bediente Empfänger gerichtet ist, und verifiziert, welche Signatur sie auch trägt. Sie liest, neben einem erforderlichen NEXT_STAGE und einem optionalen BOUNCE_STAGE:

ENABLED

(boolesch, optional) Ob überhaupt Kryptographie betrieben wird. Standardwert YES. NO entfernt weiterhin den X-Pepsi-*-Header-Namensraum aus eingehender Mail: Eine deaktivierte Stage darf nicht zum Kanal für einen gefälschten Indikator werden.

LOCAL_DOMAINS, TARGETS, RECIPIENT_DELIMITER

(optional) Welche Empfänger dieser Host bedient — dieselben Optionen, mit denselben Standardwerten, wie pepsi-stage-relay-to-maildir(1) und pepsi-stage-dot-forward(1). LOCAL_DOMAINS fällt auf [pepsi-ingress] ACCEPTED_DOMAINS zurück.

REQUIRE_ACCOUNT

(boolesch, optional) Ob ein lokaler Empfänger zusätzlich zu einem von TARGETS erlaubten passwd-Konto auflösen muss. Standardwert NO, was der Unterschied zu den Zustell-Stages ist: Sie müssen wissen, wessen Postfach zu schreiben ist, während diese Stage nur wissen muss, ob die Nachricht uns gehört. Eine gehostete Domain, deren Benutzer Krypto-Identitäten, aber keine Shell-Konten halten, ist eine gewöhnliche Installation.

ON_DECRYPT_FAILURE

(``passthrough`` | ``quarantine`` | ``bounce``, optional) Was mit einer Nachricht zu tun ist, die dieser Host nicht öffnen konnte. Standardwert passthrough: Der Benutzer hält den Schlüssel womöglich in seinem eigenen Client, und Mail zu bouncen, die wir bloß nicht öffnen konnten, hilft niemandem. quarantine braucht QUARANTINE_STAGE; bounce braucht BOUNCE_STAGE.

ON_BAD_SIGNATURE

(``record`` | ``quarantine`` | ``bounce``, optional) Was mit einer Nachricht zu tun ist, deren Signatur sich nicht verifizieren ließ. Standardwert record: Mailinglisten, die Nachrichtentexte umschreiben, Weiterleiter und Clients mit defekter Kanonisierung erzeugen alle schlechte Signaturen auf völlig legitimer Mail. Nur das invalid-Urteil zählt hier als schlecht — valid-untrusted und unverifiable sind der Normalzustand von Mail eines unbekannten Korrespondenten und werden nie geroutet.

QUARANTINE_STAGE

(Stage-Name, optional) Wohin ein quarantine-Weg führt. Erforderlich, wenn eine der obigen Richtlinien auf quarantine gesetzt ist.

SUBJECT_TAGS

(boolesch, optional) Die erworbenen Tags in Verschachtelungsreihenfolge dem Subject voranstellen — encrypted(signed(body)) ergibt [decrypted][verified] … und signed(encrypted(body)) ergäbe [verified][decrypted] …. Standardwert YES: Für die meisten Benutzer ist dies das einzige Signal, das sie je sehen werden. Der Preis ist ein verändertes benutzersichtbares Feld, was Suche, Threading und zitierte Betreffs in Antworten betrifft. (Beide Gestalten gehen auf. Die zweite erwirbt [verified] nur aus einer Signatur innerhalb des Chiffrats: Eine äußere Signatur deckt Chiffrat ab und erreicht nie das valid-Urteil, für das der Tag geschrieben wird — siehe pepsi-stage-decrypt(1).)

TAG_DECRYPTED, TAG_VERIFIED

(Zeichenkette, optional) Der Wortlaut der Tags. Standardwerte [decrypted] und [verified]. TAG_VERIFIED wird nur für das valid-Urteil geschrieben.

TAG_BAD_SIGNATURE

(Zeichenkette, optional) Der Tag für das invalid-Urteil. Standardmäßig leer: Eine schlechte Signatur ist eine routinemäßige Eigenschaft legitimer Mail, sodass ein standardmäßig eingeschalteter Tag einen großen Teil des Posteingangs eines Benutzers mit einer Anschuldigung schmückte.

STRIP_SUBJECT_TAGS

(boolesch, optional) Das eigene Tag-Vokabular dieser Stage vom Anfang eines eingehenden Subject entfernen, bevor unseres vorangestellt wird. Standardwert YES, und faktisch verpflichtend: Ohne es schreibt ein externer Absender einfach selbst [verified]. Das Vokabular wird aus den drei TAG_*-Optionen plus den eingebauten [decrypted] und [verified] abgeleitet, sodass das Umbenennen eines Tags das Loch nicht wieder öffnen kann.

STRIP_SUBJECT_KEYWORDS

(kommagetrennte Liste, optional) Zusätzliche eingehende Betreff-Tags, die zu entfernen sind. Kommas statt Leerraum, denn ein Schlüsselwort darf ein Leerzeichen enthalten.

ADD_RESULT_HEADER

(boolesch, optional) Den Ergebnis-Header X-Pepsi-Crypto einer Nachricht hinzufügen, die Schutz trug. Standardwert YES. Seine Grammatik ist in pepsi-stage-decrypt(1) dokumentiert. Jedes X-Pepsi-*-Feld wird zuvor aus eingehender Mail entfernt, bedingungslos und was auch immer diese Option sagt — diese Entfernung ist das, was den Header glaubwürdig macht.

MAX_LAYERS

(ganzzahlig, optional) Wie viele verschachtelte verschlüsselte Schichten ausgepackt werden. Standardwert 4. Eine Nachricht mit mehr wird mit dem ungeöffneten Rest zugestellt.

TRUST_ANCHOR_TTL

(zeitlich, optional) Wie lange ein Worker-Prozess die zuletzt gelesenen ca_trust-Anker wiederverwendet. Standardwert 5 m. Ein hinzugefügter oder deaktivierter Anker wird innerhalb dieses Fensters wirksam; starten Sie die Worker neu, um ihn sofort anzuwenden. Kalendereinheiten werden abgelehnt (5 m und 2 h parsen, 1 d nicht).

DISCOVERY

(boolesch, optional) Ob ein Cache-Fehltreffer eine Netzabfrage auslösen darf; dokumentiert unter Der Schalter je Absender: [stage-encrypt] DISCOVERY. Von demselben Leser aus diesem Abschnitt gelesen, sodass die beiden Krypto-Stages sich über seinen Namen oder seinen Standardwert nicht uneinig sein können.

DISCOVERY_TIMEOUT

(zeitlich, optional) Überschreibt [pepsi-keydiscovery] INBOUND_TIMEOUT für die Parkvorgänge, die diese Stage erzeugt.

[pepsi] CRYPTO_ALLOW_DOWNGRADE beschränkt diese Richtung nicht. OpenPGP-SEIPDv1+MDC und CMS-AES-CBC-EnvelopedData sind immer lesbar, was auch immer die Ausgaberichtlinie sagt: Sie eingehend abzulehnen machte diesen Host unfähig, Mail aus dem größten Teil der Welt zu empfangen, während es niemanden schützte. Nur 3DES und die schwachen Signatur-Digests sind eingehend beschränkt, und jede Ablehnung erzeugt ihr eigenes Urteil.

Das Binärprogramm wird setuid pepsi-crypto installiert, Modus 4750 pepsi-crypto:pepsi, aus genau den Gründen, die oben für pepsi-stage-encrypt(1) genannt sind. Siehe pepsi-stage-decrypt(1).

85.2.1.1.14.5. pepsi-stage-reencrypt-Optionen

Eine Stage mit PROGRAM = pepsi-stage-reencrypt versiegelt eine Nachricht, die die Decrypt-Stage geöffnet hat, vor der lokalen Zustellung für den eigenen Mail-Client-Schlüssel (MUA-Schlüssel) des Empfängers. Sie handelt nur bei Datensätzen, deren state.crypto.in besagt, dass die Nachricht verschlüsselt ankam und entschlüsselt wurde. NEXT_STAGE ist verpflichtend.

ON_NO_CLIENT_KEY

(Zeichenkette, optional) Was mit einem lokalen Empfänger ohne verwendbaren MUA-Schlüssel geschieht: plaintext (Standardwert) legt den Klartext ab; bounce weist die Nachricht über BOUNCE_STAGE mit einer 5.7.5-DSN zurück, die nur die Adressierungs-Headerfelder und keinen Nachrichtentext trägt (RET=HDRS wird erzwungen). pepsi-setup lehnt bounce ohne BOUNCE_STAGE ab. Überschreibungen pro Empfänger über pepsi.settings gelten.

PROTECT_HEADERS

(boolesch, optional) Kopiert die RFC-5322-Felder in den Chiffretext und ersetzt den äußeren Subject durch .... Standardwert NO.

ENABLED

(boolesch, optional) Ausgeschaltet reicht es jede Nachricht durch. Standardwert YES.

LOCAL_DOMAINS, TARGETS, RECIPIENT_DELIMITER, REQUIRE_ACCOUNT

Welche Empfänger hier bedient werden, wie bei pepsi-stage-decrypt Options. Andere Empfänger werden weder versiegelt noch abgewiesen.

Der Container folgt [pepsi] CRYPTO_ALLOW_DOWNGRADE wie bei der ausgehenden Verschlüsselung. Das Binärprogramm ist unprivilegiert und in das Multi-Call-Binärprogramm pepsi eingefaltet: Es versiegelt für öffentliche Schlüssel und liest nur die öffentlichen Spalten von pepsi.crypto_identity. Siehe pepsi-stage-reencrypt(1).

85.2.1.1.14.6. Der Abschnitt [pepsi-secure-link]

Das Secure-Link-Rückfallportal: wo eine Nachricht gehalten wird, die nicht verschlüsselt werden konnte, und wie der Empfänger hereingelassen wird. Gelesen von drei Programmen — der Stage, die eine Nachricht speichert (pepsi-stage-secure-link), dem Server, der sie bedient (pepsi-httpd(1)), und der Operator-CLI (pepsi-secure-link(1)) —, weshalb es ein globaler Abschnitt ist statt in einen [stage-*]-Abschnitt kopierter Optionen.

Diese Platzierung ist außerdem eine Entscheidung darüber, wer diese Werte ändern darf. Dies ist kein [stage-<name>]-Abschnitt, sodass er außer Reichweite von pepsi.settings und pepsi-stage-edit-settings(1) liegt: Ein Korrespondent kann sich nicht selbst einen längeren Ablauf, eine kürzere PIN oder eine deaktivierte Sperre mailen. Der wirklich verhaltensbezogene Knopf — ob eine unverschlüsselbare Nachricht überhaupt zum Portal geht — ist [stage-encrypt] ON_NO_KEY, das je Adresse überschreibbar ist.

BASE_URL

(Zeichenkette) Öffentlicher Ursprung, unter dem das Portal erreichbar ist, z. B. https://secure.example.org. Ihn (zusammen mit PEPPER) zu setzen ist das, was die Funktion aktiviert; der einem Empfänger gemailte Link ist <BASE_URL>/secure/<token>. Nichts hier sagt, wo das Portal eingehängt ist — ein eigener Listener und Hostname oder einer, der mit der API und dem Web Key Directory geteilt wird, werden beide unterstützt.

PEPPER

(Zeichenkette) Das serverseitige Geheimnis, das in jede Inhaltsschlüssel-Ableitung eingemischt wird. Von pepsi-setup(1) nach secrets.d/pepsi-secure-link.secret geschrieben und mit @inline-secret@ referenziert; es ist das eine verwaltete Fragment mit zwei Lesern, sodass es mit Modus 0640 und Eigentümer pepsi-httpd:pepsi installiert wird. Ohne es ist das Portal aus — es gibt keinen Modus, in dem eine Nachricht im Klartext gespeichert wird. Es zu verlieren oder zu ändern macht jede gespeicherte Nachricht unlesbar, was dieselbe Eigenschaft ist, die eine gestohlene Datenbank wertlos macht.

EXPIRY_DAYS

(ganzzahlig, optional) Wie lange eine gespeicherte Nachricht lebt. Standardwert 7. Eine ganzzahlige Anzahl von Tagen statt einer Dauer, denn duration-Werte lehnen Kalendereinheiten ab.

PIN_LENGTH

(ganzzahlig, optional) Zeichen in einer erzeugten PIN, aus einem 31-Symbol-Alphabet ohne Mehrdeutigkeiten (kein 0/O, kein 1/I/L). Standardwert 10, Minimum 8. Sechs Ziffern werden abgelehnt: Die PIN ist das einzige Geheimnis, das ein Angreifer, der sowohl die Datenbank als auch den Pfeffer hält, noch finden muss.

MAX_ATTEMPTS, LOCKOUT

(ganzzahlig / zeitlich, optional) Falsche PINs, bevor das Token sperrt (Standardwert 10), und das erste Sperrfenster (Standardwert 15 m). Das Fenster verdoppelt sich mit jeder weiteren Sperre, gedeckelt beim 64-fachen der Basis.

SESSION_LIFETIME

(zeitlich, optional) Wie lange die Portalsitzung nach einer korrekten PIN dauert. Standardwert 30 m.

RATE_LIMIT

(ganzzahlig, optional) Anfragen pro Minute je Peer-Adresse über alle Portalrouten hinweg. Standardwert 30; 0 deaktiviert den Begrenzer.

NOTIFY_STAGE

(Zeichenkette) Erforderlich. Wohin die Link-Mail, die PIN-Mail und Lesebestätigungen injiziert werden — eine Stage auf dem ausgehenden Pfad, da dies Nachrichten sind, die die Installation originiert.

REPLY_STAGE

(Zeichenkette, optional) Wohin eine im Portal verfasste Antwort injiziert wird. Ungesetzt deaktiviert das Antworten. Richten Sie es auf den eingehenden Pfad: Eine Portalantwort wird von einer externen Partei geschrieben, sodass sie ohne state.local_origin injiziert wird und nicht als eine Ihrer Domains DKIM-signiert werden darf (pepsi-setup(1) warnt, wenn es auf eine Signier-Stage auflöst).

SEND_RECEIPT

(boolesch, optional) Dem Absender einmal mitteilen, dass die Nachricht gelesen wurde. Standardwert yes. Die Bestätigung meldet wer und wann, nie was — es gibt nichts, was sie zitieren könnte.

PIN_DELIVERY

(``sender`` | ``command`` | ``none``, optional) Wie der zweite Faktor den Empfänger erreicht. Standardwert sender: Die PIN wird an den Absender gemailt, der sie per Telefon oder Textnachricht weitergibt. command führt PIN_COMMAND aus. none setzt die PIN in den Link selbst und ist strikt schwächer — das Postfach wird zum einzigen Faktor.

PIN_COMMAND

(Zeichenkette, optional) Das auszuführende Programm; ein wörtlich genommener Dateisystempfad, der also anders als eine Option vom Typ Pfad nicht $-expandiert wird. Von PIN_DELIVERY = command benötigt. Wird mit der Empfängeradresse als einzigem Argument und der PIN auf der Standardeingabe ausgeführt (eine Kommandozeile ist über /proc für alle lesbar). Ein Exit ungleich null lässt die Nachricht scheitern, statt einen Link zurückzulassen, den niemand öffnen kann, und ebenso tut es eine Laufzeit von mehr als 30 Sekunden, nach denen der Befehl getötet wird: Ein SMS-Gateway-Client, der auf einer unerreichbaren Adresse blockiert, hielte sonst für immer einen Stage-Worker fest, da der Datensatz running bleibt und nichts ihn erneut beansprucht.

MAX_REPLY_SIZE, MAX_REPLY_FILES, MAX_REPLIES

(ganzzahlig, optional) Obergrenzen für eine Portalantwort: Gesamtoktette (Standardwert 25000000, passend zu [stage-encrypt] MAX_SIZE), Dateien je Antwort (Standardwert 10) und Antworten je gespeicherter Nachricht (Standardwert 20). Die Größenobergrenze wird während des Body-Streamens durchgesetzt, sodass ein Client, der Content-Length falsch angibt, nichts gewinnt.

ACCESS_LOG_ROWS

(ganzzahlig, optional) Je Nachricht aufbewahrte Zugriffsjournal-Datensätze. Standardwert 100. Das Journal wird mit der Nachricht gelöscht.

NOTIFY_FROM

(Zeichenkette, optional) Der From:-Header der drei Benachrichtigungen, die das Portal originiert (der Link, die PIN und die Lesebestätigung). Ungesetzt — der Standardwert — trägt jede From: den ursprünglichen Absender, sodass sie sich liest, als käme sie von der Person, die tatsächlich geschrieben hat; das ist für die Link- und die PIN-Mail richtig und für die Lesebestätigung fragwürdig, die eine automatische Nachricht mit Null-Absender ist und dann vorgibt, von der eigenen Adresse des Absenders zu kommen. Setzen Sie dies, um auf alle drei ein neutrales Postfach mit eigener Marke zu setzen. Es wird wörtlich in den Header geschrieben, geben Sie also einen vollständigen RFC-5322-Wert an (Example Ltd <secure@example.com>). Der Umschlagabsender bleibt in beiden Fällen unverändert.

ORGANIZATION, BRAND_COLOR, LOGO_FILE

(Zeichenkette / Zeichenkette / Pfad, optional) Erscheinungsbild. BRAND_COLOR muss #rgb oder #rrggbb sein — es wird in das Stylesheet der Seite interpoliert, sodass beliebiger Text abgelehnt statt escaped wird. LOGO_FILE ist ein lokales PNG, JPEG, GIF oder WebP, als data:-URI eingebettet (SVG wird abgelehnt: Es kann Skript tragen). Eine Logo-URL ist bewusst keine Option — die Content-Security-Policy des Portals verbietet entfernte Inhalte, was auch das ist, was ein CDN daran hindert zu erfahren, wer was gelesen hat.

85.2.1.1.14.7. pepsi-stage-secure-link-Optionen

Eine Stage mit PROGRAM = pepsi-stage-secure-link nimmt keine eigenen Optionen: Alles steht in [pepsi-secure-link] oben. Sie hat kein NEXT_STAGE (sie ist terminal — die Nachricht verlässt die Warteschlange, und ihre Benachrichtigung ist eine neue, bei NOTIFY_STAGE injizierte Nachricht).

85.2.1.1.14.8. pepsi-stage-dkim-sign-Optionen

Eine Stage mit PROGRAM = pepsi-stage-dkim-sign liest neben einem erforderlichen NEXT_STAGE:

HEADER_CANONICALIZATION, BODY_CANONICALIZATION

(``relaxed`` | ``simple``, optional) Die beiden Hälften der c=-Kanonisierung. Beide haben den Standardwert relaxed und können unabhängig gesetzt werden; alle vier Kombinationen sind sowohl für die DKIM-Signierung als auch die ARC-Versiegelung gültig.

SIGNATURE_EXPIRATION_DAYS

(ganzzahlig, optional) Wenn auf eine positive Anzahl von Tagen gesetzt, tragen die Signaturen einen Ablauf (x=) so viele Tage nach dem Signieren. Nicht gesetzt (der Standardwert) gibt keinen Ablauf aus.

SIGNED_HEADERS

(Zeichenkette, optional) Durch Leerraum/Komma getrennte Liste der Header, die die Signaturen abdecken (h=). Muss From enthalten. Standardwert ist die eingebaute Urheber-/MIME-Header-Menge.

SIGNING_DOMAIN

(Zeichenkette, optional) Erzwingt die Signierdomain (d=). Wenn nicht gesetzt, wird die Domain aus dem From:-Header jeder Nachricht entnommen. Eine feste SIGNING_DOMAIN ist eine Sendeidentität, daher richtet pepsi-setup(1) ihre Schlüssel und ihr DNS ein.

Das DKIM-Schlüsselmaterial und die Selektoren stammen aus dem gemeinsamen [pepsi]-Abschnitt (KEY_DIR, DKIM_SELECTOR). Der Hash ist immer SHA-256; es werden sowohl eine RSA- (rsa-sha256) als auch eine Ed25519-Signatur (ed25519-sha256) ausgegeben.

85.2.1.1.14.9. pepsi-stage-relay-to-internet-Optionen

Eine Stage mit PROGRAM = pepsi-stage-relay-to-internet liest (ein NEXT_STAGE und BOUNCE_STAGE sind die allgemeinen Schlüssel oben):

SERVER_NAME

(Zeichenkette, erforderlich) Unser eigener Hostname, in EHLO angekündigt und in den Received:-Trace-Header geschrieben, z. B. mail.example.org.

POSTMASTER

(Zeichenkette, optional) Adresse, die einen Doppel-Bounce empfängt — einen Bounce (Null-Absender), der selbst unzustellbar ist. Ohne eine werden solche Doppel-Bounces verworfen.

PUBLIC_IP

(Zeichenkette, optional) Die öffentlichen Adressen, von denen dieses Relay sendet, von pepsi-setup(1) gelesen, um den SPF-Eintrag zu bauen (und, für diese Stage, um das Reverse-DNS zu prüfen) — eine Relay-Stage-Option, die weiter unten unter Die Egress-Identitätsoption: PUBLIC_IP dokumentiert ist.

CONNECT_TIMEOUT / COMMAND_TIMEOUT / DATA_TIMEOUT

(Dauer, optional) Verbindungs-Timeouts für jeweils das Herstellen der TCP-Verbindung, einen SMTP-Befehl/eine SMTP-Antwort und die DATA-Übertragung. Standardwerte 300 s / 300 s / 600 s.

RETRY_INITIAL / RETRY_MAX_INTERVAL / RETRY_FACTOR

(Dauer / Dauer / Zahl, optional) Exponentieller Backoff-Zeitplan zwischen Zustellversuchen einer vorübergehend fehlschlagenden Nachricht: die erste Wartezeit, die Obergrenze der Wartezeit und der bei jedem Versuch angewandte Multiplikator. Standardwerte 300 s / 2 h / 2.

MAX_LIFETIME

(Dauer, optional) Wie lange eine Nachricht in der Pipeline bleiben darf, bevor ein vorübergehender Fehler dauerhaft wird (sie wird dann gebounct oder schlägt fehl). Standardwert 5 d Wanduhrzeit, aber der Wert muss mit h/m/s-Einheiten geschrieben werden — der Dauer-Parser lehnt die d-Kalendereinheit ab (schreiben Sie also 120 h, nicht 5 d).

DELAY_DSN_AFTER

(Dauer, optional) Wenn gesetzt, wird dem Absender eine einmalige Action: delayed-DSN gesendet, sobald eine noch nicht zugestellte Nachricht mindestens so lange eingereiht war und der Absender NOTIFY=DELAY angefordert hat. Muss h/m/s-Einheiten verwenden. Nicht gesetzt (der Standardwert) deaktiviert Delay-Warnungen.

MAX_HOP_COUNT

(Zahl, optional) Maximale Anzahl von Received:-Headern, die toleriert werden, bevor die Nachricht als Mail-Schleife behandelt und dauerhaft fehlgeschlagen wird. Standardwert 30.

DNS_SERVERS

(Zeichenkette, optional) Durch Leerraum/Komma getrennte explizite Resolver (Port 53) für die MX- und Adress-Abfragen. Wenn nicht gesetzt, wird die System-resolv.conf verwendet.

DNS_TIMEOUT

(Dauer, optional) DNS-Timeout pro Abfrage. Standardwert 5 s.

MTA_STS

(boolesch, optional) Ob MTA-STS-Richtlinien der Empfängerdomain ermittelt und durchgesetzt werden (RFC 8461). Standardwert yes.

MTA_STS_TIMEOUT

(Dauer, optional) Timeout für das Abrufen einer MTA-STS-Richtliniendatei über HTTPS. Standardwert 10 s.

ADDRESS_FAMILY

(optional) Welche IP-Adressfamilien beim Verbinden zu Mail-Exchangern verwendet werden: any (Standardwert), ipv4 (auch v4/v4only geschrieben) oder ipv6 (v6/v6only). Der konfigurierte Wert wird mit dem geschnitten, was der lokale Host tatsächlich routen kann, sodass das Festlegen auf eine Familie, für die der Host keine Route hat, nichts zum Verbinden übrig lässt. pepsi-stage-relay-to-smarthost(1) hat dieselbe Option, zusätzlich je MTA-Eintrag setzbar.

DANE

(optional) DANE/TLSA-(RFC 7672-)Durchsetzung für den Ziel-MX: off (keine TLSA-Abfragen), warn (der Standardwert; validieren, aber bei einer Nichtübereinstimmung protokollieren und trotzdem zustellen) oder strict (ein nutzbarer, aber nicht übereinstimmender Eintrag oder eine fehlgeschlagene TLSA-Abfrage schiebt die Zustellung auf). Erfordert einen DNSSEC-validierenden Resolver (Pepsi vertraut dem AD-Bit der Antwort; siehe DNS_SERVERS); nutzbare TLSA-Einträge haben Vorrang vor MTA-STS.

85.2.1.1.14.10. pepsi-stage-relay-to-smarthost-Optionen

Eine Stage mit PROGRAM = pepsi-stage-relay-to-smarthost liest die untenstehenden Betriebsoptionen; die vorgelagerten Smarthosts selbst werden einmal in den gemeinsamen [pepsi-stage-relay-to-smarthost-mta-*]-Abschnitten definiert (siehe Die Smarthost-(MTA-)Abschnitte unten). Ein NEXT_STAGE und BOUNCE_STAGE sind die allgemeinen Schlüssel oben.

SERVER_NAME

(Zeichenkette, erforderlich) Unser eigener Hostname, in EHLO angekündigt (sofern ein MTA ihn nicht mit HELO_NAME überschreibt) und in den Received:-Header geschrieben.

CONNECT_TIMEOUT / COMMAND_TIMEOUT / DATA_TIMEOUT

(Dauer, optional) Verbindungs-Timeouts für den TCP-Connect, einen SMTP-Befehl/eine SMTP-Antwort und die DATA-Übertragung. Standardwerte 300 s / 300 s / 600 s.

RETRY_INITIAL / RETRY_MAX_INTERVAL / RETRY_FACTOR

(Dauer / Dauer / Zahl, optional) Exponentieller Backoff-Zeitplan zwischen Relay-Versuchen. Standardwerte 300 s / 2 h / 2.

MAX_LIFETIME

(Dauer, optional) Wie lange eine Nachricht in der Pipeline bleiben darf, bevor ein vorübergehender Fehler dauerhaft wird. Standardwert 5 d Wanduhrzeit, aber schreiben Sie es mit h/m/s-Einheiten — der Parser lehnt die d-Kalendereinheit ab.

DELAY_DSN_AFTER

(Dauer, optional) Wenn gesetzt, wird eine einmalige Action: delayed-DSN gesendet, sobald eine noch nicht zugestellte Nachricht mindestens so lange eingereiht war und der Absender NOTIFY=DELAY angefordert hat. Muss h/m/s-Einheiten verwenden. Nicht gesetzt deaktiviert es.

MAX_HOP_COUNT

(Zahl, optional) Maximale Anzahl von Received:-Headern, bevor die Nachricht als Schleife behandelt und dauerhaft fehlgeschlagen wird. Standardwert 30.

ADDRESS_FAMILY

(optional) Die Adressfamilie, die jeder MTA-Eintrag erbt, sofern sein eigener [pepsi-stage-relay-to-smarthost-mta-*]-Abschnitt sie nicht überschreibt: any (Standardwert), ipv4 (auch v4/v4only) oder ipv6 (v6/v6only). Dieselbe Option, dieselben Schreibweisen wie die von pepsi-stage-relay-to-internet(1) oben.

PUBLIC_IP

(Zeichenkette, optional) Die öffentlichen Adressen, von denen dieses Relay sendet, von pepsi-setup(1) gelesen, um den SPF-Eintrag zu bauen — eine Relay-Stage-Option, die weiter unten unter Die Egress-Identitätsoption: PUBLIC_IP dokumentiert ist.

DNS_SERVERS

(Zeichenkette, optional) Durch Leerraum/Komma getrennte explizite Resolver (Port 53) für die DANE-TLSA-Abfragen. Wenn nicht gesetzt, wird die System-resolv.conf verwendet.

Wird nur konsultiert, wenn ein Smarthost DANE aktiviert; der Resolver muss DNSSEC validieren.

DNS_TIMEOUT

(Dauer, optional) Timeout pro Abfrage für die DANE-TLSA-Abfragen. Standardwert 5 s.

85.2.1.1.14.11. Bounce-Stage-Optionen

Ein [stage-<name>]-Abschnitt mit PROGRAM = pepsi-stage-bounce liest zusätzlich aus seinem eigenen Abschnitt:

SERVER_NAME

(Zeichenkette, erforderlich) Hostname, der in den From:- und Reporting-MTA-Feldern des erzeugten Bounces und in seiner Message-ID-Domain verwendet wird, z. B. mail.example.org.

POSTMASTER

(Zeichenkette, optional) From:-Adresse erzeugter Bounces (Mail Delivery Subsystem <POSTMASTER>) und die DKIM-Signieridentität — der Bounce wird als die Domain dieser Adresse signiert, deren Schlüssel pepsi-setup(1) einrichtet. Standardwert ist postmaster@<SERVER_NAME>.

NEXT_STAGE

(Zeichenkette, für diese Stage erforderlich) Die Stage, zu der der umgeschriebene Bounce weitergeschaltet wird. Weil der Bounce unsigniert gelassen wird, ist dies normalerweise eine pepsi-stage-dkim-sign(1)-Stage (die ihn als die Domain des Postmasters signiert), die ihrerseits auf eine Zustell-Stage wie pepsi-stage-relay-to-internet(1) zeigt.

BOUNCE_MESSAGE

(Zeichenkette, optional) Name der Vorlage, die den menschenlesbaren (text/plain-)Teil des Bounces rendert. Die Vorlagendatei ist bounce-<NAME>.<lang>.body unter dem [pepsi]-TEMPLATE_DIR, und sie ist eine Mustache-Vorlage. <lang> folgt der state.language der Nachricht (der in der ursprünglichen Nachricht erkannten Sprache, an deren Absender der Bounce geht) in ihrer q-Reihenfolge, mit Rückfall auf bounce-<NAME>.en.body, das existieren muss. Wenn nicht gesetzt — oder wenn das Rendering fehlschlägt — wird stattdessen ein eingebauter englischer Hinweis verwendet, sodass immer ein Bounce erzeugt wird. Drei Vorlagenfamilien werden von make install installiert: bounce-default, bounce-language (die Sprachrichtlinie von pepsi-stage-block-language(1)) und bounce-payment (die unbezahlte Schranke von pepsi-stage-anti-spam(1)).

Das gesamte Nachrichten-state wird der Vorlage als Rendering-Kontext übergeben, ergänzt um die Komfortvariablen server_name, postmaster, bounce_to, failed_recipient, diagnostic, action und die Booleans failed / delayed / delivered. Insbesondere hält die Zustell-Stage strukturierte Detailangaben zum nächsten Hop unter state.bounce fest — remote_mta, smtp_code, enhanced_status, phase und reply_text — sodass die Vorlage genau angeben kann, warum der nächste MTA die Nachricht abgelehnt hat. Wenn ein state.bounce.enhanced_status (RFC 3463) vorhanden ist, wird es auch für das maschinenlesbare Status:-Feld der DSN verwendet.

RET_FULL_MAX_SIZE

(ganzzahlig, optional) Größte Originalnachricht, in Bytes, die ein RET=FULL-Bounce vollständig zurücksendet. Standardwert 262144 (256 KiB); 0 hebt die Grenze auf.

RFC 3461 §6.2 sagt, die vollständige Nachricht „SOLLTE zurückgesendet werden“, wenn der Absender RET=FULL bei MAIL FROM gesetzt hat, und erlaubt ausdrücklich, allein die Header zurückzusenden, wenn die Nachricht „eine implementierungsspezifische Größe überschreitet“ — die Grenze ist also Teil konformen Verhaltens und keine Flucht daraus. Ohne eine würde aus einer fehlgeschlagenen 40-MB-Nachricht ein 40-MB-Bounce an einen Absender, der ohnehin schon einen schlechten Tag hat. Oberhalb der Grenze fällt die DSN auf text/rfc822-headers zurück, genau wie es ein RET=HDRS-Bounce (oder einer ohne RET) tut, und der Rückfall wird protokolliert.

Der Nachrichtentext wird nur für eine Nachricht aus der Datenbank geholt, deren Absender darum gebeten hat und die innerhalb der Grenze liegt; ein gewöhnlicher Bounce lädt weiterhin nichts als den Header-Block.

BOUNCE_UNAUTHENTICATED

(``drop`` oder ``send``, optional) Was mit einem Bericht geschieht, der an einen Umschlagabsender adressiert ist, den die eingehende Nachricht nicht authentifiziert hat. Standardwert drop.

Spam fälscht seinen Umschlagabsender, sodass ein Bounce dafür an einen unbeteiligten Dritten geht. Das ist Backscatter: Die Empfänger beschweren sich, und die IP dieses Hosts landet auf Blocklisten. Unter drop wird ein Bericht nur gesendet, wenn:

• die Nachricht von einem unserer eigenen Benutzer kam (state.local_origin);

• SPF für die Domain des Umschlagabsenders bestanden hat; oder

• eine ausgerichtete DKIM-Signatur für eine From:-Domain bestanden hat, die die Domain des Umschlagabsenders oder eine ihr über- oder untergeordnete Domain ist.

Alles andere wird verworfen und geloggt. Eine Nachricht, die eine Stage erzeugt hat, statt dass sie über SMTP ankam, trägt keinen Authentifizierungsdatensatz und wird immer gemeldet. send stellt das alte Verhalten wieder her, an jeden Absender zu berichten.

Der fehlgeschlagene Empfänger und die im Bounce zitierte Diagnose werden dem state entnommen, den die Zustell-Stage, die die Nachricht hierher geroutet hat, auf dem Datensatz hinterlassen hat (siehe BOUNCE_STAGE oben); wenn nicht vorhanden (z. B. eine von Hand eingereihte Nachricht), wird ein generischer Hinweis erzeugt.

85.2.1.1.14.12. pepsi-stage-discard-Optionen

Eine Stage mit PROGRAM = pepsi-stage-discard löscht die Nachricht (eine Staging-/Test-Senke). Sie ignoriert NEXT_STAGE — ein Verwerfen ist immer terminal — und liest:

DISPOSITION

(optional) Das simulierte Ergebnis: success (Standardwert) behandelt die Nachricht als zugestellt; failure behandelt sie als dauerhaften Zustellfehler.

BOUNCE

(boolesch, optional) Ob das Verwerfen überhaupt eine DSN ausgeben darf. Standardwert no.

BOUNCE_STAGE

(Zeichenkette, optional) Die DSN-Erzeugungs-Stage, zu der ein berichtbares Verwerfen geroutet wird (normalerweise eine pepsi-stage-bounce(1)-Stage). Ohne eine wird nichts ausgegeben und der Datensatz einfach gelöscht.

Der Erfolgspfad konsultiert außerdem das gemeinsame [pepsi] ORIGINATE_SUCCESS_DSN-Flag; eine Null-Absender-Nachricht wird nie gebounct.

85.2.1.1.14.13. pepsi-stage-anti-spam-Optionen

Eine Stage mit PROGRAM = pepsi-stage-anti-spam liest (neben einem NEXT_STAGE):

BOUNCE_STAGE

(Zeichenkette, optional) Die Stage, zu der eine bis zur Frist unbezahlte Nachricht geroutet wird — normalerweise eine pepsi-stage-bounce(1)-Stage (eine Ablehnungs-DSN, unter Beachtung des NOTIFY des Absenders) oder eine pepsi-stage-discard(1)-Stage (stilles Verwerfen). Ohne eine wird eine unbezahlte Nachricht einfach gelöscht.

BOUNCE_TARGET_STAGE

(Zeichenkette, optional) Wohin ein zurückkehrender Bounce, der keinen gültigen ``Pepsi-Origin``-Nachweis trägt, geroutet wird — eine Nachricht mit Null-Absender, die vorgibt, ein Bericht über unsere Mail zu sein, von der wir nicht zeigen können, dass wir sie erzeugt haben (siehe Der Abschnitt [pepsi-origin]). Ohne eine nimmt eine solche Nachricht den gewöhnlichen NEXT_STAGE-Pfad. Richten Sie es auf eine Quarantäne- oder Prüf-Stage, wenn Sie sie zur Inspektion behalten wollen: Sie werden nie durch die Zahlungsschranke geführt, denn ein Bounce darf nicht gebouncet werden.

ORDER_CHOICES

(JSON, erforderlich) Das choices-Array der Taler-v1-Bestellung, wörtlich verwendet: ein oder mehrere OrderChoice-Objekte, die die akzeptierten Zahlungen beschreiben (zum Beispiel mehrere Beträge in verschiedenen Währungen oder Token-Familien-Eingänge/-Ausgänge). Siehe die GNU-Taler-Händler-API.

PAYMENT_DEADLINE

(Dauer, optional) Wie lange die Nachricht paused in Erwartung der Zahlung gehalten wird, bevor sie abgelehnt wird; auch die pay_deadline der Bestellung. Verwendet nur h/m/s-Einheiten (Kalendereinheiten wie d werden abgelehnt). Standardwert 48 h.

DELAY_DSN_AFTER

(Dauer, optional) Sendet dem Absender eine einmalige verzögerte Zustellungsstatusbenachrichtigung (RFC 3461), sobald eine noch unbezahlte Nachricht so lange gehalten wurde, ohne die Nachricht freizugeben — sie bleibt bis PAYMENT_DEADLINE pausiert. Die DSN wird nur gesendet, wenn der Absender NOTIFY=DELAY angefordert hat und ein BOUNCE_STAGE verdrahtet ist (sie wird mit kind = delay dorthin geroutet). Feuert nur, wenn sie strikt vor PAYMENT_DEADLINE landet. Verwendet nur h/m/s-Einheiten. Nicht gesetzt (der Standardwert) deaktiviert Delay-Warnungen.

SUMMARY

(Zeichenkette, optional) Menschenlesbare Bestellzusammenfassung, die dem Zahlenden angezeigt wird. Standardwert E-mail delivery.

FULFILLMENT_MESSAGE

(Zeichenkette, optional) Nachricht, die dem Zahlenden nach einer erfolgreichen Zahlung angezeigt wird. Standardwert Your e-mail has been queued for delivery.

BLOCK_RESPONSE_STAGE

(Zeichenkette, optional) Die Stage, bei der die Zahlungsaufforderungs-Auto-Antwort injiziert wird — üblicherweise der Kopf einer Signier-/Relay-Kette (zum Beispiel eine pepsi-stage-dkim-sign(1)-Stage). Muss eine existierende Stage referenzieren. Wenn nicht gesetzt, wird keine Antwort gesendet (die Nachricht bleibt in Erwartung der Zahlung pausiert).

BLOCK_RESPONSE_FROM

(Zeichenkette, optional) Der From:-Header der Auto-Antwort. Wenn nicht gesetzt, ist der Standardwert der ursprüngliche Empfänger (das geschützte Postfach).

BLOCK_RESPONSE_SUBJECT

(Zeichenkette, optional) Das Subject: der Auto-Antwort. Standardwert Payment required to deliver your e-mail.

BLOCK_RESPONSE_SUPPRESS

(Dauer, optional) Das Zeitfenster pro Absender für die automatische Antwort: Ein Absender, dem für dasselbe geschützte Postfach (den ersten Umschlagempfänger) innerhalb dieser Zeit bereits eine Zahlungsaufforderung geschickt wurde, erhält für die nächste Nachricht keine — die trotzdem genauso zur Zahlung zurückgehalten wird. Die Aufforderung geht an einen Umschlagabsender, den niemand verifiziert hat; ohne Zeitfenster würde also eine Flut von Nachrichten mit einem gefälschten Absender zur gleichen Flut von Aufforderungen an diese Adresse. In einer Anweisung beansprucht und festgehalten (payment_request_should_send über pepsi.payment_request_reply, das Muster von vacation_should_reply), sodass nicht zwei Worker beide eine senden können; Datensätze werden entfernt, sobald sie veralten. Nur die Einheiten h/m/s (höchstens ein Jahr); 0 s beantwortet jede Nachricht. Standardwert 1 h.

PAYMENT_MESSAGE_DEFAULT_LANGUAGE

(Zeichenkette, optional) Die Rückfallsprache für den Nachrichtentext der Auto-Antwort, verwendet, wenn die Nachricht keine erkannte state.language trägt oder keine der erkannten Sprachen eine payment-request.<lang>.body-Vorlage (unter [pepsi] TEMPLATE_DIR) hat. Diese Vorlage muss existieren (pepsi-setup prüft). Unabhängig von der Groß-/Kleinschreibung. Standardwert en.

Die Stage erfordert außerdem den gemeinsamen [pepsi-payments]-Abschnitt (das Händler-Backend und das Zugriffstoken, unten dokumentiert) und, damit der Zahlungs-Webhook pausierte Nachrichten freigeben kann, das [pepsi-httpd]-RESUME_AUTHORIZATION_TOKEN (siehe pepsi-httpd(1)).

85.2.1.1.14.14. pepsi-stage-auto-pay-Optionen

Eine Stage mit PROGRAM = pepsi-stage-auto-pay liest:

MAX_TOTAL

(Betrag, erforderlich) Das Maximum, das diese Stage insgesamt ausgibt, um eine ursprüngliche Nachricht zuzustellen — ein GNU-Taler-Betrag CURRENCY:VALUE (zum Beispiel EUR:5). Die Obergrenze ist kumulativ über jede für diese Nachricht zurückkehrende Zahlungsforderung (alle mit einer Pepsi-Origin-Nonce, z. B. eine Mailinglisten-Auffächerung) und gilt für eine einzige Währung: Eine Forderung in einer anderen Währung wird nicht bezahlt. Ein Konto kann dies für seine eigene Mail über pepsi-stage-edit-settings(1) überschreiben.

MAX_TOTAL_PER_DAY

(Betrag, optional) Das Höchste, was ein Wallet in beliebigen 24 Stunden (ein gleitendes Fenster) für Zahlungsforderungen ausgeben darf, über beliebig viele ursprüngliche Nachrichten hinweg — die Summe, die MAX_TOTAL nicht liefert, da ein Korrespondent, der k unserer Nachrichten erhalten hat, für jede MAX_TOTAL fordern kann. Das Wallet folgt WALLET_MODE/WALLET_SCOPE: das eigene Wallet eines lokalen Benutzers, das Wallet pro Absender des gemeinsamen Kontos oder dessen eines vereinigtes Wallet (dann ist die Grenze die der Installation). Nie pro Korrespondent: Mailinglisten und Aliasse machen die fordernde Partei unerkennbar. Muss in der Währung von MAX_TOTAL sein. Zusammen mit MAX_TOTAL atomar durch auto_pay_try_spend über das Journal pepsi.auto_pay_spend durchgesetzt; eine Zahlung, die nicht abgewickelt werden kann, wird zurückgebucht. Ungesetzt (der Standard) gibt es keine Tagesgrenze.

NEXT_STAGE

(Zeichenkette, erforderlich) Wohin eine Nachricht weitergeleitet wird, wenn sie keine Zahlungsforderung ist, nicht nachweislich unsere ist oder nicht bezahlt wird (über Budget / Begleichungsfehler). Eine Stage ohne NEXT_STAGE meldet zur Laufzeit einen Fehler.

WALLET_MODE

(``local-user`` | ``shared``, Standardwert ``shared``) Aus welchem Konto der Wallet-Helper bezahlt. local-user senkt die Privilegien auf das eigene lokale Login des Bounce-Empfängers (den ursprünglichen Absender) und verwendet das Standard-Wallet dieses Benutzers — der Empfänger muss auf ein erlaubtes lokales Konto auflösen (die LOCAL_DOMAINS/TARGETS/ RECIPIENT_DELIMITER-Prüfung, wie bei pepsi-stage-relay-to-maildir(1)). shared senkt sie auf ein einzelnes dediziertes Konto (WALLET_USER).

WALLET_USER

(Zeichenkette, Standardwert ``pepsi-wallets``) Das gemeinsame Konto, auf das der Helper in WALLET_MODE = shared seine Privilegien senkt; sein Home enthält die Wallet-Datenbank(en).

WALLET_SCOPE

(``per-sender`` | ``unified``, Standardwert ``per-sender``) Im shared-Modus, wie die Wallet-Datenbanken des gemeinsamen Kontos getrennt werden: eine pro Ursprungs-Absenderadresse (per-sender) oder ein einzelnes von allen geteiltes Wallet (unified — z. B. ein Unternehmen, in dem individuelle Wallets nicht sinnvoll sind).

WALLET_CLI

(Zeichenkette, Standardwert ``taler-wallet-cli``) Das GNU-Taler-Wallet-Kommandozeilenwerkzeug, das der Helper ausführt (ein auf $PATH aufgelöster Name oder ein absoluter Pfad).

WALLET_PAY_OPTIONS

(Zeichenkette, Standardwert keine) Zusätzliche Argumente, die dem Pay-Aufruf des Wallets angehängt werden, durch Leerraum getrennt. Das literale none übergibt keine zusätzlichen Optionen. (--yes und --choice-index 0 werden vom Helper immer hinzugefügt, um die Zahlung zu bestätigen und die bepreiste Vertragsauswahl zu benennen.) Standardmäßig wird hier nichts benötigt — das handle-uri des Wallets wartet bereits, bis die Zahlung einen Endzustand erreicht.

HELPER

(Zeichenkette, Standardwert ``pepsi-helper-auto-pay``) Das privilegierte Wallet-Helper-Binärprogramm (ein Name auf $PATH oder ein absoluter Pfad).

Die folgenden Optionen aktivieren und konfigurieren die Wallet-Self-Service-Rolle (eine lokal eingelieferte Nachricht an die Steueradresse bedient das eigene Wallet des Absenders per E-Mail; siehe pepsi-stage-auto-pay(1)):

RESPONSE_STAGE

(Zeichenkette, optional) Die Stage, bei der die Self-Service-Antwort injiziert wird (sodass sie DKIM-signiert und weitergeleitet wird). Ihr Setzen aktiviert die Self-Service-Rolle; sie nicht zu setzen bedeutet, dass die Stage nur eingehende Forderungen bezahlt.

CONTROL_LOCAL_PART

(Zeichenkette, Standardwert ``pepsi-wallet``) Der Local-Part der Wallet-Steueradresse: eine lokal erzeugte Nachricht an <part>@<served-domain> ist eine Wallet-Steuernachricht.

RESPONSE_FROM

(Zeichenkette, optional) Das From: der Self-Service-Antwort. Standardwert ist <{CONTROL_LOCAL_PART}@{domain}> für die adressierte bediente Domain.

RESPONSE_SUBJECT

(Zeichenkette, Standardwert ``Pepsi wallet``) Das Subject: der Self-Service-Antwort.

Ein manuelles withdraw (Aufladung) benennt den GNU-Taler-Exchange, von dem abgehoben werden soll, in der Anfrage (Subject: withdraw CURRENCY:VALUE EXCHANGE-URL); da ein Wallet mehrwährungsfähig ist und von vielen Exchanges abheben kann, gibt es keine serverseitige Exchange-Option.

Die Stage verwendet außerdem den gemeinsamen [pepsi-origin]-Abschnitt (das Herkunftsnachweis-Geheimnis), um zu verifizieren, dass eine Forderung für Mail ist, die diese Installation tatsächlich gesendet hat; ohne ihn kann keine Forderung verifiziert und keine bezahlt werden (der Self-Service ist davon unberührt). Die gesamte Wallet-Arbeit wird vom setuid-root pepsi-helper-auto-pay(1) erledigt; das Stage-Binärprogramm wird SGID pepsi-wallets installiert, damit sein Worker es ausführen darf.

85.2.1.1.14.15. pepsi-stage-check-whitelist-Optionen

Eine Stage mit PROGRAM = pepsi-stage-check-whitelist liest:

WHITELIST_NAME

(Liste, erforderlich) Die whitelist_name-Gruppen, die in der pepsi.whitelist-Tabelle konsultiert werden — eine kommagetrennte Liste, als ein einziges = ANY(...) abgefragt, kein einzelner Name.

Ein Eintrag darf eine Vorlage sein, die {localpart} oder {login} enthält, was je Umschlagempfänger vor der Abfrage expandiert wird: {localpart} ist der um die Subadresse bereinigte, kleingeschriebene Local-Part und {login} das passwd-Login, zu dem er auflöst. So wird ein mit pepsi-whitelist(1) verwalteter Namensraum je Benutzer — die <login>/segment-Namen — ohne eine Einstellungsüberschreibung je Adresse konsultiert. Zum Beispiel:

WHITELIST_NAME = correspondents, {localpart}/correspondents

konsultiert die gemeinsame Gruppe und die eigene jedes Empfängers.

LOCAL_DOMAINS, TARGETS, RECIPIENT_DELIMITER

(optional) Dieselben Lokalitätsoptionen, mit denselben Standardwerten, wie die Zustell-Stages — hier nur gelesen, um {login} aufzulösen (und für {localpart} eine Subadresse abzustreifen). Nur nötig, wenn eine Vorlage sie verwendet.

NEXT_STAGE

(Zeichenkette, erforderlich) Wohin die Nachricht nach der Prüfung weiterschaltet (ob sie passte oder nicht). Eine Stage ohne NEXT_STAGE meldet zur Laufzeit einen Fehler.

85.2.1.1.14.16. pepsi-stage-auto-whitelist-Optionen

Eine Stage mit PROGRAM = pepsi-stage-auto-whitelist liest:

WHITELIST_NAME

(Zeichenkette, erforderlich) Die whitelist_name-Gruppe, die in der pepsi.whitelist-Tabelle befüllt wird. Sie sollte mit der Gruppe übereinstimmen, die das eingehende pepsi-stage-check-whitelist(1) konsultiert. Ein einzelner wörtlicher Name in der Grammatik der Whitelist-Namen: Diese Stage expandiert keinen {login}/{localpart}-Platzhalter, sodass ein Wert, der einen enthält, abgelehnt wird. Der Operator darf jede Whitelist benennen, einschließlich einer, die alle lokalen Benutzer teilen; ein Wert, den ein Kontoinhaber per Mail über pepsi-stage-edit-settings(1) setzt, muss eine in seinem eigenen <login>/...-Namensraum benennen oder diejenige, die die Konfiguration des Operators für ihn benennt.

DKIM_REQUIRED

(boolesch, optional) Wert, der in der dkim_required-Spalte jedes von dieser Stage eingefügten Datensatzes gespeichert wird. Standardwert yes.

NEXT_STAGE

(Zeichenkette, erforderlich) Wohin die Nachricht weiterschaltet, nachdem die Empfänger festgehalten wurden. Eine Stage ohne NEXT_STAGE meldet zur Laufzeit einen Fehler.

85.2.1.1.14.17. pepsi-stage-autocrypt-learn-Optionen

Eine Stage mit PROGRAM = pepsi-stage-autocrypt-learn liest:

LEARN_KEYS

(boolesch, optional) Das eigene Schlüsselmaterial des Absenders, das in der Nachricht gefunden wird — S/MIME-Signiererzertifikate, application/pgp-keys-Teile und der Autocrypt:-Header —, auf dem inbound-Vertrauensrang speichern, wo es nie stillschweigend einen besser bequellten Schlüssel ersetzen kann. Standardwert YES. Nur Material, das die eigene Adresse des Absenders beansprucht, wird behalten. Es auszuschalten macht die ganze Stage zu einem Durchreicher, LEARN_GOSSIP inbegriffen.

LEARN_GOSSIP

(boolesch, optional) Zusätzlich die Schlüssel der anderen Empfänger aus den Autocrypt-Gossip:-Feldern innerhalb einer verschlüsselt eingetroffenen Nachricht lernen (Autocrypt Level 1 §5.3), auf dem gossip-Rang — dem unteren Ende der Leiter, unterhalb von inbound. Standardwert YES; es tut nichts, sofern nicht auch LEARN_KEYS an ist.

Das ist es, was ein verschlüsseltes Allen-Antworten an einen Korrespondenten möglich macht, von dem man nie direkt Mail hatte. Ein Feld wird nur verwendet, wenn es wirklich im Chiffrat war, nur wenn sein addr in den eigenen To:, Cc: oder Reply-To: der Nachricht erscheint, nie für die eigene Adresse des Absenders und nie für eine Adresse in LOCAL_DOMAINS — niemand darf diesem Host seine eigenen Benutzer vorstellen. Ein gegossipter Schlüssel kann nie einen besser bequellten verdrängen und lässt eine Signatur nie als verifiziert zählen.

Beachten Sie die Asymmetrie zur sendenden Hälfte ([stage-encrypt] AUTOCRYPT_GOSSIP, Standardwert NO): Gossip auszugeben verteilt die Schlüssel Dritter an Korrespondenten weiter, die nicht danach gefragt haben, während es zu lesen nur den eigenen Cache dieses Hosts füllt. Ein Operator, der die Einführungen gespeichert, aber nie verwendet haben möchte, setzt [pepsi-keydiscovery] MIN_TRUST = harvested, statt dies auszuschalten.

LEARN_FROM_SPAM

(boolesch, optional) Ob eine Nachricht, die die Pipeline bereits als Spam bewertet hat (state.spam = true), dennoch einen Schlüssel lehren darf. Standardwert NO, was Autocrypt Level 1 §5.3s „Nachrichten SOLLTEN ignoriert werden …, wenn der MUA die Nachricht für Spam hält“ entspricht.

Es ist eine Option statt einer festen Regel, weil die Überzeugung Pepsis eigene ist: Ein Operator, dessen Spam-Bewertung bewusst locker ist, mag Schlüsselkontinuität der Regel vorziehen. Beachten Sie, dass das Einhalten des Standardwerts erfordert, dass die Stage nach allem platziert wird, was state.spam setzt — siehe pepsi-stage-autocrypt-learn(1).

ACCEPT_ROTATION

(Zeichenkette, optional) Wann die Regel „das Neueste gewinnt“ der Autocrypt-Stufe den gespeicherten inbound/gossip-Schlüssel eines Korrespondenten durch den Schlüssel ersetzen darf, den eine neuere Nachricht trägt. newest (der Standardwert) ist Autocrypt Level 1: Ein strikt neueres effektives Datum genügt. expired verlangt zusätzlich, dass jeder gespeicherte Schlüssel für diese Adresse und dieses Protokoll widerrufen oder abgelaufen ist (nach seiner festgehaltenen Gültigkeit oder seinem expires_at); andernfalls wird der gespeicherte Schlüssel behalten und das Angebot zurückgehalten — auditiert als key.peer.rotate.held und den Empfängern wie eine Rotation gemeldet. Eine Ersetzung durch eine strikt besser eingestufte Quelle wird von dieser Option nicht geregelt. Jeder andere Wert ist ein Konfigurationsfehler. In jedem Fall schreibt jede Rotation eine key.peer.rotate-Audit-Zeile; siehe pepsi-stage-autocrypt-learn(1).

RESPONSE_STAGE

(Zeichenkette, optional) Die Stage, an der die Benachrichtigungen über Schlüsseländerungen eingespeist werden: Wird der Schlüssel eines Korrespondenten rotiert oder zurückgehalten, erhält jeder lokale Umschlagempfänger der auslösenden Nachricht die Vorlage key-rotation.<lang>.body per Mail (Null-Absender, From: postmaster@<domain>). Normalerweise die DKIM-Signier-Stage, wie RESPONSE_STAGE von pepsi-stage-encrypt(1). Muss eine existierende Stage benennen; pepsi-setup(1) verlangt außerdem key-rotation.en.body in [pepsi] TEMPLATE_DIR. Fehlt sie, werden Änderungen auditiert und protokolliert, aber niemand erhält eine Mail.

LOCAL_DOMAINS, TARGETS, RECIPIENT_DELIMITER

(optional) Die geteilten Lokalitätsoptionen. Nur LOCAL_DOMAINS wird herangezogen: um ein Gossip-Feld abzulehnen, das eine von diesem Host bediente Adresse benennt (eine Schlüsselsubstitution statt einer Einführung), und um auszuwählen, welche Umschlagempfänger unsere sind, denen eine Benachrichtigung über Schlüsseländerungen zu schicken ist. Standardwert ist [pepsi-ingress] ACCEPTED_DOMAINS.

NEXT_STAGE

(Zeichenkette, erforderlich) Wohin die Nachricht weiterschaltet, nachdem die Stage gelernt hat, was sie konnte. Die Stage verbraucht nie eine Nachricht, sodass ein fehlendes NEXT_STAGE von pepsi-setup(1) abgelehnt wird und zur Laufzeit einen Fehler ergibt.

85.2.1.1.14.18. pepsi-stage-detect-language-Optionen

Eine Stage mit PROGRAM = pepsi-stage-detect-language liest:

NEXT_STAGE

(Zeichenkette, erforderlich) Wohin die Nachricht nach der Klassifizierung weiterschaltet (ob eine Sprache festgehalten wurde oder nicht). Eine Stage ohne NEXT_STAGE meldet zur Laufzeit einen Fehler.

LANGUAGES

(Liste, optional) Die Kandidatensprachen, als durch Leerraum/Komma getrennte ISO-639-1-Codes (unabhängig von der Groß-/Kleinschreibung); mindestens zwei verschiedene Codes sind erforderlich. Das Token * steht für jede unterstützte Sprache und darf mit expliziten Codes kombiniert werden (die dann zuerst kommen). Die Erkennung gibt nur jemals Sprachen aus dieser Menge zurück, sie sollte also die Sprachen abdecken, die Sie zu empfangen erwarten. Standardwert ist eine breite gängige Menge (en de fr es it pt nl pl ru tr ar zh ja).

Engen Sie sie ein. Jede aktivierte Sprache erhöht den Speicher, den jeder Worker-Prozess verwendet, und — wichtiger — jede Sprache, die Ihr Verkehr nie enthält, konkurriert dennoch um Wahrscheinlichkeit. Die Stage entfernt Nicht-Prosa (URLs, Adressen, base64-Blobs, DNS-Einträge) vor der Klassifikation aus dem Nachrichtentext, was verhindert, dass ein einzelnes solches Token die Antwort rundweg entscheidet; was danach bleibt, ist ein echter Wettstreit zwischen den Kandidaten, und eine Sprache, die Ihnen niemand schreibt, kann ihn bei einer kurzen Nachricht dennoch gewinnen. pepsi-detect-language(1) klassifiziert eine gespeicherte Nachricht gegen eine beliebige Kandidatenmenge neu, sodass eine engere Liste ausprobiert werden kann, bevor sie konfiguriert wird.

85.2.1.1.14.19. pepsi-stage-block-language-Optionen

Eine Stage mit PROGRAM = pepsi-stage-block-language liest:

NEXT_STAGE

(Zeichenkette, erforderlich) Wohin eine Nachricht weiterschaltet, die über THRESHOLD bewertet — und, unter ENFORCEMENT = soft, wohin auch eine markierte Nachricht weiterläuft. Eine Stage ohne NEXT_STAGE meldet zur Laufzeit einen Fehler.

BOUNCE_STAGE

(Zeichenkette, erforderlich, wenn eine Nachricht gebounct werden kann) Wohin eine Nachricht geroutet wird, die auf oder unter THRESHOLD bewertet, damit eine Failure-DSN erzeugt werden kann (typischerweise pepsi-stage-bounce(1)). Nur unter ENFORCEMENT = hard herangezogen; ein Bounce ohne BOUNCE_STAGE meldet zur Laufzeit einen Fehler. Es lohnt sich auch unter soft, es zu setzen, sodass der Wechsel zu hard eine Ein-Wort-Änderung ist.

ENFORCEMENT

(``hard`` | ``soft``, optional) Was mit einer Nachricht geschieht, die die Richtlinie nicht besteht. hard (der Standardwert) routet sie zu BOUNCE_STAGE, sodass sie nicht zugestellt wird. soft stellt sie dennoch zu, markiert: SUBJECT_FLAG_LABEL wird an ihren Subject: angehängt, ein X-Pepsi-Detected-Languages-Header hält fest, was erkannt wurde, und die Nachricht schaltet zu NEXT_STAGE weiter.

soft markiert genau die Nachrichten, die hard gebouncet hätte, was es zu einem Trainingsmodus macht: Lassen Sie es eine Weile laufen, und die Markierungen im Postfach sind eine getreue Vorschau dessen, was die Durchsetzung abweisen würde, ohne Kosten für einen Korrespondenten, für dessen Mail die Listen noch nicht abgestimmt sind. Als gewöhnliche Stage-Option ist es je Adresse überschreibbar (pepsi-settings(1)), sodass ein Konto im Training bleiben kann, während der Rest der Installation durchsetzt.

Beachten Sie, dass die Subject:-Umschreibung die DKIM-Signatur des Absenders und das ARC-AMS dieses Servers bricht (beide übersignieren Subject), genau wie es VACATION_TAG von pepsi-stage-vacation(1) tut — kostenlos auf einem Zweig, der in lokaler Zustellung endet, nicht kostenlos auf einem, der weiterleitet.

SUBJECT_FLAG_LABEL

(Zeichenkette, optional) Die Markierung, die unter ENFORCEMENT = soft an den Subject: einer markierten Nachricht angehängt wird. Standardwert [!LANG]. Nur angehängt, wenn der Betreff sie nicht bereits enthält (ohne Beachtung der Groß-/Kleinschreibung), sodass eine Antwort, die ihn durch die Stage zurückzitiert, keine zweite sammelt. Ein leerer Wert wendet den Standardwert erneut an; es gibt keinen Weg, die Markierung abzuschalten, denn nichts zu markieren ist dasselbe, wie die Stage aus der Pipeline zu lassen.

WHITELIST

(Liste, optional) Sprachen, deren Wahrscheinlichkeit zur Bewertung addiert wird, als durch Leerraum/Komma getrennte ISO-639-1-Codes (unabhängig von der Groß-/Kleinschreibung) plus den optionalen Pseudo-Code none (der auf nicht erkannte Mail passt). Leer, wenn nicht gesetzt. Ein Eintrag darf weitere Subtags tragen (de-CH); jeder Eintrag ist ein Sprach*bereich*, der per einfacher Filterung nach RFC 4647 §3.3.1 abgeglichen wird, sodass de auch ein erkanntes de-CH trifft, während de-CH kein bloßes de trifft.

BLACKLIST

(Liste, optional) Sprachen, deren Wahrscheinlichkeit von der Bewertung subtrahiert wird, gleiche Syntax wie WHITELIST. Leer, wenn nicht gesetzt. Eine Sprache darf in höchstens einer der beiden Listen erscheinen.

Mindestens eine der beiden Listen muss nicht leer sein: Sind beide leer, erhält jede Nachricht die Bewertung 0.0, was die strikte Schranke score > THRESHOLD dann nicht besteht, sodass die Stage alle Mail mit einem Bounce versähe (oder markierte). Die Konfiguration wird zurückgewiesen statt angenommen, und sie zurückzuweisen ist das, was verhindert, dass „die Listen fülle ich später“ zu einem stillen Ausfall wird.

THRESHOLD

(Gleitkommazahl, optional) Die Bewertung, die eine Nachricht überschreiten muss, um weiterzuschalten. Standardwert ist 0.0.

85.2.1.1.14.20. pepsi-stage-vacation-Optionen

Eine Stage mit PROGRAM = pepsi-stage-vacation beantwortet Mail, die eintrifft, während der Umschlagempfänger abwesend ist. Jede Option unten ist je Adresse überschreibbar, und so ist die Funktion gedacht: Der INI-Abschnitt ist der Standardwert des Operators (kein Urlaub), und die Urlaubsdaten jedes Benutzers — und, wenn er will, sein eigener Nachrichtentext — kommen aus seinem pepsi.settings-Datensatz oder aus einem config_override-Geltungsbereich. Siehe pepsi-stage-vacation(1).

NEXT_STAGE

(Zeichenkette, erforderlich) Wohin die Nachricht weiterläuft. Sie tut es immer: Diese Stage fügt eine Antwort hinzu, sie verbraucht nie eine Nachricht. pepsi-setup(1) lehnt eine Stage ohne sie ab.

RESPONSE_STAGE

(Zeichenkette, erforderlich) Wohin die Urlaubsnotiz als neue Nachricht mit Null-Absender injiziert wird, sodass sie signiert und weitergeleitet wird (typischerweise die DKIM-Signier-Stage). pepsi-setup(1) prüft, dass es eine existierende Stage benennt.

VACATION_RANGES

(Liste, optional) Kommagetrennte YYYY-MM-DD:YYYY-MM-DD-Spannen von Tagen, an denen der Empfänger abwesend ist. Beide Endpunkte sind inklusive ganze Tage in der Zeitzone des Servers; ein leeres Ende (2026-08-01:) ist ein offener Urlaub, und ein bloßes Datum ist dieser eine Tag. Leer, wenn nicht gesetzt, was die Stage für diese Adresse ausschaltet — der Standardwert und der Zustand jedes Empfängers, der nie einen Urlaub konfiguriert hat. Eine Spanne, deren Ende vor ihrem Anfang liegt, wird abgelehnt.

DEFAULT_LANGUAGE

(Zeichenkette, optional) Die Sprache, deren Nachricht verwendet wird, wenn keine der erkannten Sprachen des Absenders (state.language) eine hat. Standardwert en. Mit beliebigem Trenner geschrieben: pt_br und pt-BR sind dasselbe Tag.

DEFAULT_MESSAGE_SECTION

(Zeichenkette, optional) Der Konfigurationsabschnitt, der eine Inline-Nachrichtenvorlage je Sprache enthält, als <LANG> = <template>. Standardwert pepsi-vacation-default-message, das mit zehn Sprachen in ${DATADIR}/config.d ausgeliefert wird. Eine MESSAGE_<LANG>-Option je Adresse dieses Abschnitts hat je Sprache Vorrang davor.

EMERGENCY_CONTACT

(Adresse, optional) Eine einzelne bloße Adresse, die der Nachrichtenvorlage als {{EMERGENCY_CONTACT}} angeboten wird. Standardmäßig nicht gesetzt, in welchem Fall der {{#EMERGENCY_CONTACT}}-Block einer Vorlage übersprungen wird. Ein Anzeigename oder eine Adressliste wird abgelehnt.

VACATION_TAG

(Zeichenkette, optional) An den Subject: der weitergeleiteten Nachricht angehängt, wenn eine Notiz gesendet wurde, sodass der Empfänger sehen kann, welche Mail für ihn beantwortet wurde. Standardwert [VACATION]; der Sentinel-Wert none deaktiviert das Markieren. Ein leerer Wert tut es nicht — der Parser liest eine leere Option als abwesend, was den Standardwert erneut anwendet. Das Anhängen ist idempotent.

SUPPRESS_DAYS

(ganzzahlig, optional) Wie lange nach der Antwort an einen Korrespondenten dieser erneut beantwortet werden darf. Standardwert 7 (der vacation-Standardwert von Sieve, RFC 5230 §4.1); 0 beantwortet jede Nachricht. Darf 3650 (zehn Jahre) nicht überschreiten — der Wert wird zu einem SQL-Intervall, das von now() subtrahiert wird, und ein größerer schiebt das Ergebnis aus dem timestamptz-Bereich, was jede Nachricht an die Adresse fehlschlagen ließe statt der Konfiguration, die ihn gesetzt hat.

REQUIRE_ADDRESSED_TO

(boolesch, optional) Nur antworten, wenn der Empfänger in To: oder Cc: erscheint (RFC 3834 §3), sodass eine Blindkopie oder eine Rundsendung an eine abgegriffene Liste keine Antwort auslöst. Standardwert yes.

SUBJECT_PREFIX

(Zeichenkette, optional) Dem ursprünglichen Betreff vorangestellt, um den Betreff der Notiz zu bilden. Standardwert Auto: (RFC 5230 §4.5). Eine Nachricht ohne Betreff ergibt allein das Präfix, und ein bereits präfigierter Betreff wird nicht zweimal präfigiert.

85.2.1.1.14.21. pepsi-stage-secretary-Optionen

Eine Stage mit PROGRAM = pepsi-stage-secretary hält Mail von Absendern zurück, die keine Whitelist kennt, und bittet sie, per Antwort zu bestätigen (Confirm-to-Send). Jede der folgenden Optionen ist adressbezogen überschreibbar, sodass ein Benutzer seinen eigenen Challenge-Text oder PENALTY festlegen kann. Siehe pepsi-stage-secretary(1).

NEXT_STAGE

(Zeichenkette, erforderlich) Wo auf der Whitelist stehende, bestätigte und nie rückgefragte Mail (ein Bounce, lokal eingelieferte Mail) weiterläuft.

RESPONSE_STAGE

(Zeichenkette, erforderlich) Wohin die Challenge und der Bestätigungshinweis als neue Nachrichten mit Null-Absender injiziert werden (typischerweise die DKIM-Signier-Stage).

BOUNCE_STAGE

(Zeichenkette, optional) Der Zeitüberschreitungspfad: wohin zurückgehaltene Mail geht, wenn niemand rechtzeitig bestätigt hat, die Challenge gebounct ist oder state.spam true ist. Nicht gesetzt wird solche Mail gelöscht.

UNCHALLENGEABLE_STAGE

(Zeichenkette, optional) Wohin Mail geht, die nicht rückgefragt werden darf: RFC 3834 sagt, sie nicht zu beantworten, ihr From: ist nicht der Umschlagsabsender, der Absender ist nicht authentifiziert, oder das Tageskontingent des Absenders ist aufgebraucht. Nicht gesetzt nimmt sie den Zeitüberschreitungspfad.

WHITELIST_NAME

(Zeichenkette, erforderlich) Die eine Whitelist, in die ein bestätigter Absender geschrieben wird; darf eine {login}/{localpart}-Vorlage sein, die je Empfänger expandiert wird wie bei pepsi-stage-check-whitelist(1). Eine Liste von Namen wird abgelehnt. Der Operator darf jede Whitelist benennen; ein Wert, den ein Kontoinhaber per Mail über pepsi-stage-edit-settings(1) setzt, muss eine in seinem eigenen <login>/...-Namensraum benennen oder diejenige, die die Konfiguration des Operators für ihn benennt.

CONTROL_LOCAL_PART

(Zeichenkette, optional) Lokaler Teil der Antwortadresse <CONTROL_LOCAL_PART>-<cookie>@<domain>. Standardwert secretary; höchstens 30 ASCII-Buchstaben, Ziffern, ., _ oder -.

HOLD_TIME

(Dauer, optional) Wie lange zurückgehaltene Mail wartet. Standardwert 120 h; nur die Einheiten h, m und s.

REQUIRE_AUTHENTICATED

(boolesch, optional) Nur einem Absender eine Challenge senden, dessen SPF- oder DMARC-Prüfung bestanden wurde. Standardwert yes.

MAX_CHALLENGES_PER_SENDER

(ganzzahlig, optional) Challenges, die an eine Adresse pro 24 Stunden gesendet werden dürfen, über alle Whitelists hinweg. Standardwert 5; 0 bedeutet keine Begrenzung.

DKIM_REQUIRED

(auto|yes|no, optional) Das dkim_required der Whitelist-Zeile, die eine Bestätigung schreibt. auto (der Standardwert) macht es erforderlich, wenn irgendeine für die Challenge zurückgehaltene Nachricht DKIM (oder ARC mit DMARC) bestanden hat.

CONFIRM_NOTICE

(boolesch, optional) Einem bestätigten Absender mitteilen, dass seine Mail zugestellt wurde. Standardwert no.

PENALTY

(Zeichenkette, optional) Was der Absender zu zahlen zusagt, falls seine Nachricht unerwünscht war; der Vorlage als {{PENALTY}} angeboten. Standardmäßig nicht gesetzt.

SUBJECT_HINT_LENGTH

(ganzzahlig, optional) Zeichen des Betreffs der zurückgehaltenen Nachricht, die die Challenge zitiert. Standardwert 8; 0 lässt den Hinweis weg; höchstens 64.

TEMPLATE

(Zeichenkette, optional) Basisname der <TEMPLATE>.<lang>.body-Challenge-Vorlagen unter [pepsi] TEMPLATE_DIR. Standardwert secretary-challenge.

SUBJECT

(Zeichenkette, optional) Der Betreff der Challenge, wenn kein SUBJECT_<LANG> zur gewählten Sprache passt. Standardwert Please confirm your message to {{RECIPIENT}}.

DEFAULT_LANGUAGE

(Zeichenkette, optional) Die Sprache, die verwendet wird, wenn keine der erkannten Sprachen des Absenders einen Text hat. Standardwert en. pepsi-setup(1) verlangt dafür eine Vorlage oder ein MESSAGE_<LANG>.

MESSAGE_<LANG>, SUBJECT_<LANG>, CONFIRM_MESSAGE_<LANG>

(Zeichenkette, optional) Sprachspezifischer Challenge-Text, Challenge-Betreff und Bestätigungstext, die die Vorlagen nur für diese Sprache überschreiben.

LOCAL_DOMAINS, TARGETS, RECIPIENT_DELIMITER

(optional) Die gemeinsamen Lokalitätsoptionen (pepsi-stage-relay-to-maildir(1)): an welchen Domains eine Antwortadresse liegen darf und wie die Platzhalter in Whitelist-Namen expandiert werden. LOCAL_DOMAINS hat den Standardwert [pepsi-ingress] ACCEPTED_DOMAINS.

85.2.1.1.14.22. pepsi-stage-if-Optionen

Eine Stage mit PROGRAM = pepsi-stage-if verzweigt anhand eines Mitglieds des state-JSON der Nachricht:

STATE_PATH

(Zeichenkette, erforderlich) Der punktgetrennte Pfad in das Nachrichten-state, dessen Wert getestet wird (Objektschlüssel und ganzzahlige Array-Indizes, z. B. spam, auth.dkim, dsn.rcpt.0.notify).

VALUE

(Zeichenkette, erforderlich, nicht leer) Der Wert, mit dem das Mitglied bei STATE_PATH verglichen wird, nach seiner natürlichen Skalar-Textform (Zeichenkette, true/false, Dezimalzahl oder null). Eine leere Option gilt als nicht gesetzt.

TRUE_STAGE

(Zeichenkette, erforderlich) Wohin die Nachricht weiterschaltet, wenn der Wert gleich VALUE ist. pepsi-setup(1) prüft, dass es eine existierende Stage benennt.

FALSE_STAGE

(Zeichenkette, erforderlich) Wohin die Nachricht andernfalls weiterschaltet (der Wert weicht ab, der Pfad fehlt oder er löst auf ein Array/Objekt auf). pepsi-setup(1) prüft, dass es eine existierende Stage benennt.

85.2.1.1.14.23. pepsi-stage-milter-Optionen

Eine Stage mit PROGRAM = pepsi-stage-milter übergibt die Nachricht an einen bestehenden Milter-Daemon (das Mailfilter-Protokoll von sendmail/Postfix) und routet sie nach dem Urteil des Filters. Siehe pepsi-stage-milter(1), und beachten Sie insbesondere, dass der Filter nach der Warteschlange läuft, sodass ein REJECT einen Bounce kostet, wo ein MTA innerhalb der SMTP-Sitzung mit 5xx geantwortet hätte.

SOCKET

(Zeichenkette, erforderlich) Wo der Milter-Daemon lauscht, in sendmails S=-Grammatik (die Postfix ebenfalls annimmt): unix:/path (oder sein Synonym local:/path), inet:host:port, inet:port@host, inet6:[addr]:port oder inet6:port@addr. Ein bloßer Pfad ohne Schema wird abgelehnt. Pepsi verbindet sich mit diesem Socket; es startet, stoppt oder sperrt den Daemon dahinter nie ein.

MILTER_NAME

(Zeichenkette, optional) Wird dem Filter als Makro {daemon_name} exportiert und in Log-Meldungen verwendet. Standardwert ist der eigene Name der Stage.

ACCEPT_STAGE

(Zeichenkette, optional) Wohin SMFIR_ACCEPT die Nachricht schickt. Standardwert ist NEXT_STAGE, was Annehmen und Fortfahren zur selben Sache macht; setzen Sie es, um am Rest einer Filterkette vorbeizuspringen, was Postfix‘ Milter-Liste nativ tut. pepsi-setup(1) prüft, dass es eine existierende Stage benennt.

REJECT_STAGE

(Zeichenkette, optional) Wohin SMFIR_REJECT die Nachricht schickt und wohin einzeln abgelehnte Empfänger aufgefächert werden. Standardwert ist das BOUNCE_STAGE des Abschnitts. Richten Sie es auf ein pepsi-stage-discard(1), um abgelehnte Mail zu verwerfen, statt sie zu bouncen. pepsi-setup(1) prüft, dass es eine existierende Stage benennt.

QUARANTINE_STAGE

(Zeichenkette, optional) Wohin SMFIR_QUARANTINE die Nachricht schickt. Ungesetzt bedeutet verwerfen: Pepsi hat keinen Quarantänespeicher, nur eine Route. Eine Quarantäneanforderung entscheidet das Routing unabhängig vom darauf folgenden Urteil, denn ein sendmail-Milter stellt unter Quarantäne und gibt danach dennoch ein Accept zurück. pepsi-setup(1) prüft, dass es eine existierende Stage benennt.

ON_FAILURE

(``tempfail``/``accept``/``reject``/``discard``, Standardwert ``tempfail``) Was zu tun ist, wenn der Milter nicht erreicht werden kann, Zeitüberschreitungen hat oder etwas Unparsbares spricht — Postfix‘ milter_default_action, mit demselben Standardwert. tempfail pausiert die Nachricht zur Wiederholung, sodass ein ausgefallener Filter Mail verzögert, statt sie zu verlieren oder ungefiltert durchzulassen. Eine Nachricht, die nach MAX_LIFETIME noch immer zurückgestellt ist (auf diesem Weg oder durch das eigene SMFIR_TEMPFAIL des Filters), geht an das BOUNCE_STAGE des Abschnitts oder bleibt, wenn es keines gibt, für pepsi-failure-bouncer(1) failed — nie an REJECT_STAGE, das Mail stillschweigend verwerfen kann.

ALLOW_ACTIONS

(Zeichenkette, Standardwert ``addhdrs chghdrs chgbody``) Die dem Filter angebotenen SMFIF_*-Änderungsaktionen, leerraum- oder kommagetrennt: addhdrs, chghdrs, chgbody, addrcpt, delrcpt, addrcpt_par, chgfrom, quarantine; dazu die Kurzformen all und none. Es gibt kein inshdr: libmilter bindet auch das Einfügen von Headern an SMFIF_ADDHDRS.

Ohne Sandbox um den Filter herum ist diese Maske der eine verfügbare Hebel auf den Wirkungsradius, und der Standardwert ist dort, wo er sich bezahlt macht: Jeder Inhaltsfilter arbeitet darunter, während einem Filter, der den Umschlag umschreiben will, das ausdrücklich gewährt werden muss. Ein Filter, der eine nicht angebotene Aktion verlangt, wird namentlich gemeldet und nimmt den ON_FAILURE-Pfad, statt seine Änderungen stillschweigend verworfen zu bekommen, wie Postfix sie verwirft.

SMFIF_SETSYMLIST ist bewusst nicht aufgeführt und braucht keine Gewährung: Es autorisiert keine Änderung an der Nachricht.

PROTOCOL_VERSION

(ganzzahlig 2–6, Standardwert 6) Die höchste angebotene Milter-Protokollversion; der Filter handelt von ihr abwärts. Postfix‘ milter_protocol.

CONNECT_TIMEOUT

(Dauer, Standardwert ``30 s``) Schranke für das Herstellen der Verbindung und das Abschließen der Optionsaushandlung — beide Hälften von „ist dieser Filter überhaupt erreichbar“. Postfix‘ milter_connect_timeout.

COMMAND_TIMEOUT

(Dauer, Standardwert ``30 s``) Schranke für die Antwort auf einen einzelnen Befehl bis zum Ende des Nachrichtentexts. Postfix‘ milter_command_timeout.

CONTENT_TIMEOUT

(Dauer, Standardwert ``300 s``) Schranke für das Urteil am Nachrichtenende, wo ein Inhaltsfilter seine eigentliche Arbeit tut. Ein SMFIR_PROGRESS vom Filter startet die Uhr neu. Postfix‘ milter_content_timeout.

Jeder der drei Timeouts muss größer als null und höchstens 24 h sein.

RETRY_INITIAL / RETRY_MAX_INTERVAL / RETRY_FACTOR / MAX_LIFETIME

(Dauern / Zahl, optional) Der geteilte Wiederholungsplan für den Tempfail-Pfad, mit derselben Bedeutung wie in den Relay-Stages. Standardwerte: 300 s, 1 h, 2, 120 h.

MACROS_CONNECT / MACROS_HELO / MACROS_MAIL / MACROS_RCPT / MACROS_DATA / MACROS_EOH / MACROS_EOM

(Zeichenkette, optional) Die in jeder Protokollphase exportierten sendmail-Makros, leerraum- oder kommagetrennt. Die Standardwerte sind die von Postfix, sodass die eigene Dokumentation eines Filters unverändert gilt: j {daemon_name} {daemon_addr} v _, {tls_version} {cipher} {cipher_bits} {cert_subject} {cert_issuer}, i {auth_type} {auth_authen} {auth_author} {mail_addr} {mail_host} {mail_mailer}, i {rcpt_addr} {rcpt_host} {rcpt_mailer} und i für die übrigen drei. Ein Makro, dessen Wert diese Installation nicht kennt, wird überhaupt nicht gesendet. Setzen Sie eine Liste auf den Sentinel none, um in dieser Phase nichts zu exportieren — ein leerer Wert liest sich als abwesend und wendet den Standardwert erneut an. Ein Filter, der mit SMFIF_SETSYMLIST seine eigene Liste benennt, überschreibt diese.

85.2.1.1.14.24. pepsi-stage-route-Optionen

Eine Stage mit PROGRAM = pepsi-stage-route wählt für jeden Umschlagempfänger eine nächste Stage anhand der Domain dieses Empfängers und teilt die Nachricht auf Geschwisterdatensätze auf, wenn die Empfänger uneinig sind. Sie existiert für ein Gateway, das vor einem anderen Mailsystem sitzt (siehe das Kapitel „Microsoft Exchange als Gateway“ des Handbuchs): Die Domains hinter einem solchen Gateway sind genau die Domains, deren öffentlicher MX das Gateway ist, sodass eine von ihnen zu einem Direkt-zum-MX-Relay zu routen eine Mail-Schleife ist statt eines Zustellfehlschlags.

Die Abfragereihenfolge je Empfänger ist ROUTES, dann die Menge der verwalteten Domains, dann NEXT_STAGE.

ROUTES

(Zeichenkette, optional) Leerraum- oder kommagetrennte <domain-pattern>=<stage>-Paare, zuerst und in der geschriebenen Reihenfolge herangezogen. Muster werden ohne Beachtung der Groß-/Kleinschreibung abgeglichen und dürfen * enthalten, das auf eine beliebige Zeichenfolge passt; sie sind Globs, keine regulären Ausdrücke, und an beiden Enden verankert, sodass *.example.org auf mail.example.org passt, aber weder auf example.org noch auf mail.example.org.evil.test. Ein Wert, der wie ein regulärer Ausdruck aussieht, wird abgelehnt, statt stillschweigend auf nichts zu passen. Explizite Regeln werden vor der verwalteten Menge herangezogen, sodass eine Subdomain herausgeschnitten werden kann, ohne ihr Elternteil aus MANAGED_DOMAINS zu entfernen.

MANAGED_DOMAINS

(Zeichenkette, optional) Die Domains hinter diesem Gateway, leerraum- oder kommagetrennt, *-Globs erlaubt. Standardwert ist [pepsi-ingress] ACCEPTED_DOMAINS, sodass die Menge nicht von dem abdriften kann, was der Ingress tatsächlich annimmt. Mindestens eine Domain muss sich aus einer der beiden Quellen ergeben.

MANAGED_STAGE

(Zeichenkette, optional) Wohin ein Empfänger an einer verwalteten Domain geht — in einer Gateway-Installation die Stage, die zum dahinterliegenden System weiterleitet. Ohne sie nehmen verwaltete Empfänger NEXT_STAGE, wovon pepsi-setup(1) dann nachweisen muss, dass es keine Schleife ist.

NEXT_STAGE

(Zeichenkette, erforderlich) Wohin jeder andere Empfänger geht. Erforderlich: Die Stage stellt nie zu, bounct nie und verwirft nie eine Nachricht, sodass jeder Empfänger irgendwohin muss.

RECIPIENT_CHECK

(``none``, ``probe`` oder ``map``, optional) Wie pepsi-ingress(1) erfahren kann, ob eine Adresse an einer verwalteten Domain auf dem System hinter dem Gateway existiert, sodass es eine unbekannte zum RCPT-Zeitpunkt ablehnen kann (siehe [pepsi-ingress] VERIFY_RECIPIENTS). Die Route selbst liest sie nie; sie steht hier, weil dieser Abschnitt das Backend beschreibt. Nur zusammen mit MANAGED_STAGE verwendet.

none (der Standard) lässt die verwalteten Domains unverifiziert: Jede Adresse wird angenommen, und der eigene Bounce des Backends ist die Antwort. probe fragt das Backend: MAIL FROM:<>, RCPT TO, RSET, ohne dass eine Nachricht gesendet wird. Nur eine 5.1.x-Ablehnung (oder ein bloßes 550) zählt als „kein solcher Benutzer“. Alles andere — das Backend nicht erreichbar, eine Zurückstellung, ein volles Postfach — nimmt an. Antworten werden zwischengespeichert, ein „ja“ eine Stunde lang und ein „nein“ fünf Minuten lang. Ein Backend, das jede Adresse annimmt und später bounct (Exchange mit ausgeschalteter Empfängerfilterung), antwortet immer „ja“; für ein solches Backend verwenden Sie map, das die gültigen Adressen aus RECIPIENT_MAP liest.

PROBE_HOST, PROBE_PORT, PROBE_TLS, PROBE_TIMEOUT

(optional; PROBE_HOST für ``probe`` erforderlich) Wohin und wie geprobt wird: der Hostname oder die Adresse des Backends, sein Port (Standard 25), opportunistic (der Standard), starttls, tls oder none, und das Timeout je Befehl (Standard 10 s). Die Probe trägt eine Adresse, nie eine Nachricht, daher akzeptiert opportunistisches TLS jedes Zertifikat, wie es die Zustellung an einen MX tut; starttls und tls verifizieren es.

RECIPIENT_MAP

(Pfad; für ``map`` erforderlich) Die gültigen Adressen, eine pro Zeile: eine Adresse oder @domain für jede Adresse an einer Domain. Alles nach dem ersten Wort wird ignoriert, sodass die Quelldatei einer Postfix-Tabelle relay_recipient_maps (alice@example.org OK) unverändert verwendet werden kann. # leitet einen Kommentar ein. Die Datei wird bei jeder Prüfung gelesen. Lässt sie sich nicht lesen, wird jede Adresse angenommen.

pepsi-setup(1) prüft, dass jedes Ziel eine existierende Stage benennt, und lehnt eine Konfiguration ab, in der eine Nachricht für eine verwaltete Domain pepsi-stage-relay-to-internet(1) erreichen könnte — indem es über NEXT_STAGE und etwaige weitere Routing-Stages vorwärtsläuft, aber bewusst nicht über BOUNCE_STAGE (ein Bounce ist eine neue Nachricht über eine bereits gescheiterte Zustellung und erreicht rechtmäßig ein Relay).

85.2.1.1.14.25. pepsi-stage-aliases-Optionen

Eine Stage mit PROGRAM = pepsi-stage-aliases expandiert die Umschlagempfänger einer Nachricht über eine Alias-Zuordnungsdatei, bevor sie sie weiterleitet:

ALIASES

(Zeichenkette, erforderlich) Die Alias-Map-Datei — ein wörtlich genommener Dateisystempfad, der also anders als eine Option vom Typ Pfad nicht $-expandiert wird —, wie eine Postfix-virtual(5)-Tabelle geparst: Jede Zeile bildet einen Schlüssel (eine Volladresse, einen @domain-Catch-All oder ein *-Wildcard wie sales-*@example.org) auf eine oder mehrere durch Komma/Leerraum getrennte Zieladressen ab; #-Kommentare und Leerzeilen werden ignoriert. Empfänger, die auf einen Schlüssel passen, werden durch seine Ziele ersetzt (transitiv, mit einem Schleifenschutz) und das Ergebnis dedupliziert; bei konkurrierenden Wildcards gewinnt der spezifischste Treffer. Die Datei wird nur dann neu gelesen, wenn ihre Änderungszeit sich ändert; eine fehlende Datei wird als leere Map behandelt. pepsi-setup(1) prüft sie zur Installationszeit auf Syntax, wenn vorhanden. Siehe pepsi-stage-aliases(1).

NEXT_STAGE

(Zeichenkette, erforderlich) Wohin die (expandierte) Nachricht weiterschaltet. pepsi-setup(1) prüft, dass es eine existierende Stage benennt.

85.2.1.1.14.26. pepsi-stage-edit-settings-Optionen

Eine Stage mit PROGRAM = pepsi-stage-edit-settings liest:

EDITABLE_STAGES

(Liste, erforderlich) Durch Leerraum/Komma getrennte Stage-Namen, deren Optionen eine Steuer-E-Mail ändern darf. Mindestens einer ist erforderlich, jeder muss eine bestehende Stage benennen (pepsi-setup(1) prüft das), und ein Nachrichtentext, der eine hier nicht aufgeführte Stage anspricht, wird abgelehnt.

RESPONSE_STAGE

(Zeichenkette, erforderlich) Stage, bei der die Antwort injiziert wird (typischerweise der Beginn des ausgehenden Signier-/Relay-Pfads), sodass sie DKIM-signiert und zugestellt wird. Muss auf eine existierende Stage auflösen.

NEXT_STAGE

(Zeichenkette, erforderlich) Wohin eine Nicht-Steuernachricht weitergeschaltet wird. Eine Stage ohne NEXT_STAGE meldet zur Laufzeit bei der ersten gewöhnlichen Nachricht einen Fehler.

SUBJECT

(Zeichenkette, optional) Der genaue Betreff, der eine Steuernachricht kennzeichnet, und der Betreff der Antwort. Standardwert Pepsi.

CONTROL_LOCAL_PART

(Zeichenkette, optional) Local-Part der Steueradresse. Standardwert pepsi.

RESPONSE_FROM

(Zeichenkette, optional) From:-Header der Antwort. Standardwert <CONTROL_LOCAL_PART@domain> für die kontrollierte Domain, an die die Nachricht adressiert war.

UNRESTRICTED_UNSAFE_STAGES

(boolesch, optional) Hebt die Sicherheitsbeschränkung dessen auf, was eine Steuer-E-Mail setzen darf. Standardwert NO.

Mit dem Standardwert werden zwei Dinge abgelehnt, wie freizügig EDITABLE_STAGES auch sein mag. Eine Zuweisung, die das PROGRAM einer Stage setzt, wird nur angenommen, wenn der Wert ein bloßer pepsi-stage-*-Befehl ohne Pfadanteil ist, sodass ein Kontoinhaber keine seiner bearbeitbaren Stages auf eine beliebige ausführbare Datei richten kann; und eine Zuweisung, die eine Identitäts-Option setzt — SIGNING_DOMAIN, das die From:-Domain der Nachricht überschreibt und die Mail eines Kontos daher als jede Domain signieren ließe, für die dieser Host einen Schlüssel hält —, wird rundweg abgelehnt, da es keinen sicheren Wert gibt, den man zulassen könnte. Dies auf YES zu setzen entfernt beide Prüfungen — die Option ist nach dem benannt, was sie tut, und es gibt keinen Grund, sie einzuschalten, der nicht damit beginnt, jeder Adresse zu vertrauen, deren Überschreibungen bearbeitbar sind.

85.2.1.1.14.27. pepsi-stage-vks-confirm-Optionen

Eine Stage mit PROGRAM = pepsi-stage-vks-confirm folgt dem Bestätigungslink in der Adressverifikationsmail eines Keyservers, sodass ein hochgeladener Schlüssel nach Adresse auffindbar wird. Sie sitzt auf dem eingehenden Pfad und schaltet alles, worauf sie nicht reagiert — nahezu alle Mail —, unangetastet weiter. Siehe pepsi-stage-vks-confirm(1) für die vollständige Liste der Bedingungen, die sie prüft, bevor sie irgendetwas abholt.

NEXT_STAGE

(Zeichenkette, erforderlich) Wohin jede Nachricht geht, die diese Stage nicht verbraucht. Erforderlich statt optional: Eine Stage auf dem eingehenden Pfad, die stillschweigend verwürfe, was sie nicht erkennt, verlöre gewöhnliche Mail. pepsi-setup(1) prüft, dass es eine existierende Stage benennt.

VKS_HOST

(Zeichenkette, optional) Der eine Host, von dem eine Verifikationsmail kommen und auf den ein Link zeigen darf. Standardwert ist der Host von [pepsi-keys] VKS_SERVER, und pepsi-setup(1) lehnt jeden anderen Host ab: Uploads gehen an diesen Server, sodass dessen Verifikationsmail die einzige Art ist, auf die hin zu handeln die Stage existiert. Exakt abgeglichen: Eine Subdomain eines Keyservers ist nicht der Keyserver. Nur wegen dieses Rückfalls optional — ohne diese Option und ohne einen VKS_SERVER-Host verweigert die Stage den Start, da sie die Mail eines Keyservers von der irgendeines anderen nicht unterscheiden kann.

MAX_LINKS

(ganzzahlig, optional) Wie viele Links eine Nachricht kosten darf. Standardwert 3, Minimum 1 (0 wird abgelehnt: Um überhaupt keinen Links zu folgen, nehmen Sie die Stage aus der Pipeline). Eine echte Verifikationsmail trägt einen; die Schranke ist das, was verhindert, dass eine Nachricht, die an jeder anderen Prüfung vorbeikam, zu einer beliebigen Anzahl von Anfragen wird.

DISCARD_CONFIRMED

(boolesch, optional) Ob eine Bestätigungsmail, auf die die Stage reagiert hat, gelöscht statt zugestellt wird. Standardwert YES: Es ist Maschinenmail über eine Handlung, die Pepsi vorgenommen hat, gerichtet an ein Postfach, dessen Eigentümer nicht darum gebeten hat, und sie ist bereits abgearbeitet, wenn sie ankäme. Gelöscht wird nur eine Mail, nach der mindestens eine Identität als veröffentlicht verifiziert wurde; wenn das Folgen ihrer Links nichts verifiziert hat, wird sie trotzdem zugestellt.

REQUIRE_AUTHENTICATION

(boolesch, optional) Ob SPF oder DMARC bestanden haben muss, nicht bloß der Umschlagabsender VKS_HOST entsprechen muss. Standardwert YES. Beachten Sie, dass ein DKIM-Bestehen dies bewusst nicht erfüllt: Es sagt, dass eine Signatur durchging, nicht wessen.

Es gibt kein BOUNCE_STAGE: Die Stage lässt eine Nachricht nie fehlschlagen.

85.2.1.1.15. Der Abschnitt [pepsi-dispatch]

Optionen für pepsi-dispatch(1). Die Worker-Pool-Dimensionierung pro Stage (PARALLELISM, MAX_MESSAGES, QUEUE_LIMIT) liegt in jedem [stage-<name>]-Abschnitt oben, nicht hier. Jede Dauer unten muss größer als null und höchstens 168 h sein; pepsi-setup(1) und der Dispatcher lehnen alles andere ab.

CONFIG_FILE

(Pfad, optional) Die Konfigurationsdatei, die gestarteten Workern über -c übergeben wird. Setzen Sie sie auf den Pfad dieser Datei, wann immer der Dispatcher mit einem expliziten -c gestartet wird (der geladene Pfad kann sonst nicht wiederhergestellt werden); wenn nicht gesetzt, verwenden Worker die Standard-Konfigurationssuche.

POLL_INTERVAL

(Dauer, optional) Sicherheitsnetz-Herzschlag: die längste Zeit, die der Dispatcher schläft, wenn kein früherer paused-Wiederholungsversuch, kein Worker-Abbau und kein Spawn-Cooldown fällig ist; danach sucht er erneut nach Arbeit und reiht fällige paused-Datensätze wieder ein. Standard 30 s. Es ist eine absolute Frist, keine Ruhephase: Nachrichtenverkehr und ein kürzeres STATS_INTERVAL verschieben sie nicht, sodass paused-Datensätze auch bei einer beschäftigten Pipeline rechtzeitig wieder eingereiht werden.

MAX_RUNTIME

(Dauer, optional) Maximale Echtzeit, die ein Worker für eine einzelne Nachricht verbringen darf. Ein Worker, der sie überschreitet, wird beendet (und ersetzt) und die Nachricht auf timeout gesetzt. Standardwert 300 s.

WORKER_IDLE_TIMEOUT

(Dauer, optional) Wie lange ein untätiger Worker-Prozess behalten wird, bevor er gestoppt wird. Die Gesamtnebenläufigkeit wird pro Stage gesetzt (PARALLELISM), nicht global. Standardwert 5 s.

STATS_INTERVAL

(Dauer, optional) Wie oft die In-Memory-Pipeline-Statistiken (von pepsi-httpd(1) unter /metrics exportiert) in einer einzigen Transaktion in die Datenbank weggeschrieben werden. Außerdem weggeschrieben, sobald die Pipeline untätig wird (höchstens einmal pro Sekunde), und beim Herunterfahren; ein untätiger Dispatcher, der nichts Neues festzuhalten hat, schreibt nichts. Standardwert 60 s.

DB_POOL_SIZE

(Zahl, optional) Maximale Anzahl von PostgreSQL-Verbindungen im Datenbankpool des Dispatchers. Anders als ein Einzelverbindungs-Stage-Worker verarbeitet der Dispatcher die Ergebnisse vieler Worker (deren Nachrichten weiterschalten/fehlschlagen lassen) nebenläufig mit seinen eigenen Koordinator-Abfragen, daher hält er einen kleinen begrenzten Pool. Die Arbeit pro Anweisung ist kurz, sodass eine Handvoll Verbindungen starke Worker-Fluktuation aufnimmt. Standardwert ist 8; erhöhen Sie es nur, wenn der Koordinator verbindungsausgehungert ist, und halten Sie die Summe der Pools jeder Komponente unter dem max_connections von PostgreSQL.

FAIR_SCHEDULING

(boolesch, optional) Verteilt die Worker-Zeit jeder Stage fair unter den Absendern (dem authentifizierten Konto, sonst der verbindenden Adresse, eine IPv6-Adresse nach /64; siehe den Absatz über faires Scheduling zwischen Absendern in pepsi-dispatch(1)), statt strikt die ältesten zuerst zu beanspruchen, sodass der Burst eines Absenders nicht alle hinter ihm Eingereihten verzögert. Standardwert yes; no stellt die Reihenfolge „älteste zuerst“ wieder her.

FAIR_HALF_LIFE

(Dauer, optional) Wie schnell der angesammelte Vorsprung eines Absenders an Worker-Zeit verblasst: Er halbiert sich alle FAIR_HALF_LIFE, sodass die Strafe für einen vergangenen Burst nachlässt, sobald der Absender aufhört. Standardwert 60 s.

FAIR_FIFO_PERCENT

(Zahl, optional) Prozentsatz der beanspruchten Plätze jeder Stage, der unabhängig vom Absender für ihre ältesten wartenden Nachrichten reserviert ist — die Garantie, dass keine Nachricht ewig wartet, gleich wie viele andere Absender weiterhin eintreffen. 1 bis 100; 100 ist „älteste zuerst“ mit zusätzlicher Buchführung (verwenden Sie dafür FAIR_SCHEDULING = no). Standardwert 10.

85.2.1.1.16. Der Abschnitt [pepsi-list]

Optionen für pepsi-list(1) und das Mailinglisten-Subsystem, gelesen von diesem Werkzeug, von den Listen-Stages und von pepsi-setup(1). Jede Option hat eine Voreinstellung, ein Betrieb, der keine Listen beherbergt, braucht daher überhaupt keinen Abschnitt.

Pepsis Mailinglisten-Subsystem ist eine Neuimplementierung von GNU Mailman 3; sein Datenmodell, seine REST-API, sein E-Mail-Befehlsvokabular und die Namen seiner Benachrichtigungsvorlagen sind der Entwurf des GNU-Mailman-Projekts, urheberrechtlich geschützt durch die Free Software Foundation. Siehe COPYING und vendor/PEPSI-VENDORING.md zu den von upstream übernommenen Dateien, die unter der GPL bleiben.

Die Konfiguration je Liste steht nicht hier. Listen werden zur Laufzeit von Leuten angelegt, die nicht der Betreiber sind, möglicherweise zu Tausenden; diese Datei gehört dem Betreiber und wird als Ganzes neu geladen. Die 99 Attribute je Liste liegen in der Tabelle mailing_list und werden mit pepsi-list(1) verwaltet. Was folgt, ist nur, was der Betrieb besitzt.

SITE_OWNER

(Adresse, optional) Wohin die Benachrichtigungen einer Liste gehen, wenn die Liste keinen eigenen Verwalter hat. Ohne sie ist eine Liste ohne Verwalter für pepsi-list check ein Fehler und keine Warnung, denn ihre zurückgehaltenen Nachrichten und Moderationsanfragen würden überhaupt niemanden erreichen.

BASE_URL

(URL, optional) Öffentliche URL, auf die die Archivlinks und die List-*-Header zeigen, für Domains, die keine eigene base_url setzen. Ohne sie kann kein List-Archive:-Header geschrieben werden.

API_USER, API_PASS

(Zeichenkette, optional) HTTP-Basic-Zugangsdaten für die REST-API von GNU Mailman 3 – upstreams [webservice] admin_user/admin_pass unter einem Pepsi-Namen. Setzen Sie beides oder keines: eine halbe Zugangsdatenangabe authentifiziert niemanden, und pepsi-list check meldet eines ohne das andere als Fehler. Die API wird nur auf einem Listener mit dem Flag LIST_API = yes angeboten.

API_BASE_URL

(URL, optional) Der absolute Ursprung, aus dem jeder self_link und jedes Location, das die REST-API ausgibt, gebildet wird, z. B. http://localhost:8001; ein abschließendes / wird entfernt. Nicht gesetzt wird der eigene Host der Anfrage verwendet, was hinter einem Reverse-Proxy richtig ist.

API_RATE_LIMIT

(Ganzzahl, optional) Anfragen pro Minute je Quelladresse an die REST-API. Standardwert 3000, bewusst hoch, damit eine Kompatibilitäts-Testsuite nicht gedrosselt wird; ein 429 von dieser API stammt von diesem Begrenzer.

DEFAULT_LANGUAGE

(Zeichenkette, optional) Die Sprache, mit der eine neue Liste beginnt, und das untere Ende der Präferenzkette (GET /<api>/system/preferences). Standardwert en.

RELEASE_STAGE

(Zeichenkette, optional) Der [stage-<name>]-Abschnitt, der pepsi-stage-list-post(1) ausführt und bei dem eine gehaltene Nachricht, die ein Moderator annimmt, wieder in die Pipeline eintritt. Ohne ihn können gehaltene Nachrichten gelesen und verworfen, aber nicht angenommen werden, und pepsi-setup(1) warnt.

NOTICE_STAGE

(Zeichenkette, optional) Die Stage, bei der die periodischen Bounce-Durchläufe von pepsi-list tasks ihre Mitgliederbenachrichtigungen einspeisen. pepsi-setup(1) verlangt sie und prüft, dass sie eine existierende Stage benennt, sobald eine pepsi-stage-list-bounce(1)-Stage existiert: Ohne sie steigt der Warnungszähler eines Mitglieds, ohne dass das Mitglied je davon erfährt.

BOUNCE_PROBES

(boolesch, optional) Ob einem Mitglied, dessen Bounce-Punktestand den Schwellenwert der Liste überschreitet, eine Probe geschickt wird (wobei der Punktestand zurückgesetzt wird, solange sie aussteht, und ein Bounce der Probe das Mitglied deaktiviert), statt es sofort zu deaktivieren. Standardwert NO. Siehe pepsi-stage-list-bounce(1).

BOUNCE_EVENT_RETENTION

(Ganzzahl, optional) Wie lange ein verarbeitetes Bounce-Ereignis aufbewahrt wird, in Tagen. Standardwert 1.

UNSUBSCRIBE_SECRET

(Zeichenkette, optional) Geheimnis, mit dem das Ein-Klick-Abmeldetoken nach RFC 8058 verschlüsselt wird, das pepsi-stage-list-deliver(1) berechnet und pepsi-httpd(1) prüft. Ohne es wird die https:-Ein-Klick-Form nicht ausgegeben, und die mailto:-Form steht allein. pepsi-setup(1) schreibt es nach secrets.d/pepsi-list.secret (Modus 0640, pepsi-httpd:pepsi) und verweist mit @inline-secret@ darauf.

TEMPLATE_FETCH_TIMEOUT, TEMPLATE_FETCH_MAX_BYTES, TEMPLATE_FETCH_ALLOW_INTERNAL

(Dauer, Ganzzahl, boolesch; optional) Grenzen für das Abrufen der list_template-URI-Überschreibung einer Liste, die ein Listeneigentümer und nicht der Operator setzt: die Frist für den gesamten Abruf (Standardwert 5 s), die größte akzeptierte Vorlage (Standardwert 65536 Bytes) und ob ein Host abgerufen werden darf, der auf eine interne Adresse auflöst (Standardwert NO; jede Adresse, auf die der Host auflöst, wird geprüft).

WEB_RATE_LIMIT, WEB_SEARCH_RATE_LIMIT

(Ganzzahl, optional) Anfragen pro Minute je Quelladresse an die öffentliche Web-Oberfläche der Listen (ein [pepsi-httpd-listener-*] mit LISTS = yes) sowie das separate, engere Budget für deren Suchroute. Standardwerte 600 und 30; ein Wert unter 1 wird auf 1 angehoben.

MAX_MESSAGE_SIZE

(Ganzzahl, optional) Serverweite Obergrenze für die max_message_size einer Liste, in Kilobyte; 0 (der Standard) bedeutet keine serverweite Obergrenze. Ein darüber liegender Wert je Liste wird beschnitten, und pepsi-list check meldet es.

MAX_LIST_HOPS

(Ganzzahl, optional) Wie oft eine Nachricht eine Liste durchlaufen darf, bevor sie als Abonnementkreis zwischen zwei Listen behandelt und verworfen wird. Standard 5. Eine Dachliste – eine Liste, die eine andere Liste abonniert hat – ist eine unterstützte Konfiguration; dies ist, was zwei gegenseitig abonnierte davon am Verstärken hindert. Der Zähler reist als X-Pepsi-List-Hops:-Header und nicht im Nachrichtenzustand, weil die Post einer Dachliste per SMTP hinausgeht und als brandneue Nachricht zurückkommt; pepsi-ingress entfernt den Header aus Post, die nicht über einen authentifizierten oder lokalen Einlieferungsweg ankam, er kann also nicht von einem Fremden zurückgesetzt werden.

INVITE_RATE

(Ganzzahl, optional) Umstellungseinladungen pro Stunde. Standard 300. Die erste Handlung eines migrierenden Betriebs ist eine Massensendung an die gesamte Mitgliedschaft von einer IP ohne Reputation, der Einladungslauf ist daher ratenbegrenzt und wiederaufnehmbar und keine Schleife.

ARCHIVE_RETENTION

(Ganzzahl, optional) Standard-Aufbewahrung des Archivs in Tagen; 0 (der Standard) behält alles. Je Liste überschrieben mit pepsi-list list set-ext <list> archive_retention_days <n>, wobei 0 das Archiv dieser Liste behält, was immer hier steht. Täglich angewendet durch den Aufbewahrungs-Durchlauf von pepsi-list tasks --once (die Unit pepsi-list-tasks.timer).

SEARCH_TRIGRAM

(off | short | full, optional) Serverweite Obergrenze dafür, wie weit der Trigramm-Index einer Liste (Teilzeichenfolgen- und Fuzzy-Suche) reichen darf. Standard short.

Eine Obergrenze, kein Standardwert: jede Liste wählt off, short oder full bis zu ihr, diesen Wert zu senken verkleinert den Index also beim nächsten pepsi-archive reindex und betrifft nicht nur später angelegte Listen. short indiziert den Betreff, den Betreff des Threads sowie Name und Adresse des Absenders; full ergänzt den Nachrichtentext und ist voraussichtlich das größte Objekt in der Datenbank.

Die Trigrammsuche braucht die Erweiterung pg_trgm, die in postgresql-contrib liegt. Ein Betrieb ohne sie installiert und läuft normal, nur mit Volltextsuche; pepsi-list check sagt, in welchem Modus der Betrieb ist.

LIST_FANOUT_BATCH

(Ganzzahl, optional) Je Fan-out-Stapel erzeugte Geschwisterdatensätze. Standard 256.

Eine Listennachricht wird als ein Warteschlangendatensatz je Empfänger zugestellt, damit jede Kopie die eigene Ein-Klick-Abmelde-URI dieses Mitglieds tragen kann. Dies begrenzt, wie viele davon gleichzeitig existieren, und damit, wie viel flüchtigen Speicher ein großer Anhang an eine große Liste belegt: eine 5-MB-Nachricht an eine Liste mit 5 000 Mitgliedern erreicht etwa 1,3 GB statt 25 GB. Den Wert zu erhöhen lässt einen großen Versand schneller abfließen und kostet mehr Platz.

TOMBSTONE_RETENTION

(Ganzzahl, optional) Wie lange ein Löschgrabstein aufbewahrt wird, in Tagen. Standard 90.

Eine Nachricht aus dem Archiv zu löschen behält ihre Message-ID so lange, damit ein erneutes Senden oder ein erneuter Import das Gelöschte nicht stillschweigend wieder archivieren kann. pepsi-archive purge --forget überspringt den Grabstein für den Fall, dass selbst neunzig Tage unerwünscht sind.

ARCHIVE_PARTITIONS

(Ganzzahl, optional) Hash-Partitionen für die Archivtabellen. Standard 32. Nur von pepsi-setup(1) gelesen und bei der Installation festgelegt.

PostgreSQL kann nicht im Betrieb neu partitionieren: den Modulus zu ändern bedeutet eine neue Tabelle und eine vollständige Kopie jeder archivierten Nachricht. pepsi-setup legt die Partitionen einmal an und weigert sich, sie bei einem späteren Lauf stillschweigend zu ändern, und pepsi-list check meldet eine Konfiguration, die dem widerspricht, was auf der Platte liegt – maßgeblich ist der installierte Wert, denn die Tabellen lassen sich nicht bearbeiten und diese Datei schon. Wählen Sie einmal.

85.2.1.1.17. Der Abschnitt [pepsi-failure-bouncer]

Optionen für pepsi-failure-bouncer(1), das failed/timeout-Nachrichten zu einer Bounce-Stage verschiebt, damit der Absender benachrichtigt wird. Nur von diesem Werkzeug gelesen.

BOUNCE_STAGE

(Zeichenkette, erforderlich, wenn das Werkzeug verwendet wird) Das [stage-<name>]-Etikett, zu dem eine festhängende Nachricht verschoben (und auf pending zurückgesetzt) wird. Normalerweise dieselbe Bounce-Stage, zu der die Pipeline dauerhafte Fehler bereits routet (z. B. bounce). Eine bereits an dieser Stage befindliche Nachricht bleibt unberührt, sodass ein Bounce, der an der Bounce-Stage fehlschlägt, nicht in eine Schleife gerät. pepsi-setup(1) prüft, dass die benannte Stage existiert. Auf jeder Installation erforderlich, die pepsi.target ausführt: dessen pepsi-failure-bouncer.timer führt das Werkzeug alle zehn Minuten aus, und ohne diese Option schlägt jeder Lauf fehl. Die ausgelieferte Konfiguration und die des Assistenten setzen sie auf bounce.

MIN_AGE = DURATION

Wie lange eine Nachricht failed/timeout gewesen sein muss, bevor sie verschoben wird (Standardwert 1 h): das Zeitfenster, in dem ein Operator sie mit pepsi-queue(1) zurückholen kann, bevor ihr Absender benachrichtigt wird. Gemessen ab state.failed_at, das die Datenbank stempelt, wenn der Datensatz fehlschlägt; ein Datensatz ohne diesen Stempel wird sofort verschoben. 0 s verschiebt jeden Fehlschlag unverzüglich.

85.2.1.1.18. Der Abschnitt [pepsi-sendmail]

Optionen für pepsi-sendmail(1), den Sendmail-kompatiblen lokalen Submission-Client, den das Debian-Paket als /usr/sbin/sendmail installiert. Jede Option hat einen Standardwert, sodass ein Standort überhaupt keinen Abschnitt benötigt.

Der Client ist unprivilegiert und behauptet keine Identität: Er übergibt die Nachricht an einen UNIX-Domain-Ingress-Listener, der das Konto des Absenders aus den vom Kernel gemeldeten Zugangsdaten des verbindenden Prozesses ableitet (AUTH_PEERCRED, oben).

SOCKET

(Pfad, optional) Der UNIX-Domain-Submission-Socket von pepsi-ingress. Standardwert /run/pepsi/submission.sock.

Obwohl sie im Abschnitt des Clients steht, wird diese Option von beiden Enden gelesen: pepsi-ingress bedient diesen Socket bedingungslos und synthetisiert seinen Listener aus diesem Pfad, sodass es dafür keinen [pepsi-ingress-listener-*]-Abschnitt gibt und keine zweite Deklaration, die einen anderen Pfad benennen könnte.

Unter systemd wird der Deskriptor geerbt, wenn pepsi-ingress.socket diesen Pfad bereits bindet — abgeglichen über die Adresse, an die der Deskriptor gebunden ist, nicht über einen FD_INDEX —, sodass eine Änderung hier ein passendes ListenStream= in der Unit braucht. Andernfalls bindet der Server den Pfad selbst, mit dem Modus 0666, und verweigert den Start, wenn er es nicht kann. Dieser Modus gewährt für sich genommen nichts: Das Öffnen des Sockets vermittelt kein Recht zu senden, denn der Kernel liefert die Identität des Aufrufers, und USERNAME_MAP entscheidet, als wer er senden darf.

Der Sonderwert none deaktiviert die lokale Submission vollständig: Kein Socket wird bedient, und pepsi-sendmail(1) verweigert den Lauf, sodass lokale Programme auf 587/465 authentifizieren müssen. pepsi-setup(1) meldet dies einmal.

EHLO_NAME

(Zeichenkette, optional) Der in EHLO angekündigte Name. Standardmäßig [pepsi-ingress] HOSTNAME. Kosmetisch: Der Server authentifiziert die Gegenstelle anhand ihrer Zugangsdaten, nicht anhand dessen, was sie hier behauptet.

DEFAULT_DOMAIN

(Zeichenkette, optional) Domain, die an das Login des aufrufenden Kontos angehängt wird, um den Umschlagabsender zu bilden, wenn weder -f noch -r angegeben wurde. Standardwert ist [pepsi-ingress] HOSTNAME (und localhost, falls auch das nicht gesetzt ist).

Setzen Sie sie, wenn die Adressen, die Ihr USERNAME_MAP kennt, bei einer anderen Domain liegen: Der Server bildet die uid der Gegenstelle auf ein Login und dann auf eine Adresse ab, sodass eine Abweichung hier das ist, was cron-Mail von einem Umschlagabsender ankommen lässt, der dem Standort nicht gehört.

85.2.1.1.19. Der Abschnitt [pepsi-whitelist]

Optionen für pepsi-whitelist(1), das Werkzeug, das die weiße Liste der Absender verwaltet und eine solche aus dem Postfach eines Benutzers befüllen kann (import). Wird nur von diesem Werkzeug gelesen; jede Option ist optional, sodass ein Standort, der nur add/list/remove verwendet, überhaupt keinen Abschnitt benötigt.

LOCAL_DOMAINS

(Zeichenkette, optional) Domains, deren Absender beim Scannen eines Postfachs als eigene Mail des Benutzers zählen: Eine Nachricht, deren From:/Sender: bei einer von ihnen liegt, ist eine, die der Benutzer gesendet hat, sodass ihre Empfänger zu Einträgen der weißen Liste werden. Durch Komma oder Leerzeichen getrennt. Standardmäßig [pepsi-ingress] ACCEPTED_DOMAINS, und es ist dieselbe Option, die pepsi-stage-relay-to-maildir(1) und pepsi-stage-dot-forward(1) verwenden.

TARGETS, RECIPIENT_DELIMITER

(Zeichenkette, optional) Wie bei den Zustell-Stages. TARGETS begrenzt, welche lokalen Konten import --all-users befüllt (Standardwert: der Bereich UID_MIN..``UID_MAX`` aus /etc/login.defs); RECIPIENT_DELIMITER entfernt eine Subadresse, bevor eine Adresse verglichen wird.

HOSTERS_FILE

(Pfad, optional) Datei, die öffentliche E-Mail-Hoster auflistet, eine Domain pro Zeile (#-Kommentare; ein führendes *. deckt einen Subdomain-Baum ab). Domains darin werden von import --auto-wildcard niemals als *@domain-Wildcard vorgeschlagen, wie viele Korrespondenten der Benutzer dort auch haben mag — „alle bei gmail.com“ ist keine Menge von Personen, die der Benutzer kennt, und sie auf die weiße Liste zu setzen würde jedem Spammer mit einem kostenlosen Konto eine Umgehung der Anti-Spam-Schranke verschaffen. Ihre einzelnen Adressen werden weiterhin importiert. Standardmäßig ${DATADIR}/hosters.txt, was make install schreibt; verweisen Sie hier auf Ihre eigene Kopie, um die Liste zu erweitern, da die installierte bei einem Upgrade überschrieben wird.

WILDCARD_THRESHOLD

(Zahl, optional) Wie viele verschiedene Adressen bei einer Domain dazu führen, dass import --auto-wildcard einen einzelnen *@domain-Eintrag dafür vorschlägt. Standardwert 10.

MAX_ENTRIES

(Zahl, optional) Höchstzahl der Datensätze, die ein import hinzufügen darf. Standardwert 5000. Jeder Datensatz einer weißen Liste wird gegen das From: jeder eingehenden Nachricht abgeglichen, die sie konsultiert, sodass dies eine Schranke für dauerhafte Kosten pro Nachricht ist und nicht nur für die Tabellengröße.

SCAN_HELPER

(Zeichenkette, optional) Das Helper-Binärprogramm für den Postfach-Scan, auf $PATH gesucht. Standardwert pepsi-helper-mailbox-scan (siehe pepsi-helper-mailbox-scan(1)).

MAILBOX

(Pfad, optional) Postfach, das gescannt wird, wenn der Benutzer keines angibt. Standardmäßig das ~/Maildir des Benutzers, falls es existiert, sonst /var/mail/<login>.

85.2.1.1.20. Der Abschnitt [pepsi-httpd]

Optionen für pepsi-httpd(1). Der Server liest außerdem die bedienten Domains (ACCEPTED_DOMAINS), den MTA-STS-mx-Host (das Ingress-HOSTNAME) und die [pepsi]-MTA_STS_*-Optionen.

MAX_CONNECTIONS

(Zahl, optional) Maximale Anzahl gleichzeitig bedienter HTTP-Verbindungen. Standardwert 256.

MAX_CONNECTIONS_PER_IP

(Zahl, optional) Höchstzahl gleichzeitiger Verbindungen von einer Client-Adresse (einer IPv4-Adresse oder einem IPv6-/64); eine Verbindung darüber hinaus wird sofort geschlossen. Verbindungen über einen UNIX-Socket — von einem Reverse-Proxy — tragen keine Client-Adresse und werden nicht gezählt; hinter einem Proxy gehört diese Grenze also in den Proxy. Standardwert 32; 0 schaltet sie ab.

DB_POOL_SIZE

(Zahl, optional) Maximale Anzahl von PostgreSQL-Verbindungen im Datenbankpool des HTTP-Servers. Der Server bearbeitet Anfragen nebenläufig, sodass er anders als die Einzelverbindungs-Stage-Worker mehr als eine verwenden kann. Standardwert ist 1; erhöhen Sie es nur, wenn die Endpunkte an der einzelnen Verbindung einen Engpass haben, und halten Sie die Summe der Pools jeder Komponente unter dem max_connections von PostgreSQL.

RESUME_AUTHORIZATION_TOKEN

(Zeichenkette, optional) Bearer-Token, das POST /resume absichert (in konstanter Zeit verglichen); der Endpunkt ist deaktiviert (404), wenn nicht gesetzt. Verwenden Sie die Taler-secret-token:-Form, sodass derselbe Wert als Authorization-Header des Händler-pepsi-resume-Webhooks wiederverwendet werden kann (siehe pepsi-stage-anti-spam(1) und den [pepsi-payments]-Abschnitt).

ADDIN

(boolesch, optional) Ob die Outlook-Add-in-Routen (GET /addin/manifest.xml und GET /addin/taskpane.html) antworten. Standardwert no: Eine Installation, die keinem Exchange vorgeschaltet ist, hat keinen Nutzen von ihnen, und ein Manifest, das ein Gateway benennt, das niemand konfiguriert hat, ist eine Supportanfrage, die nur darauf wartet zu geschehen. Siehe das Kapitel „Microsoft Exchange als Gateway“ des Handbuchs.

ADDIN_URL

(Zeichenkette, optional) Der öffentliche https://-Ursprung, der in die Add-in-Assets eingesetzt wird. Ungesetzt (der Standardwert) leitet ihn aus dem Host-Header jeder Anfrage ab, was sowohl funktioniert, wenn pepsi-httpd TLS selbst terminiert, als auch wenn es hinter einem Reverse Proxy sitzt — im letzteren Fall sieht es schlichtes HTTP über einen UNIX-Socket und kann das öffentliche Schema nicht aus der Verbindung ableiten. Setzen Sie ihn, wenn der Host, der Pepsi erreicht, nicht das Gateway benennt. Das Schema muss https sein, und das wird erzwungen: Outlook weigert sich, Add-in-Ressourcen über schlichtes HTTP zu laden, sodass ein http://-Ursprung nur ein Manifest hervorbringen könnte, das beim Laden scheitert; pepsi-httpd verweigert daher mit einem solchen den Start, statt ihn auszuliefern. Die einzige Ausnahme ist ein Loopback-Host — localhost, alles unter .localhost, 127.0.0.0/8 oder [::1] —, wo schlichtes http:// angenommen wird, damit ein Entwickler oder ein Test kein Zertifikat braucht. Der Wert wird geprüft, wann immer er gesetzt ist, gleich ob ADDIN an ist, sodass ein falscher gemeldet wird, bevor die Funktion eingeschaltet wird.

Jeder [pepsi-httpd-listener-<name>]-Abschnitt bindet einen Socket, mit denselben SERVE-(tcp/unix/systemd-) und Transportoptionen wie ein [pepsi-ingress-listener-<name>]-Abschnitt, außer dass ein tcp-Listener standardmäßig PORT 443 hat und MODE plain oder tls ist (kein STARTTLS). Ein tls-Listener kann TLS_CERT/TLS_KEY als Rückfall-Zertifikat setzen. Er nimmt zusätzlich an:

ADMIN = yes | no

Ob die administrative Oberfläche — die /api/v1-API, die /ui-Administrationskonsole und die /metrics-Seite — auf diesem Listener bedient wird. Optional; Standardwert no. Auf einem Listener ohne sie antworten jene Routen mit einem schlichten 404 — Byte für Byte dem, was jeder unbekannte Pfad bekommt —, sodass das Veröffentlichen des öffentlichen Listeners nicht die Administration veröffentlicht.

/metrics gehört zu dieser Menge, weil Warteschlangentiefen je Stage, Absturzzähler und Stage-Namen die Pipeline beschreiben; anders als die anderen beiden verlangt es kein Credential (ein Prometheus-Scraper hat keines vorzuzeigen), sodass dieses Flag auf einem Metrik-Listener die einzige Zugriffskontrolle ist. Siehe pepsi-httpd(1).

pepsi-httpd(1) weigert sich, sie auf einem markierten Listener zu bedienen, der sie im Klartext von diesem Host fortträge: Klartext-tcp wird nur auf einer Loopback-Adresse angenommen, während tls-Listener und unix-Sockets immer qualifizieren. Ein Klartext-SERVE = systemd-Listener qualifiziert nie — die Unit hat entschieden, wo der geerbte Deskriptor lauscht, und der Server kann diese Adresse nicht sehen, sodass der Fall, den er nicht beurteilen kann, abgelehnt statt zugelassen wird. Ein markierter Listener, der die Prüfung nicht besteht, protokolliert beim Start eine Warnung und bedient nur die öffentlichen Endpunkte, und pepsi-setup(1) meldet dasselbe zur Prüfzeit.

Die ausgelieferte Konfiguration markiert einen unix-Listener, was die Gestalt ist, die überhaupt keine Zugangsdaten braucht: Ein verbindender Prozess wird über SO_PEERCRED identifiziert. Siehe [pepsi-admin] unten.

LIST_API = yes | no

Ob die zu GNU Mailman 3 kompatible REST-API (die Routen /3.0/ und /3.1/) auf diesem Listener angeboten wird. Optional; Standardwert ist no, in welchem Fall diese Routen ein schlichtes 404 liefern. Sie unterliegt demselben Bindungstest wie ADMIN (TLS, ein unix-Socket oder Klartext-tcp auf Loopback), und ihre Zugangsdaten sind [pepsi-list] API_USER/API_PASS.

LIST_API_TESTING = yes | no

Ob diese API zusätzlich den nur für Tests gedachten Haken /3.1/reserved/reset anbietet, der die Listen- und Archivtabellen leert. Optional; Standardwert ist no, und die Option wirkt nur, wenn LIST_API auf dem Listener nutzbar ist. Nur für eine Kompatibilitäts-Testumgebung.

LISTS = yes | no

Ob die öffentliche Web-Oberfläche der Mailinglisten (Archive, Abonnementseiten) auf diesem Listener angeboten wird. Optional; Standardwert ist no. Anders als die beiden obigen Flags ist sie dazu gedacht, aus dem offenen Internet erreichbar zu sein, daher gilt der Bindungstest für sie nicht. Ihre Ratenbegrenzungen sind [pepsi-list] WEB_RATE_LIMIT und WEB_SEARCH_RATE_LIMIT.

Jeder [pepsi-httpd-cert-<name>]-Abschnitt registriert ein Zertifikat für die SNI-Auswahl: SNI (einen oder mehrere Hostnamen), TLS_CERT und TLS_KEY.

85.2.1.1.21. Der Abschnitt [pepsi-admin]

Optionen für die administrative API, die pepsi-httpd(1) auf einem mit ADMIN = yes markierten Listener bedient. Jede Option hat einen Standardwert, sodass der Abschnitt vollständig weggelassen werden kann. Das Authentifizierungsmodell, die Scope-Tabelle und die Endpunktreferenz stehen im Kapitel „Die administrative API“ des Handbuchs.

Dieselben Optionen regeln die /ui-Administrationskonsole, die ein Client jener API ist und keine eigene Konfiguration einführt: Sie teilt die Sitzungs-Timeouts, die Ratenbegrenzungen, die Body-Obergrenze, die Seitengröße und die Konfigurationsschreib-Verbindung. Siehe das Kapitel „Die Administrationskonsole“ des Handbuchs.

ADMIN_GROUP

(Zeichenkette, optional) UNIX-Gruppe, deren Mitglieder über einen UNIX-Socket-Listener lokale Administratoren sind, per SO_PEERCRED identifiziert. root ist es immer, mit oder ohne Gruppe. Standardwert pepsi-admin.

SESSION_IDLE

(Dauer, optional) Leerlauf-Timeout einer Browser-Sitzung, bei jeder Anfrage vorgeschoben. Standardwert 30 m.

SESSION_LIFETIME

(Dauer, optional) Harte Lebensdauer einer Browser-Sitzung, nie verlängert. Standardwert 12 h. Es gibt kein „Angemeldet bleiben“: Diese Konsole kann einen Schlüssel widerrufen und lesen, wer mit wem korrespondiert, und lokale Administratoren — die sich am häufigsten anmelden — authentifizieren per SO_PEERCRED und haben keine Sitzung, die ablaufen könnte.

EVENT_RETENTION_DAYS

(Zahl, optional) Wie lange Audit-Einträge aufbewahrt werden, in Tagen. Standardwert 90. pepsi-httpd prune wendet beide Aufbewahrungsfristen an, täglich ausgeführt von pepsi-log-prune.timer als Konto pepsi-httpd — die eine Datenbankrolle, die DELETE auf den Logs besitzt, da keine Komponente, die Mail verarbeitet, sie löschen darf. Der Timer ist vom Webserver unabhängig: Die Aufbewahrung gilt, ob pepsi-httpd.service läuft oder nicht.

MAIL_LOG_RETENTION_DAYS

(Zahl, optional) Wie lange Maillog-Datensätze aufbewahrt werden, in Tagen, wenn [pepsi] MAIL_LOG an ist. Standardwert 30.

Beide Aufbewahrungen sind ganzzahlige Tage statt Dauern, weil Section::duration über jiff::SignedDuration parst, das nur h/m/s und darunter annimmt.

RATE_LIMIT

(Zahl, optional) Anfragen pro Minute je Quelladresse (ein UNIX-Socket-Listener teilt einen Schlüssel für den ganzen Host). 0 deaktiviert die Grenze. Standardwert 120.

LOGIN_RATE_LIMIT

(Zahl, optional) Anmeldeversuche pro Minute, je Konto und je Quelladresse gezählt — viele Passwörter gegen ein Konto und ein Passwort gegen viele Konten sind verschiedene Angriffe. 0 deaktiviert die Grenze. Standardwert 10.

MAX_BODY

(Zahl, optional) Größter angenommener Anfrage-Body, in Bytes. Standardwert 1048576.

PAGE_LIMIT

(Zahl, optional) Standard-Seitengröße eines Auflistungs-Endpunkts. Ein Aufrufer darf bis zu 1000 verlangen; jede Auflistung beachtet limit und offset in ihrem SQL und meldet ein exaktes total neben der Seite, und nichts liefert eine unbegrenzte Ergebnismenge. Standardwert 100; ein konfigurierter Wert außerhalb von 1..``1000`` wird in diesen Bereich hineingezwungen statt zurückgewiesen.

CONFIG_DB

(PostgreSQL-Verbindungszeichenfolge, optional) Verbindung, die für Konfigurationsschreibvorgänge verwendet wird. Standardmäßig nicht gesetzt, in welchem Fall PUT/DELETE auf /api/v1/config mit 503 und dem Grund antworten und jeder andere Endpunkt unberührt bleibt.

pepsi.config_override zu schreiben gehört der Datenbankrolle pepsi-config, die pepsi-setup(1) gewährt und jedem Dienstkonto ausdrücklich entzieht: Eine Komponente, die Mail verarbeitet, darf die Pipeline, in der sie läuft, nicht umschreiben können. pepsi-httpd ist ein solches Konto, und die Peer-Authentifizierung richtet sich nach der effektiven uid, sodass seine eigene Verbindung nicht diese Rolle sein kann. Richten Sie dies auf eine Verbindung, die sich als pepsi-config authentifiziert — ein Passwort in einem secrets.d-Fragment, das nur das pepsi-httpd-Konto lesen kann, oder eine pg_ident-Abbildung. Der Server prüft es beim Start mit SELECT current_user und lehnt eine Verbindung ab, die sich als etwas anderes authentifiziert, denn eine Grenze, an die der Code bloß glaubt, ist keine Grenze. Die Ablehnung ist nicht fatal: Sie wird protokolliert, der Konfigurationsschreibpfad bleibt aus, und das 503 nennt die Rolle, die tatsächlich zustande kam — ein Server, der mit einem Privileg startete, das er nicht haben sollte, wäre das schlechtere Ergebnis.

Die Online-Einrichtung reiht über dieselbe Verbindung und aus demselben Grund ein: Nur pepsi-config darf in pepsi.setup_task INSERT``en, und der privilegierte Applier lehnt jeden Datensatz ab, der etwas anderes sagt. Ohne ``CONFIG_DB antworten auch die Einrichtungsendpunkte mit 503 — der Server kann die Fragen bedienen und eine Aufgabe beobachten und kann keine anfordern.

APPLY_SOCKET

(Pfad, optional) Wo für den privilegierten Setup-Applier geklingelt wird. Standardwert /run/pepsi/setup-apply.sock.

Nach dem Einreihen einer Einrichtungsaufgabe verbindet sich pepsi-httpd mit diesem Socket und schließt ihn. Diese Verbindung ist die ganze Nachricht: Es wird nichts darauf geschrieben und nie etwas davon gelesen, sodass sie kein Befehlskanal werden kann. Was sie bewirkt, ist, dass systemds Socket-Aktivierung pepsi-setup apply startet, das seine Arbeit aus der Datenbank nimmt — wo jeder Datensatz geprüft und protokolliert ist — und sich wieder beendet, wenn es keine gibt.

Ein Socket statt eines Signals oder eines Spawns, weil pepsi-httpd unprivilegiert läuft und keine Möglichkeit hat, einen root-Prozess zu starten, und sich keine verschaffen sollte. Dies ist der eine Mechanismus, der es einen privilegierten Prozess laufen lassen lässt, ohne beeinflussen zu können, was dieser Prozess tut. Ein Verbindungsfehlschlag ist kein Fehler: Die Aufgabe ist so oder so dauerhaft eingereiht, und pepsi-setup apply --once aus cron oder von einer Konsole nimmt sie auf.

Dieser Pfad ist auch das, was APPLIER = auto sondiert; siehe unten.

APPLIER

(auto|yes|no, optional) Ob von diesem Server aus überhaupt eine privilegierte Einrichtungsänderung geschehen kann. Standardwert auto.

Die systemd-Units des Appliers sind separat paketiert (Debian pepsi-httpd-admin oder make install INSTALL_ADMIN_UNITS=no aus den Quellen), sodass eine Installation, die von einem Terminal aus verwaltet wird, den einen Mechanismus entfernen kann, über den eine HTTP-Anfrage /etc/pepsi erreicht. Sind sie fort, leert nichts pepsi.setup_task, und ein Insert darin ist inaktiv — sodass die Konsole nicht weiterhin Formulare anbieten darf, deren Absendungen stillschweigend nie angewandt würden.

auto

Zwei Dinge sondieren: dass pepsi-setup-apply.socket als Unit-Datei dort existiert, wo systemd nach einer sucht (installiert), und dass APPLY_SOCKET existiert, ein Socket ist und von diesem Konto beschreibbar ist (scharf — sich mit einem UNIX-Socket zu verbinden braucht Schreibrecht). Mit dem Socket wird nie verbunden: Verbinden ist das Klingeln, was bei jedem Seitenaufbau einen root-Prozess startete. Die Sonde schlägt geschlossen fehl: Jede Ungewissheit, einschließlich eines Pfads, der nicht untersucht werden kann, und eines von einem entfernten Paket zurückgelassenen Socket-Knotens, liest sich als „kein Applier“.

yes

Annehmen, dass der Applier erreichbar ist, und die Sonde überspringen. Für eine Installation, die die Warteschlange auf andere Weise leert — pepsi-setup apply --once aus cron, eine handgeschriebene Unit, ein Host ohne systemd —, wo die Sonde eine Fähigkeit meldete, die es gar nicht gibt. Es ist ein Versprechen, das der Operator gibt; nichts prüft es.

no

Jede privilegierte Einrichtungsanfrage ablehnen, was auch immer installiert ist. Ein Weg, die Konsole nur lesend zu machen, ohne die Paketmenge zu ändern.

Wenn es keinen Applier gibt, bedient pepsi-httpd weiterhin das Setup-Interview, die vorgemerkten Antworten und die Aufgabenhistorie — nur lesend, mit deaktivierten Bedienelementen — und beantwortet die verändernden Endpunkte mit 503 setup_applier_unavailable. Siehe pepsi-httpd(1).

85.2.1.1.22. Die Egress-Identitätsoption: PUBLIC_IP

PUBLIC_IP = ADDR [ADDR …]

Durch Leerraum oder Komma getrennte Liste der öffentlichen IPv4- und/oder IPv6-Adressen, die Mail als Ihre Domains senden. Jede wird zu einem ip4:- oder ip6:-Mechanismus im v=spf1-Eintrag, den pepsi-setup(1) vorschlägt. Keine Stage liest diese Option zur Laufzeit — sie ist rein eine Eingabe für den erzeugten SPF-Eintrag.

PUBLIC_IP ist eine stage-weise Option, die im [stage-<name>]-Abschnitt einer Relay-Stage gesetzt wird, und pepsi-setup(1) sammelt sie aus jeder Stage, deren PROGRAM pepsi-stage-relay-to-internet(1) oder pepsi-stage-relay-to-smarthost(1) ist — erkannt am PROGRAM, niemals am Abschnittsnamen —, und vereinigt die Ergebnisse. Eine Installation kann daher mehrere Relay-Stages haben, jede mit ihrem eigenen PUBLIC_IP:

• Bei einer pepsi-stage-relay-to-internet-Stage sind es die eigene(n) öffentliche(n) Sende-IP(s) dieses Hosts: Der Host stellt von ihnen aus direkt an die MX der Empfänger zu.

• Bei einer pepsi-stage-relay-to-smarthost-Stage sind es die Egress-IP(s) des Smarthosts: Mail geht vom Smarthost aus ins Internet, sodass SPF sie autorisieren muss (viele Anbieter veröffentlichen stattdessen ein include:, das Sie von Hand zum Eintrag hinzufügen).

Setzt keine Relay-Stage PUBLIC_IP, ist der erzeugte Eintrag ein bloßes v=spf1 -all — was Empfängern sagt, dass kein Host für Ihre Domains senden darf, und Ihre eigene ausgehende Mail bei SPF durchfallen lässt —, und pepsi-setup(1) protokolliert eine Warnung. Eine reine Empfangs-Installation (keine Relay-Stage) hat kein PUBLIC_IP und wird nicht gewarnt.

Jede Adresse muss eine global routbare öffentliche IP sein — die Adresse, von der aus Empfänger die Mail eintreffen sehen. pepsi-setup(1) warnt (bei der Validierung und in der DNS-Ausgabe), wenn eine PUBLIC_IP keine öffentliche Adresse ist (Loopback, RFC 1918 / Unique-Local, Link-Local oder CGNAT): Verwenden Sie hinter NAT die öffentliche Ausgangs-IP des Hosts, nicht seine LAN-Adresse, sonst schlägt ausgehende Mail über diese Adressfamilie bei SPF fehl.

Reverse DNS (PTR). Jede PUBLIC_IP von pepsi-stage-relay-to-internet — die eigene Ausgangs-IP dieses Hosts — muss außerdem einen vorwärtsbestätigten Reverse-DNS-Eintrag haben, der den ``SERVER_NAME`` der Stage benennt: einen PTR für die Adresse, dessen Hostname wiederum (über A/AAAA) auf dieselbe Adresse zurück auflöst und der genau der Name ist, den die Stage im EHLO ankündigt. Viele empfangende Mailserver werten einen fehlenden, nicht vorwärtsbestätigten oder generisch/dynamisch wirkenden PTR als Spam-Signal und lehnen die Mail ab oder stufen sie als Junk ein, und eine große Familie von ihnen vergleicht zusätzlich den EHLO-Namen mit dem PTR und verweigert die Sitzung, wenn die beiden verschiedene Hosts benennen (HELO host does not match rDNS). Innerhalb Ihrer ACCEPTED_DOMAINS zu liegen erfüllt diesen Test nicht — ein Host, der auf mehrere Namen hört, kann einen ankündigen und rückwärts auf einen anderen auflösen, beide seine eigenen, und dennoch abgewiesen werden. pepsi-setup(1) warnt für jede PUBLIC_IP, deren Reverse DNS in diesem Sinne nicht korrekt ist, einschließlich dieser Abweichung, und gibt die Abhilfe aus (siehe pepsi-setup(1)). Das Reverse DNS für eine PUBLIC_IP liegt in der Zone des IP-Eigentümers (in-addr.arpa / ip6.arpa) — üblicherweise Ihr ISP oder Hosting-Provider —, sodass es anders als die Vorwärtseinträge oft nichts ist, was Sie selbst veröffentlichen können; wo es sich nicht ändern lässt, setzen Sie SERVER_NAME (und [pepsi-ingress] HOSTNAME, den MX-Eintrag und das TLS-Zertifikat) auf den Namen, den der PTR bereits angibt. Eine PUBLIC_IP von pepsi-stage-relay-to-smarthost benennt die Ausgangs-IPs des Smarthosts, deren Reverse DNS der Smarthost-Betreiber kontrolliert, weshalb diese nicht geprüft werden.

Der vereinigte Eintrag wird für jede bediente Domain identisch veröffentlicht. Das ist korrekt, aber weit gefasst; in besonderen Konstellationen, in denen verschiedene Domains von verschiedenen Hosts senden, kann ein von Hand geschriebener domainspezifischer SPF-Eintrag (der nur die eigenen Sende-IPs jener Domain auflistet) enger und dennoch korrekt sein. pepsi-setup(1) berechnet diese Gruppierung nicht automatisch und weist in seiner DNS-Ausgabe darauf hin.

85.2.1.1.23. Die [pepsi-stage-relay-to-smarthost]-MTA-Abschnitte

85.2.1.1.23.1. Die Smarthost-(MTA-)Abschnitte

Jeder [pepsi-stage-relay-to-smarthost-mta-<name>]-Abschnitt definiert einen vorgelagerten Smarthost; das Suffix <name> ist ein frei gewähltes Etikett, das in Journalen verwendet wird. Diese Abschnitte werden von jeder Smarthost-Relay-Stage geteilt. Eine Empfängerdomain wird zu dem MTA geroutet, dessen DOMAINS sie auflistet, oder zum einzelnen CATCH_ALL-MTA.

HOST

(Zeichenkette, erforderlich) Hostname oder Adresse des Smarthosts, mit dem verbunden wird.

PORT

(Zahl, erforderlich) TCP-Port, über den verbunden wird (z. B. 587 oder 465).

MODE

(optional) Transportsicherheit: starttls (Standardwert), tls (implizites TLS) oder plain (Klartext).

TLS_VERIFY

(boolesch, optional) Ob das TLS-Zertifikat des Smarthosts gegen den System-Trust-Store verifiziert wird. Standardwert yes; no akzeptiert jedes Zertifikat (unsicher, nur zum Testen).

TLS_CA

(Pfad, optional) Ein zusätzliches CA-Zertifikat (PEM), dem zusätzlich zum System-Store vertraut wird, z. B. für eine private Smarthost-CA.

TLS_CLIENT_CERT / TLS_CLIENT_KEY

(Pfad, optional; beides-oder-keines) Ein Client-Zertifikat (PEM-Kette) und sein privater Schlüssel, die dem Smarthost während des TLS-Handshakes vorgelegt werden (Mutual TLS). Bei jeder Verbindung frisch geladen. Erfordert einen verschlüsselnden MODE (tls oder starttls) und gilt für PKIX, TLS_VERIFY = no und DANE gleichermaßen. Der Schlüssel ist geheim: Halten Sie ihn nur für die pepsi-token-Gruppe lesbar, unter der die Relay-Stage SGID läuft (legen Sie auf Debian Zertifikat + Schlüssel in das SGID-/var/pepsi/tls-Verzeichnis). Setzen Sie AUTH = external, um die SMTP-Sitzung zusätzlich per SASL EXTERNAL mit dem Zertifikat zu authentifizieren.

DANE

(optional) DANE/TLSA-(RFC 7672-)Durchsetzung gegenüber diesem Smarthost: off, warn (der Standardwert) oder strict. Wenn der Smarthost DNSSEC-validierte TLSA-Einträge unter _<PORT>._tcp.<HOST> veröffentlicht, wird das Zertifikat gegen sie authentifiziert, mit Vorrang vor TLS_VERIFY (PKIX). In warn wird eine Nichtübereinstimmung protokolliert und die Zustellung fährt fort; in strict schiebt ein nutzbarer, aber nicht übereinstimmender Eintrag oder eine fehlgeschlagene TLSA-Abfrage die Nachricht auf. Wird bei MODE = plain ignoriert. Erfordert einen DNSSEC-validierenden Resolver, der über einen vertrauenswürdigen Pfad erreicht wird (Pepsi vertraut dem AD-Bit der Antwort); siehe das DNS_SERVERS der Stage.

ADDRESS_FAMILY

(optional) Welche IP-Adressfamilien verwendet werden dürfen, um diesen Smarthost zu erreichen: any, ipv4 (auch v4/v4only geschrieben) oder ipv6 (v6/v6only).

Die Vorrangfolge ist: dieser Eintrag, dann der besitzende [stage-*]-Abschnitt, dann any. Die Ebene je Eintrag ist das, was die Option nützlich macht: Ein sich fehlverhaltendes Ziel kann festgelegt werden, ohne jedes andere Ziel — einschließlich eines, das nur AAAA veröffentlicht — auf dieselbe Familie zu zwingen.

Der motivierende Fall ist Microsoft Exchange Online, das Mail von einer sendenden IPv6-Adresse ohne PTR-Eintrag ablehnt (550 5.7.1 ... S820). Ein Dual-Stack-Host bevorzugt IPv6, sodass eine Maschine mit korrektem IPv4-Reverse-DNS und nicht delegiertem IPv6-Reverse-DNS überall gut zustellt außer dort.

Mit any (dem Standardwert) wird der Hostname dem System-Resolver übergeben. Jeder andere Wert lässt Pepsi den Host selbst auflösen und jede Adresse der gewählten Familie der Reihe nach versuchen. Ein Ziel, das keine Adresse der gewählten Familie veröffentlicht, ist ein vorübergehender Fehlschlag, kein Bounce: Das ist ein Operatorfehler, an dem es sich zu wiederholen lohnt, keiner, für den es sich lohnt, eingereihte Mail zu zerstören.

AUTH

(optional) SMTP-Authentifizierungsmechanismus: none (Standardwert), plain, login, cram-md5, digest-md5, scram-sha-1, scram-sha-256, scram-sha-1-plus, scram-sha-256-plus, auto, external, oauth, ntlm oder gssapi. plain/login/cram-md5/digest-md5/die scram-*-Familie/auto erfordern alle USERNAME und PASSWORD; oauth erfordert USERNAME und TOKEN_FILE; external (SASL EXTERNAL, RFC 4422) erfordert TLS_CLIENT_CERT / TLS_CLIENT_KEY und authentifiziert sich mit diesem Zertifikat (kein Passwort gesendet), mit einem optionalen USERNAME als SASL-Autorisierungsidentität. cram-md5 (RFC 2195) und scram-sha-1/scram-sha-256 (RFC 5802 / RFC 7677) sind Challenge/Response: Das Passwort wird nie gesendet, und SCRAM authentifiziert zusätzlich den Server gegenüber Pepsi (eine fehlerhafte Server-Signatur ist ein dauerhafter Fehler). Die -plus-SCRAM-Varianten ergänzen tls-server-end-point-Channel-Binding (RFC 5929). auto wählt den stärksten vom Smarthost angekündigten Mechanismus (SCRAM-SHA-256-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1-PLUS > SCRAM-SHA-1 > CRAM-MD5 > LOGIN > PLAIN); es wählt nie das veraltete digest-md5, ntlm oder gssapi. digest-md5 (RFC 2831) ist ebenfalls ein Challenge/Response mit Server-Authentifizierung (rspauth), aber veraltet (RFC 6331 überführte es in den Status „Historic“) und nur für ältere Smarthosts bereitgestellt; seine Auswahl protokolliert eine Warnung von pepsi-setup(1) und zur Laufzeit. ntlm ist der de-facto Microsoft-Mechanismus (kein RFC; nur NTLMv2, mit tls-server-end-point-EPA-Channel-Binding), der USERNAME/PASSWORD/NT_DOMAIN erfordert; es ist schwach und authentifiziert den Server nicht, daher warnt pepsi-setup(1). gssapi ist SASL GSSAPI/Kerberos (RFC 4752); es nimmt kein Passwort und bezieht ein Service-Ticket für SERVICE_NAME aus einem Credential-Cache (KRB5CCNAME). Alle werden nur über einen verschlüsselten Transport angeboten (MODE = tls/starttls); ntlm und gssapi lehnen MODE = plain zur Konfigurationszeit ab.

USERNAME / PASSWORD

(Zeichenkette, erforderlich, wenn AUTH plain/login/cram-md5/digest-md5/scram-*/auto/ntlm ist) Die SMTP-AUTH-Zugangsdaten. Halten Sie PASSWORD in einer modusbeschränkten Datei, die mit @inline-secret@ zusammengeführt wird. Für die scram-*-Mechanismen werden beide mit SASLprep (RFC 4013) normalisiert. USERNAME ist auch die optionale Autorisierungsidentität für AUTH = external und AUTH = gssapi.

NT_DOMAIN / NT_WORKSTATION

(Zeichenkette; NT_DOMAIN erforderlich, wenn AUTH = ntlm) Die Windows-Domain des NTLM-Kontos und ein optionaler kosmetischer Client-Workstation-Name.

SERVICE_NAME

(Zeichenkette, optional; AUTH = gssapi) Das host-basierte Kerberos-Service-Principal des Smarthosts, in der Form service@host. Standardwert ist smtp@<HOST>.

KRB5CCNAME

(Zeichenkette, optional; AUTH = gssapi) Der für diesen Smarthost zu lesende Kerberos-Credential-Cache (z. B. FILE:/var/pepsi/krb5/smarthost.cc), der das umgebende KRB5CCNAME überschreibt. Pepsi liest den Cache nur; ein externer Keytab + k5start/cron-Job muss das Ticket frisch halten, und der Cache muss vom Relay-Worker lesbar sein (die SGID-pepsi-token-Gruppe; siehe /var/pepsi/krb5). Ein fehlendes/abgelaufenes Ticket schiebt die Nachricht auf (vorübergehender Fehler), statt sie zu bouncen.

TOKEN_FILE

(Pfad, erforderlich, wenn AUTH = oauth) Datei, die das aktuelle OAuth-2.0-Zugriffstoken enthält (von Leerraum befreit), bei jeder Zustellung neu gelesen. Der SASL-Mechanismus wird aus dem EHLO des Smarthosts gewählt (OAUTHBEARER bevorzugt, sonst XOAUTH2). Die Relay-Stage liest diese Datei nur; halten Sie sie mit pepsi-helper-token-refresh(1) (siehe die [pepsi-helper-token-refresh-*]-Abschnitte) oder einem gleichwertigen externen Job aktuell. Ein fehlendes/abgelaufenes/abgelehntes Token schiebt die Nachricht auf (vorübergehender Fehler), statt sie zu bouncen.

HELO_NAME

(Zeichenkette, optional) Der diesem Smarthost gegenüber in EHLO angekündigte Name. Standardwert ist das SERVER_NAME der Stage.

DOMAINS

(Zeichenkette) Durch Leerraum/Komma getrennte Empfängerdomains, die zu diesem MTA geroutet werden (unabhängig von der Groß-/Kleinschreibung). Erforderlich, sofern nicht CATCH_ALL = yes; eine Domain darf von höchstens einem MTA geroutet werden.

CATCH_ALL

(boolesch, optional) Ob dieser MTA jede Domain erhält, die nicht von einem DOMAINS-Eintrag erfasst wird. Standardwert no; höchstens ein MTA darf es setzen. Ein MTA muss DOMAINS auflisten oder CATCH_ALL = yes setzen.

85.2.1.1.24. Die Abschnitte [pepsi-helper-token-refresh]

Diese konfigurieren pepsi-helper-token-refresh(1), den optionalen Dienst, der die OAuth-Zugriffstokens von AUTH = oauth-Smarthosts aktuell hält. Die Menge der zu pflegenden Tokens wird aus den Smarthost-MTA-Abschnitten abgeleitet: Für jeden [pepsi-stage-relay-to-smarthost-mta-<name>] mit AUTH = oauth sucht der Dienst einen passenden [pepsi-helper-token-refresh-<name>]-Abschnitt. Der Dienst ist nicht Teil von pepsi.target; aktivieren Sie ihn ausdrücklich.

Weil die zielweisen Abschnitte OAuth-Client-Secrets enthalten, halten Sie sie in einer Datei, die nur für den pepsi-helper-token-refresh-Benutzer lesbar ist, und binden Sie jeden mit der @inline-secret@-Direktive ein (die ein Leser, der die Datei nicht öffnen kann — die Relay-Stage, als pepsi ausgeführt — stillschweigend überspringt, sodass dieselbe pepsi.conf für beide parst). Siehe pepsi-helper-token-refresh(1) und das Handbuchkapitel Die Pipeline erweitern.

Der optionale Basisabschnitt [pepsi-helper-token-refresh] enthält dienstweite, nicht-geheime Optionen:

STATE_DIR

(Pfad, optional) Privates Verzeichnis (Modus 0700) für zielweise rotierte Refresh-Tokens. Standardwert /var/pepsi/token-refresh.

Jeder [pepsi-helper-token-refresh-<name>]-Abschnitt (<name> passend zu einem OAuth-Smarthost-MTA) enthält:

TOKEN_ENDPOINT

(Zeichenkette, erforderlich) Die URL des OAuth-2.0-Token-Endpunkts des Anbieters (HTTPS). Sie ist auch, woran der Dienst einen fehlenden Geheimnisabschnitt von einem unlesbaren unterscheidet: Eine @inline-secret@-Datei, die dieses Konto nicht öffnen kann, ist schlicht nicht da, sodass ein fehlendes TOKEN_ENDPOINT dieses Ziel mit einer Warnung überspringt, statt den Dienst scheitern zu lassen. Die übrigen Optionen unten sind dann Fehler und keine Übersprünge.

GRANT

(optional) refresh_token (der Standardwert; z. B. Google) oder client_credentials (z. B. Microsoft 365 reine App).

CLIENT_ID / CLIENT_SECRET

(Zeichenkette, erforderlich) Die OAuth-Client-Zugangsdaten, im Request-Body gesendet.

REFRESH_TOKEN

(Zeichenkette, erforderlich für GRANT = refresh_token) Das langlebige Refresh-Token. Ein vom Endpunkt zurückgegebener rotierter Wert wird unter STATE_DIR persistiert und hat dann Vorrang.

SCOPE

(Zeichenkette, erforderlich für GRANT = client_credentials; sonst optional) Der angeforderte Scope.

REFRESH_MARGIN

(Dauer, optional) Wie lange vor dem angegebenen Ablauf eines Tokens es erneuert wird. Standardwert 5 m. Verwendet nur h/m/s-Einheiten.

85.2.1.1.25. Der Abschnitt [pepsi-payments]

Dieser optionale Abschnitt konfiguriert die GNU-Taler-Zahlungsintegration. Wenn er fehlt (oder MERCHANT_BACKEND_URL nicht gesetzt ist), führt pepsi-setup(1) keine Händler-Prüfungen durch und richtet keinen Webhook ein. Derselbe Abschnitt wird zur Laufzeit von pepsi-stage-anti-spam(1) gelesen, um nachrichtenweise Zahlungs-Bestellungen zu erstellen.

MERCHANT_BACKEND_URL = URL

Basis-URL des Taler-Händler-Backends, optional einschließlich der Instanz (…/instances/$ID). pepsi-setup(1) fragt GET /config an der Backend-Wurzel ab (ein etwaiges nachgestelltes /instances/$ID wird entfernt), um zu bestätigen, dass es ein taler-merchant-Backend ist, und GET /private/orders?limit=1 an dieser URL, um das Zugriffstoken zu bestätigen. Erforderlich, um die Integration zu aktivieren.

Sie muss eine https://-URL sein oder eine http://-URL, deren Host das Loopback-Interface ist (localhost, 127.0.0.0/8, ::1). MERCHANT_ACCESS_TOKEN wird jeder Anfrage als Bearer-Credential angehängt, sodass ein Klartext-Backend irgendwo sonst — einschließlich „es ist ja nur im LAN“ — dieses langlebige Credential an alles weitergibt, was auf dem Pfad sitzt. Anfragen sind begrenzt (10 s zum Verbinden, 30 s insgesamt), sodass ein nicht antwortendes Backend die Nachricht scheitern lässt und nicht die Stage.

MERCHANT_ACCESS_TOKEN = TOKEN

Zugriffstoken für das Händler-Backend, in der Taler-secret-token:…-Form, als Authorization: Bearer-Credential gesendet. Es benötigt die Berechtigungen orders-read und webhooks-read/webhooks-write. Erforderlich, wenn MERCHANT_BACKEND_URL gesetzt ist.

Der eingerichtete pepsi-resume-Webhook feuert beim pay-Ereignis und POSTet {"message_id":"{{order_id}}"} an https://<host>/resume (den kürzesten [pepsi-httpd-cert-*]-SNI-Host), authentifiziert mit [pepsi-httpd] RESUME_AUTHORIZATION_TOKEN. Die Händler-order_id muss daher dem externen Token der Nachricht entsprechen.

85.2.1.1.26. Der Abschnitt [pepsi-vacation-default-message]

Die Urlaubsnotizen je Sprache, auf die pepsi-stage-vacation(1) zurückfällt, eine Option je Sprache:

[pepsi-vacation-default-message]
EN = Hello {{SENDER_NAME}},  I am away until {{VACATION_END}}.
DE = Hallo {{SENDER_NAME}},  ich bin bis {{VACATION_END}} abwesend.

Der Optionsname ist das Sprach-Tag (EN, DE, PT_BR — beliebiger Trenner), und der Wert ist eine Mustache-Vorlage. Welche Sprache verwendet wird, welche Felder expandieren und warum zwei Leerzeichen zu einem Zeilenumbruch werden, ist alles in pepsi-stage-vacation(1) dokumentiert.

Dieser Abschnitt existiert normalerweise bereits. make install liefert ihn als ${DATADIR}/config.d/vacation.conf aus, und talers Konfigurationslader parst jede Datei in ${DATADIR}/config.d vor pepsi.conf. Eine Stage, die ohne eigene Nachricht konfiguriert ist, hat also dennoch zehn Sprachen verfügbar, und ein Operator, der einen anderen Wortlaut will, definiert nur die Sprache neu, die ihn interessiert, in pepsi.conf: Spätere Definitionen gewinnen Option für Option, nie Abschnitt für Abschnitt, sodass das Überschreiben von EN die anderen neun bestehen lässt. Die ausgelieferte Datei zu bearbeiten funktioniert auch, aber ein Paket-Upgrade überschreibt sie.

Der Abschnittsname ist nur ein Standardwert (DEFAULT_MESSAGE_SECTION), sodass ein Operator, der mehrere Nachrichtenmengen will — eine förmliche für eine Support-Adresse, eine knappe für alle anderen —, weitere Abschnitte definieren und verschiedene Stages, Domains oder Adressen darauf richten kann.

Ein Kontoinhaber fasst diesen Abschnitt nie an: Sein eigener Text geht in MESSAGE_<LANG> im eigenen Abschnitt der Stage, den die Einstellungsschicht tragen kann und der je Sprache gewinnt.

85.2.1.1.27. Der Abschnitt [pepsi-autoconfig]

Dieser optionale Abschnitt veröffentlicht die Autokonfiguration von Mailkonten (draft-ietf-mailmaint-autoconfig): das XML-Dokument, das ein Mailclient abholt, wenn er nur die Adresse des Benutzers kennt, sodass er sich selbst konfigurieren kann, statt nach acht Einstellungen zu fragen, die der Benutzer üblicherweise nicht liefern kann. Es wird von pepsi-httpd(1) unter /mail/config-v1.1.xml auf autoconfig.<domain> und unter /.well-known/autoconfig/mail/config-v1.1.xml auf der Maildomain selbst bedient.

Die Funktion ist aus, bis ein eingehender Server benannt ist. Lassen Sie den Abschnitt weg — oder setzen Sie weder IMAP_HOST noch POP3_HOST —, und beide Endpunkte antworten mit 404. Ein Client, der ein Konfigurationsdokument findet, hört auf, die Rückfallkette abzulaufen, sodass eines zu veröffentlichen, das ihm nicht sagen kann, wie er Mail liest, den Benutzer schlechter dastehen lässt, als überhaupt nichts zu veröffentlichen.

Pepsi bedient keine Postfächer (siehe pepsi-stage-relay-to-lmtp(1)), sodass die eingehende Hälfte den MDA benennen muss, mit dem die Installation kombiniert ist, typischerweise Dovecot auf demselben Host.

Zwei Dinge außerhalb dieser Datei werden ebenfalls gebraucht. Ein autoconfig.<domain>-DNS-Eintrag muss auf diesen Server auflösen, und das TLS-Zertifikat muss diesen Namen abdecken — Clients versuchen die https://autoconfig.…-URL zuerst, und ein Zertifikatsfehler dort ist eine fehlgeschlagene Abfrage. Die Zertifikatshälfte wird für Sie erledigt, wenn pepsi-setup(1) Zertifikate einrichtet: Benennt dieser Abschnitt einen eingehenden Server, so fügt es für jede bediente Domain autoconfig.<domain> zu den Namen hinzu, die es für das TLS-[pepsi-httpd-listener-*]-Zertifikat anfordert. Der DNS-Eintrag nicht, denn er wird in Ihrer Zone veröffentlicht. Eine Installation, die den Namen nicht hinzufügen möchte, kann sich allein auf die /.well-known/-Form verlassen, um den Preis, nur von Clients gefunden zu werden, die sie versuchen.

IMAP_HOST, POP3_HOST

(Hostname, optional) Der anzukündigende Postfachserver. Einen zu setzen aktiviert die Funktion; keinen zu setzen deaktiviert sie. Kein Standardwert — ein erfundener Hostname wäre schlimmer als Schweigen.

IMAP_PORT, POP3_PORT

(Zahl, optional) Standardwerte 993 und 995, die Implizit-TLS-Ports.

IMAP_SOCKET, POP3_SOCKET

(``SSL`` | ``STARTTLS`` | ``plain``, optional) Transportsicherheit, im Vokabular des Drafts selbst (SSL bedeutet implizites TLS); tls und none werden als Schreibweisen von SSL und plain angenommen. Standardwert SSL.

IMAP_AUTH, POP3_AUTH

(optional) Einer der Authentifizierungswerte des Drafts: password-cleartext, password-encrypted, NTLM, GSSAPI, TLS-client-cert, OAuth, client-IP-address, none. Standardwert password-cleartext — was über SSL die gewöhnliche Passwort-über-TLS-Anordnung ist und nicht etwas im Klartext Gesendetes. Ein unbekannter Wert ist ein Startfehler, kein stillschweigend veröffentlichter Tippfehler.

SMTP_HOST, SMTP_PORT, SMTP_SOCKET, SMTP_AUTH

(optional) Der anzukündigende Submission-Server. Lassen Sie normalerweise alle vier weg: Sie werden aus dem [pepsi-ingress-listener-*]-Abschnitt abgeleitet, der mit SUBMISSION = yes markiert ist — seinem Port, seinem MODE und seinem Authentifizierungsmechanismus —, sodass das Verschieben der Submission von STARTTLS auf 587 zu implizitem TLS auf 465 das veröffentlichte Dokument von selbst aktualisiert und die beiden nicht auseinanderdriften können. Setzen Sie sie nur, wenn der öffentliche Submission-Endpunkt nicht der Listener ist, etwa hinter einem Load Balancer. SMTP_HOST zu setzen schaltet die Ableitung vollständig ab, geben Sie also auch die übrigen an, wenn sie von 587/STARTTLS/password-cleartext abweichen.

Ein Submission-Listener über UNIX-Socket oder systemd-Aktivierung wird nie angekündigt: Ein entfernter Client kann den ersten nicht verwenden, und der zweite hat keinen Port in der Konfiguration, der zu veröffentlichen wäre.

DISPLAY_NAME, DISPLAY_SHORT_NAME

(Text, optional) Was der Client dem Benutzer zeigt. Beide fallen auf den ersten [pepsi-ingress] ACCEPTED_DOMAINS-Eintrag zurück (den HOSTNAME des Ingress, wenn keine Domain konfiguriert ist).

DOCUMENTATION_URL

(URL, optional) Eine Hilfeseite für die Kontoeinstellungen, als <documentation>-Element des Drafts veröffentlicht. Weggelassen, wenn nicht gesetzt.

[pepsi-autoconfig]
IMAP_HOST = mail.example.org
POP3_HOST = mail.example.org
DISPLAY_NAME = Example Mail
DISPLAY_SHORT_NAME = Example
# SMTP_* deliberately omitted: derived from the submission listener.

85.2.1.1.28. Der Abschnitt [pepsi-tlsrpt]

Dieser optionale Abschnitt konfiguriert SMTP TLS Reporting (RFC 8460). Er hat zwei unabhängige Hälften; lassen Sie den Abschnitt weg, um beide zu deaktivieren. pepsi-setup(1) liest ihn für die ankündigende Hälfte; die Sender-Hälfte wird zur Laufzeit von den Relay-Stages (Sitzungsaufzeichnung) und pepsi-tlsrpt(1) (dem täglichen Berichts-Job) gelesen.

RUA = URI [, URI …]

Berichtsadresse(n), die im _smtp._tls.<domain>-TXT-Eintrag angekündigt werden, den pepsi-setup(1) für jede Domain ausgibt, sodass andere Absender ihre TLS-Ergebnisse zu unseren Domains an uns melden. Eine mailto:- oder https:-URI oder eine kommagetrennte Liste, wörtlich gespeichert. Wenn nicht gesetzt, wird kein Eintrag veröffentlicht.

SEND_REPORTS = yes | no

Ob die Relay-Stages jede ausgehende TLS-Sitzung in pepsi.tls_session festhalten. Optional; Standardwert no. Es ist nur der Schalter für die Aufzeichnungs-Hälfte: pepsi-tlsrpt(1) prüft ihn nicht, es findet schlicht keine Sitzungen zu berichten, wenn nichts sie aufzeichnet.

REPORT_FROM = ADDRESS

Umschlagabsender und From: der Berichts-E-Mails, die pepsi-tlsrpt(1) sendet. Erforderlich, um Berichte zu senden (seine Domain ist der Berichts-Einlieferer). Berichte sind kein Null-Absender (RFC 8460 §5.3: sie müssen DKIM/DMARC-alignbar sein); die Bericht-über-einen-Bericht-Schleife wird durch das injizierte state.tlsrpt-Flag verhindert.

REPORT_STAGE = STAGE

Pipeline-Stage, bei der Berichts-E-Mails injiziert werden (sodass sie signiert und weitergeleitet werden), wie das BLOCK_RESPONSE_STAGE von pepsi-stage-anti-spam(1). Muss eine existierende [stage-*] referenzieren. Erforderlich, um Berichte per E-Mail (mailto:) zu versenden.

ORGANIZATION = NAME

organization-name, der in ausgegebene Berichte gesetzt wird. Optional; Standardwert ist die REPORT_FROM-Domain.

CONTACT = ADDRESS

contact-info, die in ausgegebene Berichte gesetzt wird. Optional.

RETAIN_DAYS = DAYS

Wie viele Tage pepsi-tlsrpt prune die pepsi.tls_session-Zähler behält. Optional; Standardwert 7. pepsi-tlsrpt-prune.timer führt das Bereinigen täglich aus.

85.2.1.1.29. Der Abschnitt [pepsi-telemetry-client]

Dieser optionale Abschnitt konfiguriert den lokalen Funktionstelemetrie-Aggregator pepsi-telemetry-client(1). Alle Optionen haben funktionierende Standardwerte; die gesamte Funktion wird durch [pepsi] SHARE_TELEMETRY oben reguliert, das aus ist, sofern der Operator es nicht eingeschaltet hat — sodass nichts hier eine Wirkung hat, bis es das ist. (Der zentrale Collector, pepsi-telemetry(1), liest stattdessen den separaten [pepsi-telemetry]-Abschnitt.)

UNIXPATH = PATH

Lokaler UNIX-Socket, auf dem der Daemon auf Funktionsereignisse lauscht; derselbe Pfad, mit dem sich die Produzenten-Programme verbinden. Optional; Standardwert /run/pepsi-telemetry/socket.

UNIXPATH_GROUP = GROUP

Gruppe, auf die der Socket chgrp-t wird (Modus UNIXPATH_MODE), damit sich die Benutzer pepsi (Stage-Worker) und pepsi-ingress verbinden können. Optional; Standardwert pepsi-telemetry.

UNIXPATH_MODE = OCTAL

Rechtebits des Sockets. Optional; Standardwert 660.

SUBMIT_INTERVAL = DURATION

Intervall zwischen Übermittlungen an den Collector (nur h/m/s-Einheiten — siehe den Dauer-Hinweis oben). Optional; Standardwert 60 s. Null ist ein Konfigurationsfehler und keine Endlosschleife.

MAX_FEATURES = N

Obergrenze für die Anzahl der im Speicher gehaltenen verschiedenen Funktionsnamen, die den Speicher gegen einen fehlerhaften lokalen Produzenten begrenzt. Optional; Standardwert 4096.

85.2.1.1.30. Gespeicherte Daten

Für jede angenommene Nachricht fügt pepsi-ingress(1) einen Datensatz in die pepsi.workqueue-Tabelle ein, der einen lokalen Bezeichner (workqueue_id), ein zufälliges token, den Empfangs-Zeitstempel (received_at), den Umschlagabsender (mail_from; die leere Zeichenkette für den Null-Absender <>), die Umschlagempfängerliste (rcpt_to) und die geparsten from_header- und subject-Header enthält. Die Nachricht selbst wird aufgeteilt in zwei Teilen gespeichert — eine headers-Spalte (der RFC-5322-Header-Block bis, aber nicht einschließlich des Leerzeilen-Trenners, mit vorangestelltem RFC-5321-§4.4-Trace-Received:-Header und darüber dem Authentication-Results-Header; das ARC-Set wird später von pepsi-stage-arc(1) hinzugefügt) und ein Nachrichtentext (alles nach der Leerzeile; leer für eine reine Header-Nachricht). Die Rekonstruktions-Invariante ist raw = headers || CRLF || body. Das Aufteilen der Nachricht lässt Stages, die nur die Header oder den Umschlag berühren, nur die headers-Spalte laden (und umschreiben) und nie den (potenziell großen) Nachrichtentext ziehen.

Der Nachrichtentext ist keine Spalte von pepsi.workqueue, sondern ein Datensatz einer eigenen Tabelle, pepsi.workqueue_body (body_id, body und die berechnete Größe octets), auf den der Nachrichten-Datensatz über body_id verweist. Das verhindert, dass eine Nachricht mit mehreren Empfängern einmal pro Empfänger gespeichert wird: Jeder daraus abgespaltene Datensatz — Einstellungen pro Adresse, der eine Datensatz pro Empfänger einer Relay-Stage, der Fan-out einer Mailingliste, ein Bounce oder eine DSN pro Empfänger — verweist auf denselben Nachrichtentext-Datensatz, sodass ein Beitrag von 25 MiB an tausend Mitglieder ein Nachrichtentext von 25 MiB und tausend kleine Datensätze ist. Eine Stage, die einen Nachrichtentext umschreibt (Entschlüsselung, die Fußzeile einer Liste), speichert einen neuen Nachrichtentext-Datensatz und lässt nur ihre eigene Nachricht darauf verweisen (Copy-on-Write), sodass kein Umschreiben ein Geschwister erreichen kann. Ein Nachrichtentext wird von einem Trigger gelöscht, sobald der letzte darauf verweisende Datensatz gelöscht oder umgelenkt wird, und pepsi-dispatch(1) räumt die seltene Waise auf, die ein Wettlauf hinterlässt (pepsi.workqueue_body_gc()). header_octets ist die passende berechnete Größe von headers; die beiden Größenspalten sind das, was die Zulassungsprüfung der Warteschlange (MAX_QUEUE_BYTES, pepsi.queue_usage()) aufsummiert, lesbar für Rollen, die die Nachricht selbst nicht lesen dürfen. Die berechneten SPF-, DKIM- und DMARC-Urteile werden im state des Datensatzes unter einem auth-Schlüssel gespeichert und die authserv_id unter state.origin; das arc-Urteil beginnt als none und wird von der ARC-Stage ausgefüllt. Der Dispatcher wird aus dieser Transaktion nicht benachrichtigt: pepsi-ingress(1) fasst Zulassungen zusammen und gibt höchstens ein Wecken je DISPATCH_WAKE_INTERVAL aus, außerhalb des Bandes und nachdem die Datensätze committet sind, mit leerer Nutzlast (siehe die Beschreibung jener Option oben). Ein LISTEN workqueue-Konsument bekommt daher keine Benachrichtigung je Nachricht und keine Nutzlast zum Parsen.

Jeder Datensatz trägt zusätzlich seinen Verarbeitungszustand für die Stage-Pipeline, die nach dem Ingress läuft: eine stage (den [stage-<stage>]-Abschnitt des aktuell für das Weiterschalten der Nachricht zuständigen Programms), einen status (eines von pending, running, paused, failed oder timeout), ein state (das mit der Nachricht mitgeführte JSON-Objekt, in pepsi.state(7) dokumentiert) und ein timeout (wann eine paused-Nachricht erneut eingereiht werden soll). Jede neue Nachricht wird explizit bei der Anfangs-Stage eingefügt — stage = init, status = pending — sodass sie bei [stage-init] in die Pipeline eintritt. Diese Spalten werden mit pepsi-queue(1) inspiziert und repariert.

pepsi.workqueue (mit seinen Nachrichtentexten in pepsi.workqueue_body) ist die einzige Warteschlange für Nachrichten in Bearbeitung; das Schema hat insgesamt etwa sechzig Tabellen. Diejenige, die neben der Warteschlange jede Installation nutzt, ist pepsi.dns_address: ein Cache aufgelöster A/AAAA-Adressen für Mail-Exchanger-Hosts von Empfängern, mit Verbindungs-Gesundheit pro Adresse, gepflegt von pepsi-stage-relay-to-internet(1). Jeder Datensatz hält einen host, eine aufgelöste address, das DNS-TTL expires_at, ein failed-Flag und die last_success_at-Zeit fest, sodass eine funktionierende Adresse bevorzugt wird, bis ihr TTL abläuft, und ein Host neu aufgelöst wird, sobald alle seine zwischengespeicherten Adressen fehlgeschlagen oder abgelaufen sind. Sie trägt keine Nachrichtendaten und wird nicht von pepsi-queue(1) verwaltet.

Der Rest sind die Funktionstabellen, jede bei der Komponente beschrieben, der sie gehört: die Pipeline-Zähler stage_stats und dispatch_stats (pepsi-dispatch(1), von pepsi-httpd(1) unter /metrics exportiert), whitelist (pepsi-whitelist(1)), tls_session (pepsi-tlsrpt(1)), settings (pepsi-settings(1)), vacation_reply (pepsi-stage-vacation(1)), payment_request_reply (pepsi-stage-anti-spam(1)), secretary_challenge und secretary_sent (pepsi-stage-secretary(1)), mailbox_quota (pepsi-quota(1)), config_override (die Datenbank-Konfigurationsschicht, pepsi-config(1)), origin_nonce und auto_pay_spend (pepsi-stage-auto-pay(1)), telemetry (pepsi-telemetry(1)), secure_message und secure_access (pepsi-secure-link(1)), der Schlüsselspeicher crypto_identity / peer_key / peer_has_own_key / ca_trust / key_request (pepsi-keys(1) und pepsi-keydisc(1)), die Mailinglisten-Tabellen mailing_list und list_* (pepsi-list(1)), das Listenarchiv archive_* (pepsi-archive(1)), die Logs event_log und mail_log sowie die administrative Oberfläche admin_account / admin_session / api_token / setup_task / setup_task_log (pepsi-httpd(1) und pepsi-setup(1)). Sie alle werden von pepsi-setup(1) angelegt. Abgesehen von secure_message (Chiffretext, der auf seinen Empfänger wartet), dem Listenarchiv, dessen Zweck es ist, Beiträge aufzubewahren, und den Nachrichten, die eine Liste zur Moderation zurückhält, hält keine Nachrichteninhalt.

Die state-Spalte ist das mit der Nachricht vom Ingress bis zu ihrer terminalen Stage mitgeführte JSON-Objekt; sie ist der Kanal, über den Stages kommunizieren. Ingress sät darin die SMTP-Ursprungs-Herkunftsdaten der Verbindung, die eingehenden SPF/DKIM/DMARC-Urteile und etwaige RFC-3461-DSN-Parameter; spätere Stages führen ihre eigenen Urteile und Zwischendaten ein. Ihr vollständiges Layout — jeder Schlüssel, wer ihn schreibt und wer ihn verbraucht — ist in pepsi.state(7) dokumentiert.

85.2.1.1.31. Beispiel

Ein vollständiger Weiterleiter: auf den drei kanonischen SMTP-Ports empfangen, beim Eintreffen per ARC versiegeln, per SRS umschreiben, direkt zum MX zustellen und Fehler bouncen (den Bounce vor der Zustellung signieren):

[pepsi]
KEY_DIR = /var/pepsi/keys
DKIM_SELECTOR = pepsi
ARC_DOMAIN = example.org
ARC_ALGORITHM = rsa

[pepsi-postgres]
CONFIG = postgres:///pepsi
# SQL_DIR defaults to ${DATADIR}/sql; set it when running from a checkout.

[pepsi-ingress]
HOSTNAME = mail.example.org
ACCEPTED_DOMAINS = example.org example.com
MAX_MESSAGE_SIZE = 26214400

# The three canonical SMTP listeners. TLS_CERT/TLS_KEY are omitted so
# pepsi-setup auto-fills the certbot path and obtains the certificate.

# Port 25: cleartext with opportunistic STARTTLS.
[pepsi-ingress-listener-mx]
SERVE = tcp
BIND_TO = 0.0.0.0
PORT = 25
MODE = starttls
MYNETWORKS = 127.0.0.0/8 ::1/128 10.0.0.0/8

# Port 465: implicit TLS (SMTPS), authenticated submission via Dovecot SASL.
[pepsi-ingress-listener-submissions]
SERVE = tcp
BIND_TO = 0.0.0.0
PORT = 465
MODE = tls
SUBMISSION = yes
SASL_TYPE = dovecot
SASL_PATH = /run/dovecot/auth-client-pepsi

# Port 587: cleartext submission upgraded with STARTTLS.
[pepsi-ingress-listener-submission]
SERVE = tcp
BIND_TO = 0.0.0.0
PORT = 587
MODE = starttls
SUBMISSION = yes
SASL_TYPE = dovecot
SASL_PATH = /run/dovecot/auth-client-pepsi

[pepsi-srs]
SRS_DOMAIN = srs.example.org
SECRET_FILE = /etc/pepsi/srs.secret

# init: ARC-seal the message as received, then hand to SRS.
[stage-init]
PROGRAM = pepsi-stage-arc
NEXT_STAGE = srs

[stage-srs]
PROGRAM = pepsi-stage-srs
NEXT_STAGE = deliver

# deliver: direct-to-MX; failures go to the bounce stage.
[stage-deliver]
PROGRAM = pepsi-stage-relay-to-internet
SERVER_NAME = mail.example.org
POSTMASTER = postmaster@example.org
BOUNCE_STAGE = bounce
# This host's public sending IP(s); pepsi-setup unions PUBLIC_IP from every
# relay stage into the SPF record.
PUBLIC_IP = 203.0.113.7 2001:db8::25

# bounce: build an unsigned DSN, sign it, then deliver it.
[stage-bounce]
PROGRAM = pepsi-stage-bounce
SERVER_NAME = mail.example.org
POSTMASTER = postmaster@example.org
NEXT_STAGE = bounce-sign
BOUNCE_MESSAGE = default

[stage-bounce-sign]
PROGRAM = pepsi-stage-dkim-sign
NEXT_STAGE = deliver

Um stattdessen über einen Smarthost weiterzuleiten, ersetzen Sie das PROGRAM der deliver-Stage durch pepsi-stage-relay-to-smarthost und fügen [pepsi-stage-relay-to-smarthost-mta-*]-Abschnitte hinzu, z. B.:

[pepsi-stage-relay-to-smarthost-mta-smarthost]
HOST = smtp.relay.example.net
PORT = 587
CATCH_ALL = yes

85.2.1.1.32. Dateien

Jede Pepsi-Komponente liest dieselbe Datei. Wenn eine Komponente ohne –config gestartet wird, wird der erste vorhandene Pfad aus der folgenden Liste verwendet:

• $XDG_CONFIG_HOME/pepsi.conf

• $HOME/.config/pepsi.conf

• /etc/pepsi/pepsi.conf

• /etc/pepsi.conf

pepsi-setup --wizard schreibt /etc/pepsi/pepsi.conf; make install legt daneben eine Referenzdatei pepsi.conf.sample ab, die jede Option dokumentiert, selbst aber keine funktionierende Konfiguration ist.

Bevor diese Datei gelesen wird, wird jede *.conf in ${DATADIR}/config.d geparst, sodass paketierte Standardwerte an Ort und Stelle sind und pepsi.conf sie Option für Option überschreibt (ein in beiden definierter Abschnitt wird zusammengeführt, nicht ersetzt). Zwei werden ausgeliefert:

• vacation.conf — die Urlaubsnotizen je Sprache; siehe Der Abschnitt [pepsi-vacation-default-message] oben.

• thunderbird.conf — [pepsi] CRYPTO_ALLOW_DOWNGRADE = yes, sodass S/MIME als AES-256-CBC-EnvelopedData hinausgeht, was Thunderbird lesen kann und was unser einkompilierter AES-256-GCM-Standardwert nicht ist. Die Datei erklärt sich ausführlich selbst und ist dazu gedacht, löschbar zu sein: Sie zu entfernen stellt die authentifizierte Verschlüsselung ohne weitere Änderung wieder her.

Diese Dateien gehören dem Paket: Definieren Sie die gewünschten Optionen in pepsi.conf neu, statt sie zu bearbeiten, sonst verwirft ein Upgrade die Änderung.

85.2.1.1.33. Siehe auch

pepsi-ingress(1), pepsi-dispatch(1), pepsi-httpd(1), pepsi-setup(1), pepsi-config(1), pepsi-queue(1), pepsi-status(1), pepsi-sendmail(1), pepsi-whitelist(1), pepsi-settings(1), pepsi-tlsrpt(1), pepsi-quota(1), pepsi-failure-bouncer(1), pepsi-list(1), pepsi-keys(1), pepsi-keydisc(1), pepsi-secure-link(1), pepsi-detect-language(1), pepsi-telemetry(1), pepsi-telemetry-client(1), pepsi-helper-token-refresh(1), pepsi-helper-auto-pay(1), pepsi-helper-mailbox-scan(1), pepsi-stage-arc(1), pepsi-stage-srs(1), pepsi-stage-encrypt(1), pepsi-stage-decrypt(1), pepsi-stage-autocrypt-learn(1), pepsi-stage-secure-link(1), pepsi-stage-vks-confirm(1), pepsi-stage-route(1), pepsi-stage-dkim-sign(1), pepsi-stage-relay-to-internet(1), pepsi-stage-relay-to-smarthost(1), pepsi-stage-relay-to-lmtp(1), pepsi-stage-relay-to-maildir(1), pepsi-stage-dot-forward(1), pepsi-stage-bounce(1), pepsi-stage-discard(1), pepsi-stage-anti-spam(1), pepsi-stage-auto-pay(1), pepsi-stage-check-whitelist(1), pepsi-stage-auto-whitelist(1), pepsi-stage-detect-language(1), pepsi-stage-block-language(1), pepsi-stage-if(1), pepsi-stage-milter(1), pepsi-stage-aliases(1), pepsi-stage-vacation(1), pepsi-stage-edit-settings(1), pepsi-archive(1), pepsi-stage-list(1), pepsi-stage-list-post(1), pepsi-stage-list-deliver(1), pepsi-stage-list-command(1), pepsi-stage-list-bounce(1), pepsi.state(7), systemd.socket(5)

85.2.1.1.34. Fehler

Melden Sie Fehler an den Pepsi-Issue-Tracker.