E-Mails verschlüsselt senden: keine praktikable Lösung in Sicht

Aus Gründen des Datenschutzes und zur Verhinderung von Identitätsdiebstahl gibt es heute wohl kaum ein dringenderes Problem zu lösen als die Verschlüsselung von E-Mails. Während man beim Surfen selbstverständlich eine verschlüsselte Verbindung nutzen kann, gehen E-Mails in der Regel unverschlüsselt vom Absender zum Empfänger. Auf den ersten Blick erscheint es unverständlich, warum keine Möglichkeit besteht, über eine einfache Option eine Verschlüsselung von E-Mail zu erzwingen. Doch dafür gibt es gleich eine Reihe technischer Gründe.

Anders als beim Surfen im Web baut sich beim Senden von E-Mail keine direkte Verbindung zwischen Absender und Empfänger auf. Klickt man auf eine Webseite, deren Server derzeit offline ist, so erhält man eine Fehlermeldung. Würde das gleiche Prinzip bei E-Mail angewandt, so ließe sich eine E-Mail nur dann verschicken, wenn der Empfänger online ist und sein E-Mail-Programm geöffnet hat.

Dies ist offensichtlich keine praktikable Lösung ist. Der E-Mail-Versand geschieht daher nach dem Store-and-Forward-Prinzip. Rein theoretisch wäre es ausreichend, wenn ein E-Mail-Client jede E-Mail beim Mailserver des Empfängers direkt ablieferte. In der Regel verschickt man jede Nachricht jedoch zunächst an den eigenen SMTP-Server. Bei privaten E-Mail-Anschlüssen stellt ihn normalerweise der Provider bereit. Unternehmen haben meist eigene SMTP-Server, um sicherzustellen, dass firmeninterne E-Mails das Intranet erst gar nicht verlassen.

Das hat vor allem historische Gründe. E-Mail ist eine sehr alte Anwendung im Internet und sogar älter als das Internet selbst. In den Anfangsjahren des Internet gab es mehrere konkurrierende Netzwerke. Dazu zählten beispielsweise Bitnet und UUCP. Das UUCP-Netz bestand aus Unix-Rechnern, die sich per Telefonmodem in regelmäßigen Abständen anriefen und so Dateien und E-Mails austauschten. Dass ein E-Mail-Client im Internet direkt Mails an einen Rechner des UUCP-Netz sandte, war schon verbindungstechnisch gar nicht möglich.

Heute gibt es faktisch nur noch das Internet als Transportnetz für E-Mails. E-Mail-Adressen wie user@node.uucp oder user%node.bitnet@interbit.cren.net existieren nicht mehr. Ein E-Mail-Client könnte also leicht die MX-Records für eine Domain selbst auslesen und die E-Mail direkt an den Server des Empfängers senden. Dabei ließe sich eine Verschlüsselung problemlos sicherstellen. Wenn der SMTP-Servers des Empfängers keine Verschlüsselung beherrscht, könnte der E-Mail-Client eine Rückmeldung an den Benutzer geben, dass die Kommunikation nur unverschlüsselt oder gar nicht funktioniert.

Diese Methode hat allerdings einen Haken. Die überwiegende Mehrheit der SMTP-Server nimmt keine E-Mails mehr von IP-Adressen an, die bei den großen Blacklistern, etwa Spamhaus.org, als "residential" geführt werden. Dazu gehören die Adressräume der überwiegend von Privatpersonen und Sohos genutzten Internetanbieter. Das ist notwendig, um der Spamflut durch von Botnetzen übernommenen privaten PCs Herr zu werden, bedeutet aber letztendlich ein E-Mail-Verbot für Unschuldige, zumindest was den direkten Versand an den Server des Empfängers betrifft.