85.1.6. pepsi-stage-encrypt

sign outgoing mail as its author and encrypt it to each recipient

Handbuchabschnitt:

1

85.1.6.1.1. Name

pepsi-stage-encrypt - die ausgehende Ende-zu-Ende-Signier- und Verschlüsselungs-Stage der Pepsi-Pipeline.

85.1.6.1.2. Übersicht

pepsi-stage-encrypt [GLOBAL-OPTIONS] worker

85.1.6.1.3. Beschreibung

pepsi-stage-encrypt ist ein Stage-Programm, das von pepsi-dispatch(1) als persistenter Worker ausgeführt wird, der Nachrichten-IDs von der Standardeingabe liest. Für jede lokal eingelieferte Nachricht entscheidet es, welcher Schutz anzuwenden ist, wendet ihn an und routet jeden Empfänger weiter.

Der Name untertreibt die Stage: Sie signiert ebenso, wie sie verschlüsselt, und zwar in dieser Reihenfolge (Signatur innen, Verschlüsselung außen). Signiert wird mit dem Schlüssel des From:-Autors, nie mit dem des Umschlagabsenders — die Signatur handelt von dem Autor, den der Empfänger sieht, und eine Signatur, deren Identität nicht passt, ist das, was Verifizierer beanstanden. Ist die From:-Adresse keine, die diese Installation bedient, oder hält sie kein Signiermaterial, wird die Nachricht unsigniert gesendet statt gebounct: Ein nicht bedienbarer Autor ist immer noch legitime Mail, und DKIM trägt den Anspruch auf Domainebene bereits.

Verschlüsselt wird je Empfänger. Jeder Empfänger, der Chiffrat bekommt, bekommt sein eigenes Chiffrat und seinen eigenen Warteschlangendatensatz: keine Offenlegung der Empfängerliste, kein zwischen Empfängern geteilter Inhaltsschlüssel, und ein Bcc-Leck ist strukturell unmöglich. S/MIME-Empfänger in ein einziges EnvelopedData zu gruppieren wäre billiger und ist der Zweck des Formats, aber es offenbart jedem Empfänger die Empfängermenge und lässt einen kompromittierten Schlüssel die Nachricht für alle öffnen.

Die Stage betreibt überhaupt keine Netzwerk-E/A. Ein Empfänger, dessen Schlüssel nicht im Cache ist, pausiert die Nachricht und reiht eine Entdeckungsanfrage ein; ein pepsi-keydisc(1)-Dienst gibt sie frei, wenn sich die Anfrage erledigt, ob ein Schlüssel gefunden wurde oder nicht. Ein Empfänger mit einem frischen negativen Cache-Eintrag nimmt sofort den Schlüssellos-Pfad, ohne Pause, denn es gibt nichts, worauf zu warten wäre.

Eine Nachricht, die diese Installation nicht erzeugt hat (kein state.local_origin), wird unberührt weitergeschaltet. Eine weitergeleitete Drittnachricht zu verschlüsseln entwertete die DKIM-Signatur und die ARC-Kette des Urhebers, und sie als einen unserer Benutzer zu signieren wäre eine Lüge. Ihre X-Pepsi-*-Anforderungs-Header werden dennoch entfernt, sodass ein außenstehender Absender Pepsis eigenen Steuerkanal nicht auf der Leitung hinterlassen kann.

Warnung

Setzen Sie diese Stage vor pepsi-stage-dkim-sign(1), nicht danach.

Die empfohlene ausgehende Kette ist:

submission -> ... -> encrypt -> srs -> dkim-sign -> relay

DKIM muss die tatsächlich übertragenen Bytes signieren. Läuft die DKIM-Signierung zuerst, schreibt diese Stage den Nachrichtentext unter der Signatur um, und das Ergebnis ist Mail, die vollkommen gültig aussieht und deren Signatur nicht verifiziert — was schlimmer ist als gar keine Signatur, denn eine kaputte Signatur ist für einen Empfänger ein stärkeres negatives Signal als eine fehlende. pepsi-setup(1) warnt, wenn es eine DKIM-Signier-Stage findet, die zu dieser führt.

Zwei weitere Nachbarn wollen Klartext und bekommen ihn: Die Pay-to-Send-Schranke (pepsi-stage-anti-spam(1)) und die Spracherkennung (pepsi-stage-detect-language(1)) lesen den Nachrichtentext, und auf dem ausgehenden Pfad laufen sie vor dieser Stage. Deshalb kommt die Verschlüsselung zuletzt.

85.1.6.1.3.1. Richtlinienauflösung

Welchen Schutz eine Nachricht verlangt, wird aus vier Eingaben aufgelöst, die spezifischste zuerst:

1. die state.local_origin-Schranke — nichts darunter gilt für eine Nachricht, die wir bloß weiterleiten;

2. die Anforderungs-Header, die ein Add-in gesetzt hat (X-Pepsi-Sign, X-Pepsi-Encrypt, jeweils yes / no / required);

3. ein Betreff-Schlüsselwort (SUBJECT_KEYWORDS_SIGN / _ENCRYPT / _BOTH);

4. die [stage-encrypt]-Standardwerte SIGN und ENCRYPT, die eine etwaige Überschreibung je Adresse aus der Tabelle pepsi.settings bereits tragen.

Die beiden Anforderungs-Header werden aus der ausgehenden Nachricht entfernt, was auch immer sie sagen und worauf auch immer STRIP_REQUEST_HEADERS gesetzt ist: Ein Steuerkanal, der auf die Leitung überlebt, ist ein Steuerkanal, dem der nächste Hop zu gehorchen angewiesen werden kann. Ein getroffenes Betreff-Schlüsselwort wird ebenso aus dem Subject entfernt.

Ein verschlüsselndes Betreff-Schlüsselwort (SUBJECT_KEYWORDS_ENCRYPT oder _BOTH) oder ein X-Pepsi-Encrypt: required-Header hebt die Richtlinie für diese Nachricht auf required, und required fällt nie auf Klartext zurück — sagt das aufgelöste ON_NO_KEY cleartext, wird es für diese Nachricht auf den Secure Link (oder einen Bounce) angehoben. Ein Benutzer, der ausdrücklich um Schutz gebeten hat, wird nicht stillschweigend ignoriert.

Mit ENABLE_PEP = no wird Schlüsselmaterial nur erzeugt, wenn eine Nachricht danach verlangt: bei einer ausdrücklichen Anforderung jeglicher Art (X-Pepsi-Sign/X-Pepsi-Encrypt mit einem anderen Wert als no oder ein beliebiges Betreff-Schlüsselwort – ein [encrypt]-Schlüsselwort unter SIGN = no eingeschlossen) oder bei SIGN = always, sofern nicht X-Pepsi-Sign: no die Signatur abgelehnt hat. Ist [pepsi-crypto] AUTO_CREATE_IDENTITY an, ist ein KEY_WRAP_SECRET konfiguriert, gehört die From:-Domain zu [pepsi-ingress] ACCEPTED_DOMAINS und hat der Autor keinerlei Identität, wird inline eine erzeugt, im Protokoll des Empfängerschlüssels, wenn die Nachricht verschlüsselt wird, und sonst im Protokoll von PREFER. Eine Adresse, die bloß in einem Umschlag auftauchte, löst das nie aus, sodass ein Benutzer, der die Funktion nie nutzt, nie Schlüsselmaterial hat und nie dadurch exponiert wird. Unter dem Standardwert ENABLE_PEP = yes wird ein Schlüssel stattdessen bei der ersten Einlieferung des Absenders erzeugt, ob angefordert oder nicht; siehe Die pEp-Voreinstellung weiter unten.

Wie auch immer sie erzeugt wird, der Eigentümer der Identität ist das passwd-Login, zu dem LOCAL_DOMAINS, TARGETS und RECIPIENT_DELIMITER aus [pepsi-crypto] die Adresse auflösen, genau wie bei pepsi-keys(1); keiner, wenn die Adresse eine Rollenadresse oder eine gehostete Domain ist.

In jedem Fall wird die automatische Erzeugung für eine Adresse verweigert, die bereits eine crypto_identity-Zeile irgendeiner Art hat – einen vom Benutzer registrierten MUA-Schlüssel, einen importierten reinen öffentlichen Schlüssel oder einen widerrufenen Schlüssel. Ein [sign]-Schlüsselwort von einem Benutzer, der seinen eigenen Schlüssel mitgebracht hat, erzeugt daher nicht hinter seinem Rücken einen zweiten Schlüssel; ein Benutzer, der neben seinem eigenen einen vom Server verwalteten Schlüssel möchte, fordert ihn ausdrücklich an (mit dem Befehl generate weiter unten, mit pepsi-keys identity generate oder über die Web-Konsole).

Ein Schlüssel, der erzeugt werden sollte und nicht erzeugt werden kann – die Datenbank verweigert den Schreibvorgang, die Erzeugung selbst schlägt fehl –, wird auf Stufe warn protokolliert, und die Nachricht wird wie bei einer Adresse ohne Schlüssel weiterbehandelt: Ihre Richtlinie entscheidet, ob sie unsigniert verschickt oder abgelehnt wird. Der Benutzer hat nicht darum gebeten, dass der Schlüssel erzeugt wird, und seine Mail wegen eines kaputten Schlüsselspeichers als Geisel zu halten, ist schlimmer, als sie ohne einen zu verschicken. (Eine Installation ohne KEY_WRAP_SECRET erzeugt überhaupt keine Schlüssel und ist nicht betroffen.) Das Registrieren des Schlüssels, den der Client eines Benutzers ankündigt, erfolgt auf dieselbe Weise nach bestem Bemühen.

Sobald ein Signierschlüssel existiert und nicht geöffnet werden kann (ein unlesbarer Schlüsselverschlüsselungsschlüssel, eine entzogene Berechtigung), wird die Nachricht nicht unsigniert verschickt: Dieser Fehler wird bis zur MAX_LIFETIME der Stage erneut versucht (siehe pepsi-dispatch(1)), wie jeder andere Fehler dieses Hosts, da unsigniertes Versenden eine kaputte Installation verbergen würde. Der Abschnitt der Stage, die [pepsi]-Krypto-Richtlinie, [pepsi-keydiscovery] und, wenn ein Schlüsselverschlüsselungsschlüssel konfiguriert ist, der daraus gebaute Schlüsselbund werden beim Start des Workers geprüft: Funktioniert einer davon nicht, verweigert der Worker den Start (Exit 78), und der Dispatcher hält die Warteschlange zurück, bis er korrigiert ist.

85.1.6.1.3.2. Die pEp-Voreinstellung

ENABLE_PEP (Standard yes) lässt die Stage sich wie das Projekt pretty Easy privacy (pEp) verhalten: Jeder lokale Absender erhält einen Schlüssel, Mail wird verschlüsselt, sobald der Schlüssel eines Empfängers bekannt oder auffindbar ist, und der öffentliche Schlüssel des Absenders geht mit jeder Nachricht hinaus. Es ist eine Voreinstellung von Standardwerten, kein erzwingender Modus: Sie ändert die Standardwerte anderer Optionen, und jede Option, die ausdrücklich im Abschnitt (oder in einer adressbezogenen pepsi.settings-Überschreibung) angegeben ist, hat weiterhin Vorrang.

Verhalten	ENABLE_PEP = yes	ENABLE_PEP = no
Standardwert von SIGN	encrypted-only	opportunistic
Schlüsselerzeugung	sofort (erste Einlieferung)	auf Anforderung oder bei SIGN = always
Standardwert von ENCRYPT	opportunistic	opportunistic
Standardwert von AUTOCRYPT	yes	yes
ATTACH_KEYS_AS_FILES	no (unabhängig)	no (unabhängig)

Die Voreinstellung betrifft nur Mail, die Benutzer senden: Unter ihr wird Klartext-Mail eines Benutzers, der einen Schlüssel besitzt, von Pepsi nicht signiert, und Absender erhalten Schlüssel, um die sie nicht gebeten haben. Was jemand empfangen kann, hängt nicht von ihr ab: Eingehende Mail wird in beiden Fällen gleich behandelt.

Die üblichen Übertragungsformate bleiben unverändert: Die Nachrichten sind gewöhnliches PGP/MIME und Autocrypt. Es gibt keine X-pEp-Version-Header, keine pEp-2.x-Nachrichtenverpackung, keine Trustwords oder Handshakes und keine Schlüsselsynchronisation zwischen Geräten, und die Voreinstellung ändert PROTECT_HEADERS nicht.

Sofortige Schlüsselerzeugung. Bei jeder festgeschriebenen lokal eingelieferten Nachricht – dem Klartext-Durchlauf ebenso wie dem geschützten Weg, damit bereits die erste Nachricht den neuen Schlüssel in ihrem Autocrypt:-Header trägt – erzeugt die Stage einen OpenPGP-MTA-Schlüssel für die From:-Adresse, wenn all dies zutrifft:

• ENABLE_PEP ist für die Nachricht eingeschaltet (es ist je Adresse überschreibbar);

• die From:-Domain ist eine der [pepsi-ingress] ACCEPTED_DOMAINS: Ein Schlüssel wird nur für eine Adresse erzeugt, deren eingehende Mail über diese Installation läuft, was es pepsi-stage-decrypt(1) ermöglicht, an sie verschlüsselte Antworten zu öffnen;

• [pepsi-crypto] AUTO_CREATE_IDENTITY ist eingeschaltet – das Veto des Operators, das keine adressbezogene Einstellung überschreiben kann;

• ein [pepsi-crypto] KEY_WRAP_SECRET ist konfiguriert;

• die Adresse hat keine crypto_identity-Zeile irgendeiner Art, unabhängig von Status, Protokoll oder Verwahrung. Ein widerrufener Schlüssel zählt: Wenn jemand einen Schlüssel widerrufen hat, erzeugt Pepsi nicht stillschweigend einen Ersatz.

Das gilt für jeden Einlieferungsweg, einschließlich mynetworks- und client-cert-Relays, sodass ein Pepsi, das als Proxy hinter einem MTA eingesetzt wird, der die Benutzer authentifiziert, genauso funktioniert. Eine Webanwendung, die als noreply@ einer Domain sendet, für die Pepsi keine Mail empfängt, erhält keinen Schlüssel. Zwei Worker, die gleichzeitig denselben erstmaligen Absender sehen, speichern genau einen Schlüssel: Test und Einfügen laufen unter einer adressbezogenen Sperre in der SQL-Funktion crypto_identity_create_if_absent, und der Verlierer verwirft, was er erzeugt hat. Ein automatisch erzeugter Schlüssel wird als auto_created markiert, über den eigenen WKD der Installation veröffentlicht und niemals auf einen Schlüsselserver hochgeladen, sofern sein Besitzer nicht darum bittet (vks_wanted = false; siehe pepsi-keys(1)).

SIGN = encrypted-only (der Standardwert der Voreinstellung) signiert eine Nachricht nur, wenn diese Stage sie verschlüsselt, und dann innerhalb des Chiffrats. Klartext-Mail trägt den Schlüssel des Absenders (den Autocrypt:-Header, dazu die Schlüsseldatei, wenn ATTACH_KEYS_AS_FILES eingeschaltet ist), aber keine Signatur, sodass ein Empfänger, der keine Kryptographie verwendet, nie eine signature.asc sieht. Eine ausdrückliche Anforderung (X-Pepsi-Sign: yes, ein [sign]-Schlüsselwort im Betreff) signiert Klartext weiterhin. Mit SIGN = opportunistic bleibt unter der Voreinstellung das Verhalten „alles signieren“ erhalten.

Die erste Nachricht an einen neuen Korrespondenten kann weiterhin bis zu DISCOVERY_TIMEOUT auf die Schlüsselentdeckung warten und dann im Klartext hinausgehen; die Voreinstellung ändert die Entdeckung nicht.

85.1.6.1.3.3. Zwei Schlüssel pro Benutzer: MTA-Schlüssel, MUA-Schlüssel und das öffentliche Gesicht

Eine Adresse kann zwei Arten von Identität haben:

MTA-Schlüssel

custody = local: Pepsi hält die private Hälfte (verpackt in crypto_identity.private_wrapped). Pepsi signiert, entschlüsselt und bewirbt damit. Automatisch erzeugt, auf Anforderung erzeugt oder mit seiner privaten Hälfte importiert.

MUA-Schlüssel

custody = client: der eigene Schlüssel des Benutzers, dessen private Hälfte nur in seinem Mailprogramm liegt. Die Zeile bleibt für immer rein öffentlich. Pepsi verschlüsselt an ihn und erkennt an ihn verschlüsselte eingehende Mail, kann mit ihm aber niemals öffnen, signieren oder ihn bewerben.

Das öffentliche Gesicht einer Adresse ist der Schlüssel, den ein Korrespondent verwenden soll: der neueste aktive MUA-Schlüssel, wenn der Benutzer einen hat, andernfalls der primäre aktive MTA-Schlüssel, der noch seine private Hälfte besitzt. Der Autocrypt:-Header, die Schlüsseldatei, der WKD der Installation und die lokale Verschlüsselung lesen es alle über dieselbe Reihenfolge, sodass sie nicht voneinander abweichen können:

• WKD liefert nur den MUA-Schlüssel aus, wenn es einen gibt;

• Mail von einem lokalen Benutzer an einen anderen wird an das öffentliche Gesicht verschlüsselt;

• Pepsi fügt keinen Autocrypt:-Header hinzu und hängt keine Schlüsseldatei an, wenn das öffentliche Gesicht ein MUA-Schlüssel ist. Das Mailprogramm bewirbt seinen eigenen Schlüssel, und würde Pepsi auf einigen Nachrichten desselben Benutzers einen anderen bewerben, würde der Schlüsselzustand der Korrespondenten nach Autocrypts Regel „der neueste gewinnt“ hin- und herspringen.

Der MTA-Schlüssel wird nicht außer Dienst gestellt, wenn ein MUA-Schlüssel hinzukommt. Er entschlüsselt weiterhin Mail von Korrespondenten, die ihn noch verwenden, und er signiert weiterhin, innerhalb des Chiffrats, Klartext-Mail, die Pepsi im Auftrag des Benutzers verschlüsselt. Eingehende Mail, die an einen MUA-Schlüssel verschlüsselt ist, wird ungeöffnet an das Mailprogramm weitergereicht; siehe pepsi-stage-decrypt(1).

85.1.6.1.3.4. Den eigenen Schlüssel des Benutzers registrieren

Eine lokal eingelieferte Nachricht, deren From:-Adresse bei einer bedienten Domain liegt, kann den Schlüssel, den ihr Mailprogramm verwendet, als MUA-Schlüssel registrieren. Die Registrierung hängt nicht von ENABLE_PEP ab. Der Schlüssel wird entnommen aus:

1. dem einzigen gültigen Autocrypt:-Header der Nachricht, dessen addr= gleich der From:-Adresse sein muss; oder, falls es den nicht gibt,

2. einem angehängten application/pgp-keys-Teil, dessen User-IDs die Adresse nennen – aber nur für den allerersten Schlüssel der Adresse. Ein Anhang ist ein schwächeres Signal als ein Header, den das Mailprogramm verwaltet, daher wird ein zweiter Schlüssel nur aus Autocrypt: registriert.

Das geschieht nur, wenn der Einliefernde für die From:-Adresse sprechen darf, was strenger ist, als unter ihr senden zu dürfen: Die Nachricht kam von einem vertrauenswürdigen Relay (state.origin.auth_method ist mynetworks oder client-cert) oder von einem authentifizierten Konto (sasl, peercred), für das Ingress state.origin.from_bound = true festgehalten hat – das From: ist genau eine Mailbox, die zu einem konkreten, platzhalterfreien USERNAME_MAP-Eintrag des Kontos oder zu dessen Standard login@HOSTNAME passte. Ein Konto, dem ein Platzhalter gewährt wurde (*@example.org, *), darf als seine Kollegen senden, registriert aber niemals einen Schlüssel für sie.

Ein Fingerabdruck, den die Adresse bereits hat, ob außer Dienst gestellt oder nicht, wird nicht erneut registriert, sodass ein Schlüssel, den der Benutzer außer Dienst gestellt hat, nicht zurückkommt, weil ein altes Gerät ihn noch sendet. Ein neuer MUA-Schlüssel wird mit vks_wanted = false gespeichert und wird sofort zum öffentlichen Gesicht. Hatte die Adresse bereits eine andere Identität, erhält der Benutzer bei RESPONSE_STAGE eine Benachrichtigung mit Null-Absender (Auto-Submitted: auto-generated, die Vorlage key-registered.<lang>.body), die den Fingerabdruck nennt und erklärt, wie er außer Dienst gestellt wird – damit ein mit einem gestohlenen Passwort hinzugefügter Schlüssel nicht unbemerkt bleibt. Ohne RESPONSE_STAGE wird der Schlüssel trotzdem registriert, aber es kann keine Benachrichtigung gesendet werden. Die Nachricht selbst geht, abgesehen von der üblichen Header-Hygiene, unverändert weiter.

Eine Adresse, die einen zweiten Faktor registriert hat (otp enroll, unten), registriert auf diesem Weg nichts: Eine Nachricht kann keinen Code tragen, und genau diesen Weg würde ein gestohlenes Passwort nutzen. Ihr Inhaber registriert einen neuen Schlüssel stattdessen mit register CODE.

85.1.6.1.3.5. Vom Mailprogramm bereits geschützte Mail

Nur die äußerste Schicht der eingelieferten Nachricht wird berücksichtigt:

Bereits verschlüsselt

PGP/MIME, ein umhülltes S/MIME-application/pkcs7-mime, ein Inline------BEGIN PGP MESSAGE, eine um Chiffrat gelegte Signatur oder alles, was kein Klassifizierer erkennen konnte. Die Stage verschlüsselt, signiert und hängt nichts an und fügt keinen Autocrypt:-Header hinzu. Header-Hygiene und die obige Registrierung von MUA-Schlüsseln laufen weiterhin. state.crypto.out.client_protected = true wird festgehalten.

Bereits signiert (multipart/signed, Inline-PGP-signiert)

Die Stage kann sie weiterhin verschlüsseln, als encrypted(signed), fügt aber keine eigene Signatur und keine Klartext-Schlüsseldatei hinzu.

Eine weitergeleitete verschlüsselte Nachricht, die als message/rfc822 angehängt ist, ist der Schutz eines anderen und zählt nicht.

85.1.6.1.3.6. Den Schlüssel als Datei anhängen

ATTACH_KEYS_AS_FILES (Standard no, unabhängig von der Voreinstellung) hängt den öffentlichen Schlüssel des Absenders zusätzlich zum Autocrypt:-Header auch auf die klassische OpenPGP-Art an, für Korrespondenten, deren Mailprogramm kein Autocrypt liest. Der Teil ist application/pgp-keys, heißt OpenPGP_0x<long key ID>.asc (die letzten 16 Hexziffern des Fingerabdrucks, der Name, den Thunderbird verwendet) und enthält dasselbe minimale Zertifikat, das der Header trägt, ASCII-armiert.

• Auf dem verschlüsselnden Weg kommt er in das Chiffrat, platziert wie Gossip.

• Auf dem Klartext-Weg wird die festgeschriebene Nachricht in ein neues multipart/mixed verpackt, das die ursprüngliche Entität und den Schlüsselteil enthält, oder der Schlüssel wird ein weiterer Teil eines bestehenden multipart/mixed. Die Stage läuft vor pepsi-stage-dkim-sign(1), sodass die DKIM-Signatur der Installation das Ergebnis abdeckt.

• Er wird angehängt, bis jeder Empfänger der Zeile nachweislich den Schlüssel besitzt (der pepsi.peer_has_own_key-Eintrag, den pepsi-stage-autocrypt-learn(1) schreibt, wenn ein Korrespondent eine verschlüsselte und signierte Antwort sendet). Der Eintrag ist nach dem Fingerabdruck geschlüsselt, sodass ein neuer Schlüssel wieder angehängt wird. Eine Klartext-Zeile mit mehreren Empfängern wird dafür nicht aufgeteilt: Der Schlüssel geht an alle, wenn irgendeinem Empfänger der Nachweis fehlt.

• Niemals, wenn das öffentliche Gesicht ein MUA-Schlüssel ist, niemals an eine Nachricht, die das Mailprogramm verschlüsselt hat, und nicht an Klartext, den das Mailprogramm signiert hat. Eine Nachricht, die bereits die Datei des Schlüssels trägt, erhält keine zweite.

state.crypto.out.key_attached = true hält fest, dass die Datei hinausging.

85.1.6.1.3.7. Die eigenen Schlüssel per E-Mail verwalten

Ist RESPONSE_STAGE gesetzt und KEYS_CONTROL_LOCAL_PART nicht none, ist eine lokal eingelieferte Nachricht, deren einziger Empfänger <KEYS_CONTROL_LOCAL_PART>@<served domain> ist (Standard pepsi-keys@), ein Schlüsselbefehl. Sie wird verbraucht – gelöscht, nie weitergeleitet – und bei RESPONSE_STAGE mit der Vorlage keys.<lang>.body beantwortet, die die Schlüssel der Adresse auflistet. Der Befehl ist der Subject:, ohne Beachtung der Groß-/Kleinschreibung, wobei Re:/Fwd:-Präfixe ignoriert werden:

status

Die Schlüssel der Adresse auflisten: Art (vom Server verwaltet oder der eigene des Benutzers), Status, Schlüsselserver-Zustand und welcher an Korrespondenten gegeben wird.

generate

Einen vom Server verwalteten OpenPGP-MTA-Schlüssel erzeugen. Auf Anforderung immer erlaubt, auch neben dem eigenen Schlüssel des Benutzers oder einem widerrufenen. Sein Hochladen auf den Schlüsselserver wird angefordert, wenn [pepsi-keys] VKS_PUBLISH eingeschaltet ist.

register

Den Schlüssel im Autocrypt:-Header dieser Nachricht oder in ihrer angehängten Schlüsseldatei als eigenen MUA-Schlüssel des Benutzers registrieren.

publish [FPR]

Ein Hochladen auf den Schlüsselserver anfordern (und über WKD veröffentlichen), standardmäßig für das öffentliche Gesicht. Nur ein aktiver OpenPGP-Schlüssel kann hochgeladen werden. Das Hochladen selbst erfolgt beim nächsten Lauf von pepsi-keys identity publish --retry und kann nicht rückgängig gemacht werden.

retire FPR

Einen Schlüssel widerrufen; so wird auch ein fälschlich registrierter MUA-Schlüssel entfernt.

otp enroll

Einen zweiten Faktor für diese Befehle registrieren (oder ersetzen): ein TOTP-Geheimnis (RFC 6238, SHA-1, sechs Ziffern, 30-Sekunden-Schritte). Die Antwort enthält es einmal – als otpauth://-URI, in base32 und als angehängten QR-Code (second-factor.png) für eine Authenticator-App – und sollte gelöscht werden, sobald das Geheimnis in der App ist. Einen bestehenden zu ersetzen erfordert dessen aktuellen Code. Da sie die einzige Kopie des Geheimnisses ist, wird die Antwort in einer Transaktion mit dem Geheimnis committet, das sie trägt, und vor beidem gerendert: Kann sie nicht erstellt oder eingereiht werden, wird nichts gespeichert, der bisherige zweite Faktor bleibt, wie er war, und der Befehl wird erneut versucht.

otp remove

Den zweiten Faktor entfernen; erfordert dessen aktuellen Code. otp allein (oder otp status) ist status.

Bei registriertem zweitem Faktor muss jeder Befehl außer status den aktuellen Code der App tragen: ein Wort aus genau sechs Ziffern irgendwo im Subject: (register 123456; otp=123456 wird ebenfalls akzeptiert). Ein Befehl ohne Code wird abgelehnt und nicht gezählt. Ein falscher Code oder ein bereits verwendeter Code (ein Code ist einmal gültig) zählt als Fehlschlag, und ein richtiger setzt den Zähler zurück; nach zehn Fehlschlägen in Folge ist der zweite Faktor gesperrt, und jeder Befehl außer status wird abgelehnt, bis der Operator ihn zurücksetzt (pepsi-keys otp reset). Das Geheimnis wird unter dem Schlüsselverschlüsselungsschlüssel des Schlüsselspeichers verpackt und ist nur für die Rolle pepsi-crypto lesbar; siehe pepsi-keys(1). Die Antwort auf status sagt, ob die Adresse einen hat und ob er gesperrt ist.

Ein Befehl wird einmal beantwortet. Eine Befehlsnachricht, deren Antwort bereits eingereiht ist (ein früherer Durchlauf hat sie ausgeführt und wurde unterbrochen, bevor er sie verbrauchte), wird nur noch verbraucht, sodass eine Wiederholung nie einen Befehl wiederholt – insbesondere nie ein zweites Geheimnis hinter der Antwort erzeugt, die das erste trägt. Ein Befehl, der aus einem Grund dieses Servers fehlschlägt, wird mit einem allgemeinen „später erneut versuchen“ beantwortet; der Fehler selbst steht im Log, nicht in der Mail.

FPR ist der vollständige Fingerabdruck oder mindestens seine letzten 16 Hexziffern, als ein Wort geschrieben (ein 0x-Präfix wird akzeptiert); da er mindestens 16 Ziffern hat, wird er nie mit einem Code verwechselt. list, upload und revoke werden für status, publish und retire akzeptiert, und 2fa/totp für otp; jeder andere Betreff wird mit der Schlüsselliste und den gültigen Befehlen beantwortet. Der Befehl wirkt auf die From:-Adresse, und nur, wenn der Einliefernde für sie sprechen darf (siehe Den eigenen Schlüssel des Benutzers registrieren); andernfalls, und für eine Adresse bei einer Domain, die die Installation nicht bedient, sagt die Antwort, dass die Anfrage abgelehnt wurde. Ohne RESPONSE_STAGE gibt es keinen Ort für eine Antwort, daher ist diese Schnittstelle abgeschaltet und eine solche Nachricht wird wie jede andere weitergesendet.

85.1.6.1.3.8. Den Schlüssel des Empfängers wählen

Normalerweise stammt der Schlüssel aus dem pepsi.peer_key-Cache, bestbewertete Quelle zuerst und vorbehaltlich MIN_TRUST — siehe pepsi.conf(5) und pepsi-keydisc(1).

Es gibt eine Ausnahme, und sie ist eine Sicherheitsgrenze und keine Optimierung. Hält diese Installation eine ``active``-Identität für den Empfänger, wird dieser Schlüssel verwendet, und es wird überhaupt kein ``peer_key``-Datensatz für die Adresse herangezogen — gleich welchen Rangs und gleich wie er eintraf. state.crypto hält die Quelle als own fest.

Der Grund ist, dass peer_key teilweise durch das Ernten eingehender Mail gefüllt wird, und das Ernten stützt sich auf den vom Absender geschriebenen From:-Header. Die eingehende Authentifizierung ist bewusst fail-open, sodass eine Nachricht, die vorgibt, von einem der eigenen Benutzer dieser Installation zu stammen, für diesen Benutzer einen Peer-Schlüssel mit dem Schlüssel eines Fremden darin säen kann; ohne die Ausnahme würde Mail von einem lokalen Benutzer an einen anderen dann an den untergeschobenen Schlüssel verschlüsselt und sähe genau wie Erfolg aus.

Die Regel hängt daran, einen Schlüssel zu halten, nicht daran, die Adresse zu bedienen. Ein Benutzer, der seinen eigenen OpenPGP-Client betreibt und hier nie einen Schlüssel hochgeladen hat, hat keine Identität, und sein echter Schlüssel ist einer, den dieser Host nur durch Entdeckung, Ernte oder Gossip lernen kann — die Ausnahme gilt also nicht für ihn. Siehe Die Schlüssel unserer eigenen Benutzer werden nicht entdeckt im Handbuch für den vollständigen Kompromiss, einschließlich seines Preises: Eine mit dem separaten persönlichen Schlüssel eines Benutzers erstellte Signatur lässt sich nicht mehr verifizieren, sobald für diese Adresse eine Identität gehalten wird.

Dieselbe Bevorzugung gilt für die untenstehenden Gossip-Felder: Ein Subjekt von uns wird mit dem Schlüssel vorgestellt, den wir ihm ausgestellt haben, nie mit einem, den jemand untergeschoben hat.

85.1.6.1.3.9. Empfängerergebnisse

Je Empfänger genau eines von:

encrypted

Ein brauchbarer Schlüssel wurde gefunden (vorbehaltlich MIN_TRUST), und die Nachricht wurde daran verschlüsselt. Der tatsächlich ausgegebene Container wird festgehalten, zusammen mit der Angabe, ob es eine Herabstufung vom AES-256-GCM-Standardwert war.

signed-only

Kein brauchbarer Empfängerschlüssel, die Richtlinie erlaubt gewöhnliche Mail, und die Signatur des Autors wurde angebracht.

cleartext

Weder signiert noch verschlüsselt.

secure-link

Zu SECURE_LINK_STAGE geroutet, statt gesendet zu werden.

bounced

Verschlüsselung war erforderlich und konnte nicht angewandt werden; zu BOUNCE_STAGE geroutet mit erweitertem Status 5.7.0 nach RFC 3463. Ohne BOUNCE_STAGE wird die Nachricht als fehlgeschlagen markiert, statt ungeschützt gesendet zu werden.

oversize

Die Nachricht war größer als MAX_SIZE und nahm den ON_OVERSIZE-Weg.

Wenn die Empfänger einer Nachricht nicht alle ein Ergebnis teilen, teilt die Stage sie auf je einen Datensatz auf (das state.dsn.rcpt jedes Datensatzes wird im Gleichschritt mit seinem rcpt_to zerteilt) und gibt die Nachricht an die Warteschlange zurück; jeder Datensatz betritt diese Stage dann allein erneut. Eine Nachricht, deren Empfänger alle ein Ergebnis teilen — der häufige Fall „niemand hat einen Schlüssel, sende sie wie üblich“ —, wird nie aufgeteilt.

Jedes Ergebnis, das ungeschützten Inhalt auf die Leitung bringt, während Verschlüsselung gewünscht war, wird auf WARN protokolliert und je Empfänger in state festgehalten. Klartext zu senden ist nie ein stillschweigendes Ergebnis.

85.1.6.1.3.10. Autocrypt-Schlüsselankündigung

Sofern AUTOCRYPT nicht abgeschaltet ist, verlässt jede lokal eingelieferte Nachricht diese Stage mit einem Autocrypt:-Header, der den eigenen OpenPGP-Schlüssel des From:-Autors ankündigt:

Autocrypt: addr=alice@example.org; prefer-encrypt=mutual;
 keydata=xjMEZ8kAABYJKwYBBAHaRw8BAQdA…

Das geschieht bei jeder Nachricht — signiert, verschlüsselt, zum Secure Link geroutet oder schlichter Klartext. Der Durchreichefall ist der, auf den es ankommt: Ein Korrespondent muss den Schlüssel aus gewöhnlicher Mail lernen können, denn bis er ihn hat, gibt es nichts, womit zu verschlüsseln wäre. Nur auf bereits geschützter Mail anzukündigen erzählte den Schlüssel genau denen, die ihn schon kennen.

Der angekündigte Schlüssel ist der minimale übertragbare öffentliche Schlüssel von Autocrypt Level 1 §2.1.1 — Primärschlüssel, primäre User-ID, deren Selbstsignatur, ein Transport-Verschlüsselungs-Unterschlüssel und dessen Bindungssignatur, und sonst nichts. Zusätzliche User-IDs, der Signier-Unterschlüssel und etwaige Drittzertifizierungen werden entfernt: Der Header reitet auf jeder Nachricht mit, seine Größe wird also wieder und wieder bezahlt, und Zertifizierungen erneut zu veröffentlichen veröffentlichte als Nebenwirkung des Mailversands den sozialen Graphen des Absenders.

Fünf Regeln begrenzen ihn:

• Nur OpenPGP. Autocrypt ist über einen übertragbaren öffentlichen OpenPGP-Schlüssel definiert und hat keine S/MIME-Form, sodass ein Absender, der nur eine X.509-Identität hält, nichts ankündigt.

• Nur lokal eingelieferte Mail, wie alles andere, was diese Stage tut.

• Nie über einen bestehenden Header. Ein echter Client (Thunderbird, K-9, Delta Chat) hat womöglich sein eigenes Autocrypt:-Feld gesetzt, das den Schlüssel benennt, dessen geheime Hälfte er hält. Dieses ist besser als unseres und bleibt unangetastet — und ein zweites Feld wäre schlimmer als nutzlos, denn Autocrypt Level 1 verwirft eine Nachricht mit zweien davon rundweg.

• Der Schlüssel muss hier noch zu öffnen sein. Angekündigt wird nur eine Identität, die ihr privates Material noch hält, sodass an einen angekündigten Schlüssel gesendetes Chiffrat stets Chiffrat ist, das pepsi-stage-decrypt(1) öffnen kann.

• Nur das öffentliche Gesicht. Hat der Benutzer seinen eigenen MUA-Schlüssel registriert, ist dieser das öffentliche Gesicht, und Pepsi bewirbt nichts; das Mailprogramm bewirbt seinen Schlüssel selbst. Eine Nachricht, die das Mailprogramm bereits verschlüsselt hat, erhält ebenfalls keinen Header.

prefer-encrypt=mutual wird nur ausgegeben, wenn das wirksame ENCRYPT der Stage required ist — auch wenn das aus einer pepsi.settings-Überschreibung je Adresse stammt, sodass ein Benutzer es ankündigen kann, ohne dass die Installation es tut. Nach Autocrypt Level 1 §2.4 aktiviert der Client eines Korrespondenten die Verschlüsselung standardmäßig nur, wenn beide Enden mutual sagen; es unter opportunistic zu beanspruchen, wo ON_NO_KEY = cleartext sagt, dass Klartext ein akzeptables Ergebnis ist, kündigte eine Präferenz an, die diese Installation nicht durchsetzt. Das Attribut wird dann weggelassen, was Level 1 als nopreference liest: Der Korrespondent hält den Schlüssel dennoch fest und bekommt Verschlüsselung weiterhin angeboten, nur nicht standardmäßig. Der Wert folgt dem konfigurierten Modus statt dem für eine einzelne Nachricht aufgelösten, sodass ein [secure]-Betreff-Schlüsselwort den Schlüsselzustand eines Korrespondenten nicht mit den Betreffzeilen unserer Benutzer schwingen lässt.

Da diese Stage vor pepsi-stage-dkim-sign(1) läuft, ist der Header von der eigenen DKIM-Signatur der Installation abgedeckt.

85.1.6.1.3.11. Autocrypt-Schlüssel-Gossip

AUTOCRYPT_GOSSIP (Standardwert NO) schaltet die andere Hälfte von Autocrypt Level 1 ein: Autocrypt-Gossip:-Felder, die die Schlüssel der anderen Empfänger ankündigen. Sie beantworten den Fall, den der obige Header nicht kann. Alice schreibt an Bob und Carol, die nie korrespondiert haben. Beide lernen Alices Schlüssel aus ihrem Autocrypt:-Header, aber keiner lernt den des anderen — sodass Bobs Antwort-an-alle nicht an Carol verschlüsselt werden kann, bis irgendeine spätere Nachricht sie zufällig vorstellt. Eine gegossipte Nachricht schließt diese Lücke:

Autocrypt-Gossip: addr=carol@example.org;
 keydata=xjMEZ8kAABYJKwYBBAHaRw8BAQdA…

Es ist standardmäßig aus, weil es eine andere Art von Handlung ist als AUTOCRYPT: Jenes veröffentlicht einen Schlüssel, dessen Eigentümer diese Installation gebeten hat, ihn zu halten, während dieses das Schlüsselmaterial Dritter — hier für unseren eigenen Gebrauch zwischengespeichert — an Korrespondenten weiterverteilt, die nie darum gebeten haben. Das ist die Entscheidung eines Operators.

Drei Regeln folgen aus der Spezifikation und eine aus der eigenen Form dieser Stage.

• Nur innerhalb eines Chiffrats. Level 1 §5.3 setzt diese Felder in den Header-Abschnitt des verschlüsselten Teils, und nicht als Nettigkeit: Ein äußeres Autocrypt-Gossip:-Feld veröffentlichte die Empfängermenge einer verschlüsselten Nachricht an jedes Relay auf dem Pfad, was das meiste von dem ist, wofür die Verschlüsselung da war. Also gibt es kein Gossip beim Klartext-Durchreichen, keines bei einer nur signierten Nachricht und keines in einem S/MIME-Container — Autocrypt ist über OpenPGP definiert und hat keine S/MIME-Form, sodass ein Gossip-Feld dort eine Weiterverteilung an eine Stelle wäre, an der kein Client nachsieht.

• Mehrere sind zu erwarten. Ein Feld je vorgestelltem Empfänger, in To:/Cc:-Reihenfolge — das Gegenteil von Autocrypt:, wo ein zweites Feld einen Level-1-Parser die Nachricht rundweg verwerfen lässt.

• Kein ``prefer-encrypt``. Das Attribut nennt die Richtlinie des Absenders, und diese Felder sprechen für jemand anderen. Eines im Namen eines Korrespondenten zu behaupten ist eine Aussage, für die diese Installation keine Berechtigung hat, und Level 1 lässt es aus demselben Grund aus der Gossip-Form heraus.

• Ein zwischengespeicherter Schlüssel oder gar nichts. Ein sichtbarer Empfänger, für den diese Installation keinen brauchbaren OpenPGP-Schlüssel hält, bleibt aus der Menge heraus. Die Stage betreibt für ihn keine Entdeckung und pausiert nie eine Nachricht, um den Schlüssel eines Dritten zu holen: Eine Vorstellung ist eine Höflichkeit, und die Mail des Absenders zu verzögern, um eine vorzunehmen, wäre keine. Die Untergrenze ist die strengere von MIN_TRUST und GOSSIP_MIN_TRUST (Standardwert owner-confirmed): Ein Schlüssel, der nicht gut genug gewesen wäre, um daran zu verschlüsseln, ist auch nicht gut genug, um weitergegeben zu werden, und standardmäßig wird ein Schlüssel, den diese Installation lediglich aus eingehender Mail geerntet hat — oder der ihr selbst per Gossip zugetragen wurde —, überhaupt nicht weiterveröffentlicht. Einem Korrespondenten einen Schlüssel vorzustellen, für den niemand bürgt, ist eine stärkere Behauptung, als ihn selbst zu verwenden.

Warnung

Eine Blindkopie wird nie gegossipt. Die Subjektadressen stammen aus den geparsten To:- und Cc:-Feldern der Nachricht und aus sonst nichts. Die Umschlagempfängerliste — die die Bcc-Empfänger sehr wohl enthält, denn das ist die gesamte Bedeutung einer Blindkopie — wird nur herangezogen, um eine Adresse aus der Menge zu entfernen (den eigenen Empfänger dieser Kopie und den From:-Autor).

Ein Bcc-Empfänger kann daher in keiner Kopie der Nachricht erscheinen, und die Zusicherung hängt nicht davon ab, dass ein Bcc:-Feld vorgelagert entfernt wurde: Das Feld wird überhaupt nicht gelesen. Level 1 §5.3 verlangt dasselbe von einem empfangenden Client, der einen Gossip-Header ignoriert, dessen addr kein To:/Cc:-Empfänger ist — ein solcher Header leckte also die Adresse und erreichte nichts.

Das Umgekehrte ist Absicht. Die eigene Kopie eines blinden Empfängers trägt sehr wohl Gossip über die To:/Cc:-Empfänger: Er hat diese Header-Felder wie alle anderen erhalten, es sagt ihm also nichts, was er nicht ohnehin lesen kann, und es ihm vorzuenthalten bräche Antwort-an-alle ausgerechnet für den Empfänger, der am unwahrscheinlichsten schon zuvor mit den anderen korrespondiert hat.

Eine Nachricht mit mehr als 50 sichtbaren Empfängern bekommt überhaupt kein Gossip. Jeder vorgestellte Schlüssel wird im eigenen Chiffrat jedes Empfängers wiederholt, sodass die Kosten mit dem Quadrat der Adressenzahl wachsen, und in dieser Größe ist die Nachricht eine Rundsendung, bei der niemand allen antworten wird. Beliebige fünfzig davon vorzustellen wäre eine stillschweigende Wahl ohne vertretbare Regel dahinter, also stellt die Stage keinen vor und sagt es im Journal.

85.1.6.1.3.12. Aushandlung des Inhaltsalgorithmus

Bei OpenPGP gibt das Zertifikat des Empfängers an, ob es RFC-9580-SEIPDv2/AEAD lesen kann; der größte Teil des installierten Bestands (GnuPG 2.4 und älter) kann es nicht. Unter [pepsi] CRYPTO_ALLOW_DOWNGRADE = negotiate (dem Standardwert) gibt die Stage SEIPDv1+MDC nur dann aus, wenn der eigene Schlüssel des Empfängers belegt, dass er es nicht besser kann, protokolliert das auf INFO und hält es fest — eine Herabstufung ist eine Tatsache über den Korrespondenten, kein Fehlschlag. Unter no wird derselbe Empfänger abgelehnt und fällt in ON_NO_KEY; siehe die Warnung unter dieser Option.

S/MIME hat nichts, wogegen es verhandeln könnte — ein X.509-Zertifikat kündigt keine Inhaltsverschlüsselungsfähigkeit an —, sodass es RFC-5083-AuthEnvelopedData ausgibt, sofern CRYPTO_ALLOW_DOWNGRADE = yes nicht AES-256-CBC erzwingt. Auf einer installierten Pepsi ist das der ausgelieferte Standardwert: ${DATADIR}/config.d/thunderbird.conf setzt yes, weil Thunderbird 140.12.0esr AuthEnvelopedData nicht lesen kann und beim Versuch stillschweigend scheitert. Diese Datei zu löschen stellt das einkompilierte negotiate wieder her und damit AEAD. Das obige OpenPGP-Verhalten ist unter beiden Werten dasselbe — die Container-Anforderung lautet auto, was beide je Empfänger auflösen —, sodass der S/MIME-Standardwert OpenPGP nichts kostet. Siehe pepsi.conf(5).

85.1.6.1.4. Konfiguration

Die Stage liest ihren eigenen [stage-<name>]-Abschnitt (PROGRAM = pepsi-stage-encrypt, ein erforderliches NEXT_STAGE — jedes Ergebnis dieser Stage ist ein Weiterschalten — und BOUNCE_STAGE, das pepsi-setup(1) seinerseits verlangt, sobald ON_NO_KEY/ON_OVERSIZE zu bounce aufgelöst wird, dazu ENABLE_PEP, SIGN, ENCRYPT, ATTACH_KEYS_AS_FILES, KEYS_CONTROL_LOCAL_PART, RESPONSE_STAGE, PREFER, ON_NO_KEY, ON_OVERSIZE, MIN_TRUST, SUBJECT_KEYWORDS_*, STRIP_REQUEST_HEADERS, PROTECT_HEADERS, AUTOCRYPT, AUTOCRYPT_GOSSIP, GOSSIP_MIN_TRUST, MAX_SIZE, SECURE_LINK_STAGE, DISCOVERY, DISCOVERY_TIMEOUT), alle dokumentiert in pepsi.conf(5). Das sind Verhaltens-Optionen und je Adresse über die Tabelle pepsi.settings überschreibbar.

Die kryptographische Richtlinie — Algorithmenwahl, Herabstufungserlaubnis, Akzeptanz schwacher Digests, Mindestschlüssellängen — liegt in den CRYPTO_*-Optionen von [pepsi] und in [pepsi-crypto]. Die sind ausschließlich Sache des Systemadministrators und aus pepsi.settings oder pepsi-stage-edit-settings(1) bewusst nicht erreichbar.

85.1.6.1.5. Privilegien

Das Binärprogramm wird setuid pepsi-crypto installiert, Modus 4750 pepsi-crypto:pepsi, und ist daher nicht in das vereinheitlichte pepsi-Multi-Call-Binärprogramm eingefaltet.

Beide Hälften der Schlüsselverwahrungsgrenze richten sich nach dieser Identität. Die Datenbankrolle pepsi-crypto ist die einzige, der crypto_identity.private_wrapped gewährt ist, und die Peer-Authentifizierung von PostgreSQL richtet sich nach der effektiven uid; der Schlüsselverschlüsselungsschlüssel liegt in secrets.d/pepsi-crypto.secret, Modus 0640, im Besitz desselben Kontos. Ein setgid-Binärprogramm erlangte die Gruppe — genug, um das Fragment zu lesen — und authentifizierte sich gegenüber der Datenbank dennoch als pepsi, genau die Rolle, der die Spalte verwehrt ist.

Die Gruppe im Modus beschränkt die Ausführung auf das Konto des Dispatchers und root; das Programm verweigert zur Laufzeit außerdem den Dienst, sofern seine reale uid nicht root oder eines der Konten pepsi, pepsi-crypto und pepsi-owner ist. Diese Laufzeitprüfung greift nur, wenn das Binärprogramm das setuid-Bit tatsächlich trägt — ein ohne dieses Bit installierter Build (ein Entwicklerbaum, cargo test) lässt jeden es ausführen, mit der Begründung, dass ein solcher Aufrufer die Datenbank als er selbst erreicht und dann PostgreSQLs eigene Berechtigungen maßgeblich sind. -c wird von diesen Aufrufern angenommen (die dokumentierte Startform des Dispatchers ist PROGRAM -c cfg worker), und die Umgebung wird bereinigt, bevor die Konfiguration geladen wird, denn die Konfigurationsschicht ist über XDG_CONFIG_HOME, HOME, PATH und die PG*-Familie steuerbar.

85.1.6.1.6. State

Eingaben: state.local_origin (die Schranke), state.dsn (beachtet und im Gleichschritt mit jeder Empfängeraufteilung zerteilt), state.origin.auth_method und state.origin.from_bound (ob der Einliefernde für die From:-Adresse sprechen darf, für die Schlüsselregistrierung und die Schlüsselbefehle per E-Mail).

Ausgaben: state.crypto.out — ob die Nachricht signiert wurde, mit welcher Identität, und je Empfänger ein Eintrag mit Ergebnis, Protokoll, Fingerabdruck, Schlüsselquelle, Vertrauensrang, Inhaltsalgorithmus und Herabstufungsflag; key_attached = true, wenn der Schlüssel des Absenders als Datei hinausging, und client_protected = true, wenn das einliefernde Mailprogramm die Nachricht bereits verschlüsselt hatte und die Stage sie unangetastet ließ. Außerdem state.encrypted = true, wenn die Nachricht eines Empfängers verschlüsselt wurde, was pepsi-stage-auto-whitelist(1) liest. Bei einem Bounce state.bounce. Das State-Layout wird in pepsi.state(7) beschrieben.

Übergänge: NEXT_STAGE für eine gesendete Nachricht (verschlüsselt, nur signiert oder Klartext); SECURE_LINK_STAGE oder BOUNCE_STAGE für einen Empfänger, der nicht geschützt werden konnte; paused während des Wartens auf die Schlüsselentdeckung; pending bei ebendieser Stage nach einer Empfängeraufteilung. Ein Schlüsselbefehl an die Steueradresse wird gelöscht (finish), nachdem seine Antwort bei RESPONSE_STAGE eingespeist wurde; die Benachrichtigungen über registrierte Schlüssel werden ebenfalls dort eingespeist, als neue Nachrichten mit Null-Absender.

85.1.6.1.7. Befehle

worker

Läuft als persistenter Dispatcher-Worker, liest Nachrichten-IDs von der Standardeingabe und schreibt eine Statuszeile je Nachricht. Das ist der einzige Modus; es gibt keine Einzelschussform. Um eine einzelne Nachricht von Hand auszuführen, pipen Sie ihre ID:

echo 1234 | pepsi-stage-encrypt -c /etc/pepsi/pepsi.conf worker

85.1.6.1.8. Exit-Status

0

Der Worker endete sauber (Standardeingabe geschlossen).

1

Ein Fehler ist aufgetreten (Fehlkonfiguration, ein nicht lesbarer Schlüsselspeicher oder ein Datenbankfehler). Der Grund wird in das Journal geschrieben.

78

Der Worker hat den Start verweigert: Seine Konfiguration oder sein Schlüsselbund funktioniert nicht. Der Dispatcher reiht erneut ein, was er übergeben hatte, und versucht die Stage später wieder.

85.1.6.1.9. Siehe auch

pepsi-stage-dkim-sign(1), pepsi-stage-srs(1), pepsi-keys(1), pepsi-keydisc(1), pepsi-stage-auto-whitelist(1), pepsi-stage-bounce(1), pepsi-dispatch(1), pepsi-setup(1), pepsi.conf(5), pepsi.state(7)

85.1.6.1.10. Fehler

Melden Sie Fehler an den Pepsi-Issue-Tracker.