2. Erste Schritte auf einem günstigen VPS

Eine durchgängige Anleitung: Ausgehend von einem frisch gemieteten virtuellen privaten Server und einem gerade registrierten Domainnamen führt sie Sie bis zu einer ersten empfangenen und in ein lokales Postfach zugestellten E-Mail, mit einem ordentlichen Bounce, der für alles Unzustellbare zurückgesendet wird. Die anderen Kapitel erklären jeden Baustein im Detail; dieses fädelt sie zusammen.

2.1. Was wir bauen werden

Ein kleiner Mail-Host, der Nachrichten für example.org auf dem Standard-SMTP-Port annimmt und jede Nachricht in das lokale Maildir des Empfängers auf demselben Server zustellt. Alles, was er nicht lokal zustellen kann — ein unbekannter Empfänger, ein volles oder nicht beschreibbares Postfach — wird in einen echten Bounce (eine Zustellungsstatusbenachrichtigung) verwandelt und an den ursprünglichen Absender zurückgesendet, statt stillschweigend in der Warteschlange zu verschwinden. Die eingehende Pipeline ist kurz:

inbound SMTP  ->  [stage-init]  ->  [stage-local]
(pepsi-ingress)   pepsi-stage-arc   pepsi-stage-relay-to-maildir
                  (record the       (deliver to the user's
                   inbound verdict)  ~/Maildir/new/)

und was nicht zugestellt werden kann, wird signiert und über einen kurzen ausgehenden Pfad an den Absender zurückgesendet:

[stage-bounce]      ->  [stage-sign]       ->  [stage-internet]
pepsi-stage-bounce      pepsi-stage-dkim-sign   pepsi-stage-relay-to-internet
(build the DSN)         (sign the bounce)       (send it to the sender's MX)

Ersetzen Sie durchgehend example.org durch Ihre eigene Domain und alice durch einen echten Kontonamen. Weil der Host diesen Bounce nun auch sendet — DKIM-signiert, von einer SPF-autorisierten Adresse — veröffentlicht dieses Setup die Absender-Authentifizierungseinträge, die es Empfängern erlauben, seiner ausgehenden Post zu vertrauen: DKIM, SPF und DMARC, die ein reiner Empfangs-Host nicht bräuchte. (MTA-STS und TLS-Reporting, die das eingehende TLS härten und den laufenden HTTPS-Server benötigen, bleiben hier weggelassen und werden als optionale Härtung ergänzt — siehe Nächste Schritte.) Ein abschließender Abschnitt verwendet genau denselben ausgehenden Pfad erneut, um einen authentifizierten Submission-Port hinzuzufügen, sodass auch Ihre eigenen Benutzer über den Host senden können.

Bemerkung

Umfang. Dies ist die einfachste realistische Installation — Mail empfangen, sie lokal zustellen und das Unzustellbare bouncen. Für einen weiterleitenden Host (ARC + SRS + erneute DKIM-Signierung auf dem Weg nach draußen) siehe Einführung und pepsi-stage-relay-to-internet, und Nächste Schritte dazu, wie Sie diesen Host dazu ausbauen.

Pepsi stellt in ein Maildir zu, liefert aber keinen IMAP/POP-Server mit, sodass Sie eingegangene Mail auf dem Rechner selbst lesen (mutt, mail), bis Sie einen Postfachserver wie Dovecot hinzufügen. Siehe Nächste Schritte.

2.2. Voraussetzungen

  • Ein VPS mit einer öffentlichen, statischen IPv4-Adresse (und idealerweise einer IPv6-Adresse) sowie Root-Zugang. Wir verwenden 203.0.113.7 / 2001:db8::25 als Platzhalter.

  • Eine registrierte Domain, deren DNS Sie bearbeiten können (example.org).

  • TCP-Port 25 muss den VPS in beide Richtungen erreichen. Der eingehende Port 25 trägt die Nachrichten, die Sie empfangen; der ausgehende Port 25 lässt den Host Bounces an die Absender zurücksenden. Viele günstige Anbieter blockieren ausgehenden Port 25 standardmäßig — wenn eingehende Post nie ankommt oder Bounces nie die Warteschlange verlassen, ist das die übliche Ursache; bitten Sie den Anbieter, ihn zu öffnen. (Lässt sich der ausgehende Port 25 nicht freigeben, senden Sie die Bounces stattdessen über einen Smarthost — siehe pepsi-stage-relay-to-smarthost.)

  • Reverse-DNS (PTR). Setzen Sie den PTR-Eintrag des VPS auf mail.example.org — das geschieht im Kontrollpanel des VPS-Anbieters, nicht in der Zone Ihrer Domain. Er muss denselben Host benennen, den Sie im EHLO ankündigen: Viele Empfänger vergleichen beide und lehnen die Sitzung ab, wenn sie sich unterscheiden (HELO host does not match rDNS), worüber man auf einer Maschine, die auf mehrere Namen hört, leicht stolpert. pepsi-setup run warnt bei jeder sendenden Adresse, deren PTR fehlt, unbestätigt ist oder einen anderen Host benennt, und pepsi-setup --wizard schlägt genau deshalb den PTR-Namen als Hostnamen vor.

  • Die Build-Voraussetzungen aus Installation: eine Rust-Toolchain, PostgreSQL und (für automatisches TLS) certbot. Installieren Sie sie mit dem Paketmanager Ihrer Plattform.

2.3. Schritt 1 — DNS delegieren und die Basis-Einträge anlegen

Pepsi enthält keinen DNS-Server; Sie veröffentlichen Einträge dort, wo die Zone Ihrer Domain autoritativ ist. Sie haben zwei Möglichkeiten, und „Delegation“ bedeutet für jede etwas anderes:

  • Die Zone bei einem DNS-Anbieter hosten (Ihrem Registrar oder einem Dienst wie einem verwalteten DNS-Host). Hier delegiert der Registrar example.org bereits an die Nameserver dieses Anbieters; Sie fügen nur Einträge in dessen Panel hinzu. Das ist der einfachste Weg.

  • Ihren eigenen autoritativen Nameserver betreiben (BIND, NSD, Knot, …) auf dem VPS oder anderswo. Dann setzen Sie beim Registrar die NS-Einträge von example.org auf Ihre Nameserver und fügen, falls ein Nameserver selbst innerhalb von example.org liegt, die passenden Glue-A/AAAA-Einträge beim Registrar hinzu, damit die Delegation auflösbar ist:

    ; at the registrar (delegation + glue)
example.org.        NS    ns1.example.org.
ns1.example.org.    A     203.0.113.7

So oder so: Sobald die Zone unter Ihrer Kontrolle ist, fügen Sie die beiden Einträge hinzu, die der Mail-Host sofort benötigt:

; the mail host's address
mail.example.org.   A     203.0.113.7
mail.example.org.   AAAA  2001:db8::25

; mail for the domain goes to that host
example.org.        MX    10 mail.example.org.

Bemerkung

Die übrigen Einträge — SPF, DKIM und DMARC — werden in Schritt 6 — Die übrigen Einträge veröffentlichen und überprüfen hinzugefügt, nachdem pepsi-setup den DKIM-Schlüssel erzeugt und den genau zu veröffentlichenden Text ausgegeben hat. (MTA-STS- und TLS-Reporting-Einträge werden nur hinzugefügt, wenn Sie diese optionalen Funktionen aktivieren — siehe Nächste Schritte.) Den A/AAAA-Eintrag fügen Sie jedoch jetzt hinzu: Das automatische TLS-Zertifikat in Schritt 5 setzt voraus, dass mail.example.org bereits auf diesen VPS auflöst.

2.4. Schritt 2 — Pepsi installieren

Diese Anleitung baut und installiert aus einem Quellcode-Checkout, damit jeder Schritt sichtbar ist. Auf Debian und dessen Derivaten können Sie stattdessen das .deb installieren, dessen postinst die Schritte 2 und 3 für Sie erledigt — siehe den Tab Debian-Paket von Installation und das Kapitel Debian-Pakete; der Rest dieses Kapitels gilt unverändert.

Holen Sie zuerst das mitgelieferte Submodul, installieren Sie dann Binärprogramme, SQL und die Beispielkonfiguration in einem Schritt:

git submodule update --init --recursive
make install PREFIX=/usr SYSCONFDIR=/etc

Dies installiert die pepsi-*-Binärprogramme, die SQL-Migrationen und eine Beispiel-/etc/pepsi/pepsi.conf. Siehe Installation dazu, was jeder Schritt tut (und Lebenszyklus des Datenbankschemas dazu, wie sich das Datenbankschema weiterentwickelt); führen Sie make install als Root aus, damit der Helper für die lokale Zustellung mit seinen Privilegien installiert werden kann (nächster Schritt).

2.5. Schritt 3 — Das System vorbereiten

Die lokale Zustellung schreibt in die Home-Verzeichnisse anderer Benutzer, daher trennt Pepsi die Privilegien mit dedizierten Dienstbenutzern und einem eng begrenzten setuid-Helper. Die Kontonamen sind nicht konventionell — sie sind einkompiliert, legen Sie sie also genau so an, wie sie geschrieben stehen (verwenden Sie die Benutzer-/Gruppenwerkzeuge Ihrer Plattform):

  • pepsi — der Dienstbenutzer, unter dem der Dispatcher und jeder Stage-Worker laufen;

  • pepsi-ingress — das eigene Konto des SMTP-Servers (er weigert sich, als Root zu starten, wenn dieses Konto nicht existiert);

  • pepsi-owner — das Bootstrap-Konto, auf das pepsi-setup seine Privilegien abgibt, wenn es als Root ausgeführt wird, und der Eigentümer des Datenbankschemas;

  • eine pepsi-maildir-Gruppe, die den Zustell-Helper absichert.

Installation listet den vollständigen Satz auf (einschließlich der Konten für die Web-Konsole, den Schlüsselspeicher und die übrigen privilegierten Helper); die vier oben sind die, die diese Anleitung verwendet.

Der Zustellpfad hat zwei Privilegien-Bits, die make install automatisch setzt, wenn es als Root ausgeführt wird und die pepsi-maildir-Gruppe bereits existiert; andernfalls setzen Sie sie von Hand:

  • pepsi-helper-maildir-writer(1) muss setuid-root und gruppenbeschränkt sein (chown root:pepsi-maildir … ; chmod 4750 …), und

  • pepsi-stage-relay-to-maildir muss setgid pepsi-maildir sein und pepsi gehören (chown pepsi:pepsi-maildir … ; chmod 2550 …); das ist es, was dem unprivilegierten pepsi-Worker erlaubt, den Helper auszuführen, und was sonst niemandem gestattet, es zu tun.

Die Begründung finden Sie in diesen beiden Kapiteln.

Legen Sie die Datenbank an. Pepsi verbindet sich über den lokalen Socket als der sich verbindende Systembenutzer (Peer-Authentifizierung), daher braucht jedes dieser Konten eine eigene Login-Rolle — der Server verbindet sich als pepsi-ingress, die Stages als pepsi, und pepsi-setup installiert das Schema als pepsi-owner und besitzt es. Legen Sie die vollständige Menge der Rollen an, nicht nur die drei, unter denen diese Anleitung läuft: pepsi-setup run vergibt Rechte an jede davon, und weil es seine Datenbankarbeit als pepsi-owner erledigt, das keine Rollen anlegen kann, bricht eine fehlende Rolle es mit permission denied to create role ab. Als Superuser postgres, mit einer Datenbank passend zu CONFIG = postgres:///pepsi unten:

for r in pepsi-owner pepsi pepsi-ingress pepsi-httpd pepsi-whitelist \
         pepsi-config pepsi-crypto pepsi-keydisc pepsi-telemetry; do
    createuser "$r"        # createuser takes one role name at a time
done
createdb -O pepsi-owner pepsi

Legen Sie schließlich mindestens ein lokales Postfachkonto an, um Mail zu empfangen:

useradd --create-home alice

2.6. Schritt 4 — Die Konfiguration schreiben

Alle Komponenten lesen eine Datei, /etc/pepsi/pepsi.conf. Die in Schritt 2 installierte Beispielkonfiguration ist ein voll ausgestatteter Weiterleiter; für diese Anleitung wollen Sie stattdessen die minimale Konfiguration aus lokaler Zustellung plus Bounce. Es gibt zwei gleichwertige Wege, sie zu erzeugen — pepsi-setup sie aus einigen Antworten generieren lassen oder sie von Hand schreiben — und beide bauen dieselbe Pipeline. (Das Format und jede Option werden in Konfiguration und pepsi.conf(5) beschrieben.)

pepsi-setup --wizard führt ein kurzes Interview durch, schreibt eine vollständige und bereits validierte /etc/pepsi/pepsi.conf und bietet anschließend an, die Einrichtung aus Schritt 5 für Sie auszuführen. Starten Sie es:

pepsi-setup --wizard

Beantworten Sie die Eingabeaufforderungen wie folgt. Drücken Sie die Eingabetaste, um einen [default] zu übernehmen; alle hier nicht aufgeführten Aufforderungen können ihre Standardwerte behalten (sie sind nein für diesen minimalen Host):

  • Mail-Richtung, die dieser Host bedient — inbound

  • Hostname des Mailservers (MX-/EHLO-Name) — mail.example.org. Der hier angebotene Standardwert ist der Name, auf den die öffentliche Adresse dieses Hosts rückwärts auflöst; ist das nicht mail.example.org, korrigieren Sie den PTR-Eintrag, bevor Sie weitergehen, statt ihn hier zu überschreiben.

  • Domain(s), für die wir E-Mails annehmen — example.org

  • Postmaster-Adresse — den Standardwert übernehmen (postmaster@example.org)

  • Öffentliche sendende IP-Adresse(n) für SPF — 203.0.113.7 2001:db8::25

  • PostgreSQL-Verbindungszeichenfolge — den Standardwert übernehmen (postgres:///pepsi)

  • E-Mails für lokale Systemkonten in deren Maildir zustellen — yes

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

  • Eine MTA-STS-Richtlinie über HTTPS bereitstellen — no (optionale Härtung, später ergänzt; siehe Nächste Schritte)

  • SMTP-TLS-Reports (TLSRPT) senden und ankündigen — no

Der Assistent validiert das Ergebnis, schreibt die Datei und fragt, ob das vollständige Setup jetzt ausgeführt werden soll: Antworten Sie mit yes, um Schritt 5 in diesen Schritt zu integrieren, oder mit no, um pepsi-setup run anschließend selbst auszuführen. Ihre Antworten werden in einem [pepsi-wizard]-Abschnitt festgehalten, sodass ein erneuter Lauf des Assistenten sie vorausfüllt.

Die Datei, die er schreibt, baut denselben eingehenden Pfad wie die handgeschriebene im anderen Reiter — ARC, dann Maildir-Zustellung, mit dem Bounce-/Signier-/Internet-Anhang dahinter — dazu ein paar produktionstaugliche Standardwerte (DANE = warn, Nachrichtenlebensdauern). Sie unterscheidet sich in einem Punkt bewusst. Die handgeschriebene Konfiguration schickt das NEXT_STAGE von [stage-local] auf den Bounce-Pfad, sodass alles, was die lokale Zustellung nicht verbrauchen kann, einen Bounce erhält; der Assistent richtet stattdessen UNKNOWN_MAILBOX_STAGE auf den Bounce (ein unbekannter Benutzer einer unserer eigenen Domains) und gibt der Stage einen bedingungslosen SRS- und Relay-Anhang (srs → dkim-sign-relay → internet) für die Empfänger, die kein Fehler sind — ein Alias, der nach außen expandiert, ein ~/.forward bei einem anderen Anbieter. Sie stellt außerdem an jedes reguläre Login-Konto zu; fügen Sie TARGETS = alice zu [stage-local] hinzu, um die Zustellung auf benannte Konten zu beschränken.

Dasselbe Interview ohne Terminal. pepsi-setup questions gibt es als JSON aus — Bezeichner, Form, Standardwert und Hilfetext jeder Frage —, und pepsi-setup --wizard --answers answers.json beantwortet es aus einer Datei dieser Bezeichner. Es ist das interaktive Interview mit vorgegebenen Antworten, keine zweite Implementierung, sodass die Verzweigungen und die Validierung je Feld dieselben sind wie oben. Das ist auch das Modell, das das Setup im Browser rendert; siehe den Abschnitt „Im Browser einrichten“ in Installation.

Ersetzen Sie /etc/pepsi/pepsi.conf durch Folgendes:

[pepsi]
# Where pepsi-setup writes the generated DKIM/ARC keys.
KEY_DIR = /var/pepsi/keys
DKIM_SELECTOR = pepsi
# Identity that signs the ARC seal recording the inbound verdict.
ARC_DOMAIN = example.org
# This minimal host does not serve an MTA-STS policy (that needs the
# HTTPS server), so do not advertise one. See "Next steps" to add it.
MTA_STS_MODE = none

[pepsi-postgres]
CONFIG = postgres:///pepsi

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

# The MX listener on port 25. MODE = starttls with no TLS_CERT/TLS_KEY
# lets pepsi-setup fill in the certbot certificate paths (Step 5).
[pepsi-ingress-listener-mx]
SERVE = tcp
BIND_TO = 0.0.0.0
PORT = 25
MODE = starttls

# New messages enter here. ARC-seal the SPF/DKIM/DMARC verdict Pepsi
# computed at the boundary, then hand the message to local delivery.
[stage-init]
PROGRAM = pepsi-stage-arc
NEXT_STAGE = local

# Deliver to a local user's Maildir. By default any regular login account
# (the /etc/login.defs UID range) may receive mail, so 'alice' is already
# covered; set TARGETS to restrict delivery to an allow-list (e.g.
# TARGETS = alice). Anything not deliverable here is sent to the bounce
# path: an unknown recipient via NEXT_STAGE, a mailbox that fails to
# accept it via BOUNCE_STAGE.
[stage-local]
PROGRAM = pepsi-stage-relay-to-maildir
SERVER_NAME = mail.example.org
NEXT_STAGE = bounce
BOUNCE_STAGE = bounce

# --- Outbound bounce path: turn an undeliverable message into a DSN and
# mail it back to the original sender. Three short stages: build, sign,
# send.

# Rewrite the message in place into an (unsigned) RFC 3464 bounce
# addressed to the original sender, then hand it to the signer.
[stage-bounce]
PROGRAM = pepsi-stage-bounce
SERVER_NAME = mail.example.org
NEXT_STAGE = sign

# DKIM-sign the bounce so it authenticates at the sender's server.
[stage-sign]
PROGRAM = pepsi-stage-dkim-sign
NEXT_STAGE = internet

# Deliver the signed bounce directly to the sender's mail exchanger.
[stage-internet]
PROGRAM = pepsi-stage-relay-to-internet
SERVER_NAME = mail.example.org
# Read by pepsi-setup to build the SPF record authorising this host to
# send (the bounces above, and any outbound mail you add later).
# PUBLIC_IP is a per-STAGE option: pepsi-setup finds it by walking the
# [stage-*] sections and keeping the relays, never by a section named
# after the program -- with no relay stage setting it the record is a
# bare "v=spf1 -all", which makes our own mail fail SPF.
PUBLIC_IP = 203.0.113.7 2001:db8::25

Eine Nachricht für einen Empfänger, der kein erlaubtes lokales Postfach ist, wird in einen Bounce verwandelt und an den Absender zurückgesendet, statt stillschweigend fehlzuschlagen: Ein unbekannter @example.org-Empfänger nimmt über das NEXT_STAGE von [stage-local] den Bounce-Pfad, und ein bekanntes Postfach, das nicht beschrieben werden kann (volle Festplatte, Rechte), wird wiederholt und dann über BOUNCE_STAGE gebounct. Beide verweisen auf dasselbe [stage-bounce].

Beachten Sie, dass NEXT_STAGE hier zur Bounce-Stage führt, nicht zu [stage-internet]. Dieser Host bedient nur lokale Postfächer, also ist jeder Empfänger, den er nicht zustellen kann, ein unbekannter Benutzer unserer eigenen Domain, und diese weiterzuleiten würde den MX von example.org nachschlagen, genau diesen Host finden und die Mail direkt an uns zurücksenden — eine Schleife. Diesen Host in einen echten Weiterleiter zu verwandeln — bei dem ein Alias legitimerweise zu einer Adresse anderswo expandieren darf — ist ein eigener Schritt (Nächste Schritte); dort erreicht NEXT_STAGE tatsächlich ein Relay, und UNKNOWN_MAILBOX_STAGE hält unbekannte lokale Benutzer auf dem Bounce-Pfad (siehe pepsi-stage-relay-to-maildir).

2.7. Schritt 5 — Schema, Schlüssel und Zertifikat einrichten

Wenn Sie in Schritt 4 den Assistenten verwendet und „Setup jetzt ausführen“ mit yes beantwortet haben, ist dies bereits erledigt — führen Sie den Befehl unten jederzeit erneut aus, um die DNS-Einträge nochmals zu erfassen (er ist idempotent). Andernfalls führen Sie das Bootstrap-Werkzeug einmal aus und erfassen die von ihm ausgegebenen DNS-Einträge:

pepsi-setup -c /etc/pepsi/pepsi.conf run > pepsi-dns.zone

Dies validiert die Konfiguration, installiert das pepsi-Schema, erzeugt die domainspezifischen DKIM/ARC-Schlüssel unter KEY_DIR, bezieht das TLS-Zertifikat für mail.example.org über certbot (dazu muss der A-Eintrag aus Schritt 1 aktiv und der eingehende Port 80 erreichbar sein) und gibt die übrigen DNS-Einträge nach pepsi-dns.zone aus. Es ist idempotent und kann gefahrlos erneut ausgeführt werden.

Wenn Sie das Zertifikat lieber selbst verwalten möchten, übergeben Sie --no-certbot und setzen TLS_CERT/TLS_KEY im Listener-Abschnitt. Der vollständige Einrichtungsablauf steht in pepsi-setup und Installation.

2.8. Schritt 6 — Die übrigen Einträge veröffentlichen und überprüfen

Öffnen Sie pepsi-dns.zone und veröffentlichen Sie die dort aufgeführten Einträge in Ihrer Zone:

  • den öffentlichen DKIM-Schlüssel (pepsi._domainkey.example.org TXT),

  • die SPF-Richtlinie, die die sendenden Adressen dieses Hosts auflistet, und

  • eine DMARC-Richtlinie (_dmarc.example.org TXT).

(Für den minimalen Host werden nur diese ausgegeben; ein MTA-STS- oder TLS-Reporting-Eintrag erscheint hier ebenfalls, sobald Sie diese Funktionen aktivieren — siehe Nächste Schritte.)

Die vorgeschlagene DMARC-Richtlinie ist v=DMARC1; p=none, die Empfänger bittet, über Mail, die die Authentifizierung nicht besteht, zu berichten, ohne darauf zu reagieren. Beginnen Sie dort, aber bleiben Sie nicht dort: Ergänzen Sie rua=mailto:<address>, damit die Sammelberichte Sie erreichen, und sobald diese Ihre eigene Mail als bestanden zeigen, verschärfen Sie p= auf quarantine und dann reject. Veröffentlichen Sie ihn von Hand, sorgfältig — ein DMARC-Eintrag, der nicht parst, wird stillschweigend verworfen, und eine Domain, deren Richtlinie ein fehlendes ; von der Gültigkeit entfernt ist, sieht geschützt aus und ist es nicht. Genau dafür ist das check unten da.

Zwei weitere Blöcke kommen hinzu, sobald dieser Host Ende-zu-Ende-Kryptographie betreibt, und bei beiden geht es darum, Korrespondenten die Schlüssel Ihrer Benutzer finden zu lassen (Schlüsselverwaltung):

  • ein openpgpkey.example.org-A/AAAA-Eintrag, der auf diesen Host zeigt, benötigt von der advanced-Methode des Web Key Directory — derjenigen, die jeder aktuelle Client zuerst versucht. pepsi-setup bittet certbot auch, diesen Namen abzudecken, veröffentlichen Sie den Eintrag also vor der nächsten Zertifikatsausstellung. Die direct-Methode auf dem Apex funktioniert ohne ihn, sodass ein fehlender Eintrag eher eine Verschlechterung als ein Ausfall ist;

  • ein OPENPGPKEY- (RFC 7929) oder SMIMEA-Eintrag (RFC 8162) je veröffentlichter Identität. Veröffentlichen Sie diese nur, wenn Ihre Zone DNSSEC-signiert ist: Ein unsignierter Schlüsseleintrag ist ein Schlüssel von wem auch immer für die Zone antworten kann, was gegenüber gar keinem Schlüssel keine Verbesserung ist. Das Web Key Directory braucht kein DNSSEC, weil HTTPS die Domain selbst authentifiziert.

Sobald sich DNS verbreitet hat, prüfen Sie das Veröffentlichte gegen das, was Pepsi erwartet:

pepsi-setup -c /etc/pepsi/pepsi.conf check

Dies ist informativ (es endet immer mit 0); es weist auf einen fehlenden oder abweichenden DKIM- oder SPF-Eintrag hin (und auf MTA-STS, sobald aktiviert), damit Sie die Zone korrigieren können, bevor Sie sich darauf verlassen. Es validiert außerdem den DMARC-Eintrag streng und meldet einen, den Empfänger ignorieren würden, als [INVALID] unter Nennung des beanstandeten Tags — der eine Fehler in dieser Liste, der weder einen Bounce noch eine Journalzeile noch eine Beschwerde von irgendjemandem erzeugt.

2.9. Schritt 7 — Die Dienste starten

Zwei langlebige Prozesse laufen dauerhaft, jeder unter seinem eigenen Konto:

  • pepsi-ingress serve — der eingehende SMTP-Server, der seine Privilegien auf den Benutzer pepsi-ingress abgibt, und

  • pepsi-dispatch serve — der Stage-Koordinator (genau einer pro Host), der als pepsi läuft und jeden Stage-Worker als dieser Benutzer startet.

Führen Sie jeden unter dem Dienst-/Prozessmanager Ihrer Plattform aus, sodass sie beim Systemstart starten und bei einem Fehler neu starten. Die Stage-Programme selbst werden vom Dispatcher gestartet; Sie starten sie nie von Hand. Das Binden von Port 25 erfordert Privilegien: Starten Sie pepsi-ingress als Root — es bindet seine Listener und wechselt dann zum Konto pepsi-ingress, bevor es eine Verbindung bedient — oder verwenden Sie Socket-Aktivierung. Geben Sie ihm stattdessen keine Datei-Capability: Im Release-Layout ist pepsi-ingress ein Symlink auf das eine Multi-Call-Binärprogramm, sodass die Capability auf jedem eingefalteten Programm landen würde. Siehe Installation und pepsi-ingress.

2.10. Schritt 8 — Die erste E-Mail senden

Senden Sie von einem Konto bei einem anderen Anbieter eine Nachricht an alice@example.org (oder verwenden Sie ein Werkzeug wie swaks --to alice@example.org --server mail.example.org). Beobachten Sie, wie sie sich durch die Pipeline bewegt:

pepsi-status -c /etc/pepsi/pepsi.conf

Eine zugestellte Nachricht wird aus der Warteschlange entfernt, sodass ein gesunder Lauf einen leeren Rückstau und einen erhöhten Zustellungszähler zeigt. Bestätigen Sie, dass die Nachricht tatsächlich angekommen ist:

ls /home/alice/Maildir/new/
mutt -f /home/alice/Maildir          # or: mail

Wenn die Datei da ist, haben Sie Ihre erste E-Mail empfangen.

2.11. Schritt 9 — Die Konsole öffnen (optional)

Alles Obige ist auch in einem Browser sichtbar. Fügen Sie einen an das Loopback gebundenen administrativen Listener hinzu:

[pepsi-httpd-listener-admin]
SERVE = tcp
BIND_TO = 127.0.0.1
PORT = 8443
MODE = plain
ADMIN = yes

und ein Konto zum Anmelden — über den lokalen Socket braucht ein Mitglied der Gruppe pepsi-admin keines, aber ein Browser kann keinen UNIX-Socket öffnen, legen Sie also eines an und erreichen Sie den Listener über einen SSH-Tunnel:

ssh -L 8443:127.0.0.1:8443 root@mail.example.org

Öffnen Sie dann http://127.0.0.1:8443/ui. Das Dashboard zeigt dieselbe Warteschlange, die pepsi-status ausgegeben hat, die Konfigurationsseiten zeigen, woher jeder Wert stammt, und das Prüfprotokoll hält jede Änderung fest, die über irgendeine Oberfläche vorgenommen wurde. Siehe Die Verwaltungskonsole für die Seitenreferenz und Die administrative API für die API, deren Client sie ist. Die Konsole übt keine Dienststeuerung aus: Eine Komponente neu zu starten bleibt Sache von systemctl.

2.12. Auch Mail senden: einen Submission-Port hinzufügen

Bisher empfängt der Host nur. Damit Ihre eigenen Benutzer Mail über ihn aus einem Mail-Client (Thunderbird, Evolution, KMail oder K-9 Mail auf dem Handy) senden können, fügen Sie einen authentifizierten Submission-Listener und einen ausgehenden Zustellpfad hinzu. Ein Client authentifiziert sich mit Benutzername und Passwort; pepsi-ingress zeichnet die Nachricht dann mit state.local_origin = true auf, was ihr sowohl erlaubt, an jede Domain weiterzuleiten (nicht nur example.org), als auch die Pipeline sie von eingehender Post unterscheiden lässt.

Öffnen Sie die eingehenden TCP-Ports 465 und/oder 587 in der VPS-Firewall, genauso wie Sie Port 25 geöffnet haben.

2.12.1. Eingehend und ausgehend getrennt routen

Sie haben bereits einen ausgehenden Zustellpfad für die Bounces gebaut — [stage-sign] → [stage-internet], mit dem SPF-Eintrag, der diesen Host abdeckt. Authentifizierte Submissions verwenden genau diesen Pfad erneut; Sie müssen sie nur darauf routen.

Ausgehende Mail muss einen anderen Pfad als eingehende nehmen, und dies falsch zu machen verursacht eine Mail-Schleife: Würden Sie [stage-init] einfach auf [stage-sign] richten, würde eingehende Mail signiert und wieder hinausgeleitet, statt lokal zugestellt zu werden. Verzweigen Sie stattdessen am Einstiegspunkt anhand von state.local_origin mit einer pepsi-stage-if-Stage — lokal erzeugte (authentifizierte) Mail geht auf den ausgehenden Pfad, alles andere auf den eingehenden Pfad. Die Aufteilung muss vor pepsi-stage-arc kommen: ARC bewahrt die Authentifizierung eines vorgelagerten Absenders über Ihren Weiterleitungs-Hop hinweg, ist also für Mail, die Ihre eigenen Benutzer erzeugen, bedeutungslos — und darf sie niemals berühren (jene Mail wird stattdessen von [stage-sign] authentifiziert; sie ARC zu versiegeln würde nur den SPF-fail der Submission selbst veröffentlichen). Machen Sie den Router also zur [stage-init]-Einstiegs-Stage und verschieben Sie ARC auf den eingehenden Zweig:

# Entry: split by direction FIRST. Authenticated submissions (local_origin =
# true) are outbound and reuse the signing path; everything else is inbound and
# goes through ARC. This only moves the stage; it never changes the message.
[stage-init]
PROGRAM = pepsi-stage-if
STATE_PATH = local_origin
VALUE = true
TRUE_STAGE = sign       # outbound: our users' mail (reuses the bounce path)
FALSE_STAGE = arc       # inbound: ARC-seal, then deliver locally

# ARC now sits on the inbound branch (received mail only), feeding local
# delivery just as [stage-init] used to.
[stage-arc]
PROGRAM = pepsi-stage-arc
NEXT_STAGE = local

[stage-sign], [stage-internet] und die PUBLIC_IP-Zeile sind aus dem Bounce-Pfad bereits in Ihrer Konfiguration, sodass Submissions sie unverändert mitnutzen. [stage-arc] ist der frühere [stage-init]-Rumpf (unverändert, nur umbenannt), und [stage-local] ist ebenfalls unverändert — sein NEXT_STAGE/BOUNCE_STAGE bouncet Mail an unbekannte lokale Benutzer weiterhin, statt sie irgendwohin weiterzuleiten. (Die ARC-Stage überspringt jede state.local_origin-Nachricht ohnehin von selbst, sodass eine Fehlplatzierung keine Submission versiegeln kann — doch sie vom ausgehenden Zweig fernzuhalten vermeidet den verschwendeten Hop.)

Bemerkung

Der ausgehende Pfad benötigt den ausgehenden Port 25 (siehe Voraussetzungen), den günstige Anbieter oft blockieren. Ist Ihrer blockiert, stellen Sie stattdessen über einen vorgelagerten Smarthost zu: Ersetzen Sie [stage-internet] durch eine pepsi-stage-relay-to-smarthost-Stage und definieren Sie den Smarthost — siehe pepsi-stage-relay-to-smarthost. Um Unzustellbarkeitsberichte zurückzugeben, wenn ein MX die ausgehende Mail Ihrer Benutzer ablehnt, geben Sie [stage-internet] ebenfalls ein BOUNCE_STAGE = bounce.

2.12.2. Ein Passwort-Backend bereitstellen (Dovecot)

Ein Submission-Listener benötigt eine Möglichkeit, Passwörter zu prüfen. Pepsi führt keine eigene Passwortdatenbank; es verifiziert Zugangsdaten über einen Dovecot-SASL-Socket. Installieren Sie Dovecot und konfigurieren Sie es, Ihre Konten zu authentifizieren (die von Ihnen angelegten Systembenutzer oder virtuelle Benutzer). Pepsis eingehender Server läuft als der unprivilegierte pepsi-ingress-Benutzer, der Dovecots geteilten, nur für root zugänglichen auth-client-Socket nicht öffnen kann; geben Sie ihm daher einen dedizierten Listener, den er besitzt — in /etc/dovecot/conf.d/10-pepsi.conf:

service auth {
  unix_listener auth-client-pepsi {
    mode = 0600
    user = pepsi-ingress
  }
}

Sie müssen dies nicht von Hand schreiben: pepsi-setup run erkennt einen nicht erreichbaren Socket und bietet an, genau dieses Drop-in zu installieren (es mit doveconf zu validieren und Dovecot neu zu laden), oder gibt es aus, wenn es das nicht kann.

Dovecot ist zugleich das, was Sie hinzufügen würden, damit Clients ihre Maildirs über IMAP lesen können (Nächste Schritte). Seine vollständige Konfiguration geht über diese Anleitung hinaus; siehe die Dovecot-Dokumentation.

2.12.3. Die Submission-Listener hinzufügen

Fügen Sie einen Implicit-TLS-Listener auf 465 (für Clients empfohlen) und/oder einen STARTTLS-Listener auf 587 hinzu. SUBMISSION = yes macht die Authentifizierung verpflichtend und wendet die RFC-6409-Korrekturen an (ein fehlendes Date:/Message-ID: wird ergänzt); SASL_TYPE/SASL_PATH binden Dovecot ein. Authentifizierung wird ausschließlich über TLS angeboten. Wie beim MX-Listener lässt das Weglassen von TLS_CERT/TLS_KEY pepsi-setup das mail.example.org-Zertifikat automatisch installieren:

# Port 465: implicit TLS.
[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 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

Führen Sie den Bootstrap erneut aus, damit die Zertifikate der neuen Listener und der aktualisierte SPF-Eintrag übernommen werden, und starten Sie dann die Dienste neu:

pepsi-setup -c /etc/pepsi/pepsi.conf run > pepsi-dns.zone

Veröffentlichen Sie die aktualisierten Einträge (der SPF-Eintrag führt diesen Host nun auf) und überprüfen Sie erneut mit pepsi-setup -c /etc/pepsi/pepsi.conf check.

2.12.4. Einen Mail-Client verbinden

Konfigurieren Sie in den Kontoeinstellungen des Clients den ausgehenden (SMTP)-Server:

  • Server / Host: mail.example.org

  • Port / Sicherheit: 465 mit implizitem TLS (SSL/TLS) oder 587 mit STARTTLS

  • Authentifizierung: normales Passwort

  • Benutzername / Passwort: das von Dovecot erwartete Konto (z. B. alice oder alice@example.org) und sein Passwort

Wenn Sie Dovecot auch für IMAP eingerichtet haben, richten Sie den eingehenden Server auf denselben Host (IMAP, Port 993, TLS). Senden Sie eine Testnachricht an eine Adresse bei einem anderen Anbieter und bestätigen Sie, dass sie die Warteschlange verlassen hat:

pepsi-status -c /etc/pepsi/pepsi.conf

und prüfen Sie, dass sie angekommen ist. Die Zustellbarkeit ausgehender Mail hängt von derselben DNS-Hygiene ab wie der Empfang — korrektes PTR/Reverse-DNS, der SPF-Eintrag, der diesen Host auflistet, und DKIM-Signierung (alles oben konfiguriert); eine brandneue IP wird bei der ersten Kontaktaufnahme manchmal gegreylistet, eine kurze Verzögerung bei der allerersten Nachricht ist daher normal.

2.13. Fehlersuche

Es kommt nichts an

Prüfen Sie, dass der MX-Eintrag auf mail.example.org auflöst und dessen A/AAAA auf den VPS zeigt; bestätigen Sie, dass der eingehende Port 25 offen ist (von einem anderen Host aus testen); bestätigen Sie, dass das PTR/Reverse-DNS gesetzt ist. Beobachten Sie das Ingress-Journal.

Eine Nachricht hängt fest oder ist failed

Untersuchen Sie sie mit pepsi-status und pepsi-queue. Ein Empfänger, der nicht in TARGETS steht oder kein Konto hat, wird an den Absender zurückgebounct (beobachten Sie [stage-bounce] und [stage-internet]), nicht in der Warteschlange belassen; ein timeout/pausierter Datensatz bedeutet oft ein Dateisystemproblem (z. B. eine volle Festplatte) im Home des Empfängers, das vor dem Bounce wiederholt wird. Ein Bounce, der selbst hängenbleibt, bedeutet meist, dass der ausgehende Port 25 blockiert ist (siehe unten).

Der Zertifikatsschritt schlug fehl

certbot setzt voraus, dass mail.example.org bereits auf diesen VPS auflöst und der eingehende Port 80 erreichbar ist. Korrigieren Sie DNS/Port 80 und führen Sie pepsi-setup … run erneut aus, oder verwenden Sie --no-certbot und stellen TLS_CERT/TLS_KEY selbst bereit.

„Permission denied“ bei der Zustellung

Die Privilegien-Bits aus Schritt 3 sind falsch: Der Helper muss 4750 root:pepsi-maildir sein und die Relay-to-Maildir-Stage 2550 pepsi:pepsi-maildir. Führen Sie make install als Root erneut aus, wobei die Gruppe und das pepsi-Konto vorhanden sein müssen, oder setzen Sie sie von Hand.

Ein Client kann sich nicht authentifizieren oder senden

Authentifizierung wird nur über TLS angeboten — verwenden Sie Port 465 (implizites TLS) oder 587 mit STARTTLS und „normales Passwort“. Eine 530-Antwort bedeutet, dass die Sitzung nicht authentifiziert war; prüfen Sie, dass der Dovecot-Auth-Socket (SASL_PATH) für den Benutzer pepsi-ingress lesbar ist — das Konto, auf das der SMTP-Server seine Privilegien abgibt und das das obige Drop-in benennt — und dass Dovecot die Zugangsdaten akzeptiert.

Ausgehende Mail hängt fest

Direkte Internet-Zustellung benötigt den ausgehenden Port 25; blockiert ihn der Anbieter, stellen Sie [stage-internet] auf einen Smarthost um (siehe den Hinweis oben). Untersuchen Sie festhängende Datensätze mit pepsi-status und pepsi-queue.

2.14. Nächste Schritte

  • Mail aus der Ferne lesen. Fügen Sie einen IMAP-Server (z. B. Dovecot) hinzu, der auf dasselbe ~/Maildir zeigt, sodass Mail-Clients sie abrufen können; Pepsi kümmert sich nur um die Zustellung in das Maildir. Wenn Sie Dovecot oben bereits für die Submission-Authentifizierung hinzugefügt haben, ist das Aktivieren von IMAP ein kleiner zusätzlicher Schritt.

  • Daraus einen Weiterleiter machen. Fügen Sie pepsi-stage-srs auf dem eingehenden Pfad ein, damit an einen Dritten weitergesendete Mail SPF besteht, und verwenden Sie dabei das ausgehende Relay ([stage-sign] → [stage-internet]) wieder, das bereits in dieser Konfiguration steht (Einführung).

  • Die Bounces anpassen. Der Bounce-Pfad ist bereits verdrahtet; Sie können den DSN-Text mit einer BOUNCE_MESSAGE-Vorlage lokalisieren oder mit Ihrer Marke versehen — siehe pepsi-stage-bounce.

  • Eingehendes TLS härten (MTA-STS + TLS-Reporting). Weisen Sie andere Absender an, validiertes TLS zu Ihrem MX zu verwenden, indem Sie eine MTA-STS-Richtlinie bereitstellen, und sammeln Sie TLS-Reports (RFC 8460). Beide benötigen den laufenden HTTPS-Server (pepsi-httpd) und ein Zertifikat für jede mta-sts.<domain>; am einfachsten fügen Sie sie hinzu, indem Sie pepsi-setup --wizard erneut ausführen und die beiden Transportsicherheitsfragen mit yes beantworten (es füllt Ihre früheren Antworten vor).

  • Filtern und schützen. Ergänzen Sie Sprachblockierung, weiße Listen für Absender oder die Pay-to-Send-Bezahlschranke — siehe Unterstützte Funktionen und die stagespezifischen Kapitel.

  • Einer bestehenden Exchange- oder Microsoft-365-Installation vorschalten. Pepsi kann als transparentes Krypto-Gateway vor und hinter Exchange sitzen, sodass Benutzer S/MIME und OpenPGP bekommen, ohne ihre Clients anzufassen. Das ist eine andere Topologie als die obige — Mail wird zu Exchange geroutet statt lokal zugestellt, was Schleifenverhinderung zwingend statt ratsam macht — und sie hat ein eigenes Kapitel: Microsoft Exchange als Gateway.