Idee: Transportverschlüsselung unter Anwender-Kontrolle

[Hendrik Sünkler]

Liebe Postfix-Kollegen,

in der letzten Zeit habe ich mir einige Gedanken zum Thema
E-Mail-Verschlüsselung gemacht und wie ich die Workflows für „meine
User“ einfacher machen kann. Leider werden S/MIME und OpenPGP in den
Unternehmen nur sehr selten eingesetzt. Wir haben zwar eine
entsprechende Gateway-Lösung und auch viele unserer
Kommunikationspartner scheinen technisch darauf vorbereitet, aber
eingesetzt wird S/MIME bzw. OpenPGP in der Praxis leider kaum. Auf der
anderen Seite unterstützen aber mittlerweile ca. 90% der Mailserver TLS.
Aus diesem Grund habe ich mir ein paar Gedanken gemacht, wie wir TLS
gewinnbringender für uns einsetzen können.

So praktisch die Grundeinstellung des opportunistischen TLS Modus auch
ist (smtp_tls_security_level = may), dem Anwender bringt es leider
wenig. Denn er muss in dem Moment, da er auf „senden“ klickt wissen, ob
seine Mail verschlüsselt wird. Die Lösung lautet also Mandatory TLS
(smtp_tls_security_level gleich mindestens encrypt). Aber da ja noch ca.
10% der Mailserver kein TLS unterstützen, werden einige Mails in der
Queue hängen bleiben. Es liegt dann am Administrator, den Absender
anzusprechen, wie mit seiner Mail verfahren werden soll, denn der
Administrator kann schlecht selbst entscheiden, ob die Informationen
sensibel sind, so dass sie nicht unverschlüsselt gesendet werden dürfen,
oder ob es sich beispielsweise nur um eine Terminbestätigung handelt,
bei der es auch in Ordnung wäre, wenn sie unverschlüsselt heraus
geschickt wird. Dieser Vorgang bindet viele personelle Ressourcen und
ist sowohl für den Administrator als auch den Anwender nervig.

Meine Idee ist es nun, dem Absender die Kontrolle über die in diesem
Szenario in der Queue hängen gebliebene Mail zu geben. Ich habe ein
Python-Programm geschrieben, welches die Postfix Queue jede Minute nach
Mails durchsucht, die wegen fehlender TLS-Unterstützung der Gegenseite
nicht zugestellt wurden („TLS is required, but was not offered“). Wenn
ein solcher Eintrag gefunden wird, erhält der Absender eine
Benachrichtigung per Mail, in der er dann zwei Buttons findet: „Mail
löschen“ oder „Mail unverschlüsselt zustellen“.

Auf diese Weise mache ich TLS neben S/MIME und OpenPGP zu einer für den
Anwender tatsächlich nutzbaren Verschlüsselungsvariante. Und ich
etabliere eine sichere Grundeinstellung: Wenn der Anwender nichts macht
außer seine Mail zu versenden, kann der davon ausgehen, dass die
Übertragung gesichert ist. Wenn dann im Einzelfall keine sichere
Verbindung zum Zielserver aufgebaut werden kann, muss der Absender sich
bewusst für die unverschlüsselte Zustellung entscheiden - oder er löscht
die Mail und findet einen anderen Weg, mit dem Empfänger zu
kommunizieren.

Natürlich ist die Welt der E-Mail-Verschlüsselung nicht schwarz-weiß und
dies ist nicht die perfekte Lösung. So ist TLS natürlich keine
Ende-zu-Ende-Verschlüsselung. Und auch ist es etwas semi-optimal, dass
eine Mail bei fehlender Verschlüsselung zunächst zurück gehalten wird
und der Absender nochmals tätig werden muss, bevor seine Mail dann
versendet wird - sofern er sie unverschlüsselt senden möchte. Aber mir
scheint dieser „Workflow“ derzeit die beste Variante zu sein.

Quasi aus einem Reflex heraus habe ich eine Domain registriert und unter
https://posttls.com eine kleine Webseite erstellt, auf der ich den
Ansatz noch etwas weiter erläutere. Es würde mich freuen, eure Meinung
zu dieser Idee zu hören. Vielleicht hat ja jemand schon etwas ähnliches
implementiert?! Den Code werde ich unter eine Open Source Lizenz stellen
und auf GitHub veröffentlichen, falls die Lösung auf Interesse stößt.


Viele Grüße!
Hendrik Sünkler

-- 
http://suenkler.info