14. Bedrohungsmodell¶

Dieses Kapitel sagt, was Pepsi schützt, vor wem und wie weit — die Zusicherungn. Das nächste Kapitel, Sicherheitsmodell, beschreibt die Mechanismen, die sie tragen (die Kontentrennung, die Datenbankrechte, die setuid-Programme, die Schlüsselverwahrung), und ist dasjenige, das nach einer Kompromittierung zu lesen ist. Jede Zusicherung hier nennt den Mechanismus, auf dem sie beruht, und jedes verbleibende Risiko — etwas, das Pepsi nicht schützt — wird als solches benannt, statt es der Schlussfolgerung zu überlassen.

14.1. Wie dieses Kapitel zu lesen ist ¶

Eine Sicherheitszusage hat drei Teile: ein Schutzgut (was schützenswert ist), einen Angreifer (wer es haben will und was er bereits tun kann) und einen Mechanismus (was zwischen beiden steht). Das Kapitel ist genauso gegliedert:

Schutzgüter listet auf, was Pepsi hält und auf welche Eigenschaft es jeweils ankommt.
Beteiligte und wie weit jedem vertraut wird listet alle auf, die rechtmäßig mit einer Installation interagieren, denn die meisten Angreifer sind einer von ihnen, der sich fehlverhält.
Vertrauensgrenzen zeigt, wo Befugnis den Besitzer wechselt.
Angreifer behandelt jede Klasse der Reihe nach: was sie tun kann, was sie aufhält und was sie trotzdem erreicht.
Ende-zu-Ende-Verschlüsselung: zwei Verwahrungsmodi und Was ein Sicherheitsindikator bedeutet geben die kryptographischen Zusicherungn an, die sich danach unterscheiden, wer den Schlüssel hält.
Adressbezogene Einstellungen sind eine Vertrauensgrenze, Der Netzwerkangreifer und Verfügbarkeit behandeln die drei Bereiche, in denen die Antwort davon abhängt, wie die Installation konfiguriert ist.
Die Garantien auf einen Blick fasst alles in einer Tabelle zusammen.

Zwei Wörter werden streng verwendet. Gilt bedeutet, dass die Zusicherung von einem Mechanismus durchgesetzt wird, den der betreffende Angreifer nicht abschalten kann. Verbleibendes Risiko bedeutet, dass der Angreifer es erreicht, und der Text sagt das mit Absicht.

14.2. Schutzgüter ¶

Schutzgut	Wo es liegt	Die Eigenschaft, auf die es ankommt
Mail unterwegs	`pepsi.workqueue` (`headers`, `state`) und `pepsi.workqueue_body` (der Nachrichtentext, gemeinsam genutzt von den Empfänger-Datensätzen einer Nachricht), im Klartext; bei der Zustellung gelöscht.	Vertraulichkeit und Integrität während der Einreihung; sie muss den Empfänger erreichen, an den sie adressiert war, und niemanden sonst.
Zugestellte Mail	Das `Maildir` des Empfängers, der LMTP-Server oder der nächste MTA. Nach der Zustellung nicht mehr Sache von Pepsi.	Pepsis Teil: an das richtige Postfach als der richtige Benutzer zustellen, nie an das eines anderen — und für einen Benutzer mit einem Client-Schlüssel eine verschlüsselt eingetroffene Nachricht nie lesbar ablegen (`pepsi-stage-reencrypt`).
Gespeicherte Secure-Link-Nachrichten	`pepsi.secure_message.ciphertext`, versiegelt unter einem aus der PIN abgeleiteten Schlüssel.	Vertraulichkeit gegenüber jedem, der die PIN nicht hat.
Private Ende-zu-Ende-Schlüssel	`crypto_identity.private_wrapped`, per AEAD verpackt unter dem Schlüsselverschlüsselungsschlüssel (KEK) in `secrets.d`.	Nie offengelegt; nur von den beiden Krypto-Stages und `pepsi-keys` verwendet.
Domain-Signaturschlüssel und Dienstgeheimnisse	DKIM-Schlüssel im Dateisystem (Gruppe `pepsi`); der SRS-Schlüssel, der `Pepsi-Origin`-Schlüssel, der Secure-Link-Pfeffer, der Listen-Abmeldeschlüssel, Smarthost- und LMTP-Zugangsdaten, OAuth-Tokens — jeweils in einem eigenen `secrets.d`-Fragment.	Vertraulichkeit; jedes nur für das Konto lesbar, das es verwendet.
Absenderidentität und Reputation	Was die obigen Schlüssel ermöglichen: für die Domain signieren (DKIM, ARC), Absender umschreiben (SRS), sich für Mail als unsere verbürgen (`Pepsi-Origin`).	Niemand außerhalb der Pipeline darf Mail versenden, die die Autorität unserer Domain trägt; der Server darf weder zu einem offenen Relay noch zu einer Backscatter-Quelle werden.
Benutzerbezogene Signaturen	OpenPGP-/S/MIME-Signaturen, die `pepsi-stage-encrypt` mit dem serverseitig gehaltenen Schlüssel eines Benutzers erstellt.	Eine Signatur als alice wird nur auf Mail erstellt, die alice eingeliefert hat.
Sicherheitsindikatoren	`X-Pepsi-Crypto`, `Authentication-Results`, die Betreff-Markierungen `[decrypted]` / `[verified]` und die `state`-Schlüssel, nach denen andere Stages entscheiden (`state.signature_verified`, `state.spam`, `state.local_origin`).	Integrität: Ein Leser oder eine spätere Stage darf ihnen glauben.
Konfiguration und Richtlinie	`pepsi.conf` (0644, keine Geheimnisse), `pepsi.config_override`, `pepsi.settings`, die Whitelist.	Integrität: Nur der Operator bestimmt die Richtlinie, und jeder Benutzer nur seinen eigenen Teil davon.
Metadaten der Korrespondenz	Umschläge in der Warteschlange, `mail_log`, `event_log`, die Whitelist, der Cache der Korrespondentenschlüssel, `dns_address`, `tls_session`.	Vertraulichkeit gegenüber Außenstehenden; siehe Was Pepsi nicht schützt dazu, was für wen sichtbar ist.
Privatsphäre gegenüber Dritten	Was den Host aus eigenem Antrieb verlässt: Abfragen der Schlüsselentdeckung (DNS, WKD, VKS, LDAP), TLS-Berichte, Opt-in-Telemetrie.	Das Minimum offenlegen, und nichts, dem der Operator nicht zugestimmt hat.
Geld	GNU-Taler-Wallets, gesteuert von `pepsi-helper-auto-pay`; die Zugangsdaten zum Händler-Backend aus `[pepsi-payments]`.	Ein Wallet wird nur von seinem Eigentümer ausgegeben oder, automatisch, innerhalb des vom Operator festgelegten Budgets, und nur gegen eine Zahlungsforderung für Mail, die wir wirklich gesendet haben.
Zugangsdaten der Verwaltungsoberfläche	`admin_account` (Argon2id), `api_token` (Digests), `admin_session`; Listenkonten in `list_user`.	Aus der Datenbank nicht wiederherstellbar; nicht wiederverwendbar.
Verfügbarkeit	Die Pipeline als Ganzes.	Mail fließt auch bei feindseliger Eingabe weiter; ein Fehler führt zum Aufschub, nicht zu Verlust oder Offenlegung. Siehe Verfügbarkeit.

14.3. Beteiligte und wie weit jedem vertraut wird ¶

Beteiligter	Vertrauen
Der Operator (root, oder wer auch immer `/etc/pepsi` bearbeiten darf)	Voll vertraut, und zwar präzise ausgedrückt: Der Operator konfiguriert die Pipeline, hält jedes Geheimnis und sieht in Gateway-Verwahrung jede durchlaufende Nachricht. Keine Zusicherung in diesem Handbuch gilt gegenüber einem Operator, der den Server verändert. Die Zusicherungn für gespeicherte Daten (verpackte Schlüssel, Secure-Link-Chiffrat, Digests von Zugangsdaten) gelten gegenüber einem passiven Leser gespeicherter Daten — einem gestohlenen Backup, einem reinen Datenbankadministrator —, nie gegenüber jemandem, der das laufende System kontrolliert.
Ein Datenbankadministrator ohne root auf dem Host	Für die Zwecke dieses Modells ein passiver Angreifer: kann jede Tabelle lesen und ändern, kann `secrets.d` und die DKIM-Schlüssel nicht lesen. Was das einbringt, ist genau Ein Angreifer, der die Datenbank hat — dazu, da er schreiben kann, die Kontrolle über die Warteschlange und über jeden `state`-Schlüssel, dem nachgelagerte Stages glauben.
Die Pipeline (das Konto `pepsi` und jede Stage, die es ausführt)	Vertraut, Mail zu verarbeiten, und deshalb Teil dessen, worauf ein Angreifer zielt. Jede Stage kann jede eingereihte Nachricht lesen und umschreiben; siehe Eine kompromittierte Komponente dazu, was eine einzelne kompromittierte Stage wert ist.
Lokale Shell-Benutzer	Feindselig untereinander und gegenüber Pepsi. Ein Benutzer darf Mail als er selbst einliefern (über `sendmail`, authentifiziert durch `SO_PEERCRED`), seinen eigenen Whitelist-Namensraum verwalten, sein eigenes Postfach lesen, und sonst nichts.
Reine Mail-Benutzer (SMTP-Submission, IMAP, keine Shell)	Feindselig untereinander. Ihre Hebel sind die Einlieferung (unter den Identitäten, die `USERNAME_MAP` ihnen erlaubt), die Steueradressen (`pepsi-stage-edit-settings`, der Wallet-Self-Service, die Schlüsselbefehle) und alles, was der Operator sie für ihre eigene Adresse überschreiben lässt.
Vertrauenswürdige Relay-Hosts (`MYNETWORKS`, Client-Zertifikate)	Vertraut, Mail mit lokaler Herkunft einzuliefern. Ein kompromittierter ist ein kompromittierter Einlieferer für jede Adresse, als die er senden darf.
Delegierte Administratoren (API-Tokens und Konsolenkonten mit engem Geltungsbereich, einschließlich `own:<address>`)	Feindselig jenseits ihres Geltungsbereichs: Ein Beteiligter kann nie Zugangsdaten ausstellen, die stärker sind als er selbst (`scope_escalation`), und ein `own:`-Beteiligter erreicht genau eine Adresse. Siehe Die administrative API.
Listenmitglieder, Listenverwalter und Moderatoren	Feindselig jenseits ihrer Listen. Ein getrenntes Kontensystem (`pepsi.list_user`), das auf der Verwaltungsseite nichts gewährt, und umgekehrt.
Entfernte Absender	Feindselig. Alles, was sie senden — Umschlag, Header, MIME-Struktur, Chiffrat, Schlüssel, `Autocrypt`-Header, DSNs, Zahlungsforderungen — ist vom Angreifer kontrollierte Eingabe.
Entfernte empfangende MTAs	Nicht vertrauenswürdig für die Vertraulichkeit, es sei denn, TLS ist authentifiziert (DANE oder eine durchgesetzte MTA-STS-Richtlinie); siehe Der Netzwerkangreifer.
Schlüsselquellen der Korrespondenten (deren DNS, WKD-Host, ein VKS-Server, ein LDAP-Verzeichnis)	Genau so weit vertraut, wie die Vertrauensleiter sie einstuft (Schlüsselverwaltung). Eine Domain kann immer für ihre eigenen Benutzer sprechen.
Externe Helfer, die der Operator einbindet (Milter, der LMTP-Server, der Smarthost, Taler-Wallets und -Exchanges)	Vertraut mit dem, was der Operator ihnen übergibt: Ein Milter sieht die Nachricht im Klartext, ein LMTP-Server legt sie ab, ein Smarthost leitet sie weiter.

14.4. Vertrauensgrenzen ¶

Befugnis wechselt an einer kleinen Zahl von Stellen den Besitzer, und jeder Mechanismus in Sicherheitsmodell sitzt an einer davon:

  remote MTAs,        local users           browser / API client
  senders             (sendmail)            (operator, delegate)
     |                    |                          |
=====|====================|=========== B1: network ==|=================
     v                    v                          v
+--------------+  SO_PEERCRED           +-----------------------+
| pepsi-ingress|<- B2: submission       |      pepsi-httpd      |
|  (auth, SPF, |   identity             |  B6: scopes, CSRF     |
|  DKIM, DMARC)|                        +-----------+-----------+
+------+-------+                                    | setup_task
       | workqueue row                              v  (a request)
=======|===== B3: queue (pepsi.workqueue)   +-----------------------+
       v                                    | pepsi-setup apply     |
+---------------------+   B4: setuid/gid    |  (root; B7: re-checks)|
| stages as `pepsi`   |------------------+  +-----------------------+
| (dispatcher, ARC,   |                  |
|  SRS, dkim-sign ...)|                  v
+----+----------------+     +-----------------------------+
     |                      | helpers: become the user    |
     | B5: key custody      | (maildir, .forward, wallet) |
     v                      +-----------------------------+
+---------------------+
| encrypt / decrypt   |  crypto_identity.private_wrapped
| (setuid pepsi-crypto)|  + KEK in secrets.d
+---------------------+

B1 — das Netzwerk. Alles Eintreffende ist feindselig, bis Ingress es authentifiziert hat, und selbst dann wird nur dem Urteil vertraut, nie dem Inhalt. Ausgehend wird einem Hop nur so weit vertraut, wie sein TLS authentifiziert ist.

B2 — die Einlieferungsidentität. Ingress entscheidet, wer eine Nachricht eingeliefert hat: SASL, ein Client-Zertifikat, MYNETWORKS oder SO_PEERCRED am lokalen Socket. USERNAME_MAP entscheidet dann, welche From:-/Umschlagidentitäten dieser Einlieferer verwenden darf. Nur an dieser Stelle wird die Frage „darf diese Person als diese Adresse senden?“ gestellt.

B3 — die Warteschlange. Alles nach Ingress ist eine Tabelle, die jede Pipeline-Stage lesen und schreiben darf. Die Urteile, die Ingress festgehalten hat (state.auth, state.local_origin), und die, die spätere Stages hinzufügen (state.spam, state.signature_verified), sind innerhalb dieser Grenze nicht authentifizierte Daten: Man glaubt ihnen, weil nur Pipeline-Code sie schreiben kann. Das ist die größte einzelne Vertrauensannahme des Entwurfs, und deshalb behandelt Eine kompromittierte Komponente eine pepsi-Stage als gleichwertig mit der Warteschlange.

B4 — die Helper. Drei Arbeiten erfordern es, ein bestimmter lokaler Benutzer zu sein (ein Maildir schreiben, auf eine ~/.forward reagieren, ein Wallet steuern). Jede ist ein kleiner setuid-root-Helper, nur über eine setgid-Stage erreichbar, der vollständig zum Zielbenutzer wechselt, bevor er irgendetwas berührt, das dem Benutzer gehört.

B5 — Schlüsselverwahrung. Nur pepsi-crypto hält sowohl die verpackten privaten Schlüssel als auch den KEK. Die Krypto-Stages überschreiten diese Grenze bei jeder Nachricht; nichts sonst in der Pipeline tut das.

B6 — die Verwaltungsoberfläche. Jede Anfrage wird authentifiziert (SO_PEERCRED, Bearer-Token oder Passwort + Sitzung) und gegen den einen Geltungsbereich des Endpunkts autorisiert.

B7 — der privilegierte Applier. Die Web-Schicht hat keine root-Befugnis. Sie hält fest, was geschehen soll, in pepsi.setup_task; pepsi-setup apply, das als root läuft und getrennt gestartet wird, validiert jede Aufgabe erneut gegen die Befugnis des Anfragenden und führt sie aus. Das Entfernen des Pakets pepsi-httpd-admin entfernt den Applier, was diese Grenze absolut macht.

14.5. Angreifer ¶

14.5.1. Ein passiver Netzwerkbeobachter ¶

Kann: den Verkehr zwischen Pepsi und anderen MTAs sowie zwischen Clients und Pepsi mitlesen.

Aufgehalten durch: opportunistisches STARTTLS in beide Richtungen, TLS bei der Submission (vorgeschrieben, außer am lokalen UNIX-Socket), HTTPS für das Portal und die Konsole. Ende-zu-Ende-verschlüsselte Nachrichten bleiben auf der Leitung verschlüsselt, was auch immer der Transport ist.

Erreicht trotzdem: die Transport-Metadaten — welche Hosts miteinander sprechen, wann und wie viel — und den Klartext jedes Hops, bei dem die Gegenseite überhaupt kein TLS anbietet.

14.5.2. Ein aktiver Netzwerkangreifer ¶

Kann: Verkehr abfangen, verändern und verwerfen; STARTTLS entfernen; sein eigenes Zertifikat vorlegen; und mit einem lügenden Resolver auf dem Weg DNS fälschen.

Aufgehalten durch: nur das, was die Installation und die Gegenseite konfiguriert haben. Mit den Standardwerten kann ein aktiver Angreifer einen ausgehenden Hop auf Klartext herabstufen oder ihn mit seinem eigenen Zertifikat abfangen, es sei denn, die empfangende Domain veröffentlicht eine MTA-STS-Richtlinie enforce (standardmäßig beachtet) oder DANE-TLSA-Einträge (die der Standardwert DANE = warn nur protokolliert). Siehe Der Netzwerkangreifer für das gehärtete Profil, das dies schließt.

Erreicht trotzdem: einen Denial of Service, immer. Mit DANE strict wird ein Angriff in einen Aufschub statt einer Offenlegung umgewandelt — die beste verfügbare Antwort, keine vollständige.

14.5.3. Ein entfernter Absender ¶

Kann: beliebige Bytes an Port 25 senden: gefälschte From:-Header, fehlerhaftes MIME, feindseliges Chiffrat und feindselige Signaturen, Autocrypt- und Autocrypt-Gossip-Header, gefälschte DSNs, gefälschte Zahlungsforderungen und gefälschte Pepsi-Sicherheits-Header.

Aufgehalten durch:

Parser werden als Angriffsfläche behandelt. Jede Stage parst feindselige Eingaben; der empfindlichste Parser, der CMS-/S/MIME-Code in pepsi-crypto, wird gefuzzt (Testsuite).
Gefälschte Indikatoren werden entfernt. Jeder X-Pepsi-*-Header wird aus eingehender Mail entfernt, bevor die Decrypt-Stage ihre eigenen schreibt, und Betreff-Markierungen [decrypted] / [verified] werden entfernt, bevor unsere hinzugefügt werden.
Geerntete Schlüssel können sich nicht als unsere Benutzer ausgeben. Aus eingehender Mail gelernte Schlüssel landen auf den untersten Sprossen der Vertrauensleiter, und für jede Adresse, für die wir eine Identität halten, hat unser eigener Schlüssel Vorrang vor jedem zwischengespeicherten Schlüssel (lookup_own_first). Ein gefälschtes From: alice@our-domain mit einem Autocrypt:-Header kann daher weder die Verschlüsselung für Alice umlenken noch eine Signatur als ihre verifizieren lassen.
Gossip ist begrenzt. Nur aus Mail, die verschlüsselt eintraf, nur über To:-/Cc:-Adressen, nie über unsere eigenen Benutzer, nie unter Verdrängung eines besseren Schlüssels und nie fähig, ein Signatururteil valid zu erzeugen. Ein gegossipter Schlüssel verlässt die unterste Sprosse nur, wenn sein Eigentümer denselben Schlüssel selbst bekannt gibt, was ihn auf die Sprosse inbound befördert (auditiert als key.peer.promote, nie als Rotation) und immer noch kein valid erzeugen kann.
Eine Schlüsselrotation ist nie still. Das Ersetzen des geernteten Schlüssels eines Korrespondenten durch einen neueren (Autocrypts „der neueste gewinnt“) schreibt in derselben Anweisung eine Audit-Zeile und benachrichtigt per Mail die lokalen Empfänger der Nachricht, die dies ausgelöst hat; unter ACCEPT_ROTATION = expired wird es abgelehnt, solange der gespeicherte Schlüssel gültig ist.
Schleifen werden unterbrochen. Mail mit Null-Absender wird nie gebounct, Auto-Replies folgen der Unterdrückung nach RFC 3834 (pepsi-common::autoreply), .forward-Ketten tragen einen Schleifenschutz, Hop-Zahlen sind begrenzt, und eine Nachricht, die den Ingress dieses Hosts MAX_SELF_HOPS Mal durchlaufen hat, wird abgelehnt.
Kein Backscatter. Eine Adresse an einer bedienten Domain, für die nichts auf dem Host bürgt, wird bei RCPT abgelehnt (VERIFY_RECIPIENTS), und ein Bounce geht nur an einen Umschlagabsender, den die Nachricht authentifiziert hat (BOUNCE_UNAUTHENTICATED), sodass ein gefälschter Absender nicht im Auftrag des Spammers angeschrieben wird.
Zahlungsforderungen werden geprüft. pepsi-stage-auto-pay bezahlt nur für Mail, von der es beweisen kann, dass wir sie gesendet haben (das Pepsi-Origin-HMAC), und nur innerhalb des Budgets je Nachricht und — wenn MAX_TOTAL_PER_DAY gesetzt ist — des Tagesbudgets des zahlenden Wallets. Ein Korrespondent kann jede Forderung trotzdem bis zu dem bepreisen, was diese Budgets übrig lassen; den Verlust zu begrenzen ist Aufgabe des Tageslimits, nicht des Beweises.
Authentifizierung wird standardmäßig festgehalten, nicht durchgesetzt. Eingehendes SPF, DKIM und DMARC sind fail-open: Nur ein eindeutiger DMARC-Fehlschlag unter DMARC_ENFORCE führt zur Ablehnung. Eine gefälschte Nachricht wird daher mit ehrlichem Authentication-Results zugestellt statt abgelehnt.

Erreicht trotzdem: Codeausführung in einer Stage, falls ein Parser-Fehler existiert (siehe Eine kompromittierte Komponente); eine Nachricht mit gefälschtem From: im Postfach des Empfängers, wenn der Operator DMARC nicht durchsetzt; ein von ihm gewählter Schlüssel, mit dem Mail an eine Adresse, für die wir keine Identität halten, verschlüsselt wird, auf den Trust-on-first-use-Stufen, sofern MIN_TRUST sie nicht ausschließt — auch indem er den geernteten Schlüssel eines Korrespondenten unter einem gefälschten From: durch einen neueren ersetzt, was auditiert und den Empfängern angekündigt, aber nicht verhindert wird, außer bei ACCEPT_ROTATION = expired. Er erfährt außerdem aus den RCPT-Antworten, welche Adressen an einer verifizierten Domain existieren — wie bei jedem MTA, der unbekannte Benutzer ablehnt —, mit zehn Rateversuchen pro Verbindung (MAX_INVALID_RECIPIENTS). Wo diese Adresse eine unserer ist — ein bedienter Benutzer, für den wir keine Identität halten und den ein gefälschtes From: erreichen kann, wann immer DMARC auf unserer eigenen Domain nicht durchgesetzt wird —, wird der untergeschobene Schlüssel ebenfalls nicht verhindert, ist aber nicht unsichtbar: pepsi-keys peer unclaimed listet jede bediente Adresse auf, über deren Verschlüsselung ein geernteter oder per Gossip erhaltener Schlüssel entscheidet, als Arbeitsliste für den Operator, sie zu bestätigen und in Identitäten umzuwandeln (Die Benutzer finden, die ihren eigenen Schlüssel mitbringen).

14.5.4. Ein lokaler Shell-Benutzer ¶

Kann: jedes für alle ausführbare Programm ausführen, sich mit für alle zugänglichen Sockets verbinden und für alle lesbare Dateien lesen — einschließlich pepsi.conf, weshalb diese keine Geheimnisse enthält.

Aufgehalten durch:

Einlieferung nur als er selbst. Der lokale Submission-Socket darf Modus 0666 haben, weil Ingress die Identität des Aufrufers aus SO_PEERCRED nimmt und an USERNAME_MAP übergibt; ein Benutzer kann nur unter den Identitäten senden, die seinem Login zugeordnet sind.
Kein privilegiertes Programm ist von einem gewöhnlichen Konto aus erreichbar, außer pepsi-whitelist, das absichtlich für alle ausführbar ist und seinen eigenen Namensraum je Login durchsetzt. Die anderen setuid-/setgid-Programme haben Modus 2550 oder 4750 und sind nur für pepsi oder eine eigene Gruppe ausführbar — und 2550 statt 2755 ist die ganze Verteidigung: Ausführbarkeit für alle gäbe jedem Konto die Gruppe, die den Zugang zu einem setuid-root-Helper öffnet.
Setuid-Programme bereinigen, bevor sie vertrauen. pepsi-whitelist wechselt sofort zum aufrufenden Benutzer, löscht die Umgebungsvariablen, die die Konfiguration und libpq steuern, lehnt -c ab und erhöht die Privilegien nur rund um seine Datenbankverbindung wieder. Das Parsen von Postfächern geschieht in einem separaten Prozess, der die Privilegien nie zurückerlangen kann (setresuid auf allen drei IDs).
Helper werden vollständig zum Benutzer. Die Helper für Maildir, .forward und Wallet setzen jede UID und GID auf den Zielbenutzer und lehnen root ab, sodass die eigenen Dateien eines Benutzers mit dessen Befugnis berührt werden und mit keiner anderen.

Erreicht trotzdem: die Konfigurationstopologie (bediente Domains, den Pipeline-Graphen, Hostnamen) aus der für alle lesbaren pepsi.conf.

14.5.5. Ein reiner Mail-Benutzer ¶

Kann: Mail über einen authentifizierten Kanal einliefern, Steuernachrichten an die Steueradressen senden und die Self-Service-Webseiten nutzen, die seine Installation aktiviert.

Aufgehalten durch: USERNAME_MAP (als welche Adressen er senden und für welche er einen Schlüssel registrieren darf); die Steuer-Stages, die jede Aktion an den authentifizierten Umschlag-Absender einer state.local_origin-Nachricht knüpfen; die Allowlist EDITABLE_STAGES, die begrenzt, was seine Überschreibungen berühren dürfen (siehe Adressbezogene Einstellungen sind eine Vertrauensgrenze); und, für einen Benutzer, der auch ein Unix-Konto ist, die Helper, die nur mit der Befugnis dieses Kontos handeln.

Erreicht trotzdem: Kontrolle über die Behandlung seiner eigenen Mail innerhalb dessen, was der Operator editierbar gemacht hat — einschließlich, bei einer editierbaren Stage, des Rechts, seine eigene Kopie einer Nachricht woandershin zu leiten als an das Standardziel des Operators.

14.5.6. Wer das Mail-Passwort eines Benutzers hat ¶

Kann: alles, was der reine Mail-Benutzer kann, als dieser Benutzer: Mail mit gebundenem From: einliefern, Steuernachrichten senden und meist auch das Postfach per IMAP lesen, da dasselbe Passwort es öffnet.

Der Weg über die Schlüsselregistrierung, und was ihn schließt. Als ein Benutzer einzuliefern ist das, was einen Schlüssel als seinen registriert (ein eingelieferter Autocrypt:-Header oder der Befehl register), daher genügt ein gestohlenes Passwort, um den eigenen Schlüssel des Angreifers zum öffentlichen Gesicht der Adresse zu machen: Künftige Mail von Korrespondenten wird dann an ihn verschlüsselt, und damit erstellte Signaturen verifizieren als die des Benutzers. Die Benachrichtigung „ein neuer Schlüssel wurde registriert“ ist nur eine teilweise Abhilfe — dasselbe Passwort liest das Postfach, in dem sie landet, und kann sie löschen.

Ein Benutzer, der einen zweiten Faktor einrichtet (otp enroll, siehe Schlüsselverwaltung), schließt diesen Weg. Von da an benötigt jede Änderung an seinen Schlüsseln, die ein Benutzer vornehmen kann — ein Befehl zur Schlüsselregistrierung oder -stilllegung per E-Mail, Erzeugen, Registrieren oder Widerrufen in der Web-Konsole unter own:<address>, ein unprivilegiertes pepsi-keys —, einen aktuellen sechsstelligen TOTP-Code aus seiner Authenticator-App, und der Autocrypt:-Header einer gewöhnlichen Nachricht registriert überhaupt nichts. Dasselbe gilt für das Ersetzen oder Entfernen des zweiten Faktors selbst.

Aufgehalten durch (mit zweitem Faktor): den Code (RFC 6238, ein 30-Sekunden-Schritt, ±1 Schritt Abweichung); Wiederholungsschutz (ein Code wird einmal akzeptiert, für einen späteren Schritt als den zuletzt verwendeten); eine Sperre nach zehn aufeinanderfolgenden falschen Codes, die nur der Operator aufhebt (pepsi-keys otp reset, DELETE /api/v1/otp/{address}); und die Verwahrung — das Geheimnis ist unter dem KEK des Schlüsselspeichers verpackt, und die Tabelle otp_key ist allein pepsi-crypto gewährt, sodass weder pepsi-httpd noch eine gewöhnliche Stage ein Geheimnis lesen, einen Zähler zurücksetzen oder eine Einrichtung löschen kann.

Erreicht trotzdem:

Ohne zweiten Faktor alles oben Genannte. Nichts erzwingt einen; es ist die Entscheidung des Benutzers, und bis er sie trifft, ist die Benachrichtigung die einzige Abhilfe.
Die erste Einrichtung. Die Einrichtung erfordert keinen Code (es gibt noch keinen), daher besitzt ein Angreifer, der zuerst dort ist, den zweiten Faktor, und der Benutzer braucht den Operator, um ihn zurückzusetzen. Die Antwort auf die Einrichtung — die das Geheimnis enthält — landet im Postfach, und ein späterer Dieb des Passworts, der sie ungelöscht findet, hat beide Faktoren: Die Antwort fordert dazu auf, sie zu löschen.
Ein Denial of Service auf die Self-Service-Schlüsselverwaltung. Zehn falsche Codes sperren sie, was ein Angreifer immer herbeiführen kann; das Zurücksetzen durch den Operator ist die Abhilfe, und die Sperre beeinträchtigt nie die Mailzustellung oder die Verschlüsselung.
Die Veröffentlichungsschalter der Web-Konsole. Das Hochladen auf einen Schlüsselserver, das Umschalten der WKD-Veröffentlichung und die Wahl des primären MTA-Schlüssels geschehen direkt in pepsi-httpd, das keinen Code prüfen kann, daher ändert ein own:<address>-Beteiligter sie ohne einen. Keiner davon ändert, welchem Schlüssel für die Adresse vertraut wird; dieselben Vorgänge per E-Mail oder pepsi-keys benötigen den Code sehr wohl.
Das Lesen des Postfachs und das Senden von Mail als der Benutzer — das Passwort ist das Passwort.

14.5.7. Ein delegierter Administrator ¶

Kann: alles, was die Geltungsbereiche seines Tokens oder Kontos erlauben — zum Beispiel queue:read ohne queue:write oder own:<address> für eine Adresse.

Aufgehalten durch: den einzelnen deklarierten Geltungsbereich jedes Endpunkts, durchgesetzt aus der Tabelle, aus der das OpenAPI-Dokument erzeugt wird; scope_escalation beim Ausstellen von Zugangsdaten; und, für own:, eine erneute Prüfung der Adresse am Endpunkt und nochmals im Applier für jede privilegierte Aufgabe.

Erreicht trotzdem: die Daten, die sein Geltungsbereich liest. queue:read sieht Umschläge und state (nie Header oder Nachrichtentexte — die Abfragen der Konsole wählen diese Spalten nicht aus), logs:read den Korrespondenzgraphen, keys:read jeden öffentlichen Schlüssel.

14.5.8. Wer eine Kopie der Datenbank hat ¶

Ein Backup, ein Replikat, ein SQL-Injection-Brückenkopf auf einem Lesepfad. Ein Angreifer, der die Datenbank hat listet es vollständig auf. Kurz gesagt: erhält die eingereihte Mail im Klartext und alle Metadaten; erhält nicht irgendeinen privaten Schlüssel (verpackt unter einem KEK außerhalb der Datenbank), irgendeinen Secure-Link-Nachrichtentext (PIN und Pfeffer fehlen beide) oder irgendwelche verwendbaren Zugangsdaten (Argon2id und Digests).

Wer die Datenbank schreiben kann, als Schema-Eigentümer oder als Pipeline-Rolle, kontrolliert zusätzlich die Warteschlange und die state-Schlüssel — und damit alles, was B3 zufolge dort geglaubt wird.

14.5.9. Wer die Konfiguration oder ein Geheimnis hat ¶

pepsi.conf ist Aufklärung. Jedes secrets.d-Fragment ist genau eine Fähigkeit: Der SRS-Schlüssel fälscht SRS-Adressen, der Pepsi-Origin-Schlüssel fälscht „das haben wir gesendet“ (und lenkt so Auto-Pay), der Pfeffer entfernt einen von zwei Faktoren aus dem Secure-Link-Schlüssel, der KEK öffnet die verpackten Schlüssel, sofern der Angreifer auch die Datenbank hat. Schreibender Zugriff auf pepsi.conf ist root vorbehalten, weil sie die Programme benennt, die die Pipeline ausführt. Siehe Ein Angreifer, der die Konfigurationsdatei hat.

14.5.10. Eine kompromittierte Komponente ¶

Der realistische ernste Fall: Ein Parser-Fehler ermöglicht Codeausführung in einem Prozess. Die Reichweite jedes Kontos ist durch seine Betriebssystemidentität und seine Datenbankrechte begrenzt (Die Privilegientrennung).

Kompromittiert	Erreicht	Erreicht nicht
Eine `pepsi`-Stage (die meisten, und der Dispatcher)	Die ganze Warteschlange: Nachrichten lesen, ändern, umleiten, löschen oder einschleusen. Jedes `state`-Urteil. Die Einstellungen, die Whitelist und den Cache der Korrespondentenschlüssel. Die DKIM-Schlüssel, sodass sie als die Domain signieren kann. Und — indem sie das `From:` einer eingereihten Einlieferung umschreibt, bevor `pepsi-stage-encrypt` es sieht — eine benutzerbezogene Signatur jedes lokalen Benutzers, der eine Identität hat.	Irgendeinen privaten Ende-zu-Ende-Schlüssel oder den KEK; die Secure-Link-Chiffratspalte; die Konfigurationsüberlagerung; die Aufgabenwarteschlange von root; die Verwaltungszugangsdaten; ein anderes Unix-Konto.
`pepsi-stage-encrypt` / `-decrypt` (`pepsi-crypto`)	Alles oben Genannte, dazu jeden privaten Ende-zu-Ende-Schlüssel und den KEK: Sie kann alle eingehende Mail an serverseitig gehaltene Schlüssel entschlüsseln und als jede Identität signieren, und sie kann die Schlüssel entwenden.	Schlüssel, deren private Hälfte der Benutzer in seinem eigenen Client behält (`custody = client`).
`pepsi-ingress`	Jede Nachricht beim Eintreffen, vor jeder Stage; den SRS-Schlüssel; den TLS-Schlüssel des Listeners; die Adresse jeder Mailingliste (die Empfängerprüfung). Er entscheidet B2 und kann daher eine Nachricht als beliebiger lokaler Einlieferer zulassen.	Irgendeine bereits eingereihte Nachricht (seine Datenbankrolle darf der Warteschlange etwas hinzufügen und nichts davon lesen); Einstellungen, Whitelists, Schlüssel; irgendeinen privaten Ende-zu-Ende-Schlüssel; Schreibzugriff auf `mailbox_quota`.
`pepsi-httpd`	Die Umschläge und den `state` der Warteschlange sowie die Macht, Nachrichten neu einzureihen, umzuleiten, zu löschen oder einzuschleusen; Schlüssel-Metadaten; die Listen- und Archivtabellen; die Tabellen der Verwaltungszugangsdaten; das Chiffrat des Portals (aber keine PIN). Es kann jede privilegierte Änderung anfordern — einschließlich des Einschaltens der Funktionstelemetrie, das nur dort wirksam wird, wo der Operator `pepsi-telemetry-client` betreibt; es erfährt, ob eine `SYSTEM_ID` existiert, nie ihren Wert.	Die Header oder den Nachrichtentext einer eingereihten Nachricht; die Einstellungen und Whitelists der Benutzer; root, `/etc`, irgendeinen privaten Schlüssel; die Konfigurationsüberlagerung, sofern `CONFIG_DB` nicht konfiguriert ist. Eine Anfrage, die es festhält, wird vom Applier erneut validiert — und ist wirkungslos, wenn `pepsi-httpd-admin` nicht installiert ist.
`pepsi-keydisc`	Den Cache der Korrespondentenschlüssel und die Warteschlange der Entdeckungsanfragen; daher kann es einen Korrespondentenschlüssel auf jedem Rang platzieren.	Die Warteschlange; unsere eigenen Identitäten (die Vorrang vor dem Cache haben).
Ein setuid-Helper (Maildir, `.forward`, Wallet)	Root, wenn er kompromittiert wird, bevor er die Privilegien abgibt. Diese werden klein gehalten und parsen erst, nachdem sie zum Benutzer geworden sind.	—

Wichtig

Signaturen sind nur so stark wie die Pipeline-Rolle. Eine benutzerbezogene Signatur sagt „diese Installation hat diese Nachricht von alice angenommen“, und diese Aussage trifft pepsi-stage-encrypt auf Grundlage eines From:-Headers, den jede pepsi-Stage umschreiben darf, nachdem Ingress ihn geprüft hat. Die Kontentrennung schützt die Schlüssel — eine kompromittierte Stage kann keinen entwenden, daher endet der Schaden, wenn die Stage repariert ist, und kein Schlüsselwechsel ist nötig —, aber nicht deren Verwendung. Domain-DKIM-Signaturen sind in derselben Lage. Dies ist ein bekanntes verbleibendes Risiko, festgehalten in Sicherheitsmodell.

14.6. Ende-zu-Ende-Verschlüsselung: zwei Verwahrungsmodi ¶

„Ende-zu-Ende“ braucht ein Ende. Pepsi unterstützt zwei, je Identität, und jede Zusicherung hängt davon ab, in welchem sich ein Schlüssel befindet.

14.6.1. Gateway-Verwahrung (`custody = local`, der MTA-Schlüssel)¶

Der Server erzeugt den Schlüssel, hält die private Hälfte verpackt und signiert und entschlüsselt im Namen des Benutzers. Der Benutzer liest gewöhnliche Mail in einem beliebigen Client.

Das Ende ist der Server. Der Schutz besteht zwischen Domains und im Ruhezustand:

Beim Transport zwischen Installationen: Mail ist vom sendenden Gateway (oder Client) bis zum empfangenden verschlüsselt. Ein Netzwerkangreifer und jedes Relay dazwischen sieht Chiffrat.
Im Ruhezustand gegenüber einem passiven Leser: Eine Datenbankkopie liefert verpackte Schlüssel, aber nicht den KEK; ein gestohlenes secrets.d liefert den KEK, aber nicht die Schlüssel.
Nicht gegenüber dem Operator, root oder einer kompromittierten ``pepsi-crypto``-Stage: Sie sehen Klartext und verwenden die Schlüssel.
Nicht gegenüber einer kompromittierten Pipeline bei Signaturen — siehe den Kasten oben.
Mail in der Warteschlange ist Klartext, auf beiden Seiten der Krypto-Stages; das ist es, was eine Pipeline ist. Verschlüsseln Sie die Datenbank im Ruhezustand, wenn das von Bedeutung ist.
Im Postfach abgelegte Mail ist Klartext — dem Mailspeicher wird vertraut —, es sei denn, der Empfänger hält zusätzlich einen Client-Schlüssel und pepsi-stage-reencrypt ist in der Pipeline; in diesem Fall wird die abgelegte Kopie erneut an diesen Schlüssel versiegelt (siehe unten). [stage-reencrypt] ON_NO_CLIENT_KEY = bounce (für die ganze Site oder je Empfänger) lehnt Mail ab, statt sie lesbar abzulegen.

Dies ist das Modell einer S/MIME-Gateway-Appliance, und es ist mit Absicht gewählt: Es schützt Benutzer, die nie etwas installieren werden.

14.6.2. Client-Verwahrung (`custody = client`, der MUA-Schlüssel)¶

Der eigene Mail-Client des Benutzers hält den privaten Schlüssel; Pepsi hält nur die öffentliche Hälfte (registriert über pepsi-keys, die Konsole, den Steuerbefehl register oder den eigenen Autocrypt:-Header des Benutzers).

Das Ende ist der Client des Benutzers. Pepsi veröffentlicht den Schlüssel (er wird in WKD zum öffentlichen Gesicht der Adresse), verschlüsselt Mail von anderen lokalen Benutzern an ihn und reicht an ihn verschlüsselte Mail ungeöffnet durch — selbst wenn sich unter den Empfängern auch ein MTA-Schlüssel desselben Benutzers befindet. Was das bringt:

Gegenüber einem Datenbankdieb, einer kompromittierten Stage oder einer kompromittierten Krypto-Stage: An den Client-Schlüssel verschlüsselte Mail kann nicht gelesen werden — kein Serverprozess hat je die private Hälfte gehalten.
Nicht gegenüber einem böswilligen Operator, der immer noch (a) einen anderen Schlüssel in das einsetzen kann, was Pepsi veröffentlicht (WKD, DANE, VKS), und in den Vorrang own, sodass künftige Mail an einen Schlüssel seiner Wahl verschlüsselt wird; (b) Mail lesen kann, die im Klartext eintraf, bevor Pepsi sie an den Benutzer verschlüsselte; und (c) Mail unterdrücken oder verzögern kann. Ein Benutzer, der Schutz vor dem Operator braucht, muss seine Korrespondenten an einen außerhalb des Kanals verifizierten Fingerabdruck verschlüsseln lassen.
Signaturen, die der Benutzer in seinem Client erstellt, gehören allein ihm; Pepsi fügt über Mail, die der Client bereits signiert hat, keine eigene Signatur hinzu.
Nur für Mail, die tatsächlich an diesen Schlüssel verschlüsselt ist — beim Transport. Ein Benutzer kann beide Arten halten: Der MTA-Schlüssel wird nicht stillgelegt, wenn ein MUA-Schlüssel hinzukommt, und er öffnet weiterhin Mail von Korrespondenten, die ihn noch verwenden. Diese Mail befindet sich, solange sie eingereiht ist, in Gateway-Verwahrung, mit den Garantien der Gateway-Verwahrung.
Im Ruhezustand wird Mail, die das Gateway geöffnet hat, erneut an den Client-Schlüssel versiegelt, wenn pepsi-stage-reencrypt vor der lokalen Zustellung läuft: Die Spam-, Sprach- und Whitelist-Stages lesen den Klartext, und abgelegt wird Chiffrat, das nur der Client öffnet. Das schützt die abgelegte Kopie gegenüber jedem, der später den Mailspeicher, die Datenbank oder den Server erlangt; es macht den Durchgang des Klartexts durch die Warteschlange nicht ungeschehen, den eine kompromittierte Stage oder der Operator zu dem Zeitpunkt hätte lesen oder umleiten können. Mail, die im Klartext eintraf, wird so abgelegt, wie sie eintraf — sie zu versiegeln, würde eine Vertraulichkeit behaupten, die sie nie hatte. Es wird keine Signatur hinzugefügt: Die Stage hält keinen privaten Schlüssel, und das Urteil über die Absendersignatur ist dasjenige, das pepsi-stage-decrypt festgehalten hat.

14.6.3. Die Wahl zwischen beiden ¶

Angreifer	Gateway-Verwahrung	Client-Verwahrung
Passiver Netzwerkbeobachter	Geschützt	Geschützt
Dieb der Datenbank oder eines Backups	Geschützt (Schlüssel verpackt)	Geschützt (kein privater Schlüssel)
Kompromittierte gewöhnliche Stage	Liest eingereihten Klartext; kann Signaturen erlangen; kann den Schlüssel nicht entwenden	Liest Mail nur, wenn sie im Klartext eintraf; kann nicht als der Benutzer signieren
Kompromittierte `pepsi-crypto`-Stage	Schlüssel entwendet; alle Mail lesbar	Geschützt für an den Client-Schlüssel verschlüsselte Mail
Böswilliger Operator	Nicht geschützt	Nicht geschützt für künftige Mail (Schlüsseltausch); geschützt für Mail, die bereits an einen verifizierten Fingerabdruck verschlüsselt ist
Dieb des Mailspeichers nach der Zustellung	Nicht geschützt (im Klartext abgelegt)	Geschützt: an den Client-Schlüssel verschlüsselte Mail und — mit `pepsi-stage-reencrypt` — Mail, die das Gateway geöffnet hat

14.6.4. Schlüssel von Korrespondenten ¶

Die Verschlüsselung an einen Korrespondenten ist nur so gut wie die Herkunft des Schlüssels. Die Vertrauensleiter (Schlüsselverwaltung) stuft jede Quelle ein, und [pepsi-keydiscovery] MIN_TRUST legt die Untergrenze fest. Die Standard-Untergrenze ist die unterste Sprosse, daher wird an Trust-on-First-Use-Schlüssel verschlüsselt — was einen passiven Lauscher besiegt und einen Angreifer nicht besiegt, der die Schlüsselquelle des Korrespondenten kontrolliert oder einen geernteten Schlüssel einschleusen kann, bevor der echte gesehen wird. Das ist ein bewusster Kompromiss: Die Alternative zu einem TOFU-Schlüssel ist Klartext, nicht ein besserer Schlüssel. Eine Installation, die Klartext (oder das Secure-Link-Portal) einem nicht authentifizierten Schlüssel vorzieht, hebt die Untergrenze an; siehe Der Netzwerkangreifer.

Derselbe Kompromiss bestimmt, wie ein Schlüssel wechselt. Innerhalb der Trust-on-first-use-Sprossen gewinnt der neueste Schlüssel (die Aktualisierung des Peer-Zustands nach Autocrypt Level 1), und „neuester“ wird anhand einer Nachricht beurteilt, deren From: der Absender geschrieben hat — ein entfernter Absender, der die Adresse eines Korrespondenten fälschen kann, kann daher künftige Mail an diesen Korrespondenten an einen Schlüssel seiner Wahl gehen lassen. Was Pepsi garantiert, ist, dass dies nie still geschieht: Jede solche Ersetzung ist eine Audit-Log-Zeile, geschrieben von der Anweisung, die sie vornimmt, und die lokalen Empfänger der Nachricht, die sie verursacht hat, erhalten per Mail beide Fingerabdrücke (Eine Rotation ist niemals still). Ein Operator, der es vorzieht, echte Rotationen abzulehnen, statt gefälschte anzunehmen, setzt ACCEPT_ROTATION = expired, unter dem ein gültiger gespeicherter Schlüssel nie durch eine Nachricht ersetzt wird; der Korrespondent kann unsere Mail dann nicht lesen, bis ein Operator seinen neuen Schlüssel von Hand annimmt oder der gespeicherte Schlüssel das Ablaufdatum erreicht, das er selbst angibt. Dieses Datum wird beim Lernen aus dem eigenen Material des gespeicherten Schlüssels gelesen (einer OpenPGP-Selbstsignatur, einem X.509-notAfter), und bei einem erneuten Sichten desselben OpenPGP-Schlüssels bewegt es sich immer nur nach hinten — das Wiedereinspielen einer älteren Kopie des Zertifikats, deren frühere Selbstsignatur einen kürzeren, verstrichenen Ablauf hatte, kann einen gültigen Schlüssel daher nicht tot aussehen lassen.

Ein gegossipter Schlüssel, den der Eigentümer später selbst bekannt gibt, wird auf die Sprosse des Eigentümers befördert, statt ersetzt zu werden (Ein gegossipter Schlüssel, den sein Eigentümer bestätigt, wird befördert). Das gewährt einem entfernten Absender nichts, was ein gefälschtes From: nicht bereits gewährte: Ein gefälschter Autocrypt:-Header mit dem eigenen Schlüssel des Angreifers verdrängt eine gegossipte Zeile ohnehin aufgrund des Rangs, daher kann das Wiederholen des gegossipten Schlüssels nur bestätigen, was gespeichert war. Die Beförderung ändert den Rang, mit dem die Zeile sich verteidigt, nie das Urteil, das eine gegen sie geprüfte Signatur erreichen kann.

14.7. Was ein Sicherheitsindikator bedeutet ¶

Ein Leser, eine Filterregel und spätere Stages handeln alle nach dem, was Pepsi über eine Nachricht sagt. Die Bedeutung jedes Indikators ist exakt:

[decrypted], state.encrypted: Die Nachricht traf verschlüsselt an einen Schlüssel ein, den diese Installation hielt, und wurde hier geöffnet. Sie sagt nichts darüber aus, wer sie gesendet hat.
[verified], state.signature_verified, Urteil valid: Eine Signatur, die den Klartext abdeckt, wurde verifiziert, und der Schlüssel ist verankert: unsere eigene Identität, ein manuell festgelegter Schlüssel, ein per DNSSEC validierter DANE-Schlüssel, ein WKD-Schlüssel oder eine S/MIME-Kette zu einem vom Operator installierten Vertrauensanker — eine Kette, die zudem innerhalb jeder nameConstraints-Grenze und jeder Zertifikatsrichtlinien-Anforderung bleibt, die die CAs auf ihr setzen, die des Ankers eingeschlossen, sodass das Verankern einer Partner-CA für den Namensraum des Partners bürgt und für nichts weiter. Nichts Schwächeres — ein geernteter, gegossipter, angehängter oder VKS-Schlüssel, eine DANE-Antwort ohne das AD-Bit, eine CA, die niemand gewählt hat — kann es erzeugen; diese ergeben valid-untrusted. Eine Signatur, die nur Chiffrat abdeckt, erzeugt es ebenfalls nie, denn jeder, der ein Chiffrat hat, kann seine eigene Signatur darum legen.
Authentication-Results: Was Ingress über SPF, DKIM, DMARC und ARC gefolgert hat, wie festgehalten; es ist kein Filter. Eingehende Authentifizierung ist fail-open.
X-Pepsi-Crypto: Die Zusammenfassung der Decrypt-Stage. Glaubwürdig nur, weil jeder eingehende X-Pepsi-*-Header zuerst entfernt wird; ein Client darf ihm bei Mail, die nicht durch eine Pepsi-Decrypt-Stage gelaufen ist, nicht glauben.

Jeder dieser Indikatoren wird von Pipeline-Code in die Warteschlange geschrieben (Grenze B3). Gegenüber einem entfernten Absender bedeuten sie, was sie sagen; gegenüber einer kompromittierten pepsi-Stage, die jeden von ihnen schreiben kann, bedeuten sie nichts.

14.8. Adressbezogene Einstellungen sind eine Vertrauensgrenze ¶

Die Konfiguration ist geschichtet (Konfiguration): die INI-Datei, dann die Datenbanküberlagerung des Operators (global, domain:, address:), dann pepsi.settings — die eine Schicht, die ein Kontoinhaber schreiben kann, per E-Mail über pepsi-stage-edit-settings. Die Schichten darunter gehören dem Operator; diese gehört dem Benutzer und wird als nicht vertrauenswürdige Eingabe behandelt:

Nur Stages, die der Operator in EDITABLE_STAGES aufführt, können geändert werden. Eine Bearbeitung jedes anderen Abschnitts wird abgelehnt, und nichts wird gespeichert.
Nur die eigene Kopie des Benutzers ist betroffen. Eine Überschreibung ist an den Umschlagabsender lokal eingelieferter Mail und an den Umschlagempfänger aller anderen Mail geknüpft, und eine Nachricht, deren Empfänger-Überschreibungen voneinander abweichen, wird zuerst aufgeteilt, sodass die Einstellungen eines Benutzers nie auf die Kopie eines anderen Benutzers wirken.
Identitätsoptionen sind gesperrt (SIGNING_DOMAIN): Als welche Domain eine Nachricht signiert wird, entscheidet der Operator.
Programme können nicht ersetzt werden. Welches Programm eine Stage ausführt, ihr Standard-Nachfolger NEXT_STAGE und BOUNCE_STAGE werden aus der Datei des Operators genommen; eine Überschreibung davon hat keine Wirkung (und PROGRAM ist durch die Edit-Stage zusätzlich auf einen pepsi-stage-*-Befehl beschränkt).
Jede Bearbeitung wird validiert, vom eigenen Parser der zuständigen Stage, gegen die effektive Konfiguration, die sie ergeben würde, bevor sie gespeichert wird.
Geheimnisse werden nie zurückgegeben. Die Antwort zitiert die effektiven Optionen, wobei jeder Wert, der Zugangsdaten enthält, maskiert ist, mit demselben Prädikat wie die API.

Was eine editierbare Stage dem Benutzer tatsächlich in die Hand gibt, ist jede Option, die diese Stage aus ihrem eigenen Abschnitt liest — einschließlich ihrer Verzweigungsziele (TRUE_STAGE, QUARANTINE_STAGE, RESPONSE_STAGE, SECURE_LINK_STAGE und dergleichen). Ein Benutzer kann seine eigene Mail also über einen anderen Zweig leiten als den Standard des Operators. Das ist die beabsichtigte Macht; die Folge ist eine Regel für den Operator:

Warnung

Führen Sie in EDITABLE_STAGES nie eine Stage auf, deren Wirkung verpflichtend sein soll. Insbesondere:

pepsi-stage-encrypt — ENCRYPT, SIGN und SECURE_LINK_STAGE entscheiden, ob eine Nachricht im Klartext hinausgeht. Führen Sie sie nur auf, wenn Benutzer das für ihre eigene Mail wählen dürfen.
pepsi-stage-dkim-sign, pepsi-stage-arc, pepsi-stage-srs — diese schützen die Reputation der Domain, nicht die des Benutzers.
pepsi-stage-decrypt auf einem gemeinsamen Pfad — ihre QUARANTINE_STAGE und ON_BAD_SIGNATURE leiten eingehende Mail.
Die Anti-Spam- und Whitelist-Stages, wenn die Richtlinie der Site ist, dass Filterung nicht optional ist.
Jede Zustell- oder Relay-Stage — ihre Zugangsdaten sind maskiert, ihre Ziele aber nicht.

UNRESTRICTED_UNSAFE_STAGES = yes hebt die Beschränkungen für PROGRAM und Identitäten vollständig auf; es macht jede editierbare Stage zu einer, die der Benutzer vollständig kontrolliert.

14.9. Der Netzwerkangreifer ¶

Die Standardwerte besiegen einen passiven Lauscher, keinen aktiven. Jeder Hop verwendet TLS, wenn die Gegenseite es anbietet, und jeder Schlüssel, den die Leiter findet, wird zur Verschlüsselung verwendet, aber ein Angreifer auf dem Weg kann STARTTLS entfernen, ein Zertifikat austauschen oder (mit dem Resolver) einen Schlüssel austauschen, überall dort, wo die Gegenseite keine Richtlinie veröffentlicht hat, die das verbietet. Das ist die Haltung jedes opportunistischen MTA, und sie ist es, die Mail an die Mehrheit der Domains fließen lässt, die nichts veröffentlichen.

Ein gehärtetes Profil macht eine Installation widerstandsfähig gegen einen aktiven Angreifer, überall dort, wo die Gegenseite etwas veröffentlicht hat, gegen das geprüft werden kann:

Einstellung	Was sie schließt
Ein validierender Resolver auf einem vertrauenswürdigen Pfad (`unbound` auf Loopback oder `systemd-resolved` mit `DNSSEC=yes`)	Jede DNSSEC-basierte Prüfung unten hängt davon ab, dass das AD-Bit ehrlich ist; ohne einen findet DANE nichts, und nichts wird mit Warnung herabgestuft.
`DANE = strict` für `pepsi-stage-relay-to-internet` (und für jeden Smarthost-Eintrag)	Eine Gegenseite mit DNSSEC-signierten `TLSA`-Einträgen kann nicht mehr abgefangen werden: Eine Abweichung führt zum Aufschub statt zur Zustellung.
`MTA_STS` aktiviert gelassen (der Standardwert)	Eine Gegenseite mit einer `enforce`-Richtlinie kann nicht mehr herabgestuft werden.
`[pepsi-keydiscovery] MIN_TRUST = owner-confirmed` (oder `wkd`)	Verschlüsselung nur an Schlüssel, deren Veröffentlichung jemand nachgewiesen hat, der das Postfach oder die Domain kontrolliert; unterhalb der Untergrenze geht die Nachricht im Klartext oder an das Secure-Link-Portal, wie `ENCRYPT` entscheidet.
`DMARC_ENFORCE` bei Ingress	Mail, die das `From:` einer DMARC-geschützten Domain fälscht — einschließlich Ihrer eigenen —, wird abgelehnt, statt mit einem fehlgeschlagenen Ergebnis zugestellt zu werden.
Veröffentlichen Sie Ihre eigenen `TLSA`-, MTA-STS-`enforce`- und TLSRPT-Einträge (`pepsi-setup` gibt sie aus)	Derselbe Schutz für Mail, die an Sie gesendet wird, durch Absender, die prüfen.

Selbst gehärtet kann ein aktiver Angreifer immer einen Denial of Service verursachen; das Profil wandelt Abfangen in Aufschub um.

14.10. Verfügbarkeit ¶

Das Verfügbarkeitsziel von Pepsi ist enger als sein Vertraulichkeitsziel und als Regel formuliert: Bei feindseliger Eingabe wird eine Nachricht aufgeschoben statt verloren, und ein Fehler schließt, statt offenzulegen. Eine Stage, die nicht entscheiden kann, parkt die eine Nachricht oder lässt sie fehlschlagen; sie hält ihre Nachbarn nicht an, und sie sendet nie im Klartext, weil eine Prüfung nicht vorgenommen werden konnte. Volumetrisches Fluten des Netzwerks oder des Hosts liegt außerhalb des Rahmens — das gehört vor den MTA.

Innerhalb dieses Rahmens ist jede Ressource, die ein Angreifer Pepsi aufwenden lassen kann, wie folgt begrenzt. Offen kennzeichnet eine Lücke: Sie ist in docs/ROADMAP.md mit der gewählten Lösung festgehalten, und bis sie geschlossen ist, ist die Komponente nur so robust wie die Grenzen um sie herum.

14.10.1. SMTP-Ingress ¶

Ressource	Grenze	Status
Verbindungen	`MAX_CONNECTIONS` (1024), unterhalb des Limits für Dateideskriptoren gedeckelt; am Deckel wird die am längsten untätige Verbindung des geschäftigsten Adressbereichs verdrängt. Neue Verbindungen werden je /32 ratenbegrenzt (`CONN_RATE_PER_SECOND`, `CONN_RATE_BURST`), und ein Adressbereich darf höchstens `MAX_CONNECTIONS_PER_IP` (16) gleichzeitig halten. Der lokale Submission-Socket, der von der Ratenbegrenzung und der Verdrängung ausgenommen ist, hat eine eigene Obergrenze (`MAX_LOCAL_CONNECTIONS`, 32), sodass lokale Benutzer entferntes SMTP nicht aushungern können.	Begrenzt
Nachrichten	`MAX_MESSAGES_PER_SESSION` (100) Transaktionen je Sitzung, dann `421` und eine neue Verbindung in die Ratenbegrenzung hinein. Lokale Einlieferung wird je `SO_PEERCRED`-UID über Sitzungen hinweg bemessen (`LOCAL_MESSAGES_PER_MINUTE`, 60, Burst `LOCAL_MESSAGE_BURST`, 120), mit Aufschub per `451`.	Begrenzt
Empfängerprüfungen	`MAX_INVALID_RECIPIENTS` (10) unbekannte Empfänger je Sitzung, dann `421`. Proben beim MDA oder Backend werden zwischengespeichert (eine Stunde für „ja“, fünf Minuten für „nein“) und auf 16 gleichzeitig laufende begrenzt; jenseits der Grenze wird die Adresse angenommen, statt hinter dem Backend eingereiht zu werden.	Begrenzt
Nachrichtengröße und -form	`MAX_MESSAGE_SIZE` (25 MiB) bei `MAIL SIZE=`, während `DATA` und `BDAT`; 1000 Empfänger; 4 KiB Befehlszeilen, 1 MiB Datenzeilen.	Begrenzt
Zeit	`COMMAND_TIMEOUT` (300 s, begrenzt auch den TLS-Handshake), `DATA_TIMEOUT` (180 s), beide je Lesevorgang.	Begrenzt
Passwort-Raten	Drei fehlgeschlagene `AUTH`-Versuche schließen die Sitzung mit `421`, sodass jede weitere Serie von Rateversuchen eine neue, ratenbegrenzte Verbindung kostet; über Sitzungen hinweg darf ein Adressbereich `AUTH_FAILURES_PER_HOUR` (20) Mal pro Stunde scheitern, danach wird `AUTH` abgelehnt, ohne dass das Passwort geprüft wird. Ungültige SRS-Empfänger sind auf drei je Sitzung gedeckelt.	Begrenzt
Authentifizierungsaufwand	Das Limit von zehn Abfragen bei SPF, höchstens 50 ARC-Sätze, `DNS_TIMEOUT` je Abfrage; höchstens `MAX_DKIM_SIGNATURES` (10) verifizierte Signaturen, die mit `From:` ausrichtbaren zuerst; SPF und DKIM nebenläufig unter `VERIFY_TIMEOUT` (20 s), dann DMARC unter einem weiteren. Eine Prüfung, deren Zeit abläuft, ist `temperror` allein für diese Prüfung, was DMARC ignoriert, sofern sie nicht ausgerichtet ist — die Frist kann daher nicht benutzt werden, um `DMARC_ENFORCE` zu umgehen.	Begrenzt

14.10.2. Die Warteschlange und die Pipeline ¶

Ressource	Grenze	Status
Warteschlangentiefe und Festplatte	`[pepsi] MAX_QUEUE_ROWS` (1 000 000 Datensätze), `MAX_QUEUE_BYTES` (standardmäßig aus) und `MIN_FREE_SPACE` (1 GiB auf `FREE_SPACE_PATH`): `pepsi-ingress` antwortet mit `452 4.3.1` bei `RCPT`, `DATA` und nach dem Ende der Daten, solange eine davon erreicht ist, und `pepsi-stage-list-post` hält eine Verteilung zurück, statt ihren nächsten Stapel auszugeben. Gemessen höchstens alle `QUEUE_CHECK_INTERVAL` (10 s), daher sind die Obergrenzen um die Aufnahmen eines Intervalls weich; eine fehlgeschlagene Messung lässt zu. Mail, die die Pipeline selbst erzeugt (Bounces, DSNs, Benachrichtigungen), wird nie abgelehnt, und eine Warteschlange, die bereits über einer Grenze liegt, leert sich normal.	Begrenzt
Speicherverstärkung	Der Nachrichtentext einer Nachricht wird einmal in `pepsi.workqueue_body` gespeichert und von jedem davon abgeteilten Datensatz gemeinsam genutzt, sodass ein Beitrag an N Empfänger einen Nachrichtentext und N kleine Datensätze kostet, nicht N Nachrichtentexte. Eine Stage, die einen Nachrichtentext umschreibt, kopiert ihn für diesen einen Datensatz (Copy-on-Write).	Begrenzt
Fairness	`pepsi-dispatch` teilt die Worker-Zeit jeder Stage unter den Absendern auf (ein authentifiziertes Konto, sonst die verbindende Adresse, IPv6 je /64), den am längsten nicht bedienten zuerst, sodass sich der Burst eines Absenders hinter ihm selbst einreiht statt vor allen anderen. `[pepsi-dispatch] FAIR_FIFO_PERCENT` (10) der Plätze jeder Stage gehen weiterhin an ihre ältesten Datensätze, was begrenzt, wie lange eine Nachricht warten kann. Ein Absender, der sich von vielen Adressen aus verbinden kann, zählt als viele Absender.	Begrenzt
Ein hängender oder abstürzender Worker	`[pepsi-dispatch] MAX_RUNTIME` (300 s) beendet den Worker, und ein Absturz beendet ihn ebenfalls; in beiden Fällen erhält die Nachricht einen Strike und wird eine Minute (dann zwei) später erneut versucht, und der dritte Strike setzt sie auf `timeout` oder `failed`, beide endgültig. Eine giftige Nachricht wird daher dreimal versucht, nicht in einer Schleife; `pepsi-failure-bouncer` erzeugt nie erneut einen Bounce für einen Datensatz, der sich bereits an der Bounce-Stage befindet.	Begrenzt
Wiederholungen	`MAX_LIFETIME` (120 h) an jeder Stage, für ihre eigenen Wiederholungen und für jeden Fehler, den sie nicht als permanent markiert; `PAYMENT_DEADLINE` an der Anti-Spam-Schranke.	Begrenzt
Parsen	MIME-Tiefe 16–32 und Anzahl der Teile; dekomprimierter OpenPGP-Klartext beim Streamen auf 64 MiB gedeckelt; drei Klartext-Signaturschichten über dem Chiffrat; X.509-Ketten von acht, mit höchstens 64 Richtlinien oder Richtlinienzuordnungen je Zertifikat im Richtlinienbaum und 2²⁰ Vergleichen von Namen gegen Teilbäume je Zertifikat bei der Prüfung der Namensbeschränkungen; geerntetes und gegossiptes Schlüsselmaterial in Anzahl und Größe gedeckelt; ein OpenPGP-Zertifikat von irgendjemand anderem mit einem RSA-Schlüssel über 8192 Bit abgelehnt (S/MIME endet bei 4096); die Spracherkennung liest höchstens 20 000 Zeichen.	Begrenzt

14.10.3. Schleifen und Verstärkung ¶

Mail-Schleifen enden bei MAX_HOP_COUNT (30) an den Relay-Stages, am Kettenschutz für .forward, bei Alias-Tiefe 32 und bei fünf Listen-Hops. Für einen Bounce wird nie ein Bounce erzeugt.
Automatische Antworten — Abwesenheitsnotizen, Sekretariats-Challenges und die Zahlungsaufforderung der Anti-Spam-Stage — befolgen alle die Unterdrückungsregeln aus RFC 3834 in pepsi-common::autoreply, sodass keine davon auf eine Liste, einen Massenversand, einen anderen Responder oder einen Zustellbericht antwortet. Abwesenheitsnotizen sind außerdem auf eine je Korrespondent je SUPPRESS_DAYS begrenzt, Sekretariats-Challenges auf fünf je Absender und Tag und Zahlungsaufforderungen auf eine je Absender und geschütztem Postfach je BLOCK_RESPONSE_SUPPRESS (standardmäßig eine Stunde), entschieden und festgehalten in einer Anweisung, sodass parallele Worker nicht beide senden können.
Mailinglisten vervielfachen einen Beitrag um ihre Mitgliederzahl, daher werden die Beiträge eines Absenders an eine Liste, die SENDER_POSTS_PER_HOUR (30) in einer Stunde überschreiten, für den Moderator zurückgehalten statt verteilt, und eine Liste hält höchstens MAX_HELD_MESSAGES (1000) Beiträge zur Moderation zurück — darüber hinaus wird ein Beitrag, der zurückgehalten würde, verworfen, der neue statt des ältesten, sodass eine Flut nicht hinausspülen kann, was ein Moderator noch nicht gesehen hat. Listen-Hops sind wie oben gedeckelt.
Mail, die die Webformulare senden (Listenanmeldung, Passwort-Zurücksetzung), ist je Zieladresse auf zwei pro Stunde begrenzt, und je Client, sodass die Formulare nicht benutzt werden können, um das Postfach eines Dritten zu fluten.
Die Schlüsselentdeckung beantwortet jede Adresse einmal, wie viele Nachrichten auch fragen (Anfragen werden dedupliziert), merkt sich Fehlschläge (NEGATIVE_TTL, ERROR_TTL), deckelt eine Antwort auf 256 KiB und eine Weiterleitung auf denselben Host und setzt der gesamten Antwort eine Frist — ein Server, der Bytes tröpfeln lässt, kann eine Entdeckungsmethode, die ihrerseits jede andere Abfrage bedient, nicht blockieren. Eine Nachricht wartet höchstens TIMEOUT auf einen Schlüssel, bevor sie ohne einen fortfährt.

14.10.4. Die Web-Schicht ¶

Ressource	Grenze	Status
Verbindungen und langsame Clients	`MAX_CONNECTIONS` (256), höchstens `MAX_CONNECTIONS_PER_IP` (32) von einer Client-Adresse (eine IPv4-Adresse oder ein IPv6-/64; Verbindungen über den UNIX-Socket eines Reverse Proxy zu begrenzen ist Sache des Proxy); jeweils 30 s für die Header, den TLS-Handshake und den Anfragerumpf.	Begrenzt
Argon2id (PINs und Passwörter)	Eine Ableitung je CPU gleichzeitig, außerhalb des Executors; eine Anfrage, die nicht binnen Sekunden einen Platz bekommt, wird mit `429` abgewiesen statt eingereiht. Die Secure-Link-PIN ist zusätzlich auf `MAX_ATTEMPTS` je Nachricht mit sich verdoppelndem `LOCKOUT` begrenzt; Anmeldungen je Konto und je Quelle.	Begrenzt
Anfragerümpfe	8 KiB für Formulare, 1 MiB für die Verwaltungs-API, 8 MiB für die Listen-API.	Begrenzt
Gespeicherte Daten	Secure-Link-Nachrichten verfallen (`EXPIRY_DAYS`). Von `pepsi.target` benannte Timer, unabhängig vom Webserver, bereinigen die Logs (90 Tage `event_log`, 30 `mail_log`; `pepsi-log-prune.timer`), die TLS-Berichtszähler (`RETAIN_DAYS`; `pepsi-tlsrpt-prune.timer`) und abgelaufene Zeilen des MX-Adress-Caches (stündlich, `pepsi-origin-gc.timer`).	Begrenzt

14.10.5. Geld und Postfächer ¶

Auto-Pay gibt höchstens MAX_TOTAL je von uns gesendeter Nachricht aus und, wenn MAX_TOTAL_PER_DAY gesetzt ist, höchstens so viel je Wallet in beliebigen 24 Stunden, beides atomar in einer Anweisung gebucht (je Wallet serialisiert), sodass nebenläufige Forderungen — für eine Nachricht oder für viele — keines von beiden überziehen können, und eine Zahlung, die nicht abgewickelt werden kann, wird beiden wieder gutgeschrieben. Ohne das Tageslimit kann jemand, der viele unserer Nachrichten erhalten hat, für jede MAX_TOTAL fordern, daher sollte es überall gesetzt sein, wo Auto-Pay es ist. Es gilt bewusst nicht je Korrespondent: Mailinglisten und Aliase machen die fordernde Partei unerkennbar, während das Wallet immer bekannt ist. Unter WALLET_SCOPE = unified gehört das eine Wallet allen, sodass ein Korrespondent den Tag für alle Absender aufbrauchen kann — eine Verweigerung automatischer Zahlung (die Forderungen erzeugen dann wie üblich einen Bounce), kein Verlust über das Limit hinaus.
Postfachkontingente lehnen nur auf Grundlage einer Messung ab, nie einer Schätzung, und die drei Regeln, die verhindern, dass ein volles Postfach geschlossen bleibt, nachdem sein Eigentümer es geleert hat (ein Höchstalter für die Messung, nach der Ingress handelt, ein erneutes Messen vor dem Ablehnen und der Timer pepsi-quota reconcile), stehen in pepsi-quota.

14.11. Was Pepsi nicht schützt ¶

Irgendetwas gegenüber root oder einem böswilligen Operator. Siehe Beteiligte und wie weit jedem vertraut wird.
Verkehrsanalyse. Wer mit wem korrespondiert, wann und wie viel, ist für jeden sichtbar, der das Netzwerk, die Warteschlange oder die Logs sehen kann. Ende-zu-Ende-Verschlüsselung verschlüsselt keine Umschläge, und der Header-Schutz deckt nur ab, was der Container zulässt.
Klartext in der Warteschlange. Jede Stage muss die Nachricht lesen, die sie verarbeitet.
Signaturen gegenüber einer kompromittierten Pipeline, wie oben.
Die eigene Kompromittierung von Korrespondenten. Ein Schlüssel, den eine kompromittierte Domain veröffentlicht, ist ein kompromittierter Schlüssel, auf welchem Rang auch immer die Leiter diese Domain einstuft.
Postfächer der Empfänger nach der Zustellung, bis auf eine Sache: Für einen Benutzer mit einem Client-Schlüssel wird Mail, die das Gateway entschlüsselt hat, erneut an ihn versiegelt abgelegt (Client-Verwahrung (custody = client, der MUA-Schlüssel)).
Privatsphäre der Abfragen gegenüber der Domain des Korrespondenten. Das Entdecken eines Schlüssels teilt dem DNS und dem WKD-Host dieser Domain mit, dass jemand hier im Begriff ist, an die Adresse zu schreiben; ein VKS-Server erfährt dasselbe. ALLOW_DOMAINS / DENY_DOMAINS und DISCOVERY = no begrenzen das (Schlüsselverwaltung). TLS-Berichte und Opt-in-Telemetrie legen nur aggregierte Zähler offen; Telemetrie ist aus, bis der Operator sie einschaltet — an einem Terminal oder in der Konsole, die sie erst anbieten kann, sobald der Operator pepsi-telemetry-client gestartet und [pepsi] von Hand eine SYSTEM_ID gegeben hat.

14.12. Die Garantien auf einen Blick ¶

„Ja“ bedeutet, dass der Angreifer dieses Schutzgut kompromittieren kann; „Nein“ bedeutet, dass ein Mechanismus es verhindert; „Teilweise“ wird in dem Abschnitt erläutert, der in der ersten Spalte genannt ist.

Angreifer	Eingereihte Mail	Private E2E-Schlüssel	Signieren als Benutzer / als die Domain	Einstellungen und Mail anderer Benutzer	Geld	Zugangsdaten	Abgelegte Mail (Benutzer mit MUA-Schlüssel)
Passives Netzwerk	Nein	Nein	Nein	Nein	Nein	Nein	Nein
Aktives Netzwerk (Standardwerte)	Teilweise (Herabstufung)	Nein	Nein	Nein	Nein	Nein	Nein
Entfernter Absender	Nein	Nein	Nein	Nein	Teilweise (Budget)	Nein	Nein
Lokaler Shell-Benutzer	Nein	Nein	Nein	Nein	Nein	Nein	Nein
Reiner Mail-Benutzer	Nein	Nein	Nein	Nein	Nur eigenes Wallet	Nein	Nein
Gestohlenes Mail-Passwort	Nein	Nein	Teilweise (kein zweiter Faktor)	Nein	Nur eigenes Wallet	Nein	Teilweise (kein zweiter Faktor)
Delegierter Administrator	Teilweise (Geltungsbereich)	Nein	Nein	Teilweise (Geltungsbereich)	Nein	Nein	Nein
Datenbankkopie	Ja	Nein	Nein	Nur Lesen	Nein	Nein	Nein
Ein Geheimnis-Fragment	Nein	Nein (KEK allein)	Teilweise (je Geheimnis)	Nein	Teilweise (Origin-Schlüssel)	Nein	Nein
Kompromittierte `pepsi`-Stage	Ja	Nein	Ja	Ja	Teilweise (Budget)	Nein	Teilweise (künftige Mail)
Kompromittierte Krypto-Stage	Ja	Ja (Gateway-Verwahrung)	Ja	Ja	Teilweise (Budget)	Nein	Teilweise (künftige Mail)
Kompromittiertes `pepsi-httpd`	Teilweise (Umschläge, Leitweg; kein Inhalt)	Nein	Nein	Teilweise (Leitweg; keine Einstellungen)	Nein	Seine eigenen Tabellen	Nein
Operator / root	Ja	Ja (Gateway-Verwahrung)	Ja	Ja	Ja	Ja	Teilweise (künftige Mail)

„Teilweise (kein zweiter Faktor)“ bei einem gestohlenen Mail-Passwort: Ohne zweiten Faktor kann der Dieb seinen eigenen Schlüssel als den des Benutzers registrieren, was Signaturen als die des Benutzers verifizieren lässt und künftige Mail — abgelegte Mail eingeschlossen — an einen Schlüssel versiegeln lässt, den er hält; ist einer eingerichtet, benötigt jede Schlüsseländerung einen Code (Wer das Mail-Passwort eines Benutzers hat).

Abgelegte Mail ist eine Nachricht, die das Gateway entschlüsselt und vor der Zustellung erneut an den eigenen Client-Schlüssel des Empfängers versiegelt hat (pepsi-stage-reencrypt, siehe Client-Verwahrung (custody = client, der MUA-Schlüssel)). „Teilweise (künftige Mail)“: Ein Angreifer, der die Pipeline, eine Krypto-Stage oder den Host kontrolliert, kann Mail lesen — oder ihr erneutes Versiegeln stoppen —, die durchläuft, solange er die Kontrolle hat, und kann nie eine bereits abgelegte Kopie öffnen, da kein Serverprozess den Client-Schlüssel hält. Für einen Benutzer ohne MUA-Schlüssel trifft die Spalte nicht zu: Seine Mail wird im Klartext abgelegt oder unter ON_NO_CLIENT_KEY = bounce abgelehnt.

Die Matrix deckt ab, was hier gehalten wird. Der Schlüssel, mit dem künftige Mail an einen Korrespondenten verschlüsselt wird, ist durch Schlüssel von Korrespondenten abgedeckt: Ein entfernter Absender, der das From: dieses Korrespondenten fälschen kann, kann einen Trust-on-First-Use-Schlüssel ersetzen (Teilweise — immer auditiert und den Empfängern angekündigt; abgelehnt, solange der gespeicherte Schlüssel gültig ist — nicht widerrufen und nicht über das Ablaufdatum hinaus, das er selbst angibt — unter ACCEPT_ROTATION = expired), und kann nie einen festgelegten, veröffentlichten oder vom Operator eingetragenen ersetzen.

14.13. Siehe auch ¶

Sicherheitsmodell — die Mechanismen hinter jedem „Nein“ oben. Schlüsselverwaltung — Verwahrung, die Vertrauensleiter, Entdeckung. Das Secure-Link-Ausweichportal — der Rückfall ohne Schlüssel und sein PIN-Modell. Die administrative API — Geltungsbereiche und der Applier. Konfiguration — die Schichtung, auf der die Einstellungsgrenze aufsitzt.