Das Symptom
Die Mail ist verschlüsselt. Das Programm zeigt ein Schloss, der Empfänger musste
seinen Schlüssel eingeben, alles hat funktioniert. Trotzdem steht in der
Übersicht des Postfachs – und in jedem Server-Protokoll auf dem Weg – gut lesbar
Betreff: Kündigung Vertrag 4711, Kontostand negativ. Der Inhalt ist ein
Zeichensalat, die Überschrift darüber liest jeder mit.
Die „Layer 8“-Wahrheit
Das ist kein Fehler in der Verschlüsselung, sondern eine Frage der Reihenfolge.
Eine E-Mail besteht aus einer Kopfzeilenabteilung und einem Körper, und
verschlüsselt wird historisch nur der Körper. RFC 9788, der genau dieses Problem
behandelt, formuliert es im ersten Absatz ohne Beschönigung: Die meisten
heutigen Umsetzungen kryptografisch geschützter E-Mail schützen nur den Körper der
Nachricht. Die Kopfzeilen müssen davorstehen und lesbar bleiben, weil die
beteiligten Server sonst nicht wüssten, wohin die Nachricht soll. Der Betreff
gehört technisch in dieselbe Abteilung wie die Zustelladresse – obwohl er
inhaltlich zum Text gehört. Genau darauf zielt die trockenste Feststellung des
Dokuments: Die meisten Nutzenden behandeln den Betreff wie den Nachrichtentext
und sind überrascht, dass er bei einer verschlüsselten Nachricht sichtbar ist.
Das ist mehr als ein Schönheitsfehler. Derselbe RFC benennt zwei konkrete Folgen.
Bei einer nur im Körper signierten Nachricht kann ein Angreifer die Kopfzeilen
ändern, ohne die Signatur ungültig zu machen – die Bedeutung der Nachricht ändert
sich damit dramatisch, während alle kryptografischen Anzeigen weiterhin grün
leuchten. Und bei einer nur im Körper verschlüsselten Nachricht gelangen
erhebliche Informationen über die Nachricht, ausdrücklich der Betreff, an jeden,
der unterwegs mitliest. Die Lösung existiert: RFC 9788 beschreibt seit August 2025
ein Verfahren, das den Betreff durch eine feste Zeichenfolge in eckigen Klammern
ersetzt und den echten Betreff mit in den geschützten Teil nimmt. Nur muss dein
Programm es können. Wie viele Programme das inzwischen tun, steht in dem Dokument
nicht und wird hier deshalb auch nicht behauptet – über das ältere Verfahren
schreibt es immerhin, nur wenige Umsetzungen erzeugten solche Nachrichten
überhaupt. Für den eigenen Fall gibt es ohnehin nur eine belastbare Auskunft, und
die steht im Quelltext der letzten selbst verschickten Mail.
Bleibt der Teil, den auch der beste Kopfzeilenschutz nicht löst, und dafür lohnt
sich die Ehrlichkeit. Damit eine Mail zugestellt werden kann, muss irgendwo eine
Empfängeradresse stehen. RFC 9788 beschreibt zwar die ambitionierte Variante, To
und Cc ganz aus dem sichtbaren Kopf zu entfernen – aber genau um den Preis, dass
die Zustellung dann am SMTP-Umschlag hängt, in dem die Adresse eben doch steht.
Wer mit wem schreibt, ist keine Information, die Verschlüsselung beseitigen kann.
Was praktisch zu tun bleibt, ist deshalb erstaunlich unmodern: in den Betreff
nichts schreiben, was nicht auf eine Postkarte darf.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.Den Quelltext einer eigenen verschlüsselten Nachricht ansehen
Statt zu spekulieren, sieht man nach. Jedes ernstzunehmende Mail-Programm kann den Quelltext einer Nachricht anzeigen oder sie als Datei speichern. Interessant ist nur der Anfang: Alles bis zur ersten Leerzeile ist die Kopfzeilenabteilung, und alles, was dort steht, ist unverschlüsselt.
sed -n '1,/^$/p' nachricht.eml
2.Gezielt nachsehen, was von außen lesbar bleibt
Vier Zeilen reichen für ein klares Bild: Absender, Empfänger, Betreff und Datum. Steht der echte Betreff dort im Klartext, schützt deine Verschlüsselung nur den Text darunter. Steht dort eine Ersatzzeichenfolge in eckigen Klammern, setzt dein Programm bereits Kopfzeilenschutz nach RFC 9788 ein.
grep -a -m 4 -E '^(From|To|Subject|Date):' nachricht.eml
3.Den Effekt einmal selbst nachbauen
Wer es mit eigenen Augen sehen will, baut in einer Minute nach, was jedes Mail-Programm tut: den Körper verschlüsseln, die Kopfzeilen davorstellen. Das Ergebnis ist unlesbar – bis auf die Zeile, um die es geht. Der Text ist geschützt, der Betreff steht offen davor.
mkdir -p /tmp/mailprobe
printf 'Der eigentliche Text der Nachricht.\n' > /tmp/mailprobe/body.txt
gpg --batch --yes --passphrase 'Testpassphrase' --symmetric --armor --output /tmp/mailprobe/body.asc /tmp/mailprobe/body.txt
{ printf 'From: alice@example.com\nTo: bob@example.net\nSubject: Quartalszahlen Q3\n\n'; cat /tmp/mailprobe/body.asc; } > /tmp/mailprobe/nachricht.eml
grep -a -m 1 '^Subject:' /tmp/mailprobe/nachricht.eml
4.Kopfzeilenschutz einschalten, falls das Programm ihn anbietet
Ob ein Programm Kopfzeilenschutz beherrscht, ist eine Frage seiner Version, nicht deiner Einstellung – RFC 9788 ist erst seit August 2025 veröffentlicht, und der RFC selbst schreibt, dass ein konformes Programm eine Standardvorgabe haben muss, die zumindest für den Betreff Vertraulichkeit bietet. Suche in den Einstellungen und in den Versionshinweisen nach Kopfzeilenschutz oder Header Protection. Findest du nichts, ist das keine Fehlbedienung, sondern der aktuelle Stand deines Programms.
5.Den Betreff behandeln wie eine Postkarte
Solange dein Programm keinen Kopfzeilenschutz beherrscht, ist der wirksamste Schritt kein technischer: Schreibe in den Betreff nichts, was nicht auf einer Postkarte stehen dürfte. Nicht die Vertragsnummer, nicht den Namen des Patienten, nicht die Diagnose, nicht die Kündigung. Der Inhalt gehört in den verschlüsselten Teil, der Betreff ist nur ein Wegweiser.
6.Die Metadaten realistisch einschätzen, statt sie zu verdrängen
Auch bei perfektem Kopfzeilenschutz bleibt die Zustellinformation übrig. RFC 9788 nennt als ambitionierte Möglichkeit, To und Cc ganz aus dem sichtbaren Kopf zu entfernen und sich für die Zustellung auf den SMTP-Umschlag zu verlassen – womit die Adresse eben dort steht. Wer wirklich verbergen muss, dass zwei Personen miteinander sprechen, löst das nicht mit einer Einstellung im Mail-Programm. Das ist keine Schwäche der Verschlüsselung; es ist einfach eine andere Aufgabe.