Re: Idee: Transportverschlüsselung unter Anwender-Kontrolle

[Peter Buettner]

Hallo Hendrik,

die Idee gefällt mir sehr gut, weil keine Eingriffe in den MUA's nötig
sind. Es wäre auch eine sehr schöne Lösung für das Versenden mit
dane-only. Dann müsste das Skript nach "non DNSSEC destination" suchen.
Da bei dieser Variante eine weitere Verarbeitung nicht erwünscht ist,
würde ein Hinweis auf die Nichtzustellbarkeit
Ich würde die Lösung gerne in meinem Produktivsystem testen.


Viele Grüße

Peter Büttner

Am 20.01.2016 um 08:35 schrieb 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
>