5. Der Assistent

pepsi-setup --wizard führt ein kurzes Interview und schreibt eine vollständige, bereits validierte pepsi.conf. Es ist der vorgesehene Weg zu einer ersten Konfiguration: das nächste Kapitel, Konfiguration, erklärt die Datei, die der Assistent schreibt, und dieses erklärt, wie die Antworten zu dieser Datei werden.

Die Stage-Pipeline wird aus den Antworten zusammengesetzt. Welche Stages es gibt und wie ihre Optionen NEXT_STAGE und BOUNCE_STAGE zusammengeschaltet sind, ergibt sich mechanisch aus der Richtung, die der Host bedient, und den eingeschalteten Funktionen. Es gibt kein Menü von Pipelines zur Auswahl und keine Vorlage, die ausgefüllt wird; der Graph wird berechnet. Dieses Kapitel zeigt die drei Pipelines, die der Assistent bauen kann, und dann, welche Frage jede Stage darin einfügt oder entfernt.

Bemerkung

Dieses Kapitel beschreibt, was die Antworten bewirken. Die betrieblichen Einzelheiten des Befehls — jedes Flag, die MTA-Migration, die readline-Tastenbelegungen, das Verhalten der Geheimnisabfragen, das Format der Antwortdatei — stehen in pepsi-setup(1).

5.1. Wie ein Lauf abläuft

  1. Import. Auf einem Host ohne pepsi.conf erkennt der Assistent ein vorhandenes Postfix, Exim, Sendmail, qmail oder Stalwart und bietet an, dessen Einstellungen als Standardwerte des Interviews einzulesen. Nichts wird stillschweigend übernommen — jeder importierte Wert wird weiterhin an seiner eigenen Eingabeaufforderung angezeigt. Bei einem erneuten Lauf liefert stattdessen der Abschnitt [pepsi-wizard] der vorhandenen Datei die Standardwerte.

  2. Interview. Die Fragen unten, gruppiert in nummerierte Schritte. Jede Antwort wird bei der Eingabe validiert, sodass eine fehlerhafte Domain oder ein fehlerhafter Port an der eigenen Eingabeaufforderung auffällt.

  3. Rendern. Die Antworten werden in eine Konfigurationsdatei umgesetzt — hier wird die Pipeline zusammengesetzt.

  4. Validieren. Der gerenderte Text wird über genau denselben Pfad geladen und validiert, den pepsi-setup run benutzt. Schlägt das fehl, gibt der Assistent den Fehler aus und geht die Fragen erneut durch, mit den vorherigen Antworten vorbelegt, sodass das Korrigieren einer Option ein Durchdrücken der Eingabetaste am Rest vorbei ist.

  5. Schreiben. Die Datei wird geschrieben, und die Geheimnisse darin (der SRS-HMAC-Schlüssel, die Passwörter für Smarthost und LMTP, die Token für Händler und /resume) werden in modusbeschränkte secrets.d/*.secret-Fragmente ausgelagert, auf die @inline-secret@-Direktiven verweisen. Das Geschriebene wird anschließend erneut geladen und erneut validiert, weil das Auslagern der Geheimnisse es umgeschrieben hat.

  6. Setup anbieten. Das Schema installieren, DKIM-Schlüssel erzeugen, TLS-Zertifikate einrichten und die zu veröffentlichenden DNS-Einträge ausgeben sind Aufgabe von pepsi-setup run, nicht des Interviews. Der Assistent bietet an, direkt dorthin überzugehen.

Dasselbe Interview stellt auch die Setup-Konsole im Browser (siehe Die Verwaltungskonsole).

5.2. Dasselbe Interview in einem Browser

Es gibt kein zweites Interview. Jede Frage, ihre Form, ihr Standardwert, ihr Hilfetext und die Bedingungen, unter denen sie gestellt wird, liegen an einer Stelle als Daten (pepsi_setup_model::questions), und beide Front-Ends rendern dieses Modell — eine Frage kann also nicht dem einen hinzugefügt werden und dem anderen nicht, und ein Test prüft, dass die beiden Bezeichnermengen gleich sind. Unterschiedlich ist nur die Darstellung: das Terminal stellt eine Frage nach der anderen unter den unten aufgeführten Schritt-Bannern, die Konsole zeigt ihre eigene, gröbere Gruppierung derselben Fragen, eine Seite nach der anderen.

Der Schritt „Serveridentität“ der Setup-Konsole im Browser

Der erste Schritt. Jedes Feld trägt dieselbe Hilfe, die das Terminal ausgibt, und — wo die Antwort genau einer Option entspricht — das [section] OPTION, in dem sie landen wird, sodass dieselbe Stellschraube danach in der Datei zu finden ist. Der Streifen am oberen Rand ist das ganze Interview, mit Markierung der bereits beantworteten Schritte.

Auch die Verzweigung gehört dem Modell, die Konsole blendet also aus, was das Terminal nicht fragen würde. Unten hat das Einschalten der Sprachblockierung die Felder für Richtlinie, Schwellwert und Durchsetzung eingeblendet — und die Frage Bounce-Nachrichten lokalisieren entfernt, weil Blockieren die Erkennung bereits voraussetzt und das Terminal jene Frage nur stellt, wenn Blockieren aus ist:

Der Schritt „Inhaltsfilterung“, mit eingeblendeten Feldern der Sprachrichtlinie

Inhaltsfilterung, mit eingeschaltetem Blockieren.

Zwei Dinge zur Konsole:

  • Antworten sind Entwürfe. Jeder Schritt wird in der Datenbank zwischengelagert, nicht nach /etc geschrieben; nichts wird wirksam, bis das Interview angewendet wird. Eine Sitzung, die auf halbem Weg in ein Timeout läuft, hat keinen Mailserver halb konfiguriert.

  • Die Konsole fragt; sie handelt nicht. Sie läuft unprivilegiert und kann weder pepsi.conf schreiben noch certbot ausführen noch das Schema installieren. Ein Speichern hält eine Anfrage fest, die das separat gestartete, als root laufende pepsi-setup apply validiert und ausführt. Auf einem Host, auf dem diese privilegierte Hälfte nicht installiert ist — sie ist ein eigenes Debian-Paket —, werden die Setup-Seiten nur lesend dargestellt: jeder Wert wird angezeigt, die Bedienelemente sind deaktiviert und der Grund steht daneben, statt Antworten in eine Warteschlange aufzunehmen, die niemand leert.

Die Bildschirmfotos werden von contrib/screenshot-setup.sh aus den ausgelieferten Vorlagen und dem Stylesheet erzeugt und lassen sich so wieder mit dem Code in Übereinstimmung bringen.

5.3. Die erste Frage bestimmt die Form

Vor jedem Schritt-Banner fragt der Assistent:

Mail direction this host serves [both]: inbound | outbound | both

Alles Weitere folgt daraus. inbound heißt, dieser Host empfängt Mail für Ihre Domains aus dem Internet; outbound heißt, er leitet weiter, was Ihre eigenen Benutzer und lokalen Programme einliefern; both — der Standardwert — heißt, er tut beides, und die beiden Flüsse werden an der ersten Stage getrennt. Die Antwort entscheidet, welche SMTP-Listener geschrieben werden, welche der späteren Schritte überhaupt gestellt werden und welche der drei Pipelines unten gebaut wird.

5.3.1. Pipeline: both

Die Einstiegs-Stage ist eine Verzweigung über state.local_origin — das Flag, das pepsi-ingress für eine authentifizierte Submission setzt —, sodass eine Nachricht, die dieser Host empfangen hat, und eine Nachricht, die unser eigener Benutzer gesendet hat, nie dieselbe Stage teilen. ARC gibt es, um die Authentifizierungsurteile einer vorgelagerten administrativen Domain über unseren Weiterleitungs-Hop zu tragen; die Submissions unserer eigenen Benutzer zu versiegeln würde deren SPF/DKIM/DMARC-Ergebnisse der Welt bekanntgeben.

                 pepsi-ingress
 Internet ──▶ :25           :465 / :587 ◀── your users
               │                 │       (and the local sendmail
               └────────┬────────┘        socket, always served)
                        ▼
                      init            pepsi-stage-if on
                        │             state.local_origin
         ┌──────────────┴────────┐
   false │                       │ true  (our own submissions)
         ▼                       ▼
the received branch              list-out            MAILING_LISTS
(second panel below)             │
                                 ▼
                                 wallet              WALLET_SELF_SERVICE
                                 │
                                 ▼
                                 edit-settings       EDIT_SETTINGS
                                 │
                                 ▼
                                 encrypt             CRYPTO
                                 │
                                 ▼
                                 auto-whitelist      LEARN_WHITELIST,
                                                     ANTI_SPAM or SECRETARY
                                 │
                                 ▼
                                 milter-*            imported
                                                     non_smtpd_milters
                                 │
                                 ▼
                                 dkim-sign           (always)
                                 │
                                 ▼
                                 internet            (always)

Und der Empfangszweig, in dem nahezu jede Funktion sitzt:

(the false branch of the split above)
                │
                ▼
                arc                  pepsi-stage-arc
                │
                ▼
                decrypt              CRYPTO
                │
                ▼
                detect-language      LANGUAGE_BLOCKING
                                     or I18N_BOUNCES
                │
                ▼
                block-language       LANGUAGE_BLOCKING
                │
                ▼
                milter-*             MILTER_* (one per filter found)
                │
                ▼
                check-whitelist      ANTI_SPAM or SECRETARY
                │
                ▼
                secretary            SECRETARY
                │
                ▼
                anti-spam            ANTI_SPAM
                │
                ▼
                autocrypt-learn      AUTOCRYPT_LEARN
                │
                ▼
                list ──▶ list-post   MAILING_LISTS
                │        list-command
                │        list-bounce
                ▼
                aliases              ALIASES_ENABLED
                │
                ▼
                vacation             VACATION
                │
                ▼
                route ──▶ exchange   EXCHANGE  (our own domains)
                │
                ▼
                dot-forward          DOT_FORWARD
                │
                ▼
                reencrypt            REENCRYPT (before local delivery)
                │
                ▼
                local                LOCAL_METHODS (maildir)
                │
                ▼
                local-lmtp           LOCAL_METHODS (lmtp; the two
                                     methods run in the order chosen)
                │
                ▼
                srs                  (always)
                │
                ▼
                dkim-sign-relay      SIGN_RELAYED
                │
                ▼
                smarthost            SMARTHOST_HOST
                or internet          (otherwise)

Zum Lesen der Abbildungen: eine Stage mit (always) ist für diese Richtung unbedingt, und jede andere Stage ist genau dann vorhanden, wenn die Antwort daneben es sagt. Die Stages werden in der gezeigten Reihenfolge aneinandergereiht, wobei NEXT_STAGE jeder Stage auf die nächste zeigt, die übrig geblieben ist — eine Funktion abzuschalten hinterlässt also keine Lücke, sondern verkürzt die Kette. list-out ist derselbe Listen-Router wie list, auf dem Submission-Zweig an erster Stelle platziert, damit ein lokaler Benutzer, der an eine hier betriebene Liste schreibt, die Liste erreicht, statt an ihren eigenen MX relayt zu werden.

Drei Randbedingungen legen diese Reihenfolge fest:

  • decrypt steht auf dem Empfangszweig zuerst, und encrypt ist die letzte der eigenen Stages des Submission-Zweigs, die die Nachricht vor dem Signieren umschreibt. Alles hinter decrypt sieht daher Klartext (Spracherkennung, die weiße Liste, die Bezahlschranke), und DKIM signiert die Bytes, die tatsächlich auf die Leitung gehen.

  • auto-whitelist kommt nach encrypt. Es hält einen Empfänger, an den die Nachricht tatsächlich verschlüsselt wurde, mit signature_required fest, und es ist encrypt, das dies angibt (state.encrypted); weiter vorn platziert, würde kein Datensatz es je tragen. Es fügt nur Zeilen in die weiße Liste ein, sodass dkim-sign weiterhin den Inhalt signiert, den encrypt erzeugt hat. Ein Empfänger, den encrypt an das Secure-Link-Portal verweist oder bouncet, verlässt das System auf jenem anderen Weg und wird nicht festgehalten.

  • srs und das Relay-Ziel dahinter sind auf dem Empfangszweig unbedingt. Empfänger, die die lokale Zustellung nicht verbraucht hat, sind keine Fehler — ein Alias, der nach außen expandiert, ein ~/.forward bei einem anderen Anbieter oder (ganz ohne konfigurierte lokale Zustellung) der gesamte reine Relay-Pfad. Sie verlassen den Host als Weiterleitung, weshalb der Umschlagabsender zuvor per SRS umgeschrieben wird.

5.3.2. Pipeline: inbound

Ohne Submission-Pfad gibt es nichts zu verzweigen, also entfällt die Stage if und ARC wird selbst zur Einstiegs-Stage. Der Empfangszweig ist ansonsten mit dem obigen identisch, abzüglich der Fragen, die nie gestellt wurden: kein encrypt, kein auto-whitelist, kein wallet und kein edit-settings.

Internet ──▶ pepsi-ingress :25
                │
                ▼
                init                 pepsi-stage-arc (the entry stage)
                │
                ▼
                decrypt              CRYPTO
                │
                ▼
                detect-language      LANGUAGE_BLOCKING
                                     or I18N_BOUNCES
                │
                ▼
                block-language       LANGUAGE_BLOCKING
                │
                ▼
                milter-*             MILTER_* (one per filter found)
                │
                ▼
                check-whitelist      ANTI_SPAM or SECRETARY
                │
                ▼
                secretary            SECRETARY
                │
                ▼
                anti-spam            ANTI_SPAM
                │
                ▼
                autocrypt-learn      AUTOCRYPT_LEARN
                │
                ▼
                list ──▶ list-post   MAILING_LISTS
                │        list-command
                │        list-bounce
                ▼
                aliases              ALIASES_ENABLED
                │
                ▼
                vacation             VACATION
                │
                ▼
                route ──▶ exchange   EXCHANGE  (our own domains)
                │
                ▼
                dot-forward          DOT_FORWARD
                │
                ▼
                reencrypt            REENCRYPT (before local delivery)
                │
                ▼
                local                LOCAL_METHODS (maildir)
                │
                ▼
                local-lmtp           LOCAL_METHODS (lmtp; the two
                                     methods run in the order chosen)
                │
                ▼
                srs                  (always)
                │
                ▼
                dkim-sign-relay      SIGN_RELAYED
                │
                ▼
                smarthost            SMARTHOST_HOST
                or internet          (otherwise)

dkim-sign und internet werden dennoch geschrieben, obwohl keine Submission sie erreicht: sie sind das Endstück, das jeder Bounce durchläuft (siehe Das gemeinsame Endstück und die Bounces), und internet ist außerdem das Relay-Ziel, wenn kein Smarthost konfiguriert wurde.

5.3.3. Pipeline: outbound

Nur der Submission-Zweig wird gebaut. Die Stage if wird trotzdem ausgegeben, weil pepsi-ingress weiterhin state.local_origin setzt und eine Nachricht, die es nicht trägt, irgendwohin muss — auf einem reinen Submission-Host kann eine solche Nachricht aber normalerweise nicht auftreten, daher fällt dieser Zweig direkt zum Signier-Endstück durch statt in eine eingehende Kette, die es nicht gibt.

your users ──▶ pepsi-ingress :465 / :587
               (and the local sendmail socket, always served)
                 │
                 ▼
               init                  pepsi-stage-if on
                 │                   state.local_origin
        ┌────────┴────────┐
  false │                 │ true
        │                 ▼
        │                 wallet        WALLET_SELF_SERVICE
        │                 │
        │                 ▼
        │                 encrypt       CRYPTO
        │                 │
        └────────┬────────┘
                 ▼
               dkim-sign               (always)
                 │
                 ▼
               internet                (always)

Beachten Sie, was hier nicht steht. auto-whitelist fehlt, obwohl es eine ausgehende Stage ist: es wird nur als Schreibseite einer weißen Liste von Korrespondenten angeboten, deren Leseseite (check-whitelist) auf dem eingehenden Pfad liegt, und die Frage, die es einschalten würde, wird innerhalb des nur eingehenden Anti-Spam-Schritts gestellt. Auch edit-settings fehlt, und EDIT_SETTINGS wird nicht gefragt: jede Stage, die ein Kontoinhaber bearbeiten darf, ist eine eingehende, sodass ihre Positivliste auf diesem Host leer wäre (siehe EDIT_SETTINGS unten). Es gibt keine milter-*-Stages, weil sowohl der Milter-Scan als auch die Übernahme importierter Milter zum nur eingehenden Schritt der lokalen Zustellung gehören. Einem reinen Outbound-Host fehlt auch srs: SRS schreibt den Absender von Mail um, die wir weiterleiten, und dieser Host leitet nichts weiter.

5.3.4. Das gemeinsame Endstück und die Bounces

dkim-sign ──▶ internet wird in jeder Richtung geschrieben, weil jeder erzeugte Bounce diesen Weg nimmt. Die Bounce-Stages selbst werden je Funktion ausgegeben, die einen erzeugen kann:

bounce             (always)           ─┐
bounce-language    LANGUAGE_BLOCKING   ├──▶ dkim-sign ──▶ internet
bounce-payment     ANTI_SPAM          ─┘

discard-rejected   any milter stage     (drops it; never bounces)

Welche Stage wohin routet, legt derselbe Rendering-Durchlauf fest: block-language erzeugt seine Bounces an bounce-language und anti-spam an bounce-payment; die Maildir-Stage, dot-forward und jede Relay-Stage erzeugen sie am schlichten bounce. Die Maildir-Stage richtet zusätzlich UNKNOWN_MAILBOX_STAGE dorthin — ein Empfänger auf einer unserer Domains ohne Postfach muss abgelehnt und nicht weitergeleitet werden, sonst fände die Abfrage unseren eigenen MX und lieferte die Nachricht wieder bei uns selbst ein — und beide lokalen Methoden richten auch QUOTA_LIMIT_STAGE dorthin, sodass eine Installation, die später eine Quota setzt, diesen Randfall nicht auch noch entdecken muss. Die LMTP-Stage hat überhaupt kein BOUNCE_STAGE (sie baut nie selbst eine DSN, sie routet, was der MDA abgelehnt hat), sodass ihr QUOTA_LIMIT_STAGE und ihr SIEVE_REJECT_STAGE diejenigen sind, die auf bounce zeigen.

discard-rejected ist die Ausnahme. Ein Milter-Urteil trifft nach der Annahme der Nachricht durch Pepsi ein, „reject“ kann also kein 5xx in der SMTP-Sitzung bedeuten, und stattdessen einen Bounce zu erzeugen würde Backscatter an denjenigen senden, den ein gefälschter Absender genannt hat. Von einem Filter, den der Host-Scan gefunden hat, abgelehnte Mail wird daher verworfen, wobei das Urteil weiterhin in state.milter und im Log festgehalten wird. Das REJECT_STAGE eines Filters auf bounce zu richten, ist eine Änderung von einem Wort, wenn Absender benachrichtigt werden sollen. Ein aus einem MTA-Import übernommener Filter behält REJECT_STAGE = bounce, da gerade die Benachrichtigung des Absenders das übernommene Verhalten ist.

5.4. Die Fragen

Nachstehend jede Frage, die das Terminal-Interview stellen kann, in der Reihenfolge, in der es sie stellt, samt dem [pepsi-wizard]-Schlüssel, unter dem die Antwort gemerkt wird. Ein Schritt erscheint nur, wenn die Richtung (und, bei einem Schritt, das Vorhandensein eines lokalen Dovecot) ihn anwendbar macht; das Banner Step X/Y zählt nur Schritte, die wirklich gestellt werden.

5.4.1. Schritt: Serveridentität

Wird in jeder Richtung gestellt.

HOSTNAME — Hostname des Mailservers (MX-/EHLO-Name)

Die Identität des Hosts, im Unterschied zu den Domains, die er bedient: die ARC-Versiegelungsdomain, jedes SERVER_NAME von Relay und Bounce sowie das Subject des Fallback-TLS-Zertifikats. Der Standardwert stammt aus dem Reverse-DNS, nicht aus /etc/hostname, weil Empfänger den EHLO-Namen mit dem PTR der verbindenden Adresse vergleichen und bei Abweichung ablehnen. Widerspricht der angebotene Standardwert dem PTR, nennt der Assistent beide und sagt vor der Frage, warum.

DOMAINS — Domain(s), für die wir Mail annehmen (durch Leerzeichen getrennt)

Wird [pepsi-ingress] ACCEPTED_DOMAINS und über dieses die Voreinstellung LOCAL_DOMAINS der Stages für lokale Zustellung, die Menge der mta-sts.*-Richtlinienhosts und die zu Exchange gerouteten Domains. Die erste ist die primäre Domain: die Adressen für TLS-Berichte, die Steueradressen der Self-Service-Stages und die SIGNING_DOMAIN der weiterleitenden Signierstage werden alle aus ihr abgeleitet, und sie ist die Voreinstellung, die für SRS_DOMAIN angeboten wird.

POSTMASTER — Postmaster-Adresse

Wird von den Bounce-Stages und vom Direct-to-MX-Relay genannt.

PUBLIC_IPS — Öffentliche sendende IP-Adresse(n) für SPF

Automatisch ermittelt und zur Bestätigung angeboten, aus den A/AAAA-Einträgen des Hostnamens, vereinigt mit den global routbaren Schnittstellenadressen dieses Hosts (und, auf einem NAT-Host ohne öffentliche IPv4, der WAN-Adresse, die das lokale UPnP-Gateway meldet). Vorbelegt werden immer nur öffentliche Adressen: sie landen wortgetreu im SPF-Eintrag, eine private dort lässt also Ihre eigene ausgehende Mail überall an SPF scheitern. Die Antwort eines früheren Laufs wird erneut geprüft, statt ihr zu vertrauen, denn ein Host kann seit dem Schreiben umgezogen sein.

DB_CONFIG — PostgreSQL-Verbindungszeichenkette

libpq-Form; der Standardwert postgres:///pepsi verwendet Peer-Authentifizierung über den lokalen Socket, was die paketierten Dienstkonten erwarten. Eine Zeichenkette, die ein Passwort enthält, wird schon bei der Eingabe abgewiesen, da sie im weltlesbaren [pepsi-postgres] CONFIG landen würde. Geben Sie für eine entfernte Datenbank jeder Rolle über den Platzhalter {role} ihr eigenes Client-Zertifikat oder ihre eigene Passwortdatei, z. B. postgres://db.example.org/pepsi?sslmode=verify-full&passfile=/etc/pepsi/postgres/{role}.pgpass (siehe CONFIG in pepsi.conf(5)).

5.4.2. Schritt: Vorhandenes Mailsystem

Wird nur auf dem eingehenden Pfad gestellt, und zwar vor der lokalen Zustellung, weil die Antwort entscheidet, ob es überhaupt eine Frage zur lokalen Zustellung gibt.

EXCHANGE — Gibt es hinter diesem Host ein vorhandenes Exchange-/Microsoft-365-Mailsystem

Standardwert nein. Ein Ja macht diesen Host zu einem transparenten Gateway vor Exchange: er wird zum MX, Exchange behält die Postfächer. Es fügt die Stage route und ein eigenes exchange-Relay in den Empfangszweig ein (siehe Pipeline: both) und unterdrückt die Fragen zur lokalen Zustellung vollständig — anzubieten, Postfächer für Domains zu schreiben, die Exchange gehören, ergäbe eine Konfiguration, in der ein Empfänger zweimal oder gar nicht beliefert wird. Empfänger, die nicht Exchange gehören (ein Alias, der nach außen expandiert, eine Weiterleitung), verlassen den Host weiterhin über das Relay-Endstück. Siehe Microsoft Exchange als Gateway.

EXCHANGE_HOST — Exchange-Host (Mandanten-Endpunkt oder der lokal betriebene Server)

Der mandantenspezifische Endpunkt, nicht der öffentliche MX Ihrer Domain. Dieser MX ist dieser Host, und Exchange dorthin zurückzuzeigen lässt jede Nachricht kreisen.

EXCHANGE_PORT — SMTP-Port von Exchange

Standardwert 25.

EXCHANGE_ADDRESS_FAMILY — IP-Adressfamilie, über die Exchange erreicht wird

any (Standardwert), ipv4 oder ipv6. Exchange Online lehnt Mail von einer sendenden IPv6-Adresse ohne PTR-Eintrag ab, diesen einen nächsten Hop auf IPv4 festzulegen ist daher eine verbreitete und legitime Antwort; andere Ziele bleiben unberührt.

5.4.3. Schritt: Lokale Zustellung

Nur auf dem eingehenden Pfad; die Fragen zu Maildir/LMTP entfallen, wenn Exchange mit Ja beantwortet wurde.

Maildir — Mail für lokale Systemkonten in deren Maildir zustellen

Fügt local dem Empfangszweig hinzu. Erfordert die SGID-Stage und den setuid-Helper, die make install einrichtet (Gruppe pepsi-maildir).

DOT_FORWARD — Benutzereigene ~/.forward-Dateien für Maildir-Konten beachten

Standardwert nein; wird nur zusammen mit Maildir angeboten, denn gelesen werden die Heimatverzeichnisse der Systemkonten selbst. Fügt dot-forward unmittelbar vor der lokalen Zustellung ein, sodass ein Empfänger mit einem ~/.forward vor dem Schreiben ins Postfach umgeleitet wird. Der erzeugte Abschnitt leitet nur an Adressen weiter; ALLOW_PIPE und ALLOW_FILE bleiben aus, da beide als Zielbenutzer einen Befehl ausführen bzw. eine Datei schreiben würden.

LMTP — Mail lokal per LMTP an einen MDA zustellen (Dovecot, das Sieve ausführt)

Fügt local-lmtp hinzu. Pepsi implementiert selbst kein Sieve; dies übergibt die Nachricht einem MDA, der es tut. Wird ein lokales Dovecot erkannt, ist die Anschlussfrage nur dessen LMTP-Socket-Pfad (LMTP_SOCKET); andernfalls wird ein entferntes TCP-Ziel erfragt — LMTP_HOST, LMTP_PORT, LMTP_TLS, LMTP_AUTH und, wo der Mechanismus sie braucht, LMTP_USERNAME und LMTP_PASSWORD. Pepsi konfiguriert Dovecot nicht: fehlen die Sockets, auf die es sich stützen wird, wird am Ende des Laufs eine vorgeschlagene 10-pepsi.conf ausgegeben.

Reihenfolge — Beide lokalen Methoden sind aktiviert — welche wird zuerst versucht?

Wird nur gestellt, wenn beide aktiviert wurden. Die Methoden werden in der angegebenen Reihenfolge verkettet, jede stellt zu, was sie kann, und leitet den Rest an die nächste weiter; was bei der letzten übrig bleibt, geht an das Relay-Endstück. Wird in LOCAL_METHODS gespeichert.

ALIASES_ENABLED — Aliase / Mailinglisten aktivieren (Empfänger über eine Map-Datei expandieren)

Standardwert nein. Fügt aliases nach den Spam-Schranken und unmittelbar vor Routing und Zustellung ein, sodass die Schranken die Adresse sehen, an die der Absender geschrieben hat, während die expandierte Menge je Empfänger geroutet wird. Die Map-Datei wird neben pepsi.conf angelegt und automatisch neu eingelesen, wenn sich ihre Änderungszeit ändert.

MAILING_LISTS – Mailinglisten auf diesem Server betreiben (ein Ersatz für GNU Mailman 3)

Standard nein. Fügt den Listen-Router in die Pipeline ein — auf beiden Zweigen, damit ein lokaler Benutzer, der an eine hier betriebene Liste schreibt, die Liste erreicht, statt an ihren eigenen MX relayt zu werden und als fremde Post zurückzukommen — und dazu die vier Stages dahinter: Einlieferung (Moderations-Chain, Handler-Pipeline, Fan-out je Mitglied), die E-Mail-Befehlsschnittstelle, die Zustellung je Mitglied mit der Ein-Klick-Abmeldung und die Bounce-Verarbeitung. Es schreibt außerdem [pepsi-list], dessen UNSUBSCRIBE_SECRET einmal erzeugt, in secrets.d/pepsi-list.secret statt in pepsi.conf gespeichert und über einen erneuten Lauf hinweg behalten wird — es zu wechseln würde jede schon zugestellte Abmelde-URI ungültig machen.

Es einzuschalten konfiguriert die Maschinerie; die Listen selbst werden danach mit pepsi-list angelegt. Ein Server, der keine betreibt, zahlt eine Umschlagprüfung je Nachricht. Das ist getrennt von ALIASES_ENABLED, das nur Empfänger umschreibt. Siehe Mailinglisten.

MILTERS_ENABLED — Die Milter in die Pipeline übernehmen

Wird nur gestellt, wenn ein MTA-Import welche gefunden hat. Die Eingabeaufforderung warnt vor dem geänderten Zeitpunkt: Pepsi führt Filter nach der Annahme der Nachricht aus, ein Filter, der unter dem alten MTA in der SMTP-Sitzung abgelehnt hat, erzeugt hier also einen Bounce (weshalb erkannte Filter stattdessen an discard-rejected verdrahtet werden — siehe Das gemeinsame Endstück und die Bounces).

MILTER_GREYLIST, MILTER_REGEX, MILTER_CLAMAV, MILTER_SPAMASSASSIN, MILTER_RSPAMD, MILTER_MIMEDEFANG, MILTER_AMAVIS

Je eine Ja/Nein-Frage pro Filter-Daemon, den ein Scan dieses Hosts installiert und antwortend vorgefunden hat. Jeder angenommene Filter wird zu einer milter-*-Stage, platziert nach dem, was er tut — zuerst Richtlinie, dann Viren, dann Spam, dann die Allzweck-Frameworks —, wobei importierte Filter unbekannten Zwecks die relative Reihenfolge behalten, in der ihr alter MTA sie ausgeführt hat. Alle stehen standardmäßig auf ja außer MILTER_GREYLIST: Greylisting arbeitet, indem es die Zustellung in der Sitzung verweigert und darauf wettet, dass eine Spam-Maschine keine Wiederholung versucht; hinter der Warteschlange gibt es nichts zu verweigern und Pepsi ist selbst dasjenige, das wiederholt, die Wette ist also immer gewonnen und nur die Verzögerung bleibt. Filter, deren Funktion Pepsi bereits erfüllt (opendkim, openarc, opendmarc, SPF-Richtlinien-Daemons, SRS-Umschreiber), werden erkannt und als überholt gemeldet, statt angeboten zu werden. Siehe pepsi-stage-milter.

ALIAS_STYLE — Importierte Aliasnamen qualifizieren

Nur wenn eine Migration nackte Aliasnamen wie postmaster oder root geliefert hat, die Pepsis Schlüssel nicht verwenden können, weil sie eine Domain tragen: per-domain (ein Eintrag je bedienter Domain), wildcard (ein einzelner @-Platzhalter) oder primary.

VACATION — Mail für abwesende Empfänger beantworten (Abwesenheitsantworten)

Standardwert nein. Fügt vacation nach der Alias-Expansion und nach den Spam-Schranken ein, sodass eine Benachrichtigung nie im Namen eines Alias und nie als Antwort auf Mail versendet wird, die die Schranken abgelehnt hätten. Das Einschalten beantwortet für niemanden: Abwesenheitszeiträume sind gewöhnliche Konfiguration je Adresse, später gesetzt mit pepsi-settings, im Geltungsbereich einer Domain mit pepsi-config für einen gemeinsamen Feiertag oder von den Benutzern selbst per E-Mail. Auf einem Host ohne lokale Zustellung setzt der erzeugte Abschnitt zusätzlich VACATION_TAG = none, weil das Markieren des Betreffs einen Header umschreibt, den sowohl die DKIM-Signatur des Autors als auch unser eigenes ARC-Siegel abdecken — harmlos, wenn die Mail hier endet, für den nächsten Hop sichtbar, wenn sie weitergeleitet wird.

Smarthost — Empfänger, die die lokale Zustellung nicht bedient, zusätzlich an einen Smarthost weiterleiten

Optional, wenn die lokale Zustellung oder Exchange Ihre Domains bedient; dann bedient er nur, was keines von beiden erledigt hat; erforderlich und ungefragt, wenn keines von beiden es tut, denn ein reines Relay muss irgendwohin senden können. Ein Ja erfragt SMARTHOST_HOST, SMARTHOST_PORT, SMARTHOST_MODE (starttls / tls / plain), SMARTHOST_AUTH (none / plain / login) und, wo authentifiziert wird, SMARTHOST_USERNAME und SMARTHOST_PASSWORD. Die Zugangsdaten werden auf der Stelle gegen das echte Relay geprüft: eine Ablehnung bietet das Passwort erneut an, während ein nicht erreichbares Relay nichts über das Passwort aussagt und Sie nicht dazu drängt, ein funktionierendes neu einzutippen.

5.4.4. Schritt: Submission-Authentifizierung

Wird nur auf dem ausgehenden Pfad gestellt und nur, wenn auf diesem Host ein Dovecot installiert ist.

DOVECOT_SASL — Submissions gegen den lokalen Dovecot-SASL-Socket authentifizieren

Standardwert ja. Setzt verpflichtendes AUTH gegen einen Pepsi-eigenen Dovecot-SASL-Socket (/run/dovecot/auth-client-pepsi) auf den Listenern 465 und 587, sodass Mailkonten und IMAP-Konten dieselben Konten sind. Bei Ablehnung bleibt in den Listenern ein auskommentierter Hinweis auf die Alternativen (Dovecot-SASL von Hand konfiguriert oder TLS-Client-Zertifikate).

5.4.5. Schritt: Loopback vertrauen

Wird nur gefragt, wenn der Host beide Richtungen bedient, und es ist eine engere Frage, als sie aussieht: Die Antwort wird zu MYNETWORKS auf dem MX-Listener an Port 25, den nur ein eingehender Host hat, und sie lohnt sich nur bei einem Host, der auch einliefert.

TRUST_LOOPBACK — Loopback-Verbindungen auf Port 25 vertrauen

Standardwert nein, und der Standardwert ist für nahezu alle die richtige Antwort. Der Assistent fragt nicht, ob lokale Programme Mail einliefern dürfen — das können sie immer: pepsi-ingress bedient den UNIX-Socket, den /usr/sbin/sendmail benutzt, unbedingt, und der Kernel teilt ihm mit, welches Konto ihn geöffnet hat, sodass ein Aufrufer stets nur als er selbst senden kann. Diese Frage betrifft nur den schwächeren zusätzlichen Mechanismus, einer Adresse zu vertrauen — ein MYNETWORKS-Eintrag für 127.0.0.0/8 ::1/128 am Listener auf Port 25 —, der eine Netzwerkposition statt eines Benutzers authentifiziert, sodass danach jeder lokale Prozess, auch eine kompromittierte Webanwendung, als beliebiger Absender senden kann. Er lässt außerdem eine Nachricht, die dieser Host an sich selbst weiterleitet, als neue Submission wieder eintreten und kreisen. Sagen Sie nur Ja für Software, die darauf besteht, SMTP mit 127.0.0.1 zu sprechen, und die nicht auf den Socket verwiesen werden kann.

5.4.6. Schritt: Weitergeleitete Mail

Nur auf dem eingehenden Pfad.

SIGN_RELAYED — Mail, die dieser Host weiterleitet, mit DKIM als eigene Domain dieses Hosts signieren

Standardwert ja. Mail, die dieser Host lediglich weiterleitet — ein Alias, der nach außen expandiert, ein ~/.forward bei einem anderen Anbieter, der gesamte reine Relay-Pfad —, verlässt ihn über den Empfangszweig, den das ausgehende dkim-sign nie berührt; ohne dies trifft sie beim nächsten Hop mit unserem SRS-Umschlag, aber mit dkim=none von uns ein. Ein Ja fügt eine zweite Signier-Stage, dkim-sign-relay, zwischen srs und dem Ziel ein, mit SIGNING_DOMAIN fest auf die primäre bediente Domain gesetzt. Signieren ist fail-closed und die Domain des Autors gehört jemand anderem, eine aus einem fremden From: abgeleitete Signierdomain ließe daher jede weitergeleitete Nachricht mangels Schlüssel scheitern.

SRS_DOMAIN – Domain, unter die der Rückweg weitergeleiteter Post gelegt wird

Standard ist die primäre bediente Domain. Wird [pepsi-srs] SRS_DOMAIN. Weitergeleitete Post verlässt den Server mit einem zu SRS0=…@SRS_DOMAIN umgeschriebenen Umschlagabsender, damit die SPF-Prüfung des nächsten Hops besteht, und das macht diese Adresse zu einem Rückweg: jeder Bounce für weitergeleitete Post ist an sie adressiert. Die Domain muss daher auf diesem Rechner Post empfangen, und die primäre tut das schon – ihre MX-, SPF- und DMARC-Einträge existieren, und es muss nichts weiter veröffentlicht werden.

Eine eigene Subdomain wie srs.<primary> funktioniert ebenfalls und hält den Bounce-Verkehr weitergeleiteter Post von der Reputation der Hauptdomain fern, braucht aber einen eigenen MX-Eintrag. Dieser Eintrag ist das eine, was pepsi-setup nicht für Sie vorschlagen kann — wohin die Post einer Domain geroutet wird, ist Ihre Entscheidung und nicht seine —, daher gibt der Assistent den zu veröffentlichenden Eintrag aus, wenn die Antwort keine hier angenommene Domain ist, und pepsi-setup(1) warnt bei jedem Lauf, bis er existiert. Ohne beide Hinweise bekommt eine Domain korrekte SPF- und DMARC-Einträge, keinen MX und jeden Bounce für weitergeleitete Post stillschweigend verworfen.

Ein erneuter Lauf verschiebt eine bestehende SRS_DOMAIN nie von selbst: umgeschriebene Absender bleiben MAX_AGE_DAYS (standardmäßig 21 Tage) überprüfbar, sie zu ändern würde daher jeden noch unterwegs befindlichen Bounce stranden lassen. Wenn [pepsi-wizard] keinen Wert festhält, wird der bereits in [pepsi-srs] stehende Wert als Standardwert angeboten.

5.4.7. Schritt: Transportsicherheit

Wird immer gestellt; die erste Frage nur auf dem eingehenden Pfad.

MTA_STS — Eine MTA-STS-Richtlinie über HTTPS bereitstellen

Standardwert ja. Setzt [pepsi] MTA_STS_MODE = enforce und gibt pepsi-httpd mit je einem mta-sts.<domain>-Zertifikatsabschnitt pro angenommener Domain aus, von pepsi-setup wie jeder andere eingerichtet. Sie müssen das DNS jedes mta-sts.<domain>-Namens auf diesen Host zeigen lassen, damit die Richtlinie erreichbar ist. Welche Hosts die Richtlinie zulässt, wird nicht gefragt: es wird aus den aktuellen MX-Einträgen der bedienten Domains gelesen und als [pepsi] MTA_STS_MX geschrieben oder weggelassen (die Richtlinie nennt dann HOSTNAME), wenn noch kein MX-Eintrag existiert.

TLS_REPORTS — SMTP-TLS-Berichte senden und ankündigen (TLSRPT, RFC 8460)

Standardwert ja; gibt [pepsi-tlsrpt] aus. Gilt für jeden Host, der sendet, wird daher in jeder Richtung gestellt. Fügen Sie den täglichen cron-Eintrag pepsi-tlsrpt report hinzu, an den der Assistent erinnert.

Auch wenn MTA-STS abgelehnt wird, werden die pepsi-httpd-Abschnitte geschrieben: HTTPS auf Port 443 (mit dem Host-Zertifikat) und der UNIX-Socket der Verwaltungskonsole. pepsi.target startet den HTTP-Server auf jedem Host, und ohne einen Listener würde er fehlschlagen und endlos neu starten.

SHARE_TELEMETRY — Anonyme Telemetrie zur Funktionsnutzung mit dem Pepsi-Projekt teilen

Standardwert nein, und es ist Opt-in im strengen Sinne: ein Operator, der sich mit der Eingabetaste durch das gesamte Interview drückt, teilt nichts. Die Frage erklärt vor dem Fragen, was gesendet würde. Ja lässt pepsi-setup run eine zufällige 256-Bit-SYSTEM_ID prägen und schaltet den Daemon pepsi-telemetry-client scharf, der unter dieser Kennung regelmäßig meldet, welche Funktionen diese Installation genutzt hat und wie oft — keine Adressen, Nachrichtendaten, Hostnamen oder IP-Adressen. Nein heißt, dass keine Kennung erzeugt und nichts gesendet wird, und ein erneuter Lauf des Assistenten mit der Antwort Nein benachrichtigt einen laufenden Daemon, der sofort in den Ruhezustand geht (und verwirft, was er noch nicht gesendet hatte), statt darauf zu warten, dass er es bemerkt. Der Daemon selbst läuft weiter, wenn der Operator ihn gestartet hat: Im Ruhezustand übermittelt er nichts, und er ist es, der es der Browser-Konsole erlaubt, diesen Schalter anzubieten (siehe pepsi-telemetry-client).

5.4.8. Schritt: Inhaltsfilterung

Nur auf dem eingehenden Pfad.

LANGUAGE_BLOCKING — Mail anhand der erkannten menschlichen Sprache ablehnen

Standardwert nein. Fügt detect-language und block-language hinzu.

I18N_BOUNCES — Bounce-Nachrichten in die Sprache des Absenders lokalisieren

Wird nur gestellt, wenn Blockieren aus ist, denn Blockieren setzt die Erkennung bereits voraus. Fügt allein detect-language hinzu, das state.language annotiert und nichts ablehnt.

DETECT_LANGUAGES — Sprachen, die der Erkenner erkennen soll

Wird gestellt, wenn eine der beiden obigen Antworten die Erkennung eingeschaltet hat, nach Ausgabe der vollständigen Liste der unterstützten ISO-639-1-Codes. * (der Standardwert) meint jede Sprache, die der Erkenner unterstützt; weniger zu nennen kostet weniger Worker-Speicher. Ein nicht unterstützter Code wird an der Eingabeaufforderung abgelehnt. Erlaubt oder blockiert werden kann anschließend nur eine erkannte Sprache, weshalb dies vor der Richtlinie kommt.

LANG_POLICY — Sprachrichtlinie (+erlauben / -blockieren, z. B. ‚+en +fr -‚)*

Eine kombinierte Antwort, aufgeteilt auf WHITELIST und BLACKLIST der Stage. Ein einzelner Platzhalter -* oder +* deckt jede weitere erkannte Sprache ab, +en +fr -* erlaubt also nur Englisch und Französisch; das Literal none darf aufgeführt werden, um über das Schicksal von Mail zu entscheiden, für die keine Sprache erkannt werden konnte.

LANG_THRESHOLD — Punktzahl-Schwellwert (Mail muss strikt darüber liegen)

Standardwert -0.1.

LANG_ENFORCEMENT — Die Sprachrichtlinie strikt oder schwach durchsetzen

hard (Standardwert) lehnt Mail ab, die an der Richtlinie scheitert, und routet sie nach bounce-language. soft markiert stattdessen genau dieselbe Mail — ein [!LANG]-Flag im Betreff und ein X-Pepsi-Detected-Languages-Header —, womit die Listen und der Schwellwert an echtem Verkehr abgestimmt werden, ohne dass zwischenzeitlich jemandes Mail weggeworfen wird. Die Bounce-Stage wird auch unter soft geschrieben, das spätere Umstellen ist also eine Änderung von einem Wort.

5.4.9. Schritt: Anti-Spam-Bezahlschranke

Nur auf dem eingehenden Pfad.

SECRETARY — Unbekannte Absender vor der Zustellung ihrer Mail um Bestätigung per Antwort bitten (Confirm-to-Send)

Standard nein. Wird in diesem Schritt als Erstes gefragt. Fügt check-whitelist und secretary zum Empfangszweig hinzu und, wenn es auch einen ausgehenden Pfad gibt, auto-whitelist zum Submission-Zweig, alle drei auf der weißen Liste correspondents: Mail von jemandem, der weder auf der weißen Liste steht noch bestätigt ist, wird zurückgehalten, und ihr Absender wird gebeten, einmal zu antworten (siehe pepsi-stage-secretary). Das erzeugte [stage-secretary] hat kein BOUNCE_STAGE (eine Nachricht mit abgelaufener Frist wird gelöscht: eine unbeantwortete Challenge bedeutet meist einen gefälschten Absender), und sein UNCHALLENGEABLE_STAGE ergibt sich aus den anderen Spam-Abwehren desselben Laufs, wobei der erste Treffer gilt: die Bezahlschranke, wenn ANTI_SPAM eingeschaltet ist (Mail, die nicht um eine Antwort gebeten werden kann, wird um Bezahlung gebeten, und secretary läuft dann vor anti-spam); sonst das eigene NEXT_STAGE der Secretary-Stage, wenn ein Spam- oder Framework-Milter angenommen wurde, weil dieser Filter bereits vor check-whitelist gelaufen ist; sonst bleibt es ungesetzt, was der Timeout-Pfad ist. Ein Kommentar über dem Abschnitt nennt, worauf die Wahl beruht; Spamfilter und der Sekretär beschreibt die alternative Platzierung der Filter. Wird die Stage in die Positivliste von EDIT_SETTINGS aufgenommen, können Benutzer ihren eigenen Challenge-Text und PENALTY festlegen.

ANTI_SPAM — Die GNU-Taler-Anti-Spam-Bezahlschranke aktivieren (Pay-to-Send)

Standardwert nein. Fügt dem Empfangszweig zwei Stages hinzu — check-whitelist und anti-spam — und, wenn es auch einen ausgehenden Pfad gibt, auto-whitelist dem Submission-Zweig. Die drei sind eine Funktion: die ausgehende Stage hält jeden fest, dem Sie schreiben, die eingehende erkennt deren Antworten, und nur das, wofür keine von beiden gebürgt hat, trifft auf die Zahlungsschranke. Sie gibt außerdem die Stage bounce-payment aus und gibt pepsi-httpd ein /resume-Webhook-Token.

MERCHANT_BACKEND_URL — URL des Taler-Händler-Backends

Wird zuerst gestellt und auf der Stelle verifiziert, weil sein /config die Währungen meldet, in denen der Preis angegeben werden darf — das Backend muss also bekannt sein, bevor der Preis validiert werden kann.

MERCHANT_ACCESS_TOKEN — Händler-Zugriffstoken (‚secret-token:…‘) oder das Instanz-Passwort

Beides wird angenommen: ein fertiges Zugriffstoken wird gegen das Backend verifiziert, ein Instanz-Passwort wird gegen ein Zugriffstoken mit begrenztem Geltungsbereich eingetauscht.

PAYMENT_AMOUNT — Preis pro Nachricht (durch Leerzeichen getrennte Taler-Beträge)

Jeder Betrag wird zu einer Wahlmöglichkeit in der erzeugten Bestellung, EUR:1 CHF:1 KUDOS:10 lässt den Zahlenden also eine Währung wählen. Wird gegen die Währungen validiert, die das Backend angekündigt hat.

PAYMENT_DEADLINE — Wie lange eine Nachricht in Erwartung der Zahlung gehalten wird

Standardwert 48 h. Nur Stunden, Minuten und Sekunden — der Dauer-Parser akzeptiert keine Kalendereinheiten.

LEARN_WHITELIST — Eine weiße Liste von Korrespondenten aus Ihrer ausgehenden Mail lernen

Wird statt der obigen gestellt, wenn sowohl die Bezahlschranke als auch SECRETARY abgelehnt werden (jede von beiden schaltet es ohnehin ein), und nur, wenn es auch einen ausgehenden Pfad gibt. Sie fügt auto-whitelist allein hinzu: die Korrespondenten werden festgehalten, und noch verbraucht nichts das Urteil. Das früh einzuschalten ist vernünftig, denn eine weiße Liste nützt erst, wenn etwas Vorgeschichte darin steht.

5.4.10. Schritt: Kontoselbstbedienung

Nur auf dem ausgehenden Pfad, und EDIT_SETTINGS nur auf einem Host, der beide Richtungen bedient. Beide stehen standardmäßig auf nein, und beide sind Stages, die gewöhnliche Mail unverändert durchlassen — sie handeln nur bei einer Nachricht, die ein lokales Konto an ihre eigene Steueradresse gesendet hat.

EDIT_SETTINGS — Kontoinhabern erlauben, ihre eigenen Einstellungen per E-Mail zu bearbeiten

Fügt edit-settings hinzu. Eine Nachricht an pepsi@<domain> von einem lokalen Konto bearbeitet die pepsi.settings-Überschreibungen genau dieser Adresse, beschränkt auf eine Positivliste von Stages, die der Assistent aus den tatsächlich aktivierten eingehenden Schranken ableitet — die Whitelist-, Sprachblockade-, Secretary-, Bezahlschranken- und Urlaubs-Stages, allesamt eingehende, weshalb ein reiner Outbound-Host nicht gefragt wird. Ist keine davon in der Pipeline, so ist diese Positivliste leer, und ein Ja gibt überhaupt keine Stage aus, nur einen Kommentar mit der Begründung: Ein EDITABLE_STAGES ohne Inhalt ist eine Steueradresse, die nichts ändern kann. Siehe pepsi-stage-edit-settings.

WALLET_SELF_SERVICE — Kontoinhabern erlauben, ihr GNU-Taler-Wallet per E-Mail zu bedienen

Fügt wallet hinzu. Eine Nachricht an pepsi-wallet@<domain> mit einem Befehl im Subject bedient das eigene Wallet des Absenders: Guthaben, Aufladen, Peer-to-Peer-Zahlungen. Siehe pepsi-stage-auto-pay.

5.4.11. Schritt: Ende-zu-Ende-Kryptographie

Wird immer gestellt — die Verschlüsselung bedient, was Ihre Benutzer senden, und die Entschlüsselung, was für sie ankommt, und eine Installation, die das eine ohne das andere tut, ist selten genug, um keine zwei Fragen wert zu sein. Welche Hälften tatsächlich ausgegeben werden, richtet sich weiterhin nach der Richtung.

CRYPTO — Mail Ende zu Ende verschlüsseln und entschlüsseln (OpenPGP / S/MIME)

Standardwert nein. Auf dem eingehenden Pfad fügt es decrypt zuerst ein, sodass alles dahinter Klartext sieht; auf dem ausgehenden Pfad fügt es encrypt zuletzt vor dem Signieren ein, sodass DKIM abdeckt, was tatsächlich auf die Leitung geht. Verschlüsselt wird nichts, solange der Schlüssel eines Empfängers nicht bekannt ist — Schlüssel stammen aus der Entdeckung (WKD, DANE, VKS, LDAP), aus pepsi-keys oder aus der Mail, die Korrespondenten Ihnen senden. Der Schlüsselspeicher, der Entdeckungs-Daemon und der Schlüsselverschlüsselungsschlüssel werden ohnehin vom übrigen Setup eingerichtet; diese Antwort entscheidet nur, ob die Stages in der Pipeline sind. Siehe Schlüsselverwaltung.

AUTOCRYPT_LEARN — Schlüssel von Korrespondenten aus der Mail lernen, die sie uns senden

Standardwert ja, wird nur gestellt, wenn CRYPTO an ist und es einen eingehenden Pfad gibt — ohne Entschlüsselungs-Stage gibt es keinen Klartext, aus dem sich Gossip lesen ließe, und ohne Verschlüsselungs-Stage würde nie etwas einen gelernten Schlüssel aufwenden. Fügt autocrypt-learn nach jeder Stage ein, die ein Spam-Urteil bilden kann, und vor allem, was antwortet oder zustellt — genau das verlangt Autocrypt Level 1: eine für Spam gehaltene Nachricht lehrt nichts, und ein nach der Zustellung gelernter Schlüssel ist zu spät gelernt, um die Antwort damit zu verschlüsseln. Gelernte Schlüssel sitzen auf den untersten Sprossen der Vertrauensleiter — ein solcher Schlüssel kann nie einen aus der Entdeckung verdrängen, und eine gegen ihn geprüfte Signatur wird nie als verifiziert gemeldet.

REENCRYPT — Entschlüsselte Mail vor dem Ablegen mit dem eigenen Mail-Client-Schlüssel des Benutzers neu verschlüsseln

Standardwert ja, nur gefragt, wenn CRYPTO eingeschaltet ist und es einen eingehenden Pfad gibt, und nur vor einer lokalen Zustellmethode ausgegeben. Fügt reencrypt unmittelbar vor der ersten lokalen Zustell-Stage ein — nach jeder Stage, die den Inhalt liest oder eine Kopie weiterleiten kann —, sodass eine Nachricht, die das Gateway mit dem MTA-Schlüssel eines Benutzers geöffnet hat, versiegelt mit dem MUA-Schlüssel abgelegt wird, den dieser Benutzer registriert hat. Benutzer ohne MUA-Schlüssel erhalten weiterhin Klartext; der Abschnitt wird mit BOUNCE_STAGE = bounce geschrieben, damit ON_NO_CLIENT_KEY = bounce, systemweit oder pro Benutzer mit pepsi-settings gesetzt, stattdessen abweisen kann. Siehe pepsi-stage-reencrypt.

PEP – Automatische Verschlüsselung im Stil von pEp: jedem Absender einen Schlüssel geben und ihn mitsenden (ENABLE_PEP)

Standardwert ja, nur gefragt, wenn CRYPTO eingeschaltet ist und es einen ausgehenden Pfad gibt. Jeder Absender an einer bedienten Domain erhält mit seiner ersten Nachricht einen OpenPGP-Schlüssel, der in einem Autocrypt:-Header bekannt gegeben wird; Mail wird verschlüsselt, wann immer der Schlüssel eines Empfängers bekannt oder auffindbar ist, und innerhalb der Verschlüsselung signiert (Klartext-Mail geht unsigniert hinaus). Ein Benutzer, der seinen eigenen Schlüssel registriert, behält ihn, und nichts wird auf einen Schlüsselserver hochgeladen, es sei denn, sein Eigentümer verlangt es.

Die Frage wird ausdrücklich gestellt, ihre Kosten werden vorab genannt: Die Schlüsselerzeugung wird eifrig – jeder, der Mail sendet, erhält einen Schlüssel, ob er Verschlüsselung je nutzt oder nicht, bereitgestellt über das Web Key Directory der Installation, und jeder dieser privaten Schlüssel liegt in der Datenbank, eingewickelt unter dem Schlüsselverschlüsselungsschlüssel, sodass eine Kompromittierung dieses Schlüssels sie alle offenlegen würde. Nein erzeugt Schlüssel nur für einen Benutzer, der um Schutz bittet. Die Antwort wird in jedem Fall geschrieben, ENABLE_PEP = yes oder ENABLE_PEP = no, und zwar in [stage-encrypt] in pepsi.conf – wo sie wirkt, da keine config.d-Datei sie setzt –, statt dem Standardwert der Stage überlassen zu bleiben. Die Encrypt-Stage erhält außerdem RESPONSE_STAGE = dkim-sign für ihre Hinweise und die Antworten auf Schlüsselbefehle per E-Mail. Siehe „Automatische Schlüssel nach Art von pEp“ in Schlüsselverwaltung.

ATTACH_KEYS_AS_FILES – Den öffentlichen Schlüssel des Absenders zusätzlich als Datei anhängen

Standard nein, nur gefragt, wenn PEP eingeschaltet ist. Der klassische OpenPGP-Weg, für Korrespondenten, deren Client keine Autocrypt-Header liest; die Datei wird angehängt, bis der Korrespondent gezeigt hat, dass er den Schlüssel besitzt (er hat eine verschlüsselte, signierte Antwort gesendet). Wird nur bei entsprechender Wahl als ATTACH_KEYS_AS_FILES = yes geschrieben.

5.4.12. Schritt: Expertenoptionen

Wird nur gezeigt, wenn --expert welche genannt hat. Dies sind echte Pepsi-Optionen, nach denen das Interview normalerweise nicht fragt — MAX_MESSAGE_SIZE, MYNETWORKS, RECIPIENT_DELIMITER, MAX_LIFETIME, DMARC_ENFORCE, HELO_NAME, TLS_CERT/TLS_KEY, DNS_TIMEOUT, MAX_CONNECTIONS, MAX_OPEN_SOCKETS, DKIM_SELECTOR, KEY_DIR, MAILBOX_QUOTA, MAILBOX_OVER_QUOTA, CRYPTO_ALLOW_DOWNGRADE —, von denen jede weiß, in welchen Abschnitt sie gehört. Ein Wert, den die Standardwerte bereits tragen (aus einem früheren Lauf oder aus einem MTA-Import), wird angewendet, ob --expert danach fragt oder nicht; das Flag entscheidet nur, welche eine Eingabeaufforderung bekommen. Eine Antwort leer zu lassen stellt Pepsis eigenen Standardwert wieder her. Siehe pepsi-setup(1).

5.5. Was der Assistent nicht fragt

Manches fehlt im Interview mit Absicht:

  • Der lokale Submission-Socket. pepsi-ingress bedient ihn unbedingt und leitet den Pfad aus [pepsi-sendmail] SOCKET ab, es wird also kein Listener-Abschnitt geschrieben und es gibt nichts, was mit etwas anderem uneins sein könnte.

  • SRS. Das Umschreiben wird überall automatisch verdrahtet, wo Post weitergeleitet werden kann, mit einem erzeugten HMAC-Geheimnis. Die einzige Wahl ist, unter welcher Domain der umgeschriebene Rückweg liegt (SRS_DOMAIN, oben); die Verdrahtung ist keine.

  • Wie die Listener binden. Ein Host mit systemd (erkannt an /run/systemd/system) bekommt socket-aktivierte Listener (SERVE = systemd, ein FD_INDEX je Listener); alles andere bekommt direkte Bindungen. Die Ingress-Nummerierung ist fest, passend zur mitgelieferten pepsi-ingress.socket, die auf jedem Host alle drei Ports aufführt: FD_INDEX 0 ist Port 25, 1 ist 465 und 2 ist 587, gleich welche Richtung der Host bedient. Ein reiner Outbound-Host schreibt also 1 und 2 für seine Submission-Listener, ein reiner Inbound-Host 0 für seinen MX. Bei Socket-Aktivierung müssen Sie passende .socket-Units installieren, deren ListenStream=-Reihenfolge zu den FD_INDEX-Werten passt — der Assistent gibt eine Erinnerung aus, und pepsi-ingress warnt beim Start vor jedem Deskriptor, den kein Abschnitt beansprucht hat (die Ports, die ein Host mit nur einer Richtung nicht bedient).

  • Schlüssel, Zertifikate, das Schema und DNS. Das alles ist pepsi-setup run, in das der Assistent überzugehen anbietet. TLS-Zertifikate werden über certbot eingerichtet; ein Zertifikat, das nicht beschafft werden kann, wird zurückgestellt, statt den Lauf abzubrechen, sodass Schema, Schlüssel und DNS-Ausgabe dennoch stattfinden.

5.6. Erneut ausführen

Das Interview hält jede nicht geheime Antwort in einem Abschnitt [pepsi-wizard] am Ende der geschriebenen Datei fest, und ein späterer --wizard-Lauf importiert diese als seine Standardwerte — ein erneuter Lauf, um eine Sache zu ändern, ist also ein Durchdrücken der Eingabetaste bis zu jener Frage. Geheimnisse werden getrennt behandelt und nie dort hineingeschrieben: ein erzeugtes (der SRS-Schlüssel, das /resume-Token, das UNSUBSCRIBE_SECRET der Mailinglisten) wird zurückgelesen und behalten, weil eine Rotation des SRS-Schlüssels jeden umgeschriebenen Absender ungültig machen würde, der noch in Bearbeitung ist; ein eingetipptes (ein Smarthost- oder LMTP-Passwort, das Händler-Token) wird an der eigenen Eingabeaufforderung als *** zurück angeboten, sodass die Eingabetaste es behält, ohne dass es je ausgegeben oder neu eingetippt wird.

Für dasselbe Interview gibt es zwei nicht interaktive Formen. --answers FILE liefert Antworten schlüsselweise aus einer JSON-Datei und überspringt jede Eingabeaufforderung (eine unbeantwortete Frage nimmt ihren Standardwert; ein unbekannter Schlüssel, eine fehlerhafte Antwort oder eine erforderliche Antwort ohne Standardwert ist ein harter Fehler statt einer Eingabeaufforderung, die niemand zu sehen bekommt), und damit lässt sich eine Konfiguration über Hosts hinweg reproduzieren. --import nennt ausdrücklich einen MTA, von dem migriert werden soll, statt einen zu erkennen. Beide sind in pepsi-setup(1) dokumentiert.