85.1.27. pepsi-stage-reencrypt¶
seal decrypted inbound mail to the recipient’s own key before filing it
- Handbuchabschnitt:
1
85.1.27.1.1. Name¶
pepsi-stage-reencrypt - die Stage der Pepsi-Pipeline für die Neuverschlüsselung zur Speicherung.
85.1.27.1.2. Übersicht¶
pepsi-stage-reencrypt [GLOBAL-OPTIONS] worker
85.1.27.1.3. Beschreibung¶
pepsi-stage-reencrypt ist ein Stage-Programm, das von pepsi-dispatch(1) als persistenter Worker ausgeführt wird, der Nachrichten-IDs von der Standardeingabe liest. Es lädt diesen pepsi.workqueue-Datensatz (und weigert sich zu handeln, sofern sein status nicht running ist) und liest seinen [stage-<stage>]-Abschnitt.
pepsi-stage-decrypt(1) öffnet Mail, die an den Gateway-Schlüssel (MTA-Schlüssel) eines Benutzers verschlüsselt ist, damit die Stages für Sprache, Spam, Whitelist und Schlüssellernen sie lesen können. Der Klartext ist dann das, was im Postfach abgelegt würde. Diese Stage läuft nach all diesen Lesern und bringt die Nachricht wieder unter Verschlüsselung — an den Schlüssel, den der Benutzer für seinen eigenen Mail-Client registriert hat (ein custody = client-Datensatz in pepsi.crypto_identity, der MUA-Schlüssel, registriert mit pepsi-keys(1) identity import, den Schlüsselbefehlen per E-Mail oder gelernt aus dem Autocrypt:-Header der eigenen Einlieferungen des Benutzers). Abgelegt wird dann Chiffrat, das nur dieser Client öffnen kann.
Sie wirkt nur auf eine Nachricht, die die Entschlüsselungs-Stage geöffnet hat: state.crypto.in muss besagen, dass sie verschlüsselt eintraf und entschlüsselt wurde. Mail, die im Klartext eintraf, wird nie angefasst (sie zu versiegeln würde eine Vertraulichkeit behaupten, die sie auf dem Übertragungsweg nie hatte), und Mail, die die Entschlüsselung ungeöffnet ließ, weil sie bereits an den MUA-Schlüssel verschlüsselt war (for_client), braucht nichts. Nur Empfänger, die dieser Host bedient, werden berücksichtigt; ein Empfänger, zu dem ein Alias bei einem anderen Anbieter aufgelöst wurde, bleibt unberührt.
Für jeden lokalen Empfänger wird der neueste aktive MUA-Schlüssel verwendet, der Verschlüsselung empfangen kann, in welchem Protokoll er auch ist (OpenPGP oder S/MIME). Eine Nachricht mit mehreren Empfängern, deren Behandlung sich unterscheidet, wird zuerst in einen Datensatz je Empfänger aufgeteilt (state.dsn.rcpt im Gleichschritt zerteilt), da jede Kopie für den Schlüssel einer einzigen Person versiegelt wird.
85.1.27.1.4. Wohin damit¶
Unmittelbar vor der lokalen Zustellung (pepsi-stage-relay-to-maildir(1), pepsi-stage-relay-to-lmtp(1)), und daher:
nach pepsi-stage-decrypt(1) — davor ist nichts geöffnet worden, sodass die Stage Mail nur durchreicht;
nach jeder Stage, die den Inhalt liest: Spracherkennung und -blockierung, die Schranken für Whitelist und Pay-to-Send, pepsi-stage-autocrypt-learn(1) (das Gossip aus dem Klartext liest), pepsi-stage-vacation(1);
nach pepsi-stage-aliases(1) und pepsi-stage-dot-forward(1) — eine anderswohin weitergeleitete Kopie darf nicht für den Schlüssel eines lokalen Benutzers versiegelt hinausgehen, den ihr neuer Empfänger nicht öffnen kann.
pepsi-setup(1) warnt, wenn keine Entschlüsselungs-Stage zu ihr führt und wenn sie zu einer der obigen Stages führt. Beachten Sie, dass das Sieve-Skript eines LMTP-Servers die versiegelte Nachricht sieht: Regeln auf den Nachrichtentext (oder, mit PROTECT_HEADERS, auf den Betreff) greifen nicht mehr.
85.1.27.1.5. Was sie schreibt¶
Die Aufteilung des Umschlags ist dieselbe, die pepsi-stage-encrypt(1) verwendet. Die Content-*-Felder und Autocrypt-Gossip: (Autocrypt Level 1 §5.3) kommen in das Chiffrat; alles andere bleibt im äußeren Block — Received:, From:/To:/Date:/Message-ID:, der eigene Autocrypt:-Header des Absenders (ein Client muss ihn lesen, bevor er irgendetwas entschlüsseln kann), die DKIM/ARC-Felder und X-Pepsi-Crypto, das Urteil des Gateways darüber, wie die Nachricht eintraf. Mit PROTECT_HEADERS werden die RFC-5322-Felder zusätzlich nach innen kopiert, und das äußere Subject wird zu ....
Es wird keine Signatur hinzugefügt. Das Urteil über die Signatur des Absenders hat die Entschlüsselungs-Stage gefällt, und es ist in state.crypto.in und in X-Pepsi-Crypto festgehalten; eine Gateway-Signatur sagte nur „das Gateway hat dies versiegelt“, was ein Mail-Client nicht von Urheberschaft unterscheiden kann. Eine Absendersignatur, die die Entschlüsselung als MIME-Schicht überstanden hat (S/MIME oder PGP/MIME-multipart/signed innerhalb des Chiffrats), liegt im Klartext, wird also mit ihm versiegelt und verifiziert im Client weiterhin; eine OpenPGP-Signatur, die im selben Datenstrom wie die Verschlüsselung verpackt war, wurde von der Entschlüsselung verbraucht und kann nicht rekonstruiert werden, sodass der Client dann eine unsignierte Nachricht und den Urteils-Header des Gateways zeigt.
Der Container folgt [pepsi] CRYPTO_ALLOW_DOWNGRADE genau wie bei der ausgehenden Verschlüsselung (siehe pepsi.conf(5)).
85.1.27.1.6. Ohne Schlüssel¶
ON_NO_CLIENT_KEY entscheidet, was mit einem lokalen Empfänger ohne verwendbaren MUA-Schlüssel geschieht — keiner registriert oder einer, für den nicht versiegelt werden kann (ein abgelaufenes Zertifikat, ein Container, den die Richtlinie ablehnt; dieser Fall wird zusätzlich als Warnung protokolliert):
plaintext(Standardwert)Den Klartext ablegen, genau wie ohne diese Stage.
bounceDie Nachricht ablehnen: Sie wird mit dem erweiterten Status
5.7.5(RFC 3463, kryptografischer Fehler) zu BOUNCE_STAGE geleitet. Die zurückgesandte DSN enthält weder den Nachrichtentext noch irgendeinen Header, den der Absender geschützt haben könnte — der Header-Block wird aufFrom,Sender,To,Cc,DateundMessage-IDgekürzt, der Nachrichtentext geleert undRET=HDRSerzwungen, was auch immer der Absender verlangt hat —, denn der Absender hat die Nachricht verschlüsselt, und eine DSN reist im Klartext. Ohne BOUNCE_STAGE wird der Datensatz stattdessen failed (und pepsi-setup(1) lehnt diese Kombination ab).
Eine Ablehnung erzeugt absichtlich einen Bounce statt eines Aufschubs: Ein Aufschub hielte den Klartext für die gesamte Lebensdauer der Nachricht in der Warteschlange — eine längere Blöße, keine kürzere —, und nichts würde ihn wecken, wenn ein Schlüssel registriert wird.
Die Option wird über die Überschreibungsschicht pro Adresse gelesen, sodass der Standort-Standardwert im Abschnitt für einen einzelnen Empfänger mit pepsi-settings(1) geändert werden kann:
pepsi-settings set bob@example.org reencrypt ON_NO_CLIENT_KEY bounce
85.1.27.1.7. Konfiguration¶
Die Optionen liegen im eigenen [stage-<name>]-Abschnitt der Stage (siehe pepsi.conf(5)):
- NEXT_STAGE (verpflichtend)
Lokale Zustellung.
- BOUNCE_STAGE
Wohin eine Ablehnung geht; erforderlich, wenn ON_NO_CLIENT_KEY im Abschnitt
bounceist, und ratsam, wann immer eine Überschreibung pro Adresse dies festlegen könnte.- ON_NO_CLIENT_KEY =
plaintext|bounce Siehe Ohne Schlüssel. Standardwert
plaintext.- PROTECT_HEADERS = yes | no
Die RFC-5322-Felder in das Chiffrat kopieren und das äußere
Subjectdurch...ersetzen (Standardwert no, wie bei pepsi-stage-encrypt(1): Die Unterstützung durch Clients ist uneinheitlich, und ein Client, der nicht hineinsehen kann, zeigt jeden Betreff als...).- ENABLED = yes | no
Ausgeschaltet wird jede Nachricht unverändert durchgereicht. Standardwert yes.
- LOCAL_DOMAINS, TARGETS, RECIPIENT_DELIMITER, REQUIRE_ACCOUNT
Welche Empfänger dieser Host bedient, mit der Bedeutung und den Standardwerten von pepsi-stage-decrypt(1) (LOCAL_DOMAINS fällt auf
[pepsi-ingress] ACCEPTED_DOMAINSzurück).
Die Stage ist unprivilegiert und in das Multi-Call-Binary pepsi eingefaltet: Das Versiegeln für einen öffentlichen Schlüssel braucht kein privates Material, und sie liest nur die öffentlichen Spalten von pepsi.crypto_identity, die die gewöhnliche Pipeline-Rolle pepsi lesen darf.
85.1.27.1.8. State¶
Eingaben: state.crypto.in.encrypted, state.crypto.in.decrypted und state.crypto.in.for_client, geschrieben von pepsi-stage-decrypt(1).
Ausgaben: state.crypto.store, dessen Vorhandensein die Stage außerdem davon abhält, einen Datensatz je zweimal zu versiegeln:
outcomereencrypted,plaintextoderbounced.protocol,fingerprint,container,downgradedBei
reencrypted: welcher MUA-Schlüssel verwendet und welcher Container erzeugt wurde.reasonBei
plaintext/bounced:no-client-key,not-localoder der Fehler beim Versiegeln.
Das State-Layout wird in pepsi.state(7) beschrieben.
Übergänge: schaltet zu NEXT_STAGE weiter; leitet unter ON_NO_CLIENT_KEY = bounce zu BOUNCE_STAGE um (oder schlägt ohne sie fehl); gibt einen Datensatz mit mehreren Empfängern nach dem Aufteilen an die Warteschlange zurück.
85.1.27.1.9. Befehle¶
- worker
Läuft als persistenter pepsi-dispatch(1)-Worker und liest Nachrichten-IDs von der Standardeingabe.
85.1.27.1.10. Globale Optionen¶
- -c FILE, –config FILE
Liest die Konfiguration aus FILE, statt die Standardorte zu durchsuchen.
- -L LOGLEVEL, –log LOGLEVEL
Setzt die Log-Ausführlichkeit (Standardwert
info).- -v, –verbose
Zeigt Log-Meldungen aus allen Quellen.
- -h, –help; -V, –version
Gibt eine Verwendungsübersicht / die Version aus und beendet sich.
85.1.27.1.11. Exit-Status¶
- 0
Die Nachricht wurde verarbeitet und weitergereicht.
- 1
Ein Fehler ist aufgetreten (Nachricht nicht gefunden oder nicht
running, eine fehlkonfigurierte Stage, ein Datenbankfehler). Der Grund wird in das Log geschrieben.- 78
Der Worker hat den Start verweigert: Sein Abschnitt oder die
[pepsi]-Krypto-Richtlinie lässt sich nicht parsen. Der Dispatcher reiht wieder ein, was er übergeben hatte, und versucht die Stage später erneut. Ein Datenbankfehler während der Verarbeitung einer Nachricht wird genauso wiederholt wie jeder andere Fehler dieses Hosts (siehe pepsi-dispatch(1)).
85.1.27.1.12. Beispiele¶
Nachricht 42 neu verschlüsseln (sie muss running sein):
echo 42 | pepsi-stage-reencrypt -c /etc/pepsi/pepsi.conf worker
Das Ende einer eingehenden Pipeline:
[stage-dot-forward]
PROGRAM = pepsi-stage-dot-forward
NEXT_STAGE = reencrypt
[stage-reencrypt]
PROGRAM = pepsi-stage-reencrypt
NEXT_STAGE = local
BOUNCE_STAGE = bounce
Für keinen Empfänger je lesbare Mail ablegen und auch die Betreffzeilen verbergen:
[stage-reencrypt]
PROGRAM = pepsi-stage-reencrypt
NEXT_STAGE = local
BOUNCE_STAGE = bounce
ON_NO_CLIENT_KEY = bounce
PROTECT_HEADERS = yes
85.1.27.1.13. Siehe auch¶
pepsi-stage-decrypt(1), pepsi-stage-encrypt(1), pepsi-keys(1), pepsi-settings(1), pepsi-stage-relay-to-maildir(1), pepsi-stage-relay-to-lmtp(1), pepsi-dispatch(1), pepsi.conf(5), pepsi.state(7), pepsi-setup(1)
85.1.27.1.14. Fehler¶
Melden Sie Fehler an den Pepsi-Issue-Tracker.