1. Einführung

1.1. Was Pepsi ist

Pepsi ist ein MTA: Es empfängt Mail auf seinem eigenen SMTP-Server, authentifiziert sie und stellt sie dann entweder in ein lokales Postfach zu oder sendet sie erneut an die eigentlichen Ziele. Es ist als eine Folge kleiner Stage-Programme mit je einem Zweck aufgebaut, die über eine gemeinsame Datenbanktabelle verkettet sind, sodass jeder Verarbeitungsschritt — ARC-Versiegelung, SRS-Umschreibung, DKIM-Signierung, Bounce-Erzeugung, Zustellung — ein eigenständiges Programm ist, das umgeordnet, ersetzt oder erweitert werden kann.

Welche dieser beiden Rollen eine Installation nutzt, ist eine Frage der Konfiguration. Richtet man das Ende der Pipeline auf eine Relay-Stage, ist Pepsi ein Weiterleiter vor einem anderen Mailsystem; richtet man es auf eine lokale Zustell-Stage, ist Pepsi das endgültige Ziel. Beides sind gewöhnliche Konfigurationen, und eine einzelne Installation tut regelmäßig beides und wählt je Empfänger.

Es ist außerdem ein Ende-zu-Ende-Krypto-Gateway. Dieselbe Pipeline, die die Authentifizierung repariert, kann ausgehende Mail als ihr Autor signieren und verschlüsseln und eingehende Mail für die von diesem Host bedienten Empfänger entschlüsseln und verifizieren, in OpenPGP oder S/MIME, und tut damit auf dem Server, was sonst ein Plugin im Mail-Client jedes Benutzers erforderte. Alles, was das praktikabel macht, gehört zum System: ein Schlüsselspeicher, automatische Entdeckung und Veröffentlichung von Schlüsseln und ein Browser-Portal für den häufigen Fall eines Korrespondenten, der überhaupt keinen Schlüssel hat. Siehe Das Verschlüsselungsproblem weiter unten.

Pepsi ist in Rust geschrieben, als Cargo-Workspace organisiert und unter der GNU Affero General Public License v3.0 oder höher lizenziert. Es verwendet die Konfigurations-, CLI- und Datenbankmechanik aus den mitgelieferten GNU-Taler-Rust-Bibliotheken wieder.

1.2. Das Weiterleitungsproblem

Wenn ein an der Grenze stehender MTA Mail weiterleitet, sendet er von seinen eigenen IP-Adressen unter der Umschlag-Domain des ursprünglichen Absenders. Das durchbricht zwei der drei großen Authentifizierungsmechanismen:

• SPF schlägt fehl, weil der SPF-Eintrag der ursprünglichen Domain die IP-Adressen des Weiterleiters nicht aufführt.

• DKIM-Alignment ist häufig gebrochen, weil Listensoftware und Weiterleiter die Nachricht verändern.

Ein naiver Weiterleiter macht aus legitimer Mail somit Mail, die der endgültige Empfänger als gefälscht bewertet. Pepsi begegnet dem an zwei Fronten:

• Es hält das Urteil an der Grenze fest — verifiziert SPF/DKIM/DMARC beim Eintreffen und versiegelt das Ergebnis in einer ARC-Kette (RFC 8617) —, sodass der endgültige Empfänger dem vertrauen kann, was Pepsi gesehen hat, obwohl die Weiterleitung die ursprünglichen Signale zerstört hat.

• Es repariert den Umschlag mit SRS (Sender Rewriting Scheme), damit SPF beim nächsten Hop besteht, und signiert ausgehende Mail unter einer von Pepsi kontrollierten Domain erneut per DKIM.

1.3. Das Verschlüsselungsproblem

Ende-zu-Ende-Mailverschlüsselung gibt es seit dreißig Jahren, und sie wird immer noch kaum genutzt. Der Grund ist nicht die Kryptographie, sondern dass jeder Beteiligte etwas installieren, konfigurieren und pflegen muss — und dann verwandelt ein Korrespondent, der das nicht getan hat, den ganzen Austausch wieder in Klartext.

Pepsi verlagert die Arbeit auf den Server:

• pepsi-stage-encrypt signiert eine lokal eingelieferte Nachricht mit dem Schlüssel des From:-Autors und verschlüsselt sie an jeden Empfänger, in OpenPGP (PGP/MIME) oder S/MIME (CMS). Jeder verschlüsselte Empfänger bekommt sein eigenes Chiffrat auf seinem eigenen Warteschlangen-Datensatz, sodass es keine Offenlegung der Empfängerliste gibt und ein Bcc-Leck strukturell unmöglich ist.

• pepsi-stage-decrypt ist die eingehende Hälfte: Es öffnet jedes eingetroffene Chiffrat, verifiziert jede darin mitgeführte Signatur, hält ein bewusst präzises Urteil fest und entfernt jeden vom Absender gefälschten Sicherheitsindikator. Der Benutzer liest gewöhnliche Mail in seinem üblichen Client.

• Die Schlüssel kommen aus einem Schlüsselspeicher, den eine asynchrone Entdeckungsschicht füllt — WKD, DANE (OPENPGPKEY/SMIMEA), das VKS-Keyserver-Protokoll, LDAP und Ernten aus eingehender Mail —, wobei jede Quelle danach eingestuft wird, wie viel ihre Herkunft wert ist. Die Schlüssel unserer eigenen Benutzer werden auf denselben Wegen veröffentlicht. Schlüsselverwaltung ist das Kapitel über all das.

• Wenn ein Korrespondent keinen Schlüssel veröffentlicht, lautet die Wahl nicht nur „Klartext oder Bounce“: Das Das Secure-Link-Ausweichportal-Portal speichert die Nachricht verschlüsselt unter einer frisch erzeugten PIN und mailt dem Empfänger einen Link. Eine gespeicherte Nachricht lässt sich ohne die PIN weder aus der Datenbank noch aus einer Sicherung lesen — aber der Server hat den Klartext verarbeitet, als die Nachricht eingeliefert wurde, daher schützt dies gegen einen passiven Leser gespeicherter Daten, nicht gegen den Betreiber.

Weil das Gateway an der Grenze sitzt statt im Client, funktioniert es für Benutzer, die nichts installieren, und es kann vor ein bestehendes Mailsystem gesetzt werden, das diese Funktionen nie selbst bekommen wird — siehe Microsoft Exchange als Gateway. Was es nicht sein kann, ist Ende zu Ende im strengen Sinne: Der Server sieht Klartext, das ist die Abwägung, die getroffen wird, und Schlüsselverwaltung sagt das unumwunden.

1.4. Der Aufbau des Systems

Alle Komponenten teilen sich eine PostgreSQL-Datenbank (das einzige pepsi-Schema) und eine Konfigurationsdatei im INI-Stil; sie sind nur im Zusammenspiel nützlich.

1. pepsi-ingress ist der eingehende SMTP-Server (MTA). Er nimmt eine Nachricht an, authentifiziert sie, speichert sie als einen Datensatz in der Tabelle pepsi.workqueue und benachrichtigt die Pipeline.

2. pepsi-dispatch ist der einzige Koordinator. Er beansprucht neu eingereihte Datensätze und reicht jeden an einen persistenten Worker-Prozess der Stage des Datensatzes weiter; eine Stage, die mit einer Nachricht fertig ist, verschiebt den Datensatz selbst zur nächsten Stage, und der Dispatcher beansprucht ihn dort in seiner nächsten Runde.

3. Die pepsi-stage-*-Programme sind die Stages: ARC, SRS, DKIM-Signierung, Verschlüsselung und Entschlüsselung, Bounce-Erzeugung, Alias-Expansion, Routing je Empfänger, Richtlinienfilter (weiße Listen, Pay-to-Send, Confirm-to-Send, Sprache, Milter nach der Warteschlange und Einstellungen je Adresse), der Abwesenheitsresponder, die Mailinglisten-Stages, zwei externe Relay-Stages, die lokalen Zustell-Stages (Maildir, LMTP, ~/.forward) und eine Test-Senke. Jede läuft als persistenter Worker (PROGRAM worker, der Nachrichten-IDs von der Standardeingabe liest).

4. pepsi-keydisc ist der asynchrone Schlüsselentdeckungsdienst — eine Instanz je Methode —, dem die Krypto-Stages eine Abfrage übergeben, statt eigene Netzwerk-E/A zu betreiben, und pepsi-keys ist die Operator-CLI für den Schlüsselspeicher.

5. pepsi-httpd ist der HTTP/HTTPS-Server: Er bedient die MTA-STS-Richtliniendatei, die Web-Key-Directory-Endpunkte, die die Schlüssel unserer Benutzer veröffentlichen, das Das Secure-Link-Ausweichportal-Portal und — auf ausdrücklich dafür markierten Listenern — eine Prometheus-/metrics-Seite, die Die administrative API und die Browser-Die Verwaltungskonsole.

6. pepsi-setup richtet Schema, Schlüssel und DNS ein; pepsi-queue inspiziert und repariert die Warteschlange.

Eine Nachricht ist ein Zustandsautomat über einer einzigen Tabelle: Ihre Spalte stage benennt den Konfigurationsabschnitt des aktuell für sie zuständigen Programms, und ihre Spalte status gibt an, ob dieser Schritt pending, running, paused, failed oder timeout ist. Das vollständige Modell wird in Architektur beschrieben.

1.5. Funktionen

• Authentifizierungserhaltende Weiterleitung. SPF, DKIM und DMARC werden beim Eintreffen verifiziert, und das Urteil wird in eine ARC-Kette versiegelt (RFC 8617).

• Umschlagreparatur. SRS schreibt den Umschlagabsender um, damit SPF beim nächsten Hop besteht, und ausgehende Mail wird unter einer von Pepsi kontrollierten Domain erneut DKIM-signiert.

• Ende-zu-Ende-Verschlüsselung und -Signierung, vom Server erledigt. pepsi-stage-encrypt verschlüsselt ausgehende Mail je Empfänger in OpenPGP (PGP/MIME, RFC 3156) oder S/MIME (CMS, RFC 8551), signiert mit dem Schlüssel des From:-Autors; standardmäßig (ENABLE_PEP) erhält jeder lokale Absender einer bedienten Domain automatisch einen Schlüssel. pepsi-stage-decrypt öffnet und verifiziert eingehendes Chiffrat und hält das Urteil fest. Kein Client-Plugin nötig. Siehe Schlüsselverwaltung.

• Automatische Schlüsselentdeckung und -veröffentlichung. Der Schlüssel eines Korrespondenten wird über WKD, DANE (OPENPGPKEY/SMIMEA), das VKS-Keyserver-Protokoll, LDAP und Ernten aus eingehender Mail gefunden, jeweils danach eingestuft, wie viel die Herkunft wert ist; die Schlüssel unserer eigenen Benutzer werden über WKD, DNS und — nur auf Anfrage — einen Keyserver veröffentlicht.

• Ein Secure-Link-Portal für Korrespondenten ohne Schlüssel. Das Secure-Link-Ausweichportal speichert die Nachricht verschlüsselt unter einer frisch erzeugten PIN und mailt dem Empfänger einen Link, statt zwischen Klartext und einem Bounce zu wählen.

• Mailinglisten. Eine Neuimplementierung von GNU Mailman 3 — Moderation, Digests, Bounce-Verarbeitung, ein Archiv und Mailmans eigene REST-API, sodass Postorius und HyperKitty damit arbeiten — aufgebaut als Pipeline-Stages. Siehe Mailinglisten.

• Eine administrative API und eine Browser-Konsole. Die administrative API legt Warteschlange, Gesundheit, Schlüsselspeicher, Journale und Konfiguration unter /api/v1 offen, und die Die Verwaltungskonsole-Konsole ist ein Client genau dieser dokumentierten Oberfläche — nur auf ausdrücklich für die Administration markierten Listenern bedient.

• Eine Pipeline aus Stages mit je einem Zweck. ARC, SRS, DKIM-Signierung, Alias-Expansion, weiße Listen, Spracherkennung, eine Pay-to-Send-Anti-Spam-Schranke, eine Confirm-to-Send-Challenge, Bounce-Erzeugung, Routing je Empfänger und mehrere Zustell-Backends — jedes ein eigenständiges pepsi-stage-*-Programm, durch Konfiguration zusammengeschaltet.

• Moderne Transportsicherheit. STARTTLS und implizites TLS, MTA-STS, DANE/TLSA (RFC 7672) und ausgehendes TLS-Reporting (RFC 8460).

• Standardvollständiges SMTP. DATA und CHUNKING/BDAT, 8BITMIME und SMTPUTF8 mit Herabstufung je Hop, vollständige DSN-Unterstützung (RFC 3461) und RFC-6409-Nachrichteneinlieferung mit SASL-Authentifizierung.

• Mehrere Zustell-Backends. Direktzustellung an den MX, Weiterleitung über einen authentifizierten Smarthost (viele SASL-Mechanismen, OAuth und beidseitiges TLS) oder lokale Zustellung — in das Maildir eines Benutzers, durch eine ~/.forward je Benutzer oder über LMTP an einen MDA wie Dovecot (der dann das Sieve-Skript des Empfängers ausführt).

• Eine datenbankgestützte Warteschlange. Ein PostgreSQL-Schema ist zugleich Warteschlange, Zustandsautomat und Prüfoberfläche; Operatoren inspizieren und reparieren es mit gewöhnlichem SQL und den mitgelieferten CLI-Werkzeugen.

• In jeder Sprache erweiterbar. Eine Stage ist bloß ein Programm, das Nachrichten-IDs von der Standardeingabe liest; neue Stages müssen nicht in Rust geschrieben sein.

Gefahr

Pepsi ist hochgradig experimentelle, unreife und nicht unterstützte Software. Sein erstes Release, 0.0.0, ist kein stabiles, und es wurde nicht für den Produktivbetrieb auditiert. Es gibt keine Gewährleistung und keinen Support. Setzen Sie Pepsi nicht auf den Pfad von Mail, deren Verlust Sie sich nicht leisten können, und verlassen Sie sich für nichts Wichtiges darauf. Verwenden Sie es zum Lernen, zum Experimentieren und zum Beitragen — nicht zum Betrieb kritischer Infrastruktur.

Was ab 0.0.0 zugesagt ist: Ein späteres Release aktualisiert die Datenbank eines früheren Releases an Ort und Stelle, ohne die Warteschlange oder irgendetwas anderes darin zu verlieren (siehe Upgrade). Konfigurationsoptionen, Kommandozeilenoptionen und die administrative API können sich zwischen Releases noch ändern; jede Änderung ist in NEWS aufgeführt.

1.6. Pepsi im Vergleich zu anderen MTA-Entwürfen

Pepsi ist ein Punkt in einem lange erkundeten Entwurfsraum. Ein Vergleich mit den bekanntesten Mailsystemen freier Software — Postfix, qmail, sendmail, Exim und dem neueren Alles-in-einem-Stalwart — zeigt die Abwägungen, die Pepsi trifft. Jeder Entwurf erkauft manche Eigenschaften auf Kosten anderer.

1.6.1. Punkte im Entwurfsraum

Postfix ist ein Mehrprozess-MTA. Ein master-Daemon beaufsichtigt eine feste Menge spezialisierter, überwiegend langlebiger Daemons — smtpd zum Empfangen, cleanup zum Kanonisieren, qmgr zum Einplanen und Transport-Daemons wie smtp und local zum Zustellen —, die über Warteschlangenverzeichnisse auf der Platte und eine kleine Menge IPC-Protokolle zusammenarbeiten. Es ist ein Allzweck-MTA: lokale Zustellung, virtuelle Domains, komplexes Routing, Inhaltsfilterung und Weiterleitung sind allesamt erstklassig unterstützt.

qmail treibt Modularität und Kompartimentierung auf die Spitze: viele winzige Programme, mehrere davon unter eigenen dedizierten Benutzerkonten, jedes mit einer kleinen Aufgabe, die über das Dateisystem und einfache Pipes kommunizieren. Der Entwurf schätzt Sicherheit durch geringstmögliche Privilegien und Einfachheit sowie eine Maildir-Warteschlange, die Dateisperren-Gefahren vermeidet. Sein Kern ist seit langem im Wesentlichen eingefroren, sodass moderne Funktionen (TLS, SMTP AUTH, DKIM) über Patches und Wrapper Dritter statt über die Basisdistribution kommen.

sendmail ist der ursprüngliche Internet-MTA und der Archetyp des monolithischen, endlos konfigurierbaren Entwurfs: Ein einziger Daemon erledigt die Arbeit, gesteuert von der berüchtigt kryptischen sendmail.cf (normalerweise aus m4-Makros erzeugt). Seine Langlebigkeit ist unerreicht, und es führte das Milter-Plugin-Protokoll ein, das Postfix und andere später übernahmen; seine Konfigurationskomplexität und seine historische Sicherheitsbilanz haben die meisten neuen Installationen jedoch zu anderen Entwürfen gedrängt.

Exim ist ein einzelnes monolithisches Binärprogramm, dessen Verhalten von einer außergewöhnlich ausdrucksstarken Laufzeit-Konfigurationssprache bestimmt wird — Zeichenketten-Expansionen und ACLs, die in jeder SMTP-Phase ausgewertet werden. Routing- und Richtlinienentscheidungen brauchen keine externen Helper-Programme, um den Preis einer Konfiguration, die leicht auf subtile Weise falsch gerät. Es ist der Standard-MTA unter Debian und hat eine große, reife Installationsbasis.

Stalwart ist ein moderner Alles-in-einem-Mailserver, wie Pepsi in Rust geschrieben. Anders als jedes obige System ist er nicht nur ein Transferagent: Er bündelt IMAP4-, JMAP- und POP3-Zugriff, Nachrichtenspeicherung und eingebaute Spamfilterung neben einem vollständigen SMTP-Server mit nativem SPF/DKIM/DMARC/ARC, MTA-STS und DANE. Er verkörpert einen anderen modernen Weg als den von Pepsi — ein integrierter Server, der alles tut statt einer Kette kleiner Programme.

Pepsi behält die Philosophie kleiner Programme, ersetzt aber die Dateisystem-Warteschlange durch eine einzige PostgreSQL-Tabelle, die zugleich Warteschlange, Zustandsautomat je Nachricht und operatives Prüfprotokoll ist. Ein einziger dispatch-Koordinator treibt Pools persistenter Stage-Worker-Programme an und schaltet jede Nachricht von einer Stage zur nächsten weiter, indem er ihren Datensatz aktualisiert. Authentifizierung für das Zeitalter von SPF/DKIM/DMARC gehört zu diesem Kernablauf, statt aufgesetzt zu sein. Am stärksten unterscheidet es sich von den anderen als Ende-zu-Ende-Krypto-Gateway: Es signiert, verschlüsselt, entschlüsselt und verifiziert OpenPGP und S/MIME auf dem Server, verwaltet und entdeckt die dafür nötigen Schlüssel und bietet ein Browser-Portal für Korrespondenten, die überhaupt keinen Schlüssel haben.

1.6.2. Auf einen Blick

Die folgende Tabelle fasst zusammen, wo diese Entwürfe sich unterscheiden. Die Zellen sind knapp — „eingebaut“ gegenüber „über Erweiterungen“ verbirgt sehr viel —, aber sie zeigen die Gestalt jedes Systems: sowohl die Fähigkeiten, die Pepsi nicht hat, als auch die zwei oder drei, die es hat und die anderen nicht.

Bemerkung

Nur die Spalte Pepsi wurde gegen diesen Quellbaum geprüft. Die anderen fünf Spalten fassen die eigene Dokumentation jener Projekte zum Zeitpunkt des Schreibens zusammen; sie dienen der Orientierung, nicht als Audit, und ein Projekt, das seither eine Funktion hinzugefügt hat, wird hier untertrieben dargestellt.

Dimension	Postfix	qmail	sendmail	Exim	Stalwart	Pepsi
Sprache	C	C	C	C	Rust	Rust
Prozessmodell	Daemon-Menge (Master + Helper)	Viele winzige Programme	Monolithischer Daemon	Ein Binärprogramm, je Aufgabe geforkt	Ein einzelner asynchroner Server	Dispatcher + Stage-Programmkette
Hauptrolle	Allzweck-MTA	Allzweck-MTA	Allzweck-MTA	Allzweck-MTA	Alles-in-einem-Server (MTA + IMAP/JMAP + Speicher)	MTA + Krypto-Gateway; Weiterleitung oder lokale Zustellung je Empfänger
Konfiguration	main.cf/master.cf + Maps	Kontrolldateien + Dateisystemkonventionen	m4-erzeugte sendmail.cf (kryptisch)	Eine Laufzeitkonfiguration: ACLs + Zeichenketten-Expansion	TOML + Web-Administration	Eine INI-Datei + Datenbank
Warteschlange / Zustandsspeicher	Spool-Verzeichnisse auf der Platte	Warteschlange im Maildir-Stil	Warteschlange auf der Platte	Spool auf der Platte + Hints-DB	Eingebetteter / SQL-Speicher	PostgreSQL-Tabelle (per SQL abfragbar)
Reife	Jahrzehnte; sehr weit verbreitet	Jahrzehnte; Kern eingefroren, Patch-Ökosystem	Am ältesten (1980er); bewährt, aber rückläufig	Jahrzehnte; Debian-Standard	Jung; reift rasch	Experimentell; erstes Release 0.0.0
Leistung	Hoch, gut abgestimmt	Hoch, leichtgewichtig	Mittel	Hoch	Hoch (asynchrones Rust)	Bescheiden; koordinations-/DB-gebunden
Installationsaufwand	Leicht; überall paketiert	Schwer; Bauen + Patches	Schwer; kryptische Konfiguration	Leichtes Paket, komplexe Konfiguration	Leicht; ein Binärprogramm + Setup	Mittel; braucht PostgreSQL + pepsi-setup
TLS / MTA-STS / DANE	TLS, DANE; MTA-STS über Erweiterung	Über Patches	TLS; STS/DANE über Erweiterungen	TLS, DANE; MTA-STS über Erweiterung	TLS, MTA-STS, DANE eingebaut	TLS, MTA-STS, DANE, TLSRPT eingebaut
Erweiterungs-/Filter-API	Milter + Richtliniendelegation	Pipes / QMAILQUEUE	Milter (Urheber)	Router/Transports + local-scan + Pipes	Sieve + Webhooks	Ein Stage-Programm einfügen (stdin/DB), beliebige Sprache; Milter-Client (nach der Warteschlange)

1.6.3. MTA-Funktionen, die Pepsi nicht hat

Postfix, Exim und sendmail decken Bereiche ab, die Pepsi nicht abdeckt:

• Postfach-Speicherformate. Pepsis eigene lokale Zustellung schreibt nur nach Maildir/new; einen mbox-Schreiber gibt es nicht. Es setzt sehr wohl Postfach-Quotas durch (siehe pepsi-quota), im Maildir++-Format maildirsize, das auch Dovecot, Courier und Exim lesen, optional gestützt auf die kerneleigene quotactl(2)-Buchführung — und eine Ablehnung wegen Quota-Überschreitung durch einen über LMTP erreichten MDA wird weiterhin geroutet statt verhindert, denn dort ist das Postfach vom MDA zu verbuchen.

• Sieve, procmail und der Rest des Benutzerfilter-Ökosystems. Pepsi implementiert selbst keine Sieve-Engine. Es übergibt die Nachricht über LMTP an einen Mail Delivery Agent — pepsi-stage-relay-to-lmtp, typischerweise im Gespräch mit Dovecot —, der beim Ablegen der Mail das Sieve-Skript des Empfängers ausführt. Eine Pepsi-Installation kann also Sieve anbieten; die Filterung gehört dem MDA, nicht Pepsi. Ein Procmail-Äquivalent gibt es nicht, doch ~/.forward-Dateien je Benutzer werden von pepsi-stage-dot-forward unterstützt, einschließlich der klassischen Direktiven |program und /file — jede hinter ihrem eigenen Schalter ALLOW_PIPE / ALLOW_FILE, ausgeführt als der Benutzer durch einen privilegierten Helper, der seine Privilegien zuvor an ihn abgibt. Die eine Benutzerfilter-Aktion, die Pepsi selbst implementiert, ist der Urlaubs-Autoresponder (pepsi-stage-vacation), denn sie muss eine Pipeline-Entscheidung sein: Die Antwort ist eine neue Nachricht, die signiert und weitergeleitet werden muss, und sie darf nicht an eine Mailingliste, einen Bounce oder einen Spammer gehen — was Wissen ist, das die Pipeline hat und ein MDA nicht.

• Beliebiges Routing und Adressumschreibung. Es gibt keine Transport-Maps, keine canonical-, relocated- oder rewrite-Tabellen, keine Relay-Tabellen je Empfänger und keine Backup-MX-/Sekundärwarteschlangen-Rolle für fremde Domains. Routing ist eine Wahl zwischen konfigurierten Stages — pepsi-stage-route wählt je Empfänger eine anhand von dessen Domain, was genügt, um vor einem bestehenden Mailsystem zu stehen — statt einer beliebigen Topologie, und das Umschreiben beschränkt sich auf SRS plus die Alias-Map.

• Eine Filterschnittstelle vor der Warteschlange. Pepsi spricht das Milter-Protokoll — pepsi-stage-milter ist ein Milter-Client, sodass opendkim, rspamd, clamav-milter und der Rest unverändert verwendet werden können —, aber es führt sie nach der Warteschlange aus, nachdem der Ingress die Nachricht bereits angenommen hat. Ein REJECT eines Filters erzeugt daher einen Bounce, wo ein MTA innerhalb der SMTP-Sitzung mit 5xx geantwortet hätte. Es gibt keinen Richtliniendelegations-Socket, und der native Erweiterungspunkt bleibt das Einfügen eines Stage-Programms in die Pipeline.

• Integrierte Inhaltsprüfung. Jenseits der optionalen Pay-to-Send- und Confirm-to-Send-Schranken und der Stages für Sprache und weiße Listen gibt es keine eingebaute Viren- oder Spamprüfung, kein Greylisting, keine DNSBL/RBL-Prüfung und keine Reputationsfilterung — die erreicht man, indem man pepsi-stage-milter auf den entsprechenden Filter-Daemon richtet.

1.6.4. Funktionen, die üblicherweise außerhalb des MTA angesiedelt sind

Mehrere Fähigkeiten gehören nicht zu dem, was ein MTA leisten muss, und die meisten Mailsysteme erreichen sie über etwas anderes: einen Milter, einen Erweiterungs-Daemon, den Mail Delivery Agent oder den Client des Benutzers selbst. Hier unterscheidet sich Pepsi am stärksten von den traditionellen Entwürfen. Der obige Vorbehalt gilt auch für diese Tabelle.

Fähigkeit	Postfix	qmail	sendmail	Exim	Stalwart	Pepsi
SPF/DKIM/DMARC/ARC/SRS	Über Milter / Erweiterungen	Patches Dritter	Über Milter	DKIM eingebaut; Rest über ACLs/Erweiterungen	Eingebaut (alle)	Eingebauter Kern (Verifikation + ARC-Siegel + SRS)
Spam-Schutz	Milter, RBL/DNSBL, Greylisting, Richtlinien	Erweiterungen (qmail-scanner, …)	Milter (SpamAssassin, …)	ACLs, RBL/DNSBL, Greylisting, Inhaltsprüfung	Eingebauter Spamfilter, DNSBL, Greylisting	Pay-to-Send-Schranke, Confirm-to-Send, weiße Liste, Sprachfilter; Milter (nach der Warteschlange) für RBL/AV/Greylisting
Benutzerfilterung (Sieve)	Der MDA (Dovecot)	Der MDA (maildrop, procmail)	Der MDA (procmail)	Eigene Filtersprache oder der MDA	Eingebautes Sieve	Der MDA über LMTP; ~/.forward und eine Urlaubs-Stage laufen in der Pipeline
Postfach-Zugriff (IMAP/POP)	Nein (mit Dovecot kombinieren)	Nein (mit einem POP/IMAP-Server kombinieren)	Nein (mit Dovecot kombinieren)	Nein (mit Dovecot kombinieren)	Ja (IMAP4 + JMAP + POP3)	Nein (mit Dovecot kombinieren; LMTP-Übergabe eingebaut)
Ende-zu-Ende-Mailverschlüsselung	Nein (clientseitig oder ein separates Gateway)	Nein	Nein	Nein	Teilweise (Verschlüsselung im Ruhezustand unter dem eigenen Schlüssel des Benutzers)	Serverseitiges OpenPGP und S/MIME: ausgehend signieren + verschlüsseln, eingehend entschlüsseln + verifizieren; Secure-Link-Portal für einen schlüssellosen Empfänger
Schlüsselverwaltung für Korrespondenten	Nein (nur TLS- und DKIM-Schlüssel)	Nein	Nein	Nein	Schlüssel der eigenen Benutzer, für Verschlüsselung im Ruhezustand	Schlüsselspeicher + Entdeckung (WKD, DANE, VKS, LDAP, Ernte) + Veröffentlichung (WKD, OPENPGPKEY/SMIMEA, Keyserver)
Administrative API / Web-Konsole	Nein (Dateien + postfix/postqueue)	Nein	Nein	Nein (Dateien + exim-Werkzeuge)	Ja (REST-API + Web-Administration)	Ja (/api/v1 + eine Browser-Konsole, nur auf Admin-markierten Listenern)

Mailinglisten sind eine weitere solche Fähigkeit, normalerweise ein separater Listenverwalter (GNU Mailman, ezmlm, Sympa), der über Alias-Tabellen an den MTA angebunden ist. Die von Pepsi ist eine Neuimplementierung von GNU Mailman 3, die als Pipeline-Stages läuft, die Listenadressen innerhalb der eigenen Pipeline routet, ohne dass eine Alias-Datei neu erzeugt werden müsste, und Mailmans REST-API bereitstellt, sodass Postorius und HyperKitty sie unverändert steuern; siehe Mailinglisten.

Die Kombination mit einem MDA ist direkt. pepsi-stage-relay-to-lmtp übergibt Nachrichten über LMTP (RFC 2033), was Dovecots erwarteter Empfangsweg ist und wodurch es das Sieve-Skript jedes Empfängers beim Ablegen der Mail ausführen kann. pepsi-setup erkennt während des Interviews ein lokales Dovecot und bietet an, die von ihm benötigte Socket-Konfiguration zu schreiben, und pepsi-stage-relay-to-maildir schreibt Maildir direkt für einen Standort, dessen Dovecot lieber schlicht den Spool liest.

1.6.5. Warteschlange und Zustand: Dateien gegenüber einer Datenbank

• Eine dateibasierte Warteschlange (Postfix, qmail, sendmail, Exim) hat keine externe Abhängigkeit, ist gut verstanden und skaliert mit dem Dateisystem; jede Nachricht ist eine eigenständige Einheit, was die Fehlerfälle lokal und einfach hält. Über die ganze Warteschlange hinweg zu inspizieren oder zu berichten bedeutet allerdings, Dateien zu durchlaufen, und nachrichtenübergreifende Operationen sind nicht transaktional.

• Eine datenbankgestützte Warteschlange (Pepsi) macht die ganze Warteschlange per SQL abfragbar, gibt transaktionale Zustandsänderungen über mehrere Datensätze (eine Nachricht je Empfänger aufteilen, Bounces auffächern) und macht Operatorwerkzeuge und Metriken unkompliziert. Der Preis ist eine harte Abhängigkeit von PostgreSQL, einer geteilten Komponente, deren Verfügbarkeits- und Skalierungseigenschaften nun das ganze System begrenzen, statt der Isolation je Nachricht, die ein Verzeichnis voller Dateien bietet.

1.6.6. Prozessmodell: Monolith, Daemon-Menge oder Programmkette

• qmail und Pepsi bevorzugen viele kleine Programme: Jedes ist isoliert leicht zu prüfen, Fehler bleiben eingedämmt, und Komponenten können auf verschiedenen Privilegienebenen laufen. Der Preis sind mehr Interprozesskommunikation, mehr einzuplanende Prozesse und die Koordinationslogik, die sie zusammenbindet (qmails Dateisystemkonventionen; Pepsis Dispatcher und geteilte Tabelle).

• Postfix nimmt einen Mittelweg ein: eine feste, sorgfältig entworfene Menge zusammenarbeitender Daemons statt entweder eines einzelnen Monolithen oder einer offenen Kette. Das verbindet gute Leistung mit starker Kompartimentierung, um den Preis eines Entwurfs, der fest ist statt frei neu zusammensetzbar.

• Pepsis Kette ist durch Konfiguration neu zusammensetzbar: Stages können umgeordnet und neue ohne Neuübersetzen eingefügt werden, und eine Stage kann in jeder Sprache geschrieben sein, weil die Integrationsoberfläche bloß die Standardeingabe und die geteilte Tabelle ist. Die Kehrseite ist, dass die Pipeline selbst der Integrationsvertrag ist — das Milter-Protokoll wird als Client gesprochen (nur nach der Warteschlange), statt als native Plugin-Oberfläche angeboten zu werden, und es gibt keine Richtliniendelegations-Schnittstelle.

1.6.7. Umfang und Reife

• Umfang. Postfix, qmail, sendmail und Exim können das gesamte Mailsystem eines Standorts betreiben, und Stalwart geht noch weiter, indem es Postfach-Zugriff bündelt. Pepsi tut auf dieser Achse weniger — die obige Liste sagt, was fehlt — und mehr auf einer, die die anderen kaum haben: Ende-zu-Ende-Kryptographie, die Schlüsselverwaltung, die sie benutzbar macht, und die administrative Oberfläche, um beides zu betreiben. Pepsi vor einem bestehenden Mailsystem zu betreiben ist daher eine übliche Installation, und Microsoft Exchange als Gateway behandelt sie.

• Authentifizierungshaltung. Moderne Weiterleitungs-Authentifizierung — SPF/DKIM/DMARC verifizieren und das Ergebnis über ARC und SRS erneut behaupten — ist in Pepsis Kernablauf eingebaut. Unter Postfix, sendmail oder qmail wird dasselbe Ergebnis aus Miltern, Helpern und Patches zusammengesetzt (Exim und Stalwart bringen mehr davon mit); das ist oft mehr Aufwand beim Verdrahten, greift aber auf reife, weit verbreitete Komponenten zurück.

• Reife. Das ist der entscheidende Unterschied. Postfix, qmail, sendmail und Exim haben jahrzehntelange Produktionshärtung, große Operatorgemeinschaften und umfangreiche Dokumentation, und selbst das viel jüngere Stalwart hat echte Installationen gesehen. Pepsi hat davon nichts (siehe den Haftungsausschluss oben): Es ist ein junger, experimenteller Entwurf, dessen Wert im Erkunden des Ansatzes Datenbank-als-Warteschlange und Programm-Pipeline liegt, nicht in Produktionsreife.

1.7. Wie man dieses Handbuch liest

Das Handbuch gliedert sich in sieben Teile, denen das Inhaltsverzeichnis der Reihe nach folgt:

1. Der Leitfaden — dieses Kapitel, Erste Schritte auf einem günstigen VPS, Installation, Debian-Pakete, Der Assistent, Konfiguration, Pepsi betreiben, Fehlersuche, Unterstützte Funktionen und SMTP-Protokollerweiterungen: was Pepsi ist, wie man es zum Laufen bringt (aus den Quellen oder aus den Debian-Paketen, von Hand oder über das Einrichtungsinterview), wie man es am Laufen hält (Logs, Überwachung, Sicherungen, Upgrades) und der Funktionsumfang auf Protokoll- und Richtlinienebene.

2. Ende-zu-Ende-Kryptographie — Schlüsselverwaltung (Identitäten, Verwahrung, Schlüsselentdeckung und -veröffentlichung), Das Secure-Link-Ausweichportal (das Portal für einen Empfänger ohne Schlüssel), Interoperabilität mit Clients (welche Fremdclients tatsächlich gegen Pepsis Ausgabe gemessen wurden), Sicherheitsmodell (das Bedrohungsmodell, gegen das all dies gebaut ist) und Microsoft Exchange als Gateway (Pepsi als Krypto-Gateway vor einem bestehenden Mailsystem betreiben).

3. Mailinglisten — Mailinglisten (die Neuimplementierung von GNU Mailman 3), Archive (das HyperKitty-kompatible Archiv) und Die REST-API von GNU Mailman 3 (die Mailman-REST-API, die Postorius und HyperKitty verwenden).

4. Administration — die Die administrative API und die Browser-Die Verwaltungskonsole, die ihr erster Client ist.

5. Interna — Architektur (Pipeline, Datenbank und Dispatcher), Der Nachrichten-State (das JSON je Nachricht), Die Pipeline erweitern (wie man ein eigenes Programm hinzufügt) sowie Testsuite, Benchmark-Suite und Leistung.

6. Ein Referenzkapitel für jedes Programm, gefolgt von der Funktionsstabilität-Tabelle und den Handbuchseiten (die Referenz man 1/man 5/man 7, vollständig wiedergegeben).

7. Ein Verzeichnis der von Pepsi implementierten Standards — RFC-Index — mit Verweisen darauf, wo jeder umgesetzt ist.

Wo man anfängt, hängt davon ab, weswegen man gekommen ist:

• Neu bei Pepsi? Folgen Sie Erste Schritte auf einem günstigen VPS für eine vollständige Anleitung von DNS bis zur ersten empfangenen E-Mail, lesen Sie dann Installation und Konfiguration für die Tiefe und überfliegen Sie Unterstützte Funktionen für die Standards, die Pepsi beherrscht.

• Sie betreiben Pepsi? Lesen Sie Pepsi betreiben (Logs, Überwachung, Sicherung und Wiederherstellung), Upgrade und Fehlersuche. Die programmspezifischen Kapitel führen jede Funktion und Option jedes Binärprogramms auf, und die Handbuchseiten der Abschnitte 1/5 liefern die genaue Kommandozeilenreferenz.

• Mail verschlüsseln? Lesen Sie zuerst Schlüsselverwaltung, dann pepsi-stage-encrypt und pepsi-stage-decrypt; Das Secure-Link-Ausweichportal behandelt den Rückfall für schlüssellose Empfänger, und Interoperabilität mit Clients hält fest, welche Fremdclients tatsächlich gegen Pepsis Ausgabe gemessen wurden — und welche nicht.

• Sie erweitern Pepsi? Architektur und Die Pipeline erweitern beschreiben den Stage-Vertrag und wie Sie Ihr eigenes Programm hinzufügen.

• Sie prüfen die Standardkonformität? RFC-Index ordnet jeden Standard — RFCs sowie die Internet-Drafts und De-facto-Spezifikationen, die genauso wichtig sind — der Stelle zu, an der er umgesetzt ist, und hält fest, was bewusst nicht implementiert ist. SMTP-Protokollerweiterungen dokumentiert die beiden privaten Header-Felder, die Pepsi für den Austausch zwischen Installationen definiert: Pepsi-Origin: und Taler:.

1.8. Hilfe und Fehlerberichte

Die Website des Projekts ist https://pepsi.taler.net/, der Quellcode ist unter https://git.taler.net/pepsi.git veröffentlicht.

Bitte melden Sie Fehler und schlagen Sie Verbesserungen im öffentlichen Bugtracker unter https://bugs.gnunet.org/view_all_bug_page.php?project_id=35 vor. Ein hilfreicher Bericht nennt die Version (pepsi-setup --version), den relevanten Teil der Konfiguration (ohne Geheimnisse) und die Ausgaben von pepsi-status und den Dienst-Logs.

Eine Sicherheitslücke gehört nicht in den öffentlichen Tracker: Melden Sie sie vertraulich per E-Mail, wie in Eine Schwachstelle melden beschrieben.