Hier überlegte ich noch, ob wir nicht an der Schule ein Horde mit Verschlüsselungsfunktion für die Kollegen einrichten sollten und wollte dies zuerst ausführlich mit ein paar Unerschrockenen testen. Soweit ist es noch nicht – aber die nächsten Schritte stehen an … und da fiel der Blick auch wieder zurück auf mögliche Alternativen und Erweiterungen.

Daniel und ich diskutierten die Möglichkeit einer Autoverschlüsselung von E-Mails, wenn diese an Kollegen gerichtet sind. Technisch ginge das z.B. mit:

• GNU Anubis (ein message submission daemon). Der wird aber seit ein paar Jahren wohl nicht mehr weiter entwickelt;
• DJIGZO (ein Gateway), das im Prinzip recht interessant aussieht, aber leider nur S/MIME und encrypted PDF kann;
• gpg-mailgate (ein Postscript Filter) und dessen Forks, der das leisten würde, was wir diskutierten, aber noch ziemlich frisch ist;

Für uns schien zuerst gpg-mailgate der vielversprechendste Kandidat zu sein – aber noch kann gpg-mailgate kein Multipart. Die Anhänge würden demnach unverschlüsselt durchrutschen und genau da stecken bei uns die relevanten Informationen drin.

Dazu kommen noch weitere Kritikpunkte an der Idee an sich:

1. jede Nachricht zu verschlüsseln ist eigentlich overkill, weil wir bei Mails von Kollege1 an Kollege2 lediglich lokal einen copy machen;
2. Es nervt, jedes mal ein extra Passwort für den Key einzugeben, nur um eine harmlose Mail zu lesen. Das führt zur Ablehnung des Gesamtsystems und zu verdammt kurzen Passwörtern. Diesen Weg könnten wir nur beschreiten, wenn wir auch automatisch entschlüsseln (also der Kontologin den Private Key gleich mit auspackt);
3. Es entlastet zwar – aber damit verhindert es auch, dass man sich mit dem Thema Datenschutz überhaupt auseinander setzt. Es ist demnach anti-aufklärerisch … und wenn dann alle Kollegen gar nicht mehr denken, weil ja alles automatisch passiert, dann denken sie auch nicht mehr an das Thema, wenn sie eine Mail an Eltern verfassen. Datenschutz ist eben auch und vor allem eine Kopffrage.

Im Moment will ich lieber keinen ganz so radikalen Schritt. Wir sollten auf den Kopf unserer akademisch gebildeten Kollegen setzen, das Thema damit warm halten und lieber riskieren, dass mal die eine oder andere Mail unverschlüsselt durchläuft – also auf unserem Mailserver von /home/mailuser/1 nach /home/mailuser/2 kopiert wird.

Ein fester Slot „Datenschutz“ in jeder (zweiten?) GLK, evtl. noch nett verpackt als Rätselaufgabe zu einem aktuellen Fall, halte ich im Moment für zielführender und wirksamer.

Wenn wir dann eines Tages doch noch auf die Default-Verschlüsselung umsteigen wollen, dann könnte Horde selbst schon genug können, sofern den Kollegen klar ist, warum sie dies tun sollen.

In den Einstellungen von Webmail kann bei Horde im Bereich „Erstellen“ hinterlegt werden, dass jede neue Nachricht standardmäßig unterschrieben und verschlüsselt werden soll. Das kann ein Nutzer dann zwar wieder abknipsen … aber dann haftet er auch. Oder man nagelt diese Einstellung in der Datenbank über die Konfiguration von Horde selbst fest, statt sich mit mail-gateway und Freunden gleich die nächste zu betreuende Technik an Bord zu holen.