Seite drucken

Der Weg einer E-Mail vom Sender zum Empfänger

Vorwort

E-Mail ist der meist genutzte Dienst im Internet und viele fragen sich des öfteren: "Welchen Weg nimmt eigentlich meine Mail, wenn ich diese abschicke?". Ich will auf diese Frage eine Antwort geben. Sollten sich aus dem Dokument Fragen ergeben, schreibt eine E-Mail an Jens Kubieziel oder nutzt das Kontaktformular.

E-Mail schreiben

Bevor du eine E-Mail versenden kannst, musst du natürlich erst einmal eine schreiben. Dies geschieht zumeist unter Benutzung eines sog. Mail User Agent (MUA) oder Mailprogrammes. Eine Auswahl solcher Programme für Windows oder Linux findet man bei dem Open Directory Projekt dmoz.

Für mein Beispiel nutze ich den MUA KMail. Die Beispielmail sieht hier so aus:
Testmail im Programm KMail
Nachdem nun die E-Mail verfasst ist, wird diese über die entsprechende Sendefunktion verschickt. Euer Mailprogramm gibt dann die Mail an den Mail Transfer Agent (MTA), oder auch Mailserver genannt, weiter. Die verschiedenen MUAs verwenden hier verschiedene Mechanismen der Weitergabe. Grob kann man diese in zwei Arten einteilen:

Piping zum Serverprozess
Diese Methode wird meines Wissens überwiegend von UNIX-basierten Systemen genutzt. Hierbei schickt der Mailclient die Daten der E-Mail im übertragenen Sinne durch eine Röhre (=Pipe; Selflinux hat eine Beschreibung zu Pipes). Am anderen Ende lauscht der Server und nimmt die empfangenen Daten entgegen. Die Daten gibt er anschliessend wie unten beschrieben weiter.
Unter anderen gehören die Programme mutt, pine oder auch KMail.
Übertragung per SMTP oder MAPI
Bei dieser Methode spielt der MUA selbst Mailserver. Der Klient überträgt die E-Mail auf die selbe Art wie unten beschrieben Erkennen kann man dies meist daran, dass man in der Einstellung einen SMTP-Server angeben muss (siehe Bild unten:
Mozilla E-Mail Setup
Zu diesen Programmen gehören u.a. Microsoft Outlook Express, Mozilla bzw. Netscape Mail und andere.

Aussehen der E-Mail

Nachdem nun die Mail beim Server abgelegt wurde, will ich einen kurzen Blick darauf werfen. So könnte die E-Mail nun aussehen:

Wie ihr sehen könnt, besteht diese E-Mail aus zwei Teilen, einem Mailkopf und dem Körper. Da die Standards i.d.R. aus dem Englischen stammen, heißen diese Bestandteile offiziell Header und Body.

Der Kopf wird immer durch eine Leerzeile vom Körper getrennt, d.h. nach der ersten Leerzeile beginnt der eigentliche Nachrichtentext, der dann wieder beim Empfänger angezeigt wird.

Bestandteile der E-Mail

Die ersten vier Zeilen der obigen Mail sollten selbsterklärend sein. Zunächst erscheint dort der Absender der E-Mail im From:. Danach findet man den Empfänger und eine Zeile später den Betreff. Die vierte Zeile schließlich enthält das Sendedatum.

Der Eintrag "User-Agent" oder bei anderen Programmen "X-Mailer" enthält den Namen des MUAs, sofern dieser dort einen Eintrag macht. Unten findet ihr eine Aufstellung von üblichen Beispielen (Die Versionsnummer sind dabei sehr verschieden.):

Die Message-ID stellt eine eindeutige Kennzeichnung der E-Mail dar. Diese sollte vom Mailserver gesetzt werden. Eindeutig heisst hier, dass keine E-Mail von einem beliebigen Absender mindestens innerhalb der nächsten zwei Jahre die gleiche Message-ID haben darf.

Diese Zeilen sagen dem empfangenden Mailprogramm, welche Art von Zeichen verwendet wurde und ob evtl. Anhänge vorhanden sind. Die Abkürzung MIME steht für Multipurpose Internet Mail Extensions.

Im obigen Fall sagen die Angaben, dass die E-Mail aus reinem Text, der kein Anhang ist ("Content-Disposition: inline"), besteht. Des weiteren enthält die E-Mail Umlaute, für deren Darstellung ein erweiterter Zeichensatz (ISO-8859-1) benötigt wird.

Falls man Anhänge verwendet, ändert sich obiges ein wenig. In der Regel wird zum Versand von Anhängen der MIME-Standard verwendet. Eine solche E-Mail würde dann ungefähr so aussehen:

Der Eintrag "Multipart/Mixed" sagt, dass diese Mail aus verschiedenen Teilen besteht. Der Text "Hier steht der normale Text" würde auch im MUA als ganz normaler E-Mail-Text angezeigt werden. Daneben gibt es noch einen Anhang namens "testbild.jpg". Die Angabe "--Boundary-00=_SK05+P40Zd5sLMZ" trennt die einzelnen Einträge voneinander.

Neben den oben erklärten Einträgen im Kopf einer E-Mail kann es noch beliebig weitere geben. Es existiert hier eine schier unerschöpfliche Vielfalt und ist nur durch die Kreativität der Nutzer begrenzt. Jeder, der die E-Mail schreibt oder weiter bearbeitet, kann einen Header setzen. Dieser muss mit einem "X-" beginnen. Unten findet ihr eine kleine Auswahl von X-Headern, die ich in meiner Mailbox fand:

Falls jemand der Leser noch einen als sehr wichtig erachtend, möge er mir bitte eine Mail schreiben. Ich werde diesen dann eventuell hier mit aufnehmen.

Transport der E-Mail

Nach dem kurzen Ausflug in das Aussehen der E-Mail komme ich nun zurück zum Transport der Mail.

Oben hatten wir eine E-Mail verfasst und diese an den Mailserver weitergereicht. Seine Aufgabe ist nun, diese E-Mail zu transportieren. Daher auch die Bezeichnung Mail Transport Agent.

Adresse des SMTP-Servers finden

Der MTA schaut sich die Mail an und stellt fest, dass diese an die Domain "gmx.de" gerichtet ist. Oftmals ist das aber nicht die Adresse des MTAs der betreffenden Domain. Deshalb muss unser MTA zunächst herausfinden, wie die Adresse des MTAs von GMX ist. Er richtet dazu eine Anfrage an einen so genannten Domain Name Server (DNS). Dieser hat Zuordnungen von Namen und Adressen gespeichert. Als Antwort erhält unser MTA, dass es zwei MTAs auf der Seite von GMX gibt. Dies sind mx0.gmx.net und mx0.gmx.de.

Unter Linux kann man das mit dem Befehl mx nachvollziehen:
kubi@QBI050102:~$ mx gmx.de
gmx.de MX 10 mx0.gmx.net
gmx.de MX 10 mx0.gmx.de

Die Zahl vor dem Eintrag gibt die Priorität an. In dem Falle ist die bei beiden zehn. Dies bedeutet, unser MTA kann sich aussuchen, welchen GMX-MTA er nutzt. Wäre die Priorität z.B. 20 und 100, dann müsste unser MTA zuerst versuchen, die Mail an den mit der höchsten Priorität (niedrigste Zahl) zuzustellen. Wenn dies scheitert, ist der MTA mit der nächstniedrigeren Priorität dran.

Unser MTA entscheidet sich, die E-Mail an die Adresse "mx0.gmx.net" zu senden. Wie ich in meinem Dokument zu IP-Adressen und Ports schon dargelegt habe, kann der Rechner mit dem Namen zunächst noch nichts anfangen. Stattdessen benötigt er eine IP-Adresse. Diese bekommt er durch eine nochmalige DNS-Abfrage nach dem Motto: "Wie ist/sind die IP-Adresse(n) von mx0.gmx.net?" und bekommt zur Antwort, dass diese 213.165.64.100 ist.

Nun weiß der Mailserver die IP-Adresse und die Zustellung kann beginnen. Hierzu nutzt man das Protokoll SMTP, was im Internet-Standard RfC 2821 genau beschrieben ist.

E-Mail übertragen

Der erste Schritt ist die Öffnung einer Verbindung zum MTA von GMX. Wenn dies erfolgreich ist, bekommt unser MTA eine Begrüßungsmeldung von GMX: (Zur besseren Unterscheidung ist der Text des MTA von GMX rot und der des sendenden MTA grün gekennzeichnet.)

220 {mx014-rz3} GMX Mailservices ESMTP
Dies ist dann für unseren MTA das Zeichen, mit der Übertragung zu beginnen. Er sendet:

EHLO kubieziel.de
Dies ist sozusagen eine Vorstellung und bedeutet "Guten Tag, mein Name ist kubieziel.de und ich spreche erweitertes SMTP (EHLO)." Eine weitere Möglichkeit wäre "HELO kubieziel.de". Hier gibt der Mailserver zu verstehen, dass er SMTP ohne Erweiterungen kann.

Daraufhin antwortet mx0.gmx.net:
250-{mx014-rz3} GMX Mailservices
250 8BITMIME
Die erste Zahl (250) sagt unserem MTA, dass alles in Ordnung ist und er weitermachen kann. Der Text dahinter kann frei gewählt werden, sollte so formuliert werden, dass auch ein menschlicher Leser diese Meldung interpretieren kann.

MAIL FROM: <jens@kubieziel.de>
Dieses Kommando beginnt die Transaktion, die die Mail an den MTA ausliefert. Hier sagt unser Mailserver: "Die Mail stammt von <jens@kubieziel.de>." I.d.R. wird der Mailserver der Gegenstelle wieder mit dem Code 250 = Alles in Ordnung antworten:

250 {mx014-rz3} ok

Danach macht unser MTA weiter:
RCPT TO: <kubieziel@gmx.de>
Dieses Kommando identifiziert den Empfänger der E-Mail. RCPT steht für das englische Wort "Recipient", was Empfänger bedeutet.

Theoretisch könnte oben auch eine andere Adresse, z.B. <kubieziel@example.com> stehen. Dies würde dann bedeuten, dass GMX nicht der endgültige Empfänger ist, sondern dass diese Mail an den MTA von example.com weiter geschickt werden muss. Dies bezeichnet man als Relaying, abgeleitet vom Wort "to relay" - übertragen.

GMX wie auch viele weitere MTAs verweigern das Relaying, da das ein Hauptgrund für Spam ist. Spamversender nutzen diese offenen Relays, d.h. MTAs, die Mails von überall annehmen und nach überall schicken. Diese Server nehmen die Spammails an und senden diese dann an die Endempfänger. Oftmals resultiert dies aus einer Fehlkonfiguration des betreffenden Servers und viele Serverbetreiber sind sich dieser Tatsache nicht bewusst.

Nun aber wieder zurück zu unserer Mail. Nachdem der GMX-Server wieder sein OK ("250 {mx014-rz3} ok") gegeben hat, folgt
DATA
Sender und Empfänger sind geklärt. Nun wird die E-Mail, wie ich sie oben besprochen hatte an den MTA von GMX geschickt. GMX behandelt diese Daten als einfachen Text ohne Bedeutung, d.h. alles, was nunmehr kommt, interessiert den MTA nicht. Er speichert diese Daten einfach ab. (Wenn der Server den DATA-Befehl annimmt, sendet er noch eine Antwort mit dem Zahlencode 354.)

Wichtig ist noch der Punkt am Ende. Immer wenn ein einzelner Punkt am Zeilenanfang auftaucht, heißt das: "Hier ist der Datenblock der E-Mail zu Ende." Alles, was jetzt folgt, nimmt der MTA wieder als Befehl entgegen.

Findige Köpfe werden nun die Idee haben, den Mailserver auszutricksen. Sie schreiben in ihrem Mailprogramm einfach eine leere Zeile mit einem Punkt und danach eventuell Text oder ähnliches. Das wird nicht funktionieren. Denn falls eine E-Mail selbst einen Punkt im Text enthält, muss dieser "geschützt" werden, in dem man einen Punkt voran stellt. D.h. eine E-Mail, die in eurem MUA so aussieht:
Text
.
Text
sieht dann im SMTP-Dialog mit dem Server so aus:
Text
..
Text

So weiß der MTA, dass dies noch nicht das Ende der E-Mail ist, sondern nur ein Punkt, der nicht zu beachten ist.

Wie ich oben schon schrieb, ist der Datenteil (=alles nach DATA und vor dem Punkt) dem MTA egal. D.h. dort kann im Grunde stehen, was will. Z.B. hätte ich als From-Adresse auch "Bundeskanzler <kanzler@example.org>" oder ähnliches wählen können.

Dies ist wiederum ein Punkt, den sich auch viele Spamversender zu Nutze machen. Sie tragen als Absender und Empfänger beliebige Namen ein. Oftmals wird auch das Datum (Date:) manipuliert.

Die Übertragung unserer E-Mail ist nun beendet. Deshalb sendet unser MTA noch
QUIT
an den GMX-Mailserver und dieser antwortet mit
221 {mx014-rz3} GMX Mailservices

Hier nochmal der komplette Dialog zwischen GMX und unserem Mailserver:
220 {mx014-rz3} GMX Mailservices ESMTP
EHLO kubieziel.de
250-{mx014-rz3} GMX Mailservices
250 8BITMIME
MAIL FROM: <jens@kubieziel.de>
250 {mx014-rz3} ok
RCPT TO: <kubieziel@gmx.de>
250 {mx014-rz3} ok
DATA
354 {mx014-rz3} Go ahead
From: Jens Kubieziel <jens@kubieziel.de>
To: kubieziel@gmx.de
Subject: Test
Date: Wed, 11 Jun 2003 15:32:00 +0200
User-Agent: KMail/1.5.1
Message-Id: <200306111531.10719@kubieziel.de>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Das ist eine Testmail.
Gruß
Jens
.
250 {mx014-rz3} Message accepted
QUIT
221 {mx014-rz3} GMX Mailservices

Jetzt fügt GMX noch einen wichtigen Punkt an den Beginn des Kopfes der E-Mail hinzu, die sog. Received-Zeile. Dies ist eine Information, von wo der GMX-Server die E-Mail bekommen hat. Jeder Mailserver, über den die Mail gesandt wird, fügt diese Informationen hinzu:

Dies heißt: "Ich habe eine E-Mail von einem Rechner erhalten, der sich 'kubieziel.de' genannt hat. Sein richtiger Name war 'D5eb0.pppool.de' und hatte die IP-Adresse 80.184.94.176. Die Transaktion fand am 2003-06-11 um 15:32:04 Uhr statt."

GMX legt nun die E-Mail in mein Postfach ab, wo ich diese später wieder abhole und lese.

Dies ist die E-Mail nachdem ich diese abgerufen habe:

Im Webinterface von GMX sieht diese so aus:
Ansicht der E-Mail bei GMX
Später, als ich diese heruntergeladen habe, kann ich sie ebenfalls in meinem lokalen MUA betrachten: Ansicht der E-Mail in mutt

Literaturhinweise

Weiterführende Texte bzw. die Links zu den betroffenen RfCs findest du im folgenden:

FAQs und Einführungen

Erklärung zum Transport von E-Mails von Daniel A. Rehbein
http://www.daniel-rehbein.de/rfc2821.html
FAQ der Gruppe de.admin.net-abuse.mail
FAQ von de.admin.net-abuse.mail
"E-Mail-Header lesen und verstehen" von Thomas Hochstein
http://th-h.de/faq/headerfaq.php
E-Mail-Einführung des Förderverein Informationstechnik und Gesellschaft
http://www.fitug.de/bildung/e-mail/e-mail.html
Mail-Einführung von Boris 'pi' Piwinger
http://piology.org/mail/
Verzeichnis diverser RfCs, die E-Mail betreffen
http://www.tin.org/docs.html
The MIME Information page
http://hunnysoft.com/mime/

RfCs

RfC 2045 - MIME Part One: Format of Internet Message Bodies
http://www.ietf.org/rfc/rfc2045.txt
RfC 2046 - MIME Part Two: Media Types
http://www.ietf.org/rfc/rfc2046.txt
RfC 2047 - MIME Part Three: Message Header Extensions for Non-ASCII Text
http://www.ietf.org/rfc/rfc2047.txt
RfC 2048 - MIME Part Four: Registration Procedures
http://www.ietf.org/rfc/rfc2048.txt
RfC 2049 - MIME Part Five: Conformance Criteria and Examples
http://www.ietf.org/rfc/rfc2049.txt
RfC 2076 - Common Internet Message Headers
http://www.ietf.org/rfc/rfc2076.txt
RfC 2821 - Simple Mail Transfer Protocol
http://www.ietf.org/rfc/rfc2821.txt
RfC 2822 - Internet Message Format
http://www.ietf.org/rfc/rfc2822.txt
MIME Media Types
http://www.iana.org/assignments/media-types/

Versionen

Version Änderungen Datum
1.6 kurze Erklärung von 354 nach einem Hinweis von Stefan Klose. 2005-09-20
1.5 In der Newsgroup de.comm.software.mailserver kündigte Daniel A. Rehbein an, dass er eine Einführung zum E-Mail-Transport geschrieben hat. Ich habe diesen Link heute mit aufgenommen. 2004-02-10
1.4 Weitere Vorschläge von Thomas Lotze eingebaut. U.a. eine Beschreibung der div. Übertragungsarten vom MUA zum MTA und Ansicht der E-Mail nach dem Empfang. 2003-07-09
1.3 Thomas Lotze gab mehrere gute Hinweise um Unklarheiten im Text zu korrigieren. Diese wurden zum Großteil angepasst. 2003-07-02
1.2 farbliche Unterscheidung der SMTP-Dialoge, Hervorhebung der E-Mail-Erklärung, Verweise zu den MUAs hinzugefügt 2003-06-24
1.1 Erstnennung von MUA und MTA hingefügt, Description angepasst 2003-06-20
1.0 Initialversion des Textes 2003-06-12