E-Mail

Von hier nach da

E-Mail, genauer, Internet Mail ist ein asynchrones Mitteilungssystem zum Austausch von Nachrichten. Warum asynchron? Für die E-Mail-Kommunikation müssen Sender und Empfänger einer Nachricht nicht zur gleichen Zeit mit dem Internet verbunden sein. Beispiel für ein synchrones Verfahren wäre der Abruf einer Internetseite.

Bei synchronen Verfahren stellen die beteiligten Computer eine direkte Verbindung her, bei asynchronen Verfahren gibt es Instanzen, die die Information mindestens so lange aufbewahren bis sie jemand abholt.

Eine E-Mail beginnt ihr Dasein in Ihrem E-Mail-Programm (MUA = Mail User Agent), dies kann auch Ihr Browser sein, allerdings bieten spezielle Mail-Programme meist weit mehr Komfort hinsichtlich Archivierung und Adressverwaltung.

1. Sie schreiben in Ihrem Mail-Programm eine beliebige Mitteilung und teilen dem Programm mindestens den Empfänger der E-Mail mit.

Ihr E-Mail-Programm stellt eine Verbindung zu einem Internet-Server her, der für den Transport von E-Mails spezialisiert ist (MTA = Mail Transport Agent). Um die Nachricht befördern zu können, benötigt der MTA bestimmte Informationen, mindestens die Adresse des Empfängers. Damit nicht jeder jeden MTA benutzen kann, muss sich Ihr E-Mail-Programm in der Regel identifizieren und nachweisen, dass es berechtigt ist, eine E-Mail zu versenden. Dieser Verbindungsvorgang ist in einem so genannten Internet Protocol (Protocol = Vorschrift über den Ablauf einer Zeremonie) geregelt, dies heißt in diesem Fall SMTP (Send Mail Transport Protocol = Postversendungsvorschrift). Unter einem SMTP-Server versteht man entsprechend einen Postausgangsserver, also ein Programm im Internet, das E-Mails vom Absender entgegennimmt und diese auf den Weg bringt.

2. Ihr E-Mail-Programm leitet das Programm in das Internet an einen SMTP-Server weiter. Hierzu ist in der Regel ein Nachweis zu führen, dass Sie den SMTP-Server benutzen dürfen (Anmeldekennung und Passwort).

Heute erfolgt bereits dieser erste Schritt über eine gesicherte Verbindung, die Transportverschlüsselung. Um diese Transportverschlüsselung müssen Sie sich nicht kümmern, sie wird zwischen den beteiligten Stationen für jede Verbindung neu ausgehandelt und aufgebaut. Kann eine der beiden Verbindungsstellen keine Transportverschlüsselung realisieren, erfolgt die Verbindung ungesichert. Wichtig ist nur der Aspekt, dass die Transportverschlüsselung innerhalb jedes Knotenpunkts (Verbindungsstelle) im Internet nicht mehr wirkt (die Verschlüsselung wird aufgelöst).

Ihr SMTP Server macht sich nun an die Weiterleitung der Nachricht , manchmal kann sie direkt erfolgen, manchmal werden weitere Verbindungsstellen einbezogen. Der Weg der Nachricht wird von so genannten Router Programmen (Services) festgelegt. Der erste Router (in der Regel der MTA/ SMTP Server) entscheidet über die nächste sinnvolle Station für die Nachricht. Senden Sie z. B. eine E-Mail in die USA, wird die nächste Station vermutlich ein großer Knoten in Deutschland sein, von dort geht es an einen großen Knoten auf der anderen Seite des Atlantiks usw. All diese Knoten sind ebenfalls MTA (Verbindungsstellen für E-Mail), die Kommunikation erfolgt nach dem SMTP (Send Mail Transport Protocol).

Schlussendlich kommt Ihre E-Mail bei dem Server an, dessen Adresse Sie nach dem „@“ der E-Mail-Adresse angegeben haben, z. B. „lamprecht-software.de“ oder „gmx.de“. Der Transport vom Absender zum Server des Empfängers erfolgt mit synchronen Verfahren. Alle bis dahin beteiligten Instanzen sind permanent ansprechbar (online).

3. Das Internet befördert Ihre E-Mail zum Server des Empfängers

Die am Transport beteiligten Server ergänzen den Header der E-Mail (Kopfzeile, siehe unten) in der Regel um Angaben zum Transport. Diese Angaben stehen in „Received: from …“. Vorweg genommen: Auch diese Angaben sind nicht verlässlich. Die von den MTA hinzu gefügten „Received: …“-Einträge werden kaum gefälscht, aber: Der betrügerische Absender kann schon beim Erstellen der E-Mail gefälschte „Received: …“-Einträge vornehmen!

Auf dem Server des Empfängers oder bei dessen E-Mail-Dienstleister werkelt ein Posteingangsserver. Der ist für die Verteilung der eingehenden E-Mails an die Postfächer der Empfänger zuständig. Selbstverständlich wird an dieser Stelle jegliche Transportverschlüsselung aufgelöst. Die E-Mails, einfache Textdokumente, werden gespeichert und warten nun auf den Festplatten des Posteingangsservers auf ihre berechtigten Abholer.

4. Der Empfangende Server bewahrt die E-Mails auf.

Damit Sie an Ihre E-Mails kommen, gibt es zwei etablierte Verfahren:

IMAP (= Internet Mail Access Protocol) und POP3 (= Post Office Protocol). Bei IMAP wird davon ausgegangen, dass Sie Ihre E-Mails auf dem Server belassen und nur bei Bedarf abrufen. Entsprechend können Sie unter IMAP auf dem Server strukturieren, also dort Ordner und Unterordner anlegen, direkt vom Server löschen etc. E-Mail-Programme, die IMAP unterstützen, bilden die Struktur auf dem Server nur ab, alle Befehle an das E-Mail-Programm werden an den Server weitergeleitet und vom IMAP-Service bearbeitet. POP3 liefert im Prinzip nur die Post aus. Sie wird nicht sortiert. Bei POP3 können Sie nicht viel entscheiden, nur, ob Sie die E-Mails nach dem Abholen vom Server löschen wollen oder ob sie dort bleiben sollen.

5. Sie holen die E-Mails ab (POP3) oder verwalten sie auf dem Server (IMAP).

So ist eine E-Mail aufgebaut

Eine E-Mail ist im Prinzip ein Textdokument. Texte bestehen aus Bytes, also einer Informationseinheit, die 256 verschiedene „Zustände“ annehmen kann. Ursprünglich wurden in E-Mails nur 7bit Informationseinheiten (entsprechend dem amerikanischen Zeichensatz) verwendet, damit können 128 verschiedene Zustände dargestellt werden. Damit eine E-Mail auch chinesische Zeichen enthalten kann, oder Filme oder Bilder etc., werden diese Informationen in Bytefolgen verwandelt. Die Regeln, nach denen diese Umwandlung erfolgt, nennt man Kodierung. Im Gegensatz zur Verschlüsselung von Informationen, soll die Dekodierung einfach und eindeutig möglich sein, in einem kodierten Text steckt also kein Geheimnis (im Sinne eines kryptologischen Schlüssels), sie ist eine Geburt der Not, führt aber nichts desto trotz zur Unleserlichkeit für den Nichtcomputer.

Aber fangen wir vorne an:

Eine E-Mail soll einen Header (Kopfzeile) mit Metainformationen enthalten und einen Body (Textkörper) mit der zu übermittelnden Information.

Der Header dient den auswertenden E-Mail-Programmen zur Strukturierung der E-Mail-Eingänge. Er ist zu nichts anderem da, als Listen mit Von: …., Betreff: …., Absendedatum: …. etc. bilden zu können. Der E-Mail-Header ist keine zuverlässig glaubwürdige Information. Er wird an keiner Stelle validiert.

Für die Internetkommunikation gibt es diverse „Vorschriften“ (rfc = Request for Comment), Sie merken, etwas undeutsch, dies sind keine Normen sondern Vorschläge), die die Gestaltung und den Aufbau verschiedener Informationsarten im Internet regeln sollen, natürlich auch für E-Mail. Dadurch, dass sich die Absender an die rfc halten, sind die Empfänger bzw. deren Programme, in der Lage, sie korrekt zu interpretieren.
Ein Header-Eintrag besteht aus dem Namen des Eintrags, gefolgt von einem Doppelpunkt.

„Offizielle“ Einträge (erkennbar daran, dass kein "X-" vorangestellt ist) sind u. a.

Headererweiterungen erkennen Sie am vorangestellten „X-„ des Eintrags, z. B.

Der Header wird durch eine Leerzeile vom Body der E-Mail getrennt.

Jetzt aber mal eine Minimal-E-Mail als Beispiel:

To: info@lamprecht-software.de
Date: Sat, 3 Dec 2016 22:53:21 +0100 (CET)

dies ist meine mail

Das reicht bereits (er klappt meist sogar, den Header ganz wegzulassen, dann muss man aber den SMTP-Server direkt ansprechen).

Um eine E-Mail mit Anhängen, alternativen Darstellungen, integrierten Bildern oder auch kryptologischen Features auszustatten, wird MIME (= Multipurpose Internet Mail Extensions; Internet Mail Erweiterungen für viele Zwecke) verwendet. Kompliziert ist das nicht:

Der Header wird um die Einträge

erweitert. Der Content-Type (= Inhaltstyp) entscheidet dabei, wie das E-Mail-Programm des Empfängers den (immer noch ist es einer) folgenden Text interpretieren soll.
Die Angabe eines „Content-Type“ enthält eine Präzisierung (z. B. „Content-Type: mulktipart/mixed;…“) und eine Grenzmarkierung (boundary=“dies_ist_der_erste_streich“), die die einzelnen „mixed“ Teile im nachfolgenden Text voneinander trennt.

Der Body einer solchen Nachricht enthält dann durch die Grenzmarkierung getrennte Bereiche, denen jeweils wieder ein Header vorangeht (dieser sollte aber nur Angaben zum Inhaltstyp und zur Kodierung enthalten). Der Inhaltstyp eines MIME-Teils kann wiederum eine „multipart/…“ Nachricht sein. Dadurch wird Verschachtelung möglich.

Kryptologie in E-Mails

Dieser Abschnitt greift dem folgenden Kapitel "Kryptologie" teilweise vor.

Sichere E-Mails verwenden z. B. den Inhaltstyp „multipart/encrypted“. Die beiden MIME-Teile sind eine Versionsinformation und ein verschlüsselter „Text“. Wird die Verschlüsselung aufgelöst, erscheint möglicherweise ein „multipart/signed“ Inhalt. Hier gibt es wieder zwei MIME-Teile, den Teil, der signiert wurde und einen Teil mit der Signatur. Der Teil, der signiert wurde, ist dann die ursprüngliche E-Mail vor der kryptologischen Bearbeitung.

Die Verbindung von Kryptologie und MIME bedeutet, dass immer alle Teile der E-Mail, auch die Anhänge, verschlüsselt bzw. signiert werden.

Ich schreibe dies ausdrücklich, da mir über viele Jahre niemand sagen konnte, was eigentlich verschlüsselt wird.

Während MIME standardmäßig eher wie ein Puzzle erscheint, die Teile liegen neben- oder hintereinander, sind die kryptologischen Erweiterungen der MIME eher nach dem Matrjoschka-Prinzip gestaltet, ineinander verschachtelt.

Im Zuge des Signierens werden der Eintrag „Content-Type“ im Haupt-Header der E-Mail und der gesamte Body zum MIME-Teil „signed message“, der Eintrag „Content-Type“ im Haupt-Header wird in „multipart/signed...“ geändert und ein weiterer MIME-Teil „...signature“ hinzugefügt.

Die ursprüngliche Nachricht mit Ihrer Beschreibung „Content-Type“ wurde also in eine Schachtel gepackt („signed message“) und diese Schaltel versiegelt („signature“). Dieses Enveloping (= Briefumschlag)-Verfahren lässt sich wiederholen, z. B. wenn man eine Nachricht von einer zweiten Person signieren lassen möchte: Die „multipart/signed...“-Nachricht wird zum ersten MIME-Teil, eine Signatur kommt als zweiter MIME-Teil dazu und der „Content-Type“ im Haupt-Header wird modifiziert..., die signierte Nachricht liegt nun in einer neuen Schachtel mit einem weiteren, neuen Siegel. Entscheidend bei diesen Vorgängen ist der korrekte Austausch der Grenzmarkierungen (boundaries). Machen sie sich auch bewusst, dass in diesem Beispiel die komplette schon einmal signierte Nachricht signiert wird, also inklusive der Signaturinformationen. Soll die Nachricht endlich auch verschlüsselt werden, geht es wie gehabt: Die verschlüsselte Nachricht (verschlüsselt wird der Eintrag „Content-Type“ des Haupt-Headers, also hier „multipart/signed“ und die komplette bisherige Nachricht) wird zu einem MIME-Teil, es wird ein weiterer MIME-Teil mit einem Versionseintrag angefügt  und der Haupt-Header wird in „multipart/encrypted...“ (bei Verwendung von openPGP) geändert.

Das Auspacken geht in umgekehrter Reihenfolge: Der MIME-Teil, der die verschlüsselte Nachricht enthält, wird entschlüsselt. Der „Content-Type“ im Haupt-Header („multipart/encrypted...“) wird durch den Content-Type des entschlüsselten MIME-Teils ersetzt und lautet nun („multipart/signed“). Das Auspacken dieses Teils erfordert andere Aktionen, die Signatur im MIME-Teil „signature“ wird geprüft und es wird geprüft, ob die Signatur zur Nachricht im MIME-Teil „signed message“ passt. Für die letzte Signatur wird entsprechend verfahren.

Die Nachricht kann angezeigt werden, wenn alle Verschlüsselungen aufgelöst sind.
Diese Technik funktioniert auch, wenn unterschiedliche kryptologische Verfahren (X.509 bzw. PKCS#7 und openPGP) zusammen eingesetzt werden.

In den rfc und der Literatur wird vorausgesetzt, dass erst signiert und dann verschlüsselt wird. Das ist nachvollziehbar, kann doch eine Nachricht, die erst verschlüsselt und dann signiert wird, nicht mit erhaltener Signatur weitergeleitet werden (der Empfänger der Weiterleitung kann die Nachricht nicht entschlüsseln, also müsste die Verschlüsselung vor Weiterleitung aufgelöst werden. Da sich die Signatur aber auf die verschlüsselte Nachricht bezieht, ist sie nach Entschlüsselung unbrauchbar). Trotzdem kann diese Reihenfolge sinnvoll sein, nämlich wenn sich Absender und Empfänger nicht kennen. Der Empfänger kann so zunächst die zuverlässigen (in der Signatur enthaltenen und darum zuverlässigen) Absenderangaben prüfen und dann entscheiden, ob er die Nachricht überhaupt ansehen will.

Beachten Sie, dass kaum ein E-Mail-Programm in dieser Beziehung variabel ist. Meist werden nur die Varianten

akzeptiert.

Wenn beide Kommunikationspartner WiSiKo verwenden, haben Sie in dieser Hinsicht Wahlfreiheit. WiSiKo kann auch die von Enigmail, der Thunderbird openPGP Erweiterung, verwendete Inline-Kryptologie verarbeiten, bietet diese Methode aber (weil veraltet) nicht an. Nur wenn WiSiKo nicht weiß, ob der Partner es ebenfalls verwendet, werden openPGP Signatur und Verschlüsselung mit dem kombinierten Verfahren (Verschlüsselung und Signierung in einem Ergebnis) ausgeführt.