86. RFC-Index¶

Pepsi will ein standardkonformer MTA und ein standardkonformes Ende-zu-Ende-Krypto-Gateway sein. Dieses Kapitel bildet jeden RFC, den Pepsi implementiert (oder bewusst noch nicht), darauf ab, wo im System er umgesetzt ist, sodass ein Prüfer von einem Standard zu seinem Code und seiner Konfiguration springen kann.

Die Übersichtstabelle führt jeden anwendbaren RFC auf einen Blick auf; die Notizen pro RFC unten liefern die Details. RFCs, die geplant, aber noch nicht implementiert sind, sind unter Anwendbare, noch nicht implementierte RFCs gesammelt.

Nicht alles hier Verzeichnete ist ein RFC. Das OpenPGP Web Key Directory ist ein Internet-Draft; Autocrypt und das VKS-Keyserver-Protokoll sind De-facto-Standards; NTLM ist eine Microsoft Open Specification; XOAUTH2 hat überhaupt kein Spezifikationsgremium; SRS und Maildir sind veröffentlichte Verfahren, die nie durch die IETF gingen; FIPS 186-4 ist eine NIST-Publikation. Jedes davon ist das, was in echten Installationen tatsächlich gesprochen wird. Sie sind nach den RFCs aufgeführt, kursiv, mit benanntem Status.

Einen Standard zu implementieren ist nicht dasselbe wie mit den Clients zu interoperieren, die behaupten, ihn zu implementieren. Interoperabilität mit Clients hält fest, welche davon gegen echte Software gemessen wurden, welche einmalige Beobachtungen sind und welche überhaupt nie ausgeführt wurden.

„Implementiert in“ benennt das Modul oder Programm, in dem der Standard umgesetzt ist, nicht jeden Aufrufer. Wo ein Standard nur teilweise implementiert ist — BINARYMIME aus RFC 3030 —, sagt die Zelle das. Standards, die Pepsi bewusst nicht implementiert, stehen unter Anwendbare, noch nicht implementierte RFCs mit der Begründung.

86.1. Übersichtstabelle¶

RFC	Titel (Thema)	Implementiert in
RFC 1035	Domainnamen — Implementierung und Spezifikation (DNS)	Alle DNS-Abfragen; Domain-/Label-Syntax in `pepsi-common::domain`
RFC 1870	SMTP-Dienst-Erweiterung für die Deklaration der Nachrichtengröße (`SIZE`)	Von pepsi-ingress angekündigt und durchgesetzt; der ausgehende Client beachtet die angekündigte Grenze des nächsten Hops, `pepsi-common::smtp::client`
RFC 1918	Adressvergabe für private Internets	Zusammen mit RFC 6598 und RFC 2544 die Adressbereiche, die ein ausgehender Abruf ablehnt, damit eine Schlüsselentdeckungs-URL nicht in die Installation hineinreichen kann (die SSRF-Absicherung von `pepsi-keydisc`)
RFC 1951	`DEFLATE`-Format komprimierter Daten	Die Schranke beim Dekomprimieren von OpenPGP-Schlüsselmaterial — eine Kompressionsbombe wird abgelehnt statt entfaltet (`pepsi-crypto::pgp`, angewendet auf abgeholte und geerntete Schlüssel)
RFC 1153	Format für Sammelnachrichten	Die einfache (nicht-MIME) Form der Sammelnachricht, `pepsi-list::digest::build`
RFC 2033	Local Mail Transfer Protocol (LMTP)	Lokale Zustellung an einen MDA (Dovecot), pepsi-stage-relay-to-lmtp
RFC 2034	SMTP-Dienst-Erweiterung für die Rückgabe erweiterter Fehlercodes	`ENHANCEDSTATUSCODES`, von pepsi-ingress angekündigt; jede Antwort trägt einen RFC-3463-Code
RFC 2045	MIME Teil eins: Format von Nachrichtentexten (Transferkodierungen)	8-Bit→7-Bit-Herabstufung des Nachrichtentexts, `pepsi-common::mime`
RFC 2046	MIME Teil zwei: Medientypen (`multipart` und Grenzsyntax)	MIME-Baum-Parsen und Grenzenprüfung, `pepsi-common::mime` und `pepsi-crypto::mime`
RFC 2047	MIME Teil drei: Nachrichten-Header-Erweiterungen (Encoded-Words)	UTF-8-Header-Herabstufung, `pepsi-common::mime`
RFC 2104	HMAC: schlüsselbasiertes Hashing zur Nachrichtenauthentifizierung	Der SRS-Umschlagabsender-MAC (`pepsi-common::srs`), der `Pepsi-Origin`-Herkunftsnachweis-Header und die Ableitung des Schlüsselverschlüsselungsschlüssels (KEK) in `pepsi-common::keystore::wrap` (eine HKDF-Extract-förmige Konstruktion mit festem Etikett)
RFC 2195	IMAP/POP-`AUTHorize`-Erweiterung für einfaches Challenge/Response (`CRAM-MD5`)	Ausgehendes SMTP-`AUTH` zu einem Smarthost, `pepsi-common::smtp::sasl`
RFC 2231	MIME-Parameterwert- und Encoded-Word-Erweiterungen	Gelesen (Fortsetzungen, erweiterte Werte und Zeichensätze, §3–§4.1) von `pepsi_common::mime::param`, das die Dateinamensfilterung verwendet; erzeugt vom UTF-8-Header-Downgrade in `pepsi-common::mime`, der einen Nicht-ASCII-Parameter von `Content-Type`/`Content-Disposition` in einem beliebigen MIME-Teil als `name=UTF-8''…` umschreibt (bei einem langen mit `0`/`1*`-Fortsetzungen), wenn der Hop kein `SMTPUTF8` anbietet. Die Encoded-Word-Erweiterung aus §5 (Sprach-Tags) wird nicht erzeugt
RFC 2392	Content-ID- und Message-ID-Uniform-Resource-Locators	Die `cid:`-Referenz vom HTML der Zahlungsanforderungs-Autoantwort auf ihr eingebettetes QR-Code-Bild, `pepsi-stage-anti-spam`
RFC 2831	Digest-Authentifizierung als SASL-Mechanismus (`DIGEST-MD5`)	Ausgehendes SMTP-`AUTH` (veraltet; siehe RFC 6331), `pepsi-common::smtp::sasl`
RFC 2920	SMTP-Dienst-Erweiterung für Befehls-Pipelining	`PIPELINING`, von pepsi-ingress angekündigt; der ausgehende Client schreibt den Umschlag und `DATA` in einem Zug
RFC 2986	PKCS #10: Syntax der Zertifizierungsanforderung	Zertifikatsanforderungen für extern ausgestellte S/MIME-Zertifikate, `pepsi-crypto::keygen`
RFC 3030	SMTP-Dienst-Erweiterungen für große und binäre Nachrichten (`CHUNKING`/`BDAT`)	pepsi-ingress (`BINARYMIME` wird nicht angekündigt)
RFC 3156	MIME-Sicherheit mit OpenPGP (PGP/MIME)	`multipart/encrypted`- und `multipart/signed`-Container, von `pepsi-crypto::mime` gebaut und geparst; `micalg` aus `pepsi-crypto::pgp`
RFC 3207	SMTP-Dienst-Erweiterung für sicheres SMTP über TLS (`STARTTLS`)	pepsi-ingress-Listener; ausgehender SMTP-Client
RFC 3339	Datum und Uhrzeit im Internet: Zeitstempel	Zeitstempel der Berichtserzeugung, `pepsi-common::tlsrpt`
RFC 3370	Algorithmen der Cryptographic Message Syntax (CMS)	S/MIME-Digest- und Signaturalgorithmus-Bezeichner, `pepsi-crypto::smime`
RFC 3394	Schlüsselverpackungsalgorithmus des Advanced Encryption Standard (AES)	Das Verpacken des Inhaltsverschlüsselungsschlüssels in einem ECDH-`KeyAgreeRecipientInfo`, `pepsi-crypto::smime`
RFC 2369	Die Verwendung von URLs als Metasyntax für zentrale Mailinglistenbefehle	Die Header `List-Help`/`List-Subscribe`/`List-Unsubscribe`/`List-Post`/ `List-Owner`/`List-Archive`, der `rfc-2369`-Handler von `pepsi-stage-list-post`
RFC 3461	SMTP-Dienst-Erweiterung für Zustellungsstatusbenachrichtigungen (`DSN`)	`pepsi-common::dsn`; Ingress, Relay-Stages, Bounce-Stage
RFC 3463	Erweiterte Mailsystem-Statuscodes	DSN-Statuscodes, `pepsi-stage-bounce`
RFC 3464	Ein erweiterbares Nachrichtenformat für Zustellungsstatusbenachrichtigungen	Erzeugung von `multipart/report`, `pepsi-stage-bounce`; und das Lesen eines solchen, das einzige normierte Format unter den siebzehn Bounce-Erkennern von `pepsi-stage-list-bounce`
RFC 3492	Punycode	IDNA-Label-Kodierung für internationalisierte Domains, `pepsi-common::domain` und `pepsi-common::dns`
RFC 3565	Verwendung der AES-Verschlüsselung in CMS	AES-256-CBC-`EnvelopedData`, der Herabstufungscontainer, wenn ein Empfänger AEAD nicht lesen kann (`pepsi-crypto::smime`)
RFC 3676	Der Medientyp text/plain format=flowed	Extraktion des Nachrichtentexts und der `--`-Signaturschnitt, `pepsi-common::mime_text`
RFC 3834	Empfehlungen für automatische Antworten auf E-Mail	Das gemeinsame Regelwerk „darauf darf nicht automatisch geantwortet werden“, `pepsi-common::autoreply`; `Auto-Submitted` auf den automatischen Antworten, die Pepsi erzeugt, darunter die von pepsi-stage-vacation, `pepsi-stage-secretary`, `pepsi-stage-anti-spam` und `pepsi-stage-edit-settings`
RFC 3848	ESMTP- und LMTP-Übertragungstypen (`with`-Klausel)	`Received:`-Header (`SMTP`/`ESMTP`/`ESMTPS`/`ESMTPA`/ `ESMTPSA`), Ingress
RFC 3864	Registrierungsverfahren für Nachrichten-Header-Felder	Das Verfahren, unter dem Pepsis zwei private Header-Felder (SMTP-Protokollerweiterungen) nicht registriert sind; beide sind absichtlich unregistriert
RFC 4013	SASLprep: stringprep-Profil für Benutzernamen und Passwörter	SCRAM-Benutzername-/Passwort-Aufbereitung, `pepsi-common::smtp::sasl`
RFC 4055	Zusätzliche Algorithmen und Bezeichner für RSA in PKIX	RSAES-OAEP- und RSASSA-PSS-Parameterkodierung, `pepsi-crypto::smime`
RFC 4121	Der Kerberos-5-GSS-API-Mechanismus, v2	Ausgehendes Smarthost-`AUTH = gssapi` (über System-Kerberos), `pepsi-common::smtp::gssapi`
RFC 4155	Der Medientyp application/mbox	Lesen von `mbox`-Postfächern für den Import einer weißen Liste, `pepsi-helper-mailbox-scan`; Archiv-Import und -Export, `pepsi-archive`
RFC 4422	Simple Authentication and Security Layer (SASL) — `EXTERNAL`-Mechanismus	Ausgehendes SMTP-`AUTH EXTERNAL` über TLS-Client-Zertifikat (Smarthost)
RFC 4511	LDAP: das Protokoll	LDAP-Schlüsselentdeckung, das `ldap`-Modul von `pepsi-keydisc` (hinter dem Cargo-Feature `ldap`, standardmäßig aus)
RFC 4514	LDAP: Zeichenkettendarstellung von Distinguished Names	Darstellung von Zertifikats-Subject-/Issuer-DNs, `pepsi-crypto::smime`
RFC 4515	LDAP: Zeichenkettendarstellung von Suchfiltern	Filter-Escaping für die LDAP-Entdeckungsabfrage — die Injektionsabsicherung, `pepsi-keydisc`
RFC 4616	Der `PLAIN`-SASL-Mechanismus	Eingehendes (Ingress) und ausgehendes (Smarthost) `AUTH PLAIN`
RFC 4648	Die Base16-, Base32- und Base64-Datenkodierungen	SRS-Hash-Kodierung (`pepsi-common::srs`); Schlüsselmaterial
RFC 4752	Der Kerberos-V5-(`GSSAPI`-)SASL-Mechanismus	Ausgehendes Smarthost-`AUTH = gssapi`, `pepsi-common::smtp::gssapi`
RFC 4954	SMTP-Dienst-Erweiterung für Authentifizierung (`AUTH`)	Eingehendes `AUTH PLAIN`/`LOGIN` (Ingress, nur TLS) und die vollständige ausgehende Smarthost-SASL-Suite
RFC 5083	Der CMS-Inhaltstyp `AuthEnvelopedData`	Der Standard-S/MIME-Verschlüsselungscontainer (AES-256-GCM), `pepsi-crypto::smime`
RFC 5084	Verwendung von AES-CCM und AES-GCM in CMS	AES-256-GCM-`AuthEnvelopedData`, der Standard-S/MIME-Container, `pepsi-crypto::smime`
RFC 5064	Das Nachrichtenheaderfeld Archived-At	Die Archiv-URL je Nachricht, die eine Listennachricht trägt, von `pepsi-stage-list-post` aus dem Hash in `pepsi-list::hash` hinzugefügt; ausgeliefert von pepsi-httpd
RFC 5228	Sieve: eine E-Mail-Filtersprache	Vom MDA (Dovecot) bei der LMTP-Zustellung ausgeführt; Pepsi implementiert selbst kein Sieve
RFC 5280	Profil für Internet-X.509-PKI-Zertifikate und CRLs	Zertifikatsparsen, Erweiterungsbehandlung und Pfadvalidierung — einschließlich Namens- und Richtlinienbeschränkungen, gegen NIST PKITS auf Konformität getestet — `pepsi-crypto::trust`; Ausstellung in `pepsi-crypto::keygen`
RFC 5321	Simple Mail Transfer Protocol	Kern von Ingress und beiden Relay-Stages; Umschlagbehandlung, MX, Null-Absender
RFC 5322	Internet Message Format	Header-/Nachrichtentext-Modell (`pepsi-common::message`); Parsen und Signieren
RFC 5480	Subject Public Key Information für Elliptische-Kurven-Kryptographie	EC-Kodierung öffentlicher Schlüssel in Zertifikaten, `pepsi-crypto::smime`
RFC 5652	Cryptographic Message Syntax (CMS)	`SignedData`/`EnvelopedData`/`certs-only`, von `pepsi-crypto::smime` gebaut und geöffnet (das `cms`-Crate liefert nur die Typen)
RFC 5753	Verwendung von ECC-Algorithmen in CMS	ECDH-Schlüsselvereinbarungs-`RecipientInfo` (P-256/P-384 + X9.63-KDF + AES-KW), `pepsi-crypto::smime`
RFC 5758	Zusätzliche Algorithmen und Bezeichner für DSA und ECDSA in PKIX	Signaturbezeichner `ecdsa-with-SHA256`/`-SHA384`, `pepsi-crypto::smime`
RFC 5802	Salted Challenge Response Authentication Mechanism (`SCRAM`)	Ausgehendes `SCRAM-SHA-1`/`-SHA-256` (±``-PLUS``), `pepsi-common::smtp::sasl`
RFC 5890	Internationalisierte Domainnamen für Anwendungen (IDNA2008): Definitionen	Domainbehandlung durchgängig, über das `idna`-Crate; siehe auch RFC 3492
RFC 5915	Struktur privater Elliptische-Kurven-Schlüssel	EC-Kodierung privater Schlüssel, `pepsi-crypto::keygen`
RFC 5929	Channel-Bindings für TLS (`tls-server-end-point`)	SCRAM-`-PLUS`-Channel-Binding, `pepsi-common::smtp::sasl`
RFC 5937	Verwendung von Vertrauensanker-Beschränkungen bei der Verarbeitung von Zertifizierungspfaden	Die `nameConstraints`, Richtlinienerweiterungen und `pathLenConstraint` eines Ankers binden jede Kette durch ihn, `pepsi-crypto::trust`
RFC 5958	Asymmetrische Schlüsselpakete (PKCS #8)	Kodierung privater Schlüssel im Ruhezustand, `pepsi-crypto::keygen` und `pepsi-common::keys`
RFC 6125	Dienst-Identität in TLS (Zertifikatsnamenprüfung)	MTA-STS-Zertifikatsvalidierung, `pepsi-stage-relay-to-internet`
RFC 6152	SMTP-Dienst-Erweiterung für 8-Bit-MIME-Transport (`8BITMIME`)	Von Ingress angekündigt; erneutes Ankündigen/Herabstufen pro Hop in den Relay-Stages
RFC 6265	HTTP-Zustandsverwaltungsmechanismus (Cookies)	Das administrative Sitzungs-Cookie und das Cookie des Secure-Link-Portals, beide mit `__Host-`-Präfix; `pepsi-httpd`
RFC 6331	Überführung von `DIGEST-MD5` in den Status „Historic“	Der Grund, warum `DIGEST-MD5` veraltet ist und von `AUTH = auto` ausgeschlossen wird
RFC 6376	DomainKeys-Identified-Mail-(DKIM-)Signaturen	Verifikation (Ingress) und Signieren (`pepsi-stage-dkim-sign`)
RFC 6409	Nachrichteneinlieferung für Mail	Submission-Listener (`SUBMISSION = yes`): verpflichtendes `AUTH`, `Date:`/`Message-ID:`-Korrekturen, `Sender:`-Korrektur und Durchsetzung der Submission-Identität
RFC 6531	SMTP-Erweiterung für internationalisierte E-Mail (`SMTPUTF8`)	Von Ingress angekündigt; erneutes Ankündigen/Herabstufen pro Hop in den Relay-Stages
RFC 6598	Von der IANA reservierter IPv4-Präfix für gemeinsam genutzten Adressraum	Teil der Adressabsicherung für ausgehende Abrufe; siehe RFC 1918
RFC 6648	Abschaffung des `X-`-Präfixes in Anwendungsprotokollen	Warum `Pepsi-Origin:` und `Taler:` kein `X-`-Präfix tragen, während die Urteils-Header, die pepsi-stage-decrypt entfernt, es bewusst tun (`X-Pepsi-*` ist ein zu entfernender Namensraum, kein zu übernehmendes Feld)
RFC 6698	DNS-basierte Authentifizierung benannter Entitäten (DANE): TLSA	`TLSA`-Eintragstypen und -Abgleich, `pepsi-common::smtp::dane`; das SMTP-Profil ist RFC 7672
RFC 6749	Das OAuth-2.0-Autorisierungsframework	Erwerb und Erneuerung von Smarthost-Token, `pepsi-helper-token-refresh`
RFC 6750	Das OAuth-2.0-Autorisierungsframework: Verwendung von Bearer-Token	Die `Authorization: Bearer`-Form der Token der administrativen API, Die administrative API — nur die Drahtform; Pepsi prägt sie lokal und betreibt keinen Autorisierungsserver
RFC 6761	Domainnamen mit Sonderverwendung	`.invalid`: Eine darauf endende Identität ist die unbearbeitete Beispielkonfiguration und wird von `pepsi-setup` abgelehnt; `localhost`: von `pepsi-httpd` als Loopback akzeptiert
RFC 6840	Klarstellungen und Implementierungshinweise für DNSSEC	Das aus der Antwort des validierenden Resolvers gelesene `AD`-Bit — Pepsi vertraut einem validierenden Resolver, statt selbst zu validieren; `pepsi-common::dns`
RFC 6891	Erweiterungsmechanismen für DNS (EDNS(0))	UDP-Nutzlastgröße bei ausgehenden Abfragen, `pepsi-common::dns`
RFC 6979	Deterministische Verwendung von DSA und ECDSA	Nonce-Erzeugung für ECDSA-Signaturen, `pepsi-crypto::smime`
RFC 7208	Sender Policy Framework (SPF) zur Autorisierung der Domain-Nutzung	Eingehende SPF-Verifikation (Ingress, über `mail_auth`)
RFC 7235	HTTP/1.1: Authentifizierung	Das `Authorization: Bearer`-Schema auf `/api/v1`, `pepsi-httpd`
RFC 7489	Domain-based Message Authentication, Reporting, and Conformance (DMARC)	Eingehende DMARC-Auswertung und optionale Durchsetzung (Ingress)
RFC 7505	Ein „Null-MX“-Kein-Dienst-Resource-Record	MX-Klassifizierung, `pepsi-stage-relay-to-internet`
RFC 7595	Richtlinien und Registrierungsverfahren für URI-Schemata	Das Verfahren, unter dem das `taler://`-Schema nicht registriert ist; angemerkt, damit sein Status nicht für IANA-registriert gehalten wird
RFC 7628	Ein Satz von SASL-Mechanismen für OAuth (`OAUTHBEARER`)	Ausgehendes Smarthost-`AUTH = oauth` (`OAUTHBEARER`, de facto `XOAUTH2`)
RFC 7672	SMTP-Sicherheit über opportunistisches DANE-TLS (`TLSA`)	`DANE = off\|warn\|strict` auf beiden Relay-Stages; `pepsi-common::smtp::dane`
RFC 7677	`SCRAM-SHA-256`- und `SCRAM-SHA-256-PLUS`-SASL-Mechanismen	Ausgehendes `SCRAM-SHA-256` (±``-PLUS``), `pepsi-common::smtp::sasl`
RFC 7748	Elliptische Kurven für die Sicherheit (X25519)	Curve25519-Schlüsselvereinbarung in OpenPGP und TLS
RFC 7929	DNS-basierte Authentifizierung benannter Entitäten (DANE): Bindungen für OpenPGP	`OPENPGPKEY`-Einträge, von `pepsi-keys dns` ausgegeben; AD-gebundene Abfragen durch `pepsi-keydisc@dane` (pepsi-keydisc)
RFC 8017	PKCS #1 v2.2: RSA-Kryptographie-Spezifikation	RSA-Signatur- und Schlüsseltransport-Primitiven (über das `rsa`-Crate) für DKIM, ARC und S/MIME
RFC 8018	PKCS #5: passwortbasierte Kryptographie (PBKDF2)	`SCRAM-SHA-*`-Ableitung des gesalzenen Passworts, `pepsi-common::smtp::sasl`
RFC 8162	Verwendung von sicherem DNS, um Zertifikate für S/MIME mit Domainnamen zu verknüpfen	`SMIMEA`-Einträge, von `pepsi-keys dns` ausgegeben; AD-gebundene Abfragen durch `pepsi-keydisc@dane` (pepsi-keydisc)
RFC 8187	Angabe von Zeichenkodierung und Sprache für Parameter von HTTP-Header-Feldern (ersetzt RFC 5987)	Der Parameter `filename*` der `Content-Disposition` beim Herunterladen eines Secure-Link-Anhangs, `pepsi-httpd`
RFC 8314	Klartext gilt als überholt: Verwendung von TLS für Submission und Zugriff	Implicit-TLS-Submission-Listener (`MODE = tls`), Ingress; ausgehandelte TLS-Version/-Chiffre im `Received:`-Trace-Header festgehalten (§4.3)
RFC 8446	Das Transport-Layer-Security-Protokoll (TLS) Version 1.3	Jeder TLS-Listener und -Client, über `rustls` — eingehendes `STARTTLS`/implizites TLS, ausgehendes Relay, LMTP, HTTP und LDAP
RFC 8058	Signalisierung der Ein-Klick-Funktion für Listen-E-Mail-Header	`List-Unsubscribe-Post` und die geschlüsselte Ein-Klick-URI, `pepsi-stage-list-deliver` und `pepsi-httpd`
RFC 8460	SMTP TLS Reporting (TLSRPT)	Aufzeichnung ausgehender TLS-Sitzungen (Relay-Stages) + tägliche Berichte (`pepsi-tlsrpt`)
RFC 8461	SMTP MTA Strict Transport Security (MTA-STS)	Richtliniendurchsetzung (`pepsi-stage-relay-to-internet`); Veröffentlichung (`pepsi-setup`)
RFC 8463	Eine neue kryptografische Signaturmethode für DKIM (Ed25519)	Ed25519-DKIM-Schlüssel/-Signaturen, `pepsi-common::keys`
RFC 8550	S/MIME-4.0-Zertifikatsbehandlung	Pfadbildung, `emailProtection`-EKU und `rfc822Name`-Bindung (`pepsi-crypto::trust`); Zertifikatsausstellung (`pepsi-crypto::keygen`, `pepsi-keys::ca`)
RFC 8551	S/MIME-4.0-Nachrichtenspezifikation	`application/pkcs7-mime` / `-signature` und der `smime-type`-Parameter, `pepsi-crypto::mime` + `pepsi-crypto::smime`
RFC 8601	Nachrichten-Header-Feld zur Angabe des Nachrichten-Authentifizierungsstatus	`Authentication-Results` (inkl. `iprev`), `pepsi-common::auth`
RFC 8617	Das Authenticated-Received-Chain-(ARC-)Protokoll	ARC verifizieren/signieren/versiegeln, pepsi-stage-arc
RFC 8905	Das `payto`-URI-Schema	Überweisungsziele in der Wallet-Selbstbedienungsantwort, `pepsi-stage-auto-pay`
RFC 8959	Das `secret-token`-URI-Schema	Die Form des Händler-Zugriffstokens, `pepsi-common::config`
RFC 9051	Internet Message Access Protocol (IMAP) Version 4rev2	Nur lesendes Scannen von Postfächern für den Import einer weißen Liste (`EXAMINE` + `BODY.PEEK[HEADER]`, sodass nichts als `\Seen` markiert wird), `pepsi-helper-mailbox-scan`
RFC 9106	Argon2, speicherharte Funktion für Passwort-Hashing und Proof of Work	Der Secure-Link-Inhaltsschlüssel, abgeleitet aus der PIN des Empfängers (`pepsi-secure-link::crypto`), und das Hashing von Administratorpasswörtern (das `admin`-Modul von `pepsi-httpd`)
RFC 9110	HTTP-Semantik	Anfrage-/Antwortbehandlung in pepsi-httpd
RFC 9112	HTTP/1.1	Das von pepsi-httpd bediente Drahtprotokoll, über `hyper`
RFC 9580	OpenPGP (die Krypto-Auffrischung; Nachfolger von RFC 4880)	`pepsi-crypto::pgp` über `sequoia-openpgp`; ausdrückliche SEIPDv2/v1-Containeraushandlung
RFC 9989	Domain-based Message Authentication, Reporting, and Conformance (DMARCbis)	Der DNS-Baumdurchlauf (Richtlinienermittlung und die Organisationsdomain für gelockertes Alignment) hinter der DMARC-Auswertung von Ingress, durchgeführt vom mitgelieferten `mail_auth`
Autocrypt Level 1	Der `Autocrypt:`-Schlüsselankündigungs-Header (ein De-facto-Standard, kein RFC)	Aus eingehender Mail von `pepsi-stage-autocrypt-learn` geerntet (über das `harvest`-Modul von `pepsi-keydisc`), im Rang nur über Gossip stehend; auf ausgehender Mail vom `autocrypt`-Modul von `pepsi-stage-encrypt` ausgegeben, unter `[stage-encrypt] AUTOCRYPT`. Das Schlüssel-Gossip aus §5.3 wird vom `gossip`-Modul derselben Stage unter `[stage-encrypt] AUTOCRYPT_GOSSIP` (standardmäßig aus) ausgegeben und von `pepsi-stage-autocrypt-learn` unter `LEARN_GOSSIP` (standardmäßig an) gelesen, auf eine eigene Vertrauenssprosse
FIPS 186-4	Digital Signature Standard (eine NIST-Publikation)	Die mit RFC 6979 geteilte `bits2int`-Kürzungsregel, `pepsi-crypto::smime`
draft-ietf-mailmaint-autoconfig	Autokonfiguration von Mailkonten (ein Internet-Draft der IETF-Arbeitsgruppe `mailmaint`, für den Status Informational vorgesehen)	Das `config-v1.1.xml`-Dokument, das pepsi-httpd unter `autoconfig.<domain>` und unter `/.well-known/autoconfig/` bedient, gebaut aus `[pepsi-autoconfig]` und dem Submission-Listener
MS-NLMP	Das NT-LAN-Manager-Authentifizierungsprotokoll (eine Microsoft Open Specification, kein RFC)	Ausgehendes Smarthost-`AUTH NTLM`, `pepsi-common::smtp::sasl`. Nur NTLMv2 — NTLMv1 ist kryptographisch gebrochen — mit Kanalbindung, und nie außerhalb von TLS angeboten
Maildir	D. J. Bernstein’s mailbox format (a specification, not an RFC — `tmp`/`new`/`cur` with the rename-into-`new` delivery rule)	pepsi-stage-relay-to-maildir über den setuid-Helper; Maildir++-Rekursion beim Scannen für den Import einer weißen Liste
SRS	Das Sender Rewriting Scheme (ein veröffentlichtes Verfahren ohne RFC; das `SRS0`/`SRS1`-Umschlagadressformat)	`pepsi-common::srs`, pepsi-stage-srs und die Rückwärtsdekodierung beim Ingress. Der MAC ist HMAC nach RFC 2104
VKS (`keys.openpgp.org`)	Das `/vks/v1`-HTTP-Protokoll des verifizierenden Keyservers (ein De-facto-Standard, kein RFC — es ist nicht HKP)	Abfrage durch `pepsi-keydisc@vks`; Hochladen und Adressverifikation durch pepsi-keys, dessen Bestätigungsmail pepsi-stage-vks-confirm beantwortet
XOAUTH2	Der vorstandardisierte SASL-Bearer-Token-Mechanismus von Google und Microsoft (kein Spezifikationsgremium; abgelöst durch RFC 7628 `OAUTHBEARER`, das dieselben Server ebenfalls annehmen)	Ausgehendes Smarthost-`AUTH`, `pepsi-common::smtp::sasl`. Angeboten, weil manche Mandanten `OAUTHBEARER` weiterhin ablehnen
draft-koch-openpgp-webkey-service	OpenPGP Web Key Directory (ein Internet-Draft, kein RFC)	Clientseite: `pepsi-keydisc@wkd-advanced` / `@wkd-direct`. Bedienseite: die vier Endpunkte von pepsi-httpd, beantwortet aus dem gespeicherten `pepsi_common::keystore::wkd_local_part_hash`

86.2. Notizen pro RFC¶

86.2.1. RFC 1035 — Domainnamen (DNS)¶

Alle DNS-Auflösung (MX, A/AAAA, TXT für SPF/DKIM/DMARC/MTA-STS und Reverse-PTR) folgt RFC 1035. Die Syntaxgrenzen von Domainnamen und Labels werden in pepsi-common::domain durchgesetzt. DNS wird von Ingress (Authentifizierung), der ARC-Stage (erneute Verifikation) und pepsi-stage-relay-to-internet (MX-Ermittlung und Adress-Caching in der Tabelle pepsi.dns_address) verwendet.

86.2.2. RFC 2045 / RFC 2047 — MIME-Nachrichtentexte und Header-Encoded-Words¶

Wenn ein nächster Hop 8BITMIME (RFC 6152) nicht ankündigt, durchläuft pepsi-common::mime den MIME-Baum und kodiert jeden 8-Bit-Blattteil mit einer 7-Bit-Content-Transfer-Encoding um (RFC 2045: Quoted-Printable für text/*, sonst Base64). Wenn ein Hop SMTPUTF8 (RFC 6531) nicht ankündigt, werden UTF-8-Header-Felder als RFC-2047-Encoded-Words umgeschrieben — nur dort, wo §5 eines erlaubt (ein unstrukturierter Feldinhalt, eine Anzeigename-phrase, das Innere eines comment), sodass aus einem Quoted-String ein Encoded-Word ohne seine Anführungszeichen wird. Ein Nicht-ASCII-MIME-Parameter erhält stattdessen die erweiterte Form aus RFC 2231, im Header-Block jedes Teils, und ein Nicht-ASCII-boundary= wird in seinem gesamten Multipart durch ein neues ASCII-Boundary ersetzt. Siehe pepsi-stage-relay-to-internet.

86.2.3. RFC 3030 — CHUNKING / BDAT¶

Ingress kündigt CHUNKING an und nimmt Nachrichtentexte an, die mit BDAT-Chunks gerahmt sind (zusätzlich zu DATA). Der BODY=BINARYMIME-Wert desselben RFC wird nicht angekündigt oder angenommen. Siehe pepsi-ingress.

86.2.4. RFC 3207 — STARTTLS¶

Ingress-Listener im starttls-Modus kündigen das STARTTLS-Verb an und upgraden eine Klartextsitzung an Ort und Stelle. Der ausgehende SMTP-Client verwendet STARTTLS opportunistisch (oder wie von MTA-STS verlangt). Implizites TLS wird stattdessen durch RFC 8314 geregelt.

86.2.5. RFC 3461 / RFC 3463 / RFC 3464 — Zustellungsstatusbenachrichtigungen¶

Ingress kündigt die DSN-Erweiterung an und validiert/speichert RET/ENVID/NOTIFY/ORCPT unter state.dsn (pepsi-common::dsn). Die Relay-Stages propagieren die Parameter an einen nächsten Hop, der ebenfalls DSN ankündigt (RFC 3461 §5–6). pepsi-stage-bounce gibt die Benachrichtigung als RFC-3464-multipart/report mit erweiterten RFC-3463-Statuscodes aus und beachtet NOTIFY (Failure standardmäßig; Success/Delay nur auf ausdrückliche Anforderung). Siehe Unterstützte Funktionen und pepsi-stage-bounce.

86.2.6. RFC 3834 — Automatische Antworten¶

Die von Pepsi erzeugten Auto-Antworten — darunter die Abwesenheitsnotiz von pepsi-stage-vacation, die Challenge von pepsi-stage-secretary, die Zahlungsaufforderungs-Nachricht von pepsi-stage-anti-spam und die Bestätigungs-/Fehler-Antworten von pepsi-stage-edit-settings — setzen Auto-Submitted gemäß RFC 3834 und werden mit dem Null-Absender gesendet. Eine Nachricht, die selbst eine automatische Antwort ist (Null-Absender / Auto-Submitted), wird nie aufgehalten, nie mit einem Bounce und nie mit einer Auto-Antwort beantwortet, sodass die Stages keine Antwortschleife bilden können.

Die Unterdrückungsregeln sind gemeinsam, in pepsi-common::autoreply, statt je Stage neu hergeleitet zu werden: Sie lassen sich nicht aus ersten Grundsätzen wiedergewinnen, und sie falsch zu bekommen ist der Weg, auf dem ein Auto-Antworter eine Mailschleife baut. suppress_reason verweigert die Antwort auf einen Null-Absender, ein Auto-Submitted ungleich no, ein Precedence: bulk|list|junk, ein X-Auto-Response-Suppress, das All, OOF oder AutoReply nennt, irgendein List-*-Feld, einen Dienstabsender (einschließlich eines VERP-<list>-bounces+…), ein multipart/report, Mail an sich selbst und eine bereits als state.spam markierte Nachricht. Die Vacation-Stage fügt hinter REQUIRE_ADDRESSED_TO den Test aus RFC 3834 §3 hinzu, „ist der Antwortende überhaupt adressiert?“, und ihre eigene Ratenbegrenzung je Korrespondent (SUPPRESS_DAYS, das vacation :days von Sieve). Siehe pepsi-stage-vacation und pepsi-stage-anti-spam.

86.2.7. RFC 3848 — ESMTP-Übertragungstypen¶

Der Received:-Trace-Header, den Ingress voranstellt, hält den Transport in der with-Klausel als SMTP, ESMTP, ESMTPS, ESMTPA oder ESMTPSA fest, gemäß RFC 3848. Das A wird immer dann hinzugefügt, wenn die Sitzung eine authentifizierte Identität trägt: mit TLS ist das ESMTPSA (SMTP-AUTH), ohne TLS ESMTPA, was der Klartext-UNIX-Submission-Socket für lokal eingelieferte Mail erzeugt.

86.2.8. RFC 4648 — Base16/Base32/Base64¶

SRS-Adressen kodieren ihren gekürzten HMAC in Base32 (RFC 4648), damit das Token unabhängig von der Groß-/Kleinschreibung und adress-sicher ist; Schlüsselmaterial verwendet Base64. Siehe pepsi-stage-srs.

86.2.9. RFC 4954 — SMTP AUTH¶

Beide Richtungen werden unterstützt. Eingehend: Ingress implementiert das AUTH-Verb mit den Mechanismen PLAIN (RFC 4616) und LOGIN (SASL-PLAIN-Initial-Response und der aufgeforderte LOGIN-Austausch). Es wird nur auf einer verschlüsselten Sitzung angekündigt und akzeptiert (implizites TLS oder nach STARTTLS); ein AUTH-Versuch im Klartext wird mit 504 5.5.4 abgelehnt (RFC 4954 §4; §1 erklärt das ältere 538 für veraltet). Zugangsdaten werden gegen ein konfiguriertes SASL-Backend (Dovecots Auth-Client-Socket, SASL_TYPE/SASL_PATH) verifiziert; ein erfolgreiches AUTH markiert die Sitzung als lokal erzeugt, lässt sie an jede Domain weiterleiten und stempelt ESMTPSA in die Received:-with-Klausel.

Ausgehend: Der SMTP-Client authentifiziert sich bei einem Smarthost über die AUTH-Option eines […-mta-*]-Abschnitts. Die vollständige Mechanismus-Suite (alle in pepsi-common::smtp::sasl, von Hand auf den bereits im Baum vorhandenen RustCrypto-Primitiven gebaut — keine SASL/SCRAM-Crate) ist:

plain — PLAIN (RFC 4616) und login — LOGIN (Klartextpasswort innerhalb des TLS-Tunnels).
cram-md5 — CRAM-MD5 (RFC 2195), HMAC-MD5-Challenge-Response.
scram-sha-1 / scram-sha-256 und ihre -plus-Varianten — SCRAM (RFC 5802) und SCRAM-SHA-256 (RFC 7677); die -PLUS-Formen ergänzen tls-server-end-point-Channel-Binding (RFC 5929). Die Server-Signatur wird zur gegenseitigen Authentifizierung verifiziert; Benutzernamen/Passwörter werden per SASLprep aufbereitet (RFC 4013).
digest-md5 — DIGEST-MD5 (RFC 2831), veraltet (RFC 6331 überführte es in den Status „Historic“): für ältere Smarthosts unterstützt, aber von auto ausgeschlossen; sowohl die pepsi-setup-Validierung als auch die Laufzeit warnen davor.
oauth — OAUTHBEARER (RFC 7628), mit Rückfall auf das de-facto XOAUTH2; das Bearer-Token wird aus TOKEN_FILE gelesen (siehe pepsi-helper-token-refresh).
external — SASL EXTERNAL (RFC 4422), authentifiziert durch das konfigurierte TLS-Client-Zertifikat statt durch ein Passwort.
ntlm — der de-facto Microsoft-NTLM-Mechanismus (kein RFC; nur NTLMv2). Wird nur unter TLS ausgeführt und trägt daher stets Extended Protection for Authentication: das tls-server-end-point-Channel-Binding (RFC 5929) und die smtp/<host>-SPN-AV-Paare plus den MIC. Schwach und ohne Server-Authentifizierung — pepsi-setup warnt davor.
gssapi — SASL GSSAPI / Kerberos (RFC 4752, über den RFC-4121-Kerberos-5-GSS-Mechanismus), über die System-Kerberos-Bibliothek (pepsi-common::smtp::gssapi). Das Ticket stammt aus einem Credential-Cache, der außerhalb des Bandes frisch gehalten wird; die SASL-Sicherheitsschicht wird auf keine Sicherheitsschicht ausgehandelt (TLS schützt die Sitzung bereits).
auto — handelt den stärksten Mechanismus aus, den das EHLO des Smarthosts anbietet (SCRAM-SHA-256-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1-PLUS > SCRAM-SHA-1 > CRAM-MD5 > LOGIN > PLAIN; DIGEST-MD5, NTLM und GSSAPI werden nie automatisch ausgewählt).

Wie eingehend weigert sich der ausgehende Client, Zugangsdaten über eine unverschlüsselte Verbindung zu senden. Eine 5xx-Ablehnung eines Passwort-Mechanismus wird als dauerhafter Fehler (Bounce) behandelt. Siehe pepsi-ingress und pepsi-stage-relay-to-smarthost.

GSSAPI/Kerberos ist der eine Mechanismus, der nicht von Hand gebaut ist: Er bindet die System-Kerberos-GSS-Implementierung (MIT krb5 / Heimdal). Das Debian-Paket hat daher als Build-Abhängigkeit libkrb5-dev und als Abhängigkeit libgssapi-krb5-2.

86.2.10. RFC 2369 / RFC 5064 / RFC 1153 / RFC 8058 – Mailinglisten¶

Die vier Normen, die das Mailinglisten-Subsystem implementiert und die sonst nichts in Pepsi braucht. Zusammen sind sie das, was eine Listennachricht für ein Mailprogramm, das nie von Pepsi gehört hat, als Listennachricht erkennbar macht.

RFC 2369 ist die List-*-Headerfamilie. Der rfc-2369-Handler in pepsi-stage-list-post schreibt List-Id, List-Help, List-Subscribe, List-Unsubscribe, List-Post und List-Owner aus den eigenen Adressen der Liste, und List-Archive, wenn die Liste archiviert wird. Auf diese Header stützt sich auch das gemeinsame Regelwerk nach RFC 3834, wenn es eine automatische Antwort verweigert: jeder List-*-Header unterdrückt eine Abwesenheitsnachricht, und so bleibt eine Abwesenheitsantwort von einer Mailingliste fern.

RFC 5064 ist Archived-At, die Archiv-URL je Nachricht. Pepsi leitet sie aus dem Message-ID-Hash der Nachricht ab, die URL in einer zugestellten Kopie und die URL, die das Archiv anbietet, sind daher dieselbe Zeichenkette, zweimal berechnet, und kein gespeichertes Paar, das auseinanderlaufen kann. Siehe Archive.

RFC 1153 ist das einfache Sammelnachrichtenformat: eine Nachricht je Trennerfolge, ein Inhaltsverzeichnis und die Band- und Ausgabennummerierung, die das Mailprogramm eines Abonnenten seit dreißig Jahren auffaltet. Pepsi baut sie und die MIME-Alternative multipart/digest, je nach dem delivery_mode des Abonnenten; siehe Mailinglisten.

RFC 8058 ist die Ein-Klick-Abmeldung, und es ist die eine Stelle, an der Pepsi über upstream hinausgeht: pepsi-stage-list-deliver ergänzt List-Unsubscribe-Post: List-Unsubscribe=One-Click neben einer geschlüsselten https:-URI, die pepsi-httpd mit einem einzigen POST einlöst – kein Bestätigungsschritt, keine Sitzung und keine Richtlinie, die das überstimmen kann, denn die Abmelden-Schaltfläche eines Mailbox-Anbieters ist eine Anfrage mit einem Versuch, die keine zweite Gelegenheit erhält, mit einem Menschen zu sprechen. Das Token ist ein geschlüsselter Hash über die Liste, die Adresse und eine wechselbare Seriennummer und kein gespeicherter Datensatz; siehe Mailinglisten.

86.2.11. RFC 2033 / RFC 5228 — LMTP-Lokalzustellung und Sieve¶

pepsi-stage-relay-to-lmtp stellt eine Nachricht an einen lokalen Mail Delivery Agent — typischerweise Dovecot — über LMTP (RFC 2033) zu: Es bietet jeden Empfänger in einer einzigen LMTP-Transaktion an (LHLO, optionales STARTTLS und SASL, Multi-Reply-DATA) und routet jeden Empfänger anhand der empfängerweisen Antwort des MDA weiter (zugestellt oder anhand seines RFC-3463-Status klassifiziert). Der MDA, nicht Pepsi, führt beim Ablegen der Mail den Sieve-Filter (RFC 5228) jedes Empfängers aus; Pepsi implementiert selbst kein Sieve. Der gemeinsame LMTP-Client ist pepsi-common::smtp::deliver_lmtp. Weil der MDA Privilegien abgibt, benötigt diese Stage keinen setuid/setgid-Helper (anders als pepsi-stage-relay-to-maildir). Siehe Unterstützte Funktionen und pepsi-stage-relay-to-lmtp.

86.2.12. RFC 5321 — SMTP¶

RFC 5321 ist das Rückgrat: die Ingress-Befehlsgrammatik und -Antworten; der Umschlag (MAIL FROM/RCPT TO, der Null-Absender <>); das domainlose <Postmaster>-Postfach (§4.5.1); der Received:-Trace-Header (§4.4); impliziter MX über Adress-Einträge (§5.1); und die Regel „auf einen Bounce nie einen Bounce erzeugen“ (§6.1). Er regelt Ingress und beide Relay-Stages.

86.2.13. RFC 5322 — Internet Message Format¶

Nachrichten werden an der ersten Leerzeile aufgeteilt in einen Header-Block und einen Nachrichtentext gespeichert (pepsi-common::message); die Header-Auswahl zum Signieren und das geparste From:/Subject: folgen RFC 5322. Die DKIM/ARC-h=-Auswahl erfolgt von unten nach oben, sodass ein vorangestellter Header nie eine bestehende Signatur stört.

86.2.14. RFC 3156 / RFC 9580 — OpenPGP und PGP/MIME¶

RFC 9580 ist die OpenPGP-Spezifikation von 2024 (die „Krypto-Auffrischung“, Nachfolgerin von RFC 4880); RFC 3156 ist, wie eine OpenPGP-Nachricht in MIME getragen wird. Pepsi implementiert beide über die Bibliothek sequoia-openpgp, in pepsi-crypto::pgp (Kryptographie) und pepsi-crypto::mime (Container).

Die MIME-Hälfte (RFC 3156). Die Verschlüsselung gibt multipart/encrypted; protocol="application/pgp-encrypted" mit dem Version: 1-Steuerteil und einem application/octet-stream-Chiffratteil aus (§4). Das abgetrennte Signieren gibt multipart/signed; protocol="application/pgp-signature" mit dem micalg-Parameter aus, berechnet aus dem tatsächlich verwendeten Hash (§5) — pgp-sha256 für den Standardwert. Beide Formen werden beim Eingang erkannt, ebenso der Nicht-MIME-Inline-Armor, den [pepsi] CRYPTO_INLINE_PGP ablehnen darf.

Die Containerfrage (RFC 9580). Die Wahl zwischen dem SEIPDv2-Container von RFC 9580 (AEAD) und dem SEIPDv1-Container von RFC 4880 (einem MDC) wird ausdrücklich aus den deklarierten Fähigkeiten der Empfängerschlüssel getroffen, statt sie der Bibliothek zu überlassen, sodass eine Herabstufung eine festgehaltene Entscheidung ist statt einer stillschweigenden; [pepsi] CRYPTO_ALLOW_DOWNGRADE regelt, ob sie überhaupt erlaubt ist. Eine SEIPDv1+MDC-Nachricht zu lesen ist nie eingeschränkt — der größte Teil der installierten Basis erzeugt sie noch —, aber das Vor-MDC-SED-Paket wird rundweg abgelehnt.

Siehe Schlüsselverwaltung, pepsi-stage-encrypt und pepsi-stage-decrypt; Interoperabilität mit Clients hält fest, was gegen gpg gemessen wurde.

86.2.15. RFC 5280 — X.509-Zertifikate und Pfadvalidierung¶

Jede S/MIME-Entscheidung ruht auf dieser einen. pepsi-crypto::trust parst Zertifikate, wendet die für Mail wichtigen Erweiterungen an (basicConstraints — einschließlich der pathLenConstraint, die begrenzt, wie viele Zwischenzertifikate eine CA unterhalb ihrer selbst autorisiert hat — keyUsage, die erweiterte Schlüsselverwendung emailProtection aus §4.2.1.12 und den rfc822Name-Subject-Alternative-Name, der ein Zertifikat an eine Adresse bindet) und baut einen Pfad zu einem konfigurierten Anker. Über diesen Pfad führt es dann die zustandsbehaftete Hälfte von §6.1 aus: nameConstraints (§4.2.1.10), policyConstraints (§4.2.1.11) und inhibitAnyPolicy (§4.2.1.14), zusammen mit dem certificatePolicies-/policyMappings-Baum, auf den sie wirken. Die NIST-PKITS-Suite (Abschnitte 4.6 und 4.8–4.13) ist eingecheckt und besteht, einschließlich jeder vom Standard abweichenden Eingabeeinstellung, die sie aufführt.

Vier Grenzen:

Der Vertrauensspeicher wird vor den eigenen Zertifikaten der Nachricht durchsucht. Ein CMS-SignerIdentifier benennt ein Zertifikat über Aussteller und Seriennummer, sodass eine Nachricht ein gefälschtes Zertifikat mit dem Aussteller und der Seriennummer eines gepinnten, aber mit einem anderen Schlüssel tragen kann. Ein Prüfer, der zuerst in die Nachricht sähe, würde es akzeptieren.
Der Widerruf wird nicht geprüft. Weder das CRL-Profil aus §5 noch OCSP (RFC 6960) wird herangezogen — siehe Anwendbare, noch nicht implementierte RFCs. Der Revocation-Wert auf einem validierten Pfad ist immer NotChecked, was ehrlich gemeldet statt als „nicht widerrufen“ dargestellt wird.
Die Beschränkungen einer CA binden jedes Zertifikat unter ihr — die des Ankers eingeschlossen. Erlaubte Teilbäume werden entlang der Kette geschnitten und ausgeschlossene vereinigt, für den Subject-DN, jeden Subject Alternative Name und jedes emailAddress-Attribut des Subject-DN (immer, nicht nur, wenn es keinen SAN gibt, wie §4.2.1.10 verlangt, weil Pepsi eine Nachricht an dieses Attribut bindet, wenn der SAN kein Postfach nennt). Die eigenen nameConstraints und Richtlinienerweiterungen eines Ankers werden angewandt, wie RFC 5937 es vorschreibt, sodass eine direkt als Anker eingetragene, namensbeschränkte Partner-CA ihre Grenze behält. Ein Verstoß ist policy-rejected. Pepsi legt keine eigene Zertifikatsrichtlinie fest (user-initial-policy-set ist any-policy), sodass der Richtlinienbaum nur dort etwas entscheidet, wo eine CA eine explizite Richtlinie verlangt.
Eine kritische Erweiterung, die Pepsi nicht verarbeiten kann, führt zur Ablehnung. Ein Zertifikat mit einer kritischen Erweiterung, die Pepsi nicht erkennt — oder deren Wert es nicht dekodieren kann —, wird rundweg abgelehnt (policy-rejected). Bei Namensbeschränkungen betrifft das einen Teilbaum mit minimum oder maximum, eine x400Address und eine leere Erweiterung; ein Teilbaum einer Form, die Pepsi nicht abgleicht (otherName, ediPartyName, registeredID), wird nur abgelehnt, wenn ein Zertifikat unter ihm einen Namen dieser Form trägt, wie §4.2.1.10 es erlaubt. Ein fehlerhaftes nameConstraints, policyConstraints oder inhibitAnyPolicy wird abgelehnt, selbst wenn es nicht kritisch ist: Der Aussteller hat eine Einschränkung geschrieben, und eine, die nicht gelesen werden kann, darf nicht fallen gelassen werden. Jede andere nicht erkannte, nicht kritische Erweiterung wird ignoriert, wie es sein muss: Echte Zertifikate sind voll davon.

Ein Zertifikat, das sich zu keinem konfigurierten Anker kettet, ist nicht vertrauenswürdig, nicht ungültig (Verdict::Untrusted): Der größte Teil der signierten Mail der Welt kettet sich zu einer CA, für die uns niemand einen Anker gegeben hat, und das als Fehlschlag zu melden würde den Indikator nutzlos machen.

86.2.16. RFC 5652 / 5083 / 5753 / 8550 / 8551 — CMS und S/MIME¶

S/MIME ist Pepsis zweites Ende-zu-Ende-Protokoll, und seine Standards teilen die Arbeit sauber auf.

RFC 5652 (CMS) ist die Containersyntax. pepsi-crypto::smime baut und öffnet SignedData (abgetrennt und opak), EnvelopedData und die certs-only-Form, mit der ein Zertifikat veröffentlicht wird. Das cms-Crate liefert nur die ASN.1-Typdefinitionen; die Builder und Öffner sind Pepsis eigene, sodass hier entschieden wird, was ausgegeben und was angenommen wird, statt es zu erben.

RFC 5083 (``AuthEnvelopedData``) ist der Container für authentifizierte Verschlüsselung, und er ist das, was Pepsi standardmäßig ausgibt (AES-256-GCM). Die EnvelopedData aus RFC 5652 mit AES-CBC bleibt als Herabstufungspfad für einen Empfänger, der es nicht besser kann — wiederum durch [pepsi] CRYPTO_ALLOW_DOWNGRADE beschränkt. Welche Clients AuthEnvelopedData tatsächlich lesen können, ist die größte offene Interoperabilitätsfrage im Baum; siehe Die AuthEnvelopedData-Frage.

RFC 5753 deckt die Elliptische-Kurven-RecipientInfo ab: ECDH-Schlüsselvereinbarung über P-256/P-384 mit der X9.63-KDF und AES-Key-Wrap, neben den RSA-Formen (RSAES-OAEP-SHA-256 und PKCS#1 v1.5 für einen Empfänger, der es braucht).

RFC 8550 (Zertifikatsbehandlung) ist pepsi-crypto::trust: Pfadbildung zu einem konfigurierten Anker, Gültigkeitsdaten, basicConstraints, keyUsage gegen die durchgeführte Operation, die erweiterte Schlüsselverwendung id-kp-emailProtection und der rfc822Name-Subject-Alternative-Name, der ein Zertifikat an die From:-Adresse bindet. Der Widerruf ist dreiwertig — „nicht geprüft“ wird nie als „nicht widerrufen“ dargestellt — und das Modul öffnet keine Sockets: Es gibt kein OCSP und kein CRL-Abholen, nur ihm gelieferte CRLs — und die Stages liefern keine.

RFC 8551 (Nachrichtenspezifikation) ist die MIME-Oberfläche: application/pkcs7-mime mit dem smime-type-Parameter (signed-data/enveloped-data/authEnveloped-data/certs-only) und application/pkcs7-signature innerhalb von multipart/signed, mit den üblichen Dateinamen smime.p7m/smime.p7s/smime.p7c. Die alten Schreibweisen application/x-pkcs7-* werden bei der Eingabe erkannt (vom Klassifikator, den die Decrypt-Stage verwendet, und von der Schlüsselernte), aber nie ausgegeben.

Zertifikate für die eigenen Benutzer dieser Installation stellt pepsi-crypto::keygen über die lokale CA in pepsi-keys aus. Siehe Schlüsselverwaltung; Interoperabilität mit Clients hält fest, was gegen OpenSSL gemessen wurde.

86.2.17. RFC 6125 — TLS-Dienst-Identität¶

Wenn MTA-STS authentifiziertes TLS verlangt, wird das MX-Zertifikat des Empfängers gemäß RFC 6125 daraufhin geprüft, ob es für den erwarteten Hostnamen gültig ist. Siehe pepsi-stage-relay-to-internet.

86.2.18. RFC 6152 — 8BITMIME¶

Ingress kündigt 8BITMIME an und hält den BODY=-Wert unter state.origin fest. Jede Relay-Stage kündigt BODY=8BITMIME einem Hop gegenüber erneut an, der es unterstützt, und stuft andernfalls den Nachrichtentext herab (RFC 2045); danach prüft sie das Ergebnis erneut: §3 verbietet, 8-Bit-Inhalt „unter irgendwelchen Umständen“ zu übertragen, sodass ein Nachrichtentext, den die Herabstufung nicht umwandeln konnte, ein dauerhafter Fehler ist statt etwas, das trotzdem gesendet wird. Siehe Unterstützte Funktionen.

86.2.19. RFC 6376 / RFC 8463 — DKIM (RSA und Ed25519)¶

Ingress verifiziert eingehende DKIM-Signaturen; pepsi-stage-dkim-sign signiert ausgehende Mail. Jede Domain hat sowohl einen RSA-2048-Schlüssel (RFC 6376) als auch einen Ed25519-Schlüssel (RFC 8463), eingerichtet von pepsi-setup; beide Signaturen werden hinzugefügt, sofern [pepsi] DKIM_ALGORITHMS nicht nur eine nennt. Das l=-Body-Längen-Tag wird nie ausgegeben: Strenge Verifizierer lehnen eine solche Signatur rundweg ab, und RFC 6376 §8.2 warnt davor. Siehe pepsi-stage-dkim-sign.

86.2.20. RFC 6409 — Nachrichteneinlieferung¶

Ein mit SUBMISSION = yes markierter Listener handelt als Message Submission Agent. Er verlangt AUTH, wie RFC 6409 es erwartet (ein nicht authentifiziertes MAIL FROM wird mit 530 abgelehnt; siehe RFC 4954 — SMTP AUTH) und wendet die Submission-Korrekturen auf jede angenommene Nachricht an: ein fehlendes Date: wird ergänzt (§8.2) und ein fehlendes Message-ID: erzeugt (§8.3). Die Durchsetzung der Submission-Identität (§6) und die Sender:-Korrektur (§8.1) werden von der USERNAME_MAP-Zuordnung des authentifizierten SASL-Benutzers zu seinen erlaubten Adressen getrieben: ein Umschlag-MAIL FROM oder ein From:, das der Benutzer nicht verwenden darf, wird mit 550 abgelehnt, und ein erlaubtes From:, das von der kanonischen Identität des Benutzers abweicht, erhält einen Sender:-Header, der diese Identität benennt. Siehe pepsi-ingress.

86.2.21. RFC 6531 — SMTPUTF8¶

Ingress kündigt SMTPUTF8 an und nimmt UTF-8 in Headern und im Umschlag an. Jede Relay-Stage kündigt es einem unterstützenden Hop gegenüber erneut an und stuft andernfalls UTF-8-Header herab (RFC 2047); eine Nicht-ASCII-Adresse, die einem Nicht-SMTPUTF8-Hop gegenüber nicht darstellbar ist, ist ein dauerhafter Fehler (Bounce). Siehe Unterstützte Funktionen.

86.2.22. RFC 7208 — SPF¶

Ingress verifiziert SPF auf der MAIL FROM-Identität unter Verwendung der IP des sich verbindenden Clients (über die mail_auth-Bibliothek) und hält das Urteil in Authentication-Results und unter state.auth.spf fest.

86.2.23. RFC 7489 — DMARC¶

Ingress wertet DMARC aus und hält das Urteil fest. Mit gesetztem DMARC_ENFORCE wird ein eindeutiger DMARC-Fehlschlag unter einer quarantine/reject-Richtlinie zur SMTP-Zeit abgelehnt (550); andernfalls wird das fehlschlagende Urteil festgehalten und die Mail angenommen (fail-open).

Die organisatorische Domain, mit der die gelockerte Ausrichtung vergleicht, wird durch den Baumdurchlauf nach RFC 9989 (DMARCbis) ermittelt, den mail_auth intern durchführt; siehe unten.

86.2.24. RFC 9989 — DMARCbis¶

Die vendorte mail_auth-Bibliothek implementiert den DNS-Baumdurchlauf von DMARCbis (§4.10): Der Richtlinieneintrag wird an der From:-Domain und dann entlang ihrer übergeordneten Labels nachgeschlagen, und die organisatorische Domain, mit der die gelockerte Ausrichtung vergleicht, wird auf dieselbe Weise bestimmt statt aus einer Public-Suffix-Liste. Das DMARC_ENFORCE von Ingress und das aufgezeichnete Urteil bauen auf den ausgerichteten SPF- und DKIM-Ergebnissen auf, die sie liefert.

86.2.25. RFC 7505 — Null-MX¶

pepsi-stage-relay-to-internet klassifiziert ein 0 .-Exchange als dauerhaften Fehler (ein sofortiger Bounce, niemals eine Wiederholung).

86.2.26. RFC 7672 — DANE / TLSA für SMTP¶

Beide Relay-Stages unterstützen opportunistisches DANE: Eine DANE = off|warn|strict-Option (Standardwert warn) schlägt die TLSA-Einträge des nächsten Hops nach — pro MX für pepsi-stage-relay-to-internet, pro […-mta-*] für pepsi-stage-relay-to-smarthost — und gleicht sie mit der vorgelegten Zertifikatskette ab. Der Verifizierer und die TLSA-Typen liegen in pepsi-common::smtp::dane; die AD-Bit-bewussten TLSA/MX-Abfragen in pepsi-common::dns (Pepsi vertraut einem validierenden Resolver und liest das AD-Bit der Antwort, statt DNSSEC selbst zu validieren). DANE hat Vorrang vor MTA-STS und TLS_VERIFY; eine Nichtübereinstimmung eines nutzbaren Eintrags schiebt in strict auf und warnt in warn nur.

86.2.27. RFC 7929 / RFC 8162 — OPENPGPKEY- und SMIMEA-Schlüsseleinträge¶

Pepsi implementiert beide Hälften: das Veröffentlichen der Schlüsseleinträge unserer eigenen Adressen und das Nachschlagen der eines Korrespondenten.

Veröffentlichen. pepsi-keys dns <address> gibt die DNS-Einträge aus, die das gespeicherte öffentliche Schlüsselmaterial einer Adresse veröffentlichen: einen OPENPGPKEY-Eintrag (RFC 7929) mit einem übertragbaren öffentlichen OpenPGP-Schlüssel und einen SMIMEA-Eintrag (RFC 8162) mit einem S/MIME-Zertifikat in der TLSA-Gestalt (usage, selector, matching-type) — 3 0 0 (domänenausgestelltes Zertifikat, vollständiges Zertifikat, exakte Übereinstimmung), die Form, die ein selbstsigniertes oder direkt gepinntes Zertifikat annimmt. Nur veröffentlichte, aktive Identitäten werden ausgegeben. pepsi-setup run gibt dieselben Einträge für jede veröffentlichte Identität neben den DKIM-, SPF- und MTA-STS-Einträgen aus.

Nachschlagen. Die Entdeckungsinstanz pepsi-keydisc@dane fragt dieselben beiden Eintragstypen für die Adresse eines Korrespondenten ab, OPENPGPKEY zuerst und SMIMEA, wenn die Domain keinen OpenPGP-Eintrag veröffentlicht. Sie rangiert auf der Vertrauensleiter an zweiter Stelle — nur unterhalb von Material, das ein Operator von Hand eingetragen hat —, weil DNSSEC die eine Quelle mit kryptographischer Herkunft ist.

Beide Richtungen verwenden denselben gehashten Eigentümernamen — das Hex der ersten 28 Oktette des SHA-256 des lokalen Teils, gefolgt von ._openpgpkey. oder ._smimecert. —, sodass eine Zone die von ihr bedienten Adressen nicht aufzählt. Dieser Hash ist groß-/kleinschreibungsempfindlich (RFC 7929 §3), anders als der Web-Key-Directory-Hash unten.

Beide Standards setzen eine DNSSEC-signierte Zone voraus, und Pepsi behandelt das in beiden Richtungen als bindend. pepsi-keys dns sagt es in seiner eigenen Ausgabe, und eine Abfrage ist AD-gebunden: Eine Antwort, die der Resolver nicht validiert hat, wird rundweg abgelehnt statt auf niedrigerem Rang angenommen, denn ein unsignierter Schlüsseleintrag ist ein Schlüssel von dem, der für die Zone antworten kann. Pepsi vertraut einem validierenden Resolver, statt DNSSEC selbst zu validieren, sodass eine Installation ohne einen überhaupt keine DANE-Ergebnisse bekommt — pepsi-setup sondiert danach und meldet es. Siehe pepsi-keys, pepsi-keydisc und Schlüsselverwaltung.

86.2.28. OpenPGP Web Key Directory (draft-koch-openpgp-webkey-service)¶

Das Web Key Directory ist die HTTPS-Hälfte derselben Aufgabe: Der Schlüssel eines Korrespondenten wird von der eigenen Domain der Adresse unter einem Hash ihres lokalen Teils abgeholt. Pepsi berechnet diesen Hash in pepsi_common::keystore::wkd_local_part_hash — z-base-32 des SHA-1 des kleingeschriebenen lokalen Teils — und speichert ihn indiziert bei jeder Identität, sodass eine Anfrage mit einer Abfrage beantwortet wird, statt jeden in Frage kommenden Datensatz zu hashen. (Der SHA-1 dort ist eine Benennungsfunktion, die die Spezifikation festlegt, keine Sicherheitsfunktion, sodass er bewusst nicht von CRYPTO_ALLOW_WEAK_DIGESTS beschränkt wird.)

Die Client-Seite ist implementiert: pepsi-keydisc@wkd-advanced fragt openpgpkey.<domain> ab und pepsi-keydisc@wkd-direct die Domain selbst. Sie sind getrennte Ränge und daher getrennte nebenläufige Abfragen statt einer Rückfallkette, denn direct nur „falls advanced scheitert“ auszuführen nähme die schwächere Antwort an, wann immer die stärkere bloß langsam war. Der Abruf ist über die eigenen Anforderungen des Drafts hinaus gehärtet: nur HTTPS mit Zertifikatsvalidierung und ohne unsicheren Modus, höchstens eine HTTPS-zu-HTTPS-Weiterleitung zum selben Host, Weigerung, sich mit Loopback-/privaten/Link-Local-Adressen zu verbinden, eine während des Streamens durchgesetzte Obergrenze für den Nachrichtentext, eine Frist auf jedem Schritt und IDNA-A-Label-Konvertierung. Ein zurückgelieferter Schlüssel, dessen User ID nicht die abgefragte Adresse benennt, wird verworfen — ohne das könnte eine Domain jede Anfrage mit einem Schlüssel ihrer Wahl beantworten — und die Direktiven mailbox-only und dane-only der Richtliniendatei werden beachtet.

Die Bedien-Seite ist ebenfalls implementiert, von pepsi-httpd: die direkte und die erweiterte Form sowohl des Schlüssel- als auch des Richtlinienpfads, beantwortet durch eine indizierte Abfrage nach (domain, local-part hash) über Identitäten, die diese Installation hält und als published markiert hat. Die Antwort ist der binäre übertragbare Schlüssel mit Access-Control-Allow-Origin: *; die Richtliniendatei ist ein 200 der Länge null, das existieren muss, weil GnuPG ihr Fehlen als „hier kein Web Key Directory“ liest; ein unbekannter Hash ist ein 404 ohne Inhalt. Der ?l=-Parameter wird gelesen und ignoriert — ihn zu beachten würde den Endpunkt zu einer Abfrage nach einer vom Aufrufer gelieferten Adresse machen statt nach einem Hash, den der Aufrufer kennen musste.

Zwei Eigenschaften der ausliefernden Seite sind bewusst so gewählt. Sie liefert nie einen zwischengespeicherten Korrespondentenschlüssel aus, nur unsere eigenen Identitäten: Material zu veröffentlichen, das wir nicht verifiziert haben, unter unserem eigenen Domainnamen, ist das, was ein Keyserver tut, und wir sind keiner. Und sie wendet keine Ratenbegrenzung an, denn ein Web Key Directory ist konstruktionsbedingt ein öffentliches Orakel — siehe Schlüsselverwaltung.

Die Spezifikation ist ein Internet-Draft und kein RFC.

86.2.29. Autocrypt — der `Autocrypt:`-Header¶

Autocrypt ist kein RFC, sondern ein De-facto-Standard, und es ist die Art, wie die meisten PGP-nutzenden Mailclients heute einen Schlüssel ankündigen. Pepsi erntet den Header — zusammen mit application/pgp-keys-Teilen und den Signiererzertifikaten in einer S/MIME-SignedData — aus bereits eingetroffener Mail.

Das Ernten ist bewusst kein Entdeckungsdienst: Es kostet keine Netz-E/A, weil das Material bereits vorliegt, sodass es inline läuft statt als pepsi-keydisc-Instanz, und inbound wird in [pepsi-keydiscovery] SOURCES abgelehnt. Es schreibt allerdings über denselben Pfad, sodass ein geernteter Schlüssel auch jede Nachricht freigibt, die auf diese Adresse wartend geparkt ist.

Ein geernteter Schlüssel sitzt nahe dem unteren Ende der Vertrauensleiter — Vertrauen beim ersten Gebrauch; nur ein Schlüssel, den das Autocrypt-Gossip:-Feld eines Dritten einführt, rangiert tiefer (siehe unten) — und die serverseitige Konfliktregel hindert ihn daran, etwas besser Bezeugtes zu verdrängen. Der Unterschied ist eine echte Einstellung: MIN_TRUST = harvested bedeutet genau Rang 7, sodass es die opportunistische Verschlüsselung erhält und zugleich Einführungen durch Dritte ausschließt. Ein geernteter Schlüssel ist dennoch standardmäßig verwendbar, denn die Alternative dazu, an einen TOFU-Schlüssel zu verschlüsseln, ist, Klartext zu senden. Siehe Schlüsselverwaltung.

Pepsi schreibt den Header auch. Sofern [stage-encrypt] AUTOCRYPT nicht ausgeschaltet ist, kündigt pepsi-stage-encrypt den eigenen OpenPGP-Schlüssel des From:-Autors auf jeder lokal eingelieferten Nachricht an — einschließlich schlichter Klartextmail, was der Fall ist, auf den es ankommt, denn ein Korrespondent muss den Schlüssel lernen, bevor es etwas zu verschlüsseln gibt. Angekündigt wird der minimale übertragbare öffentliche Schlüssel aus fünf Paketen gemäß Level 1 §2.1.1, nur für eine Identität, die ihr privates Material noch hält, und nie auf einer Nachricht, die bereits ein Autocrypt:-Feld aus dem eigenen Client des Absenders trägt. Weil die Stage unmittelbar vor dem DKIM-Signieren läuft, ist der Header von unserer eigenen Signatur abgedeckt.

prefer-encrypt=mutual wird nur beansprucht, wenn die effektive ENCRYPT-Richtlinie required ist. Level 1 §2.4 lässt den Client eines Korrespondenten standardmäßig nur dann verschlüsseln, wenn beide Enden mutual sagen, sodass es unter einer opportunistischen Richtlinie zu beanspruchen — einer, deren ON_NO_KEY = cleartext sagt, dass unverschlüsselte Mail akzeptabel ist — eine Präferenz ankündigen würde, die die Installation nicht durchsetzt.

Das Schlüssel-Gossip aus Level 1 §5.3 — der Mechanismus, mit dem eine Nachricht die Schlüssel der anderen Empfänger ankündigt, sodass zwei Korrespondenten, die einander nie geschrieben haben, dennoch verschlüsselt antworten können — ist ebenfalls implementiert, unter [stage-encrypt] AUTOCRYPT_GOSSIP. Es ist standardmäßig aus: Anders als der Autocrypt:-Header, der einen Schlüssel veröffentlicht, dessen Eigentümer diese Installation gebeten hat, ihn zu halten, verteilt Gossip zwischengespeichertes Schlüsselmaterial Dritter an Korrespondenten, die nicht danach gefragt haben, und das ist eine Entscheidung, die ein Operator bewusst treffen muss.

Zwei Eigenschaften machen das Feature sicher einschaltbar. Die Felder reiten innerhalb des Chiffrats und nur dort — ein äußeres würde die Empfängermenge einer verschlüsselten Nachricht an jedes Relay auf dem Pfad veröffentlichen —, sodass es kein Gossip auf Klartext, auf nur signierter Mail oder in einem S/MIME-Container gibt, den Autocrypt nicht definiert. Und die gegossipten Adressen werden allein aus den To:- und Cc:-Feldern der Nachricht gelesen: Die Umschlagempfängerliste, die die Bcc-Empfänger trägt, wird nur herangezogen, um eine Adresse aus der Menge zu entfernen. Ein blinder Empfänger kann daher nie in irgendeiner Kopie auftauchen, was genau die Regel ist, die Level 1 §5.3 auch einem Empfänger auferlegt.

Die empfangende Hälfte ist ebenfalls implementiert, in pepsi-stage-autocrypt-learn unter LEARN_GOSSIP (standardmäßig an) — eine eigene Stage, damit sie nach den Spam-Prüfungen läuft, worum §5.3 ebenfalls bittet und was pepsi-stage-decrypt, konstruktionsbedingt zuerst auf dem eingehenden Pfad, nicht leisten kann. §5.3 verlangt, dass ein gegossipter Schlüssel in einem getrennten Peer-Zustand von einem aus einem Autocrypt:-Header gelernten gehalten wird, sodass die Einführung durch einen Dritten nie verdrängen kann, was der Eigentümer einer Adresse über sich selbst gesagt hat; Pepsi setzt das als eigene Sprosse am unteren Ende der Entdeckungs-Vertrauensleiter um (gossip, Rang 8, unterhalb von harvested), was die Konfliktregel der Datenbank bereits durchzusetzen weiß. Ein Feld zählt nur, wenn es wirklich im Chiffrat war — ein äußeres könnte von allem auf dem Pfad geschrieben worden sein —, nur wenn sein addr im eigenen To:/Cc: der Nachricht steht, nie für die eigene Adresse des Absenders und nie für eine Adresse, die dieser Host bedient. Es trägt nie prefer-encrypt, und eine gegen einen gegossipten Schlüssel geprüfte Signatur kommt als valid-untrusted zurück, sodass eine Einführung keine Schranke öffnet.

86.2.30. VKS — das Protokoll des verifizierenden Keyservers¶

keys.openpgp.org und seine Nachahmer sprechen ein kleines HTTP-Protokoll unter /vks/v1, und es ist bewusst nicht HKP: Ein Schlüssel wird für eine Adresse erst ausgeliefert, wenn der Adressinhaber eine Bestätigungsmail beantwortet hat, was die Antwort mehr wert macht als „irgendwer hat das hochgeladen“.

Pepsi spricht beide Hälften. pepsi-keydisc@vks schlägt einen Korrespondenten nach Adresse nach, verwirft dabei einen Schlüssel, dessen User ID nicht die abgefragte Adresse benennt, und überspringt einen widerrufenen; er rangiert unterhalb von DANE, beiden Web-Key-Directory-Methoden und LDAP, denn die Bestätigung beweist die Kontrolle über das Postfach und nichts weiter. pepsi-keys lädt unsere eigenen Identitäten hoch und fordert die Verifikation an — standardmäßig aus ([pepsi-keys] VKS_PUBLISH), denn die Adresse eines Benutzers bei einem Dritten zu veröffentlichen ist eine Operatorentscheidung und kann, anders als beim Web Key Directory, nicht rückgängig gemacht werden. Die Bestätigungsmail des Servers muss dann beantwortet werden, was die ganze Aufgabe von pepsi-stage-vks-confirm ist — einer Stage, die einem Link erst nach sechs unabhängigen Prüfungen folgt, darunter, dass der Host des Umschlagabsenders genau der konfigurierte Keyserver ist und dass auch jeder Link im Nachrichtentext dorthin zeigt.

86.2.31. RFC 8446 — TLS 1.3¶

Jede TLS-geschützte Verbindung in Pepsi — eingehende STARTTLS- und Implizit-TLS-Listener, der ausgehende Relay-Client, LMTP, der HTTP-Server und der LDAP-Entdeckungsclient — läuft über rustls, das TLS 1.3 und 1.2 spricht und nichts Älteres. Es gibt keinen Konfigurationsknopf, um SSLv3 oder TLS 1.0/1.1 wieder zu aktivieren, denn rustls implementiert sie nicht.

Was zwischen diesen Verbindungen variiert, ist nicht das Protokoll, sondern welche Authentifizierung vom Peer verlangt wird, und dort übernehmen die mailspezifischen Standards: RFC 6125 für den Identitätsabgleich, RFC 7672 für DANE, RFC 8461 für MTA-STS und die TLS_VERIFY-Option für den Fall, dass ein Operator sie wissentlich lockert. Opportunistisches STARTTLS zu einem beliebigen MX authentifiziert konstruktionsbedingt nichts — das ist das Modell von RFC 3207, keine Schwäche hier —, weshalb es DANE und MTA-STS gibt und weshalb das Ergebnis jedes Versuchs für das Reporting nach RFC 8460 festgehalten wird.

86.2.32. RFC 8314 — Implizites TLS¶

Ein Listener mit MODE = tls führt den TLS-Handshake vor der SMTP-Begrüßung durch (implizites TLS, z. B. der Submission-Port 465), wie von RFC 8314 empfohlen.

Gemäß RFC 8314 §4.3 hält Ingress außerdem die ausgehandelte TLS-Version und -Chiffre in dem von ihm vorangestellten Received:-Trace-Header fest — als (version=… cipher=…)-Kommentar nach dem ESMTPS-Schlüsselwort — da der bloße ESMTPS-Übertragungstyp nicht vermittelt, welche Parameter verwendet wurden.

86.2.33. RFC 8460 — SMTP TLS Reporting (TLSRPT)¶

Wenn [pepsi-tlsrpt] SEND_REPORTS aktiv ist, halten die Relay-Stages das Ergebnis jeder ausgehenden TLS-Sitzung in der Aggregat-Zähler-Tabelle pepsi.tls_session fest. pepsi-tlsrpt(1), täglich per Cron ausgeführt, gruppiert die Datensätze eines Tages in einen RFC-8460-JSON-Bericht pro Richtliniendomain, gzippt ihn, schlägt das rua des _smtp._tls der Domain nach und verschickt ihn per mailto: (zurück in die Pipeline injiziert, sodass er signiert und weitergeleitet wird) oder HTTPS-POST. Die ankündigende Hälfte ist pepsi-setup, das unseren eigenen _smtp._tls-TXT-Eintrag aus [pepsi-tlsrpt] RUA ausgibt. Die gemeinsamen Typen, der Fehlerklassifizierer und die Berichtsersteller liegen in pepsi-common::tlsrpt. Siehe pepsi-tlsrpt.

86.2.34. RFC 8461 — MTA-STS¶

pepsi-stage-relay-to-internet ermittelt und setzt die MTA-STS-Richtlinien der Empfängerdomain durch: Eine enforce-Richtlinie beschränkt die Zustellung auf die gelisteten MX-Hosts über authentifiziertes STARTTLS. pepsi-setup veröffentlicht unseren eigenen _mta-sts-TXT-Eintrag und gibt die Richtliniendatei aus. Siehe pepsi-setup.

86.2.35. RFC 8601 — Authentication-Results¶

Ingress stellt einen eigenständigen Authentication-Results-Header voran, der die SPF-, DKIM-, DMARC- und iprev-(FCrDNS-)Urteile trägt, mit dem Ingress-Hostnamen als authserv-id. Die ARC-Stage reproduziert dieselbe Bewertung in ihrer AAR.

86.2.36. RFC 8617 — ARC¶

pepsi-stage-arc verifiziert jede eingehende ARC-Kette und versiegelt die Nachricht als unsere ADMD, indem es ein AAR/AMS/AS-Set voranstellt, signiert mit dem einzigen ARC_ALGORITHM. Dies erlaubt dem endgültigen Empfänger, dem Grenzurteil zu vertrauen, selbst nachdem Pepsis Weiterleitung das SPF/DKIM-Alignment zerstört. Die RFC-6376-Parameter der ARC-Message-Signature — Kanonisierung (c=), abgedeckte Header (h=) und ein x=-Ablauf — sind an der Stage konfigurierbar (wie an pepsi-stage-dkim-sign); das l=-Body-Längen-Tag wird nie ausgegeben, da es die Kette unvalidierbar machen würde.

86.2.37. RFC 9051 / RFC 4155 — ein Postfach lesen (IMAP und mbox)¶

Pepsi bedient keines der beiden Protokolle: Es ist kein Mailspeicher. Es liest Postfächer an zwei Stellen: pepsi-helper-mailbox-scan, das eine weiße Liste aus der Mail sät, die ein Benutzer bereits gesendet hat (siehe pepsi-whitelist), und pepsi-archive, das ein Listenarchiv als mbox importiert und exportiert. Der Rest dieses Abschnitts behandelt Ersteres.

Der IMAP-Client ist im strengen Sinne nur lesend — er setzt EXAMINE statt SELECT ab und holt BODY.PEEK[HEADER], sodass keine Nachricht als \Seen markiert wird und sich kein Postfachzustand ändert. Nur Header-Blöcke werden gelesen; jeder Leser hält an der Leerzeile an, sodass Nachrichtentexte nie in den Prozess gelangen. Derselbe Helper liest lokales mbox (RFC 4155) und Maildir und kann einen doveadm -f json-Strom verarbeiten.

LMTP (RFC 2033) ist das Zustellungsgegenstück und hat überhaupt kein Abholverb, weshalb ein Postfach auf einem reinen LMTP-MDA nicht gescannt werden kann; IMAP ist die Netzoption.

86.2.38. RFC 9106 — Argon2¶

Argon2id taucht zweimal auf, für zwei verschiedene Bedrohungen.

Im Secure-Link-Portal (Das Secure-Link-Ausweichportal) leitet es den Schlüssel ab, der eine gespeicherte Nachricht verschlüsselt, aus der PIN des Empfängers plus einem Salz je Nachricht und einem serverseitigen Pfeffer, der außerhalb der Datenbank gehalten wird. Die Kostenparameter sind so gewählt, dass eine PIN, die kurz genug ist, um sie am Telefon vorzulesen, dennoch teuer durchzuprobieren ist, und der Pfeffer ist das, was eine gestohlene Datenbank für sich allein unzureichend macht — weshalb seine Offenlegung so ernst genommen wird wie die Offenlegung der Nachrichten.

In der administrativen API hasht es Kontopasswörter. Beide Instanzen kosten 19 MiB je Ableitung, weshalb beide Pfade ratenbegrenzt sind: Ein unauthentifizierter Angreifer, der frei wiederholen könnte, würde Speicher so schnell verbrauchen, wie er Rateversuche verbraucht.

86.3. Anwendbare, noch nicht implementierte RFCs¶

Diese Standards liegen im Aufgabenbereich eines MTA oder eines Krypto-Gateways, sind aber nicht implementiert, manche davon per Entscheidung. Mehrere sind auf eine bestimmte Weise teilweise umgesetzt: Ein Statusobjekt existiert und wird gemeldet, was man leicht für eine durchgeführte Prüfung hält.

RFC	Titel	Status in Pepsi
RFC 3030	`BINARYMIME`-Wert für den Nachrichtentext	`CHUNKING`/`BDAT` wird unterstützt, aber `BODY=BINARYMIME` wird nicht angekündigt oder angenommen.
RFC 6960	Online Certificate Status Protocol (OCSP)	Nicht implementiert, und dies ist das, was am ehesten falsch gelesen wird. `pepsi-crypto::trust` trägt auf jedem validierten Pfad einen `Revocation`-Status, aber er ist immer nur `NotChecked` — kein OCSP-Responder wird abgefragt und keine CRL (RFC 5280 §5) abgeholt. Ein widerrufenes S/MIME-Zertifikat validiert daher weiterhin. Der dreiwertige Status existiert, damit ein Bericht „wir haben nicht geprüft“ sagen kann, statt „nicht widerrufen“ zu implizieren; lesen Sie ihn nicht als eine geschehene Prüfung.
RFC 2634	Enhanced Security Services für S/MIME (Triple Wrapping)	Nicht ausgegeben, per Entscheidung: Pepsi signiert und verschlüsselt dann (die Signatur liegt innerhalb des Chiffrats), nie signieren-verschlüsseln-signieren. Eine eintreffende dreifach verpackte Nachricht wird geöffnet (RFC 8551 §3.7), und ihre innere Signatur ist die maßgebliche. Signierte Empfangsbestätigungen und Sicherheitslabels fehlen.
RFC 3161	Time-Stamp Protocol (TSP)	Nicht implementiert. Das S/MIME-Attribut `signingTime` ist die eigene Behauptung des Signierers; sie wird auf die Gegenwart geklemmt, sodass sie nicht vordatiert werden kann, aber eine rückdatierte Behauptung ist von einer wirklich alten Nachricht nicht zu unterscheiden. Eine Installation, die „signiert, als es behauptet“ braucht, benötigt ein Zeitstempel-Token, das Pepsi weder erzeugt noch verlangt.
RFC 6541	DKIM Authorized Third-Party Signatures (ATPS)	Nicht implementiert. Das vendorte `mail-auth` parst die Tags `atps=` und `atpsh=` eines `DKIM-Signature`-Felds, führt aber, für Pepsi gepatcht, keine ATPS-Abfrage durch: Die Tags werden ignoriert und das Ergebnis der Signatur ist ihr eigenes, sodass ein fehlender oder unerreichbarer ATPS-Eintrag eine gültige Signatur nicht in einen Fehler verwandeln kann. Keine Richtlinie zieht ATPS heran.
RFC 6651	Erweiterungen von DKIM für Fehlschlagsberichte	Nicht implementiert. Das `r=`-Tag wird geparst; es wird nie ein Fehlschlagsbericht erzeugt oder gesendet.
RFC 5321	`ETRN` / bedarfsgesteuertes Starten der Warteschlange	Nicht implementiert und nicht geplant. Pepsis Warteschlange ist eine Datenbanktabelle, die der Dispatcher leert; es gibt keine Warteschlange je Domain, die freizugeben wäre.
Autocrypt Level 1	Gossip-Peer-Zustands-Beförderung (§5.3)	Beide Hälften des Gossips sind implementiert, aber eine Feinheit des Peer-Zustandsmodells nicht: Level 1 erlaubt einem Client, einen gegossipten Schlüssel zu befördern, wenn der Eigentümer der Adresse ihn später bestätigt, und Pepsi hat keinen solchen Übergang. Eine besser belegte Antwort ersetzt den gegossipten Datensatz rundweg (was die sichere Richtung ist), und bis eine eintrifft, bleibt der Schlüssel auf der `gossip`-Sprosse, wie viele Nachrichten ihn auch einführen. Es geht nichts verloren, was ein echter `Autocrypt:`-Header nicht in einer Nachricht behöbe.