Sichere E-Mail, erklärt

Sichere E-Mail ist kein einzelner Schalter und kein einzelnes Protokoll. Eine Nachricht durchläuft mehrere Systeme, und jede Sicherheitsschicht beantwortet eine andere Frage: Ist die Verbindung privat, ist der Absender echt, hat sich die Nachricht verändert, wer kann sie lesen, und wie wird sie gespeichert?

Dieser Leitfaden beginnt mit dem Weg, den jede E-Mail nimmt, und zeigt anschließend, wo Owlat Schutz hinzufügt — einschließlich der Stellen, an denen dieser Schutz bewusst endet.

Die Kurzfassung

• TLS verschlüsselt die Netzwerkverbindung zwischen zwei Systemen. Jeder Mailserver erhält die Nachricht dennoch im Klartext.
• SPF, DKIM und DMARC helfen dabei, die sendende Domain zu authentifizieren und Manipulationen zu erkennen. Sie verbergen den Nachrichtentext nicht.
• Ende-zu-Ende-Verschlüsselung verschlüsselt die Nachricht selbst. Zwischengeschaltete Mailserver transportieren Chiffrat statt lesbaren Inhalts.
• Verschlüsselung im Ruhezustand schützt gespeicherte Daten, falls Festplatten, Objektspeicher oder Datenbank-Backups offengelegt werden. Der laufende Dienst kann die Daten für die autorisierte Nutzung weiterhin entschlüsseln.

Wie eine E-Mail unterwegs ist

Wenn Sie Senden wählen, übergibt Ihr Mailprogramm die Nachricht an einen ausgehenden Mailserver. Dieser Server schlägt die MX-Einträge der Empfängerdomain im DNS nach, verbindet sich per SMTP mit einem empfangenden Mailserver und überträgt die Nachricht. Der empfangende Server filtert und speichert sie; die Empfängerin oder der Empfänger liest sie später über Webmail oder eine IMAP-Verbindung.

Die meisten modernen Verbindungen nutzen TLS. Die Einlieferung aus einer App verwendet üblicherweise TLS auf Port 587 oder 465, Server-zu-Server-SMTP wird per STARTTLS auf Port 25 hochgestuft, und der Postfachzugriff läuft über HTTPS oder IMAPS. Das verhindert, dass ein passiver Beobachter im Netzwerk den Datenverkehr mitliest.

Gewöhnliches TLS wirkt jedoch Sprung für Sprung (hop-by-hop). Eine TLS-Verbindung endet an jedem Mailserver, wo die Nachricht im Klartext für Routing, Spamfilterung, Indizierung, Weiterleitung und Speicherung vorliegt. Für den nächsten Sprung beginnt eine neue verschlüsselte Verbindung. Der Anbieter auf beiden Seiten — und jedes Relay, das einen Sprung terminiert — kann die Nachricht daher möglicherweise lesen.

Warum STARTTLS Verstärkung braucht

SMTP wurde entworfen, bevor Verschlüsselung normal war. STARTTLS erlaubt es zwei Mailservern, eine Klartextverbindung hochzustufen, doch die gewöhnliche SMTP-Zustellung ist oft opportunistisch: Ist TLS nicht verfügbar, wird unter Umständen auch ohne zugestellt. Ein aktiver Angreifer kann versuchen, das STARTTLS-Angebot zu entfernen oder die Zustellung auf den falschen Server umzuleiten.

Zwei Standards erschweren das:

• MTA-STS weist kompatible Absender an, zertifikatsgeprüftes TLS zu den erwarteten Mailservern der Domain zu verlangen.
• DANE veröffentlicht TLS-Zertifikatszuordnungen in DNSSEC-geschützten TLSA-Einträgen und ermöglicht es einem Absender, den empfangenden Server zu authentifizieren, ohne sich allein auf das öffentliche System der Zertifizierungsstellen zu verlassen.

TLS-RPT schafft Sichtbarkeit. Empfangende Domains veröffentlichen, wohin Sammelberichte gehen sollen; sendende Systeme melden fehlgeschlagene oder herabgestufte TLS-Zustellversuche.

Authentifizierung ist keine Verschlüsselung

E-Mail-Authentifizierung erschwert Identitätsmissbrauch und unbemerkte Veränderungen, macht die Nachricht aber nicht geheim.

Diese Prüfungen ergänzen einander. Eine Nachricht kann einwandfrei authentifiziert und dennoch für jeden Server lesbar sein, der sie verarbeitet. Sie kann ebenso verschlüsselt, aber mit einem unbekannten Schlüssel signiert sein — der Inhalt ist dann privat, während die Identität des Absenders ungewiss bleibt.

Was Ende-zu-Ende-Verschlüsselung ändert

Bei Ende-zu-Ende-Verschlüsselung beschafft sich der Absender den öffentlichen Schlüssel jedes Empfängers und verschlüsselt die Nachricht vor dem Transport. Nur der passende private Schlüssel kann sie öffnen. Mailserver benötigen weiterhin genügend äußere Metadaten, um die Nachricht zu routen — etwa die Envelope-Adressen —, doch der geschützte Inhalt reist als Chiffrat.

Normalerweise wird gleichzeitig eine digitale Signatur hinzugefügt. Beim Empfang lässt sich damit prüfen, dass der geschützte Inhalt unverändert ist und mit dem erwarteten Schlüssel signiert wurde.

Damit entsteht ein Schlüsselverwaltungsproblem: Software muss den richtigen öffentlichen Schlüssel finden, unerwartete Schlüsselwechsel bemerken, private Schlüssel schützen und einen Wiederherstellungsweg bieten, der keinen verborgenen Generalschlüssel schafft. Ein Großteil der Verbesserung durch Owlat liegt darin, diese betrieblichen Details automatisch und sichtbar zu handhaben.

Wie Owlat sichere E-Mail verbessert

Owlat kombiniert unabhängige Schutzmaßnahmen, statt eine einzelne davon als vollständigen Schutz auszugeben.

1. Sichererer Transport für jede Nachricht

Owlat verlangt für eingehende SMTP-Zustellung standardmäßig TLS. Ein Absender, der nicht hochstuft, erhält einen Fehler, bevor Owlat Nachrichten-Bytes annimmt oder speichert.

Für stärkere Widerstandsfähigkeit gegen Downgrades können Betreiber eine MTA-STS-Richtlinie veröffentlichen, die MTA-STS-Richtlinien anderer Domains bei ausgehender Zustellung durchsetzen, eine TLS-Untergrenze für ausgehenden Verkehr wählen und DANE-TLSA-Einträge im Report- oder Enforce-Modus auswerten. Die Aufnahme von TLS-RPT und das Zustellungs-Dashboard machen Fehler sichtbar, bevor eine Richtlinie verschärft wird.

Diese Maßnahmen schützen auch gewöhnliche Internetpost — einschließlich Nachrichten an Anbieter, die Owlats Ende-zu-Ende-Verschlüsselung nicht unterstützen. Einrichtung und die genauen Betreiber-Steuerungen beschreibt Transportsicherheit.

2. Automatischer Ende-zu-Ende-Schutz zwischen fähigen Workspaces

Sealed Mail schützt persönliche Postbox-Nachrichten mit interoperablem OpenPGP/PGP-MIME. Owlat erzeugt für jede Adresse einen Schlüssel, ermittelt den veröffentlichten öffentlichen Schlüssel eines Empfängers, signiert die Originalnachricht und verschlüsselt sie vor der SMTP-Zustellung für jeden Empfänger.

Versiegelt wird die vollständige Originalnachricht, einschließlich echtem Betreff und Body. Die äußere Nachricht verwendet Subject: ... und behält nur das, was das Mailsystem zur Zustellung braucht. Zwischengeschaltete MTAs transportieren daher Routing-Metadaten und Chiffrat statt der lesbaren Nachricht.

Versiegeln gilt ganz oder gar nicht. Es geschieht nur, wenn jeder Empfänger einen nutzbaren, vertrauenswürdigen Schlüssel hat. Ist das bei einem nicht der Fall, nennt der Editor den Grund und bietet eine eigene Aktion Unversiegelt senden an — Owlat bezeichnet eine nur teilweise geschützte Nachricht nicht stillschweigend als versiegelt.

3. Schlüsselermittlung mit Warnungen bei Änderungen

Owlat veröffentlicht Adressschlüssel über Web Key Directory (WKD) und weist sie in einem signierten Instanz-Manifest aus. Bei der ersten Verwendung pinnt der Absender den ermittelten Fingerprint — ein Trust-on-first-use-Modell.

Ändert sich der Schlüssel später ohne gültige signierte Rotation, stellt Owlat das Versiegeln an diese Adresse ein und zeigt eine Warnung zum Schlüsselwechsel. Ein Owner oder Admin muss den Ersatzschlüssel prüfen und annehmen, bevor wieder versiegelt wird. So wird verhindert, dass einem neu beobachteten Schlüssel stillschweigend vertraut wird.

4. Ehrliche Sicherheitszustände in der Oberfläche

Die Leseansicht hält Verschlüsselung und Absenderechtheit auseinander:

• Versiegelt — Absender verifiziert bedeutet, dass Owlat eine Ende-zu-Ende-verschlüsselte Nachricht geöffnet und ihre Signatur geprüft hat.
• Versiegelt — Absender nicht verifiziert bedeutet, dass der Inhalt verschlüsselt war, der Signierende aber nicht bestätigt werden konnte.
• Verschlüsselt — Entschlüsselung nicht möglich bedeutet, dass die Nachricht für die Adresse verschlüsselt wurde, dieser Workspace jedoch keinen passenden privaten Schlüssel besitzt.
• Verifizierter Absender, Absender nicht autorisiert und verwandte Absender-Badges geben die Ergebnisse von SPF, DKIM und DMARC unabhängig von Sealed Mail wieder.

Ein fehlendes Badge wird nicht stillschweigend als Erfolg gewertet. Alle Editor- und Leseansicht-Zustände beschreibt Sealed Mail.

5. Gespeicherte Bodies und Secrets sind ebenfalls versiegelt

Owlat versiegelt Nachrichten-Bodies und gespeicherte rohe .eml-Blobs im Ruhezustand mit AES-256-GCM unter Schlüsseln, die aus dem Instanz-Secret abgeleitet werden. Private DKIM-Schlüssel und Zugangsdaten für SMTP-Relays werden zusätzlich unter einem separaten MTA-Secret versiegelt. Autorisierte Leser erhalten den Klartext über einen geprüften Entschlüsselungspfad statt über eine direkte Speicher-URL zum Chiffrat.

Das schützt Datenbank- und Speicher-Snapshots, ist aber etwas anderes als Ende-zu-Ende-Verschlüsselung: Ein laufender Owlat-Workspace muss Mail für autorisiertes Lesen, für die Suche und für optionale KI-Funktionen öffnen können. Kurze Suchfelder und Vektor-Embeddings sind dokumentierte Ausnahmen von der vollständigen Chiffrat-Speicherung des Bodys. Die genaue Vertrauensgrenze und das Speicherdesign behandelt Sealed Mail im Ruhezustand.

Die Vertrauensgrenze, klar benannt

Sealed Mail ist Ende-zu-Ende zwischen dem sendenden und dem empfangenden Owlat-Workspace. Relay-Server dazwischen können den geschützten Betreff und Body nicht lesen. Am Ziel öffnet der Owlat-Workspace die Nachricht, damit autorisierte Nutzerinnen und Nutzer sie lesen und durchsuchen und, sofern aktiviert, mit den KI-Funktionen des Workspace verwenden können.

Das unterscheidet sich von rein gerätegebundener Verschlüsselung, bei der private Schlüssel nie das Telefon oder den Computer einer Person verlassen. Selbst-Hoster kontrollieren ihren Endpunkt und dessen Instanz-Secret; Nutzerinnen und Nutzer verwalteter Workspaces vertrauen ihrem Owlat-Workspace als Endpunkt. Ein Wiederherstellungs-Kit kann den privaten Schlüssel einer Adresse wiederherstellen, und wer dieses Kit erlangt, kann die dafür versiegelte Mail lesen.

Was ist an welcher Stelle geschützt?

Weiterführende Lektüre

• Sealed Mail — Verhalten des Editors, Badges, Richtlinien und Hinweise bei Schlüsselwechseln.
• Sealed-Mail-Wiederherstellungs-Kit — Sicherung und Wiederherstellung von Adressschlüsseln.
• Transportsicherheit — MTA-STS, DANE, TLS-RPT und TLS-Konfiguration.
• Wie E-Mail funktioniert — SMTP, DNS, Aufbau einer Nachricht und Zustellbarkeit im Detail.
• Sealed Mail im Ruhezustand — Speicher-Envelopes, Migrationen, Ausnahmen und Entschlüsselungspfade.