 |
 |
 |
![[Diese Seite ist Teil der Homepage www.daniel-rehbein.de]](http://www.daniel-rehbein.de/rahmen-link.gif) |
| |
| |
| |
| |
|
Transport von E-Mails - RFC 2821
|
 |
|
Ein Problem beim Umgang mit den Internet, so auch mit dem Medium E-Mail, ist die Tatsache, daß viele
technische Vorgänge für den gewöhnlichen Benutzer verborgen bleiben.
Während bei der herkömlichen Briefpost
sich der Brief anfassen und so im wahrsten Sinn des Wortes "begreifen" läßt und man auch zumindest eine
ungefähre Vorstellung davon hat, wie die Post den Brief transportiert und der Briefträger ihn schließlich
in den Hausbriefkasten des Empfängers einwirft, so erscheint eine E-Mail vergleichsweise überraschend wie
von Zauberhand auf dem Bildschirm.
So entsteht bei zahlreichen Personen die Meinung "der Komputer kann und weiß alles" und es besteht
unbegrenzter Glaube in die auf dem Monitor angezeigten Daten, als würde es sich um amtliche Dokumente
handeln.
Die Folgen davon bekommen Personen zu spüren, deren E-Mail-Adressen die Versender von Massenmails
oder die Programmierer von Viren/Würmern als Absenderadressen eintragen. Die völlig unbeteiligten Personen
bekommen im E-Mail-Postfach, telephonisch oder sogar per Briefpost den Unmut der Empfänger ab. Die Palette
reicht von einfachen Rückfragen bis zu Beschimpfungen und strafrechtlich relevanten Bedrohungen.
Tatsächlich aber ist die auf dem Bildschirm angezeigte Absenderadresse eben gerade keine geprüfte
Information. Sondern sie kann vom tatsächlichen Absender genauso frei gewählt werden wie im klassischen
Briefverkehr die Adresse, die man als Absender auf den Briefumschlag schreibt.
|
 |
 |
Im herkömmlichen Briefverkehr ist uns dieser Umstand bekannt. Keiner würde auf die Richtigkeit
vertrauen, wenn beispielsweise auf einer Morddrohung als Absender die Adresse des örtlichen Bürgermeisters
steht. Zum Glück bekommt man eher selten Briefe von Personen, die ihre Identität nicht preisgeben wollen.
Denn jeder einzelne Brief kostet den Absender Zeit und Geld.
Im Internet ist dies anders: Die einzelne E-Mail verursacht quasi keinerlei Kosten und auch keinerlei Mühe.
Spam-Versender verschicken mit simplen Programmen Millionen von E-Mails, ohne daß ein Benutzer den
Vorgang beaufsichtigen oder gar von Hand eingreifen müsste. Und damit diese E-Mails vertrauenserwechend
wirken und nicht sofort gelöscht werden, wird auch eine Absenderadresse eingetragen.
Diese Absenderadressen stammen auch aus dem Adreßbestand des Spam-Versenders oder werden zu existieren
Domains anhand von Wortlisten generiert. Viren und Würmer, die sich per E-Mail versenden, nehmen häufig
sowohl als Absender- und als Empfängeradresse E-Mail-Adressen, die sie auf der Festplatte ihres Opfers
finden.
Im Folgenden werde ich erläutern, wie der Transport von E-Mail geschieht und damit darstellen, welche
Angaben in einer E-Mail vertrauenswürdig sind und welche nicht.
|
 |
So werden E-Mails transportiert
Der Transport von E-Mails im Internet erfolgt nicht über eine zentrale Stelle, sondern ist eine
gewöhnliche TCP/IP-Kommunikation genauso wie der Abruf von Webseiten oder Dateiübertragungen per FTP.
Es gibt also keine zentrale Kontrolle von E-Mails und auch keine Möglichkeit, eine Gebührenpflicht
für E-Mails einzuführen (was angesichts der Spam-Flut häufig gefordert wird).
Der Transport von E-Mails erfolgt mit dem Protokoll SMTP (Simple Mail Transfer Protocol). Dieses
ist definiert in dem technischen Standard RFC 2821. Der (englische) Originaltext dieses Protokolls, das
ich im folgenden näher skizzieren werde, kann unter www.faqs.org/rfcs/rfc2821.html
nachgelesen werden.
Das Protokoll SMTP regelt die Weitergabe einer E-Mail von einem an das Internet angeschlossenen Rechner
an einen anderen. Verglichen mit der gewohnten Briefpost kann man es als Vorschrift sehen, wie ein Brief
von einer Person an eine andere zum Weitertransport oder zum Empfänger weitergegeben wird: Der Absender
eines Brief übergibt diesen an ein Postunternehmen (in Deutschland meistens die Deutsche Post AG), deren
örtliche Niederlassung sorgt für den Transport in die richtige Stadt. Dort bekommt ein Briefträger den Brief
und stellt ihn zu. Wenn der Empfänger in einem größeren Unternehmen sitzt, landet der Brief erst bei der
Hauspost und wird dann unternehmensintern zugestellt. Wenn der Empfänger gerade auf Geschäftsreise ist, wird
ihm der Brief vielleicht sogar hinterhergeschickt. Es können also zahlreiche und je nach Einzelfall unterschiedlich
viele Stationen am Transport eines einzelnen Briefes beteiligt sein. Genauso können auch beim Transport einer
E-Mail durch das Internet unterschiedlich viele Rechner beteiligt sein. Jede Übergabe einer einzelnen E-Mail
von einem Rechner zum nächsten erfolgt anhand des Protokolls SMTP.
Nun werden Sie sich vielleicht fragen, warum ich nicht auf das Protokoll POP3 (Post Office Protocol 3)
eingehe. Denn zum Empfang von E-Mail stellt man in der Regel einen POP3-Server ein. Nun, POP3 ist eine
Besonderheit, die bei dieser Betrachtung keine Rolle spielt. Denn POP3 ist kein Protokoll zum Transport
von E-Mail, sondern lediglich vom Abholen von E-Mails, die auf einem Server bereitliegen.
Da der durchschnittliche Internetnutzer in der Regel keine feste IP-Adresse hat, sondern jeweils für die Zeitdauer
der Internetverbindung eine zugeteilt bekommt, macht es keinen Sinn, E-Mails an ihn direkt zuzustellen. Statt
dessen werden die E-Mails auf einem Server mit fester Adresse abgelegt und können dann mit POP3 abgeholt
werden. Im realen Leben wäre dies so, als ob sich unsere Hausnummer ständig ändern würde. Damit wir
trotzdem Post empfangen können, hängen wir keinen Briefkasten neben die Haustür, sondern lassen uns im
Postamt ein Postfach geben. Die Post wird dann nicht direkt nach Hause, sondern wird an das Postfach geliefert.
POP3 entspricht dem (regelmäßigen) Gang ins Postamt, um im Postfach nachzuschauen, ob Post eingetroffen ist, und
diese Post ggf. abzuholen. Für den eigentlichen Transport von E-Mail spielt POP3 keine Rolle. Deshalb gehe
ich hier nur auf das Protokoll SMTP ein.
|
 |
Simple Mail Transfer Protocol (SMTP)
Das Protokoll SMTP überträgt wie die meisten im Internet genutzten Protokolle einfachen Text (ASCII), keine
Binärdaten. Eventuelle Binärdaten (z.B. Dateianhänge) werden nach einer festgelegten Codierung (base64) als
Buchstaben übertragen. Da die Kommunikation zur Übertragung einer E-Mail im Klartext erfolgt, kann man
E-Mails also auch von Hand übertragen. Man kann also das, was sonst eigentlich eine Software erledigt, direkt
an der Tastatur nachvollziehen.
Eine einfache Textverbindung über TCP/IP, also dem Internet, kann man mit jedem Terminalprogramm
aufbauen. Ein simples Terminalprogramm, das an der Kommandozeile gestartet wird (unter Windows also an
der MS-DOS-Eingabeaufforderung) ist das Programm Telnet. Dieses wird einfach aufgerufen, indem man den
Namen Telnet, gefolgt von dem Namen des anzusprechenden Servers und der TCP/IP-Portnummer eingibt. Für die
Übertragung von E-Mails ist es wichtig, die Portnummer 25 anzugeben, denn ohne Angabe einer Portnummer
versucht Telnet, eine Verbindung zu Port 23 aufzubauen.
Um eine E-Mail an einen Mailserver von T-Online, mailin00.sul.t-online.de, zu übergeben, startet man
also telnet mit: telnet mailin00.sul.t-online.de 25. Der Mailserver
von T-Online antwortet mit: 220 mailin00.sul.t-online.de T-Online ESMTP receiver
fssmtpd ready.. Gibt man nun in Großbuchstaben den Befehl QUIT ein, so antwortet
der Server mit 221 mailin00.sul.t-online.de closing und beendet die Verbindung.
Wartet man zu lange, so beendet der Server die Verbindung von sich aus. Der Mailserver ist sehr ungeduldig. ;-)
An diesem kleinen Beispiel sieht man schon den prinzipiellen Ablauf der SMTP-Kommunikation: Ähnlich wie bei
einem Telephonanruf meldet sich der Server mit seinem Namen und einer Begrüßung. Dem Server gibt man dann
Befehle, die jeweils aus vier Buchstaben bestehen und grundsätzlich in Großbuchstaben geschrieben werden. Die
Antworten des Server beginnen jeweils mit einem dreistelligen Zahlencode. Beginnt die Zahl mit der Ziffer 2,
so ist alles in Ordnung. Beginnt sie mit Ziffer 3, so wartet der Server auf die Übertragung von Daten.
Die Ziffer 4 signalisiert, daß ein Fehler auf dem Server aufgetreten ist, die Anfangsziffer 5 dagegen,
daß derjenige, der Mail einliefern will, einen Fehler gemacht hat. Zahlencodes mit anderen Anfangsziffern sind
nicht zulässig.
Folgt nach der dreistelligen Zahl ein Leerzeichen, so ist die Meldung des Servers mit der
betreffenden Zeile abgeschlossen. Folgt dagegen nach der dreistelligen Zahl ein Bindestrich (Minuszeichen), so
folgende noch weitere Zeilen nach. Dies sieht man z.B., wenn man sich mit einem Mailserver des Online-Dienstes
AOL verbindet. Wieder habe die die selbst eingegebenen Zeilen in blau und die
Antworten des Servers in rot wiedergegeben:
telnet mailin-01.mx.aol.com 25
220-rly-yg04.mx.aol.com ESMTP mail_relay_in-yg4.6
220-America Online (AOL) and its affiliated companies do not
220- authorize the use of its proprietary computers and computer
220- networks to accept, transmit, or distribute unsolicited bulk
220- e-mail sent from the internet. Effective immediately: AOL
220- may no longer accept connections from IP addresses which
220 have no reverse-DNS (PTR record) assigned.
QUIT
221 SERVICE CLOSING CHANNEL
Der Mailserver von AOL meldet sich mit einer mehrzeiligen Begrüßung. Daß jeweils noch eine weitere
Zeile folgt, signalisiert er durch den Bindestrich nach der Zahl. Erst, wenn nach der dreistelligen Zahl
ein Leerzeichen folgt, hat der Server seine Ausgabe beendet und wartet auf Eingaben. Die Zeilen mit
Bindestrich werden auch als "Fortsetzungszeilen" bezeichnet.
Wenn Sie diesen Dialog selbst nachvollziehen wollen, so ist es erforderlich, daß Sie direkte
TCP/IP-Kommunikation mit dem Internet haben, d.h. das Ihr Rechner entweder direkt ins Internet
einwählt oder Sie über einen Router mit dem Internet verbunden sind. Wenn Sie dagegen in einem
Unternehmen sitzen, dessen Netz lediglich über einen Proxy-Server mit dem Internet kommuniziert, dann
kommt die Telnet-Verbindung nicht zustande.
Wie wird nun eine E-Mail übertragen? In den bisherigen beiden Beispielen folgte direkt nach dem
Verbindungsaufbau bereits die Verabschiedung mit QUIT. Dies ist natürlich untypisch. Der
Ablauf der Übertragung einer E-Mail erfolgt ähnlich wie die telephonische Aufgabe eines Telegramms: Nachdem man
freundlich begrüßt wurde, sagt man selbst auch eine Grußformel und trägt dann sein Anliegen vor, d.h.
man nennt Absender und Empfänger, teilt den Text der Nachricht mit und verabschiedet sich erst danach
wieder.
Der folgende Ablauf zeigt die Übergabe einer Mail an beispiel.adresse@magik.de an den Server
mailin.webmailer.de, den Mailserver des Providers Strato:
telnet mailin.webmailer.de 25
220 mailin.webmailer.de ESMTP Sendmail 8.12.10/8.12.10
HELO ich
250 mailin.webmailer.de Hello, pleased to meet you
MAIL FROM:<x@x>
250 2.1.0 <x@x>... Sender ok
RCPT TO:<beispiel.adresse@magik.de>
250 2.1.5 <beispiel.adresse@magik.de>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
From: Irgendein Absender <a@b>
To: Internet Teilnehmer
Subject: Eine kleine E-Mail
Hallo Daniel,
dies ist eine E-Mail.
Alles Gute!
.
250 2.0.0 i0AJZIo0017718 Message accepted for delivery
QUIT
221 2.0.0 mailin.webmailer.de closing connection
Hier sehen wir die wichtigsten Befehle im SMTP-Dialog und ihre Reihenfolge: Mit HELO
(auch EHLO ist möglich) und der Nennung des eigenen Namens wird der Server begrüßt.
Mit MAIL wird die Absenderadresse übermittelt, mit RCPT die
Empfängeradresse. Mit dem Kommando DATA wird die Übermittlung der E-Mail eingeleitet
und schließlich kommt die Verabschiedung mit QUIT.
|
Selbst ausprobieren
Diese Übermittlung einer E-Mail können Sie natürlich mit Ihrer eigenen E-Mail-Adresse ausprobieren.
Den Mailserver für Ihre E-Mail-Adresse können Sie über das Formular auf der folgenden Seite abfragen:
http://mailserver.aplerbeck.net
|
Bei den Befehlen MAIL und RCPT wird mit FROM: bzw. TO:
die E-Mail-Adresse eingeleitet. Die Adresse selbst wird in spitze Klammern geschrieben. Der Befehl RCPT
kann auch mehrfach angegeben werden, um diesselbe E-Mai an mehrere Empfänger zu schicken. Mit dem Code 250
signalisiert der Mailserver, daß er die Adressen akzeptiert. Obwohl es die Absenderadresse "x@x" gar nicht
geben kann (es gibt keine Domain "x"), wird diese akzeptiert. Der Mailserver von Strato prüft nur, ob das
Zeichen "@" in der Adresse vorkommt. Andere Mailserver prüfen tatsächlich, ob die Domain nach dem "@"-Zeichen
wirklich existiert, dann wäre "x@x" nicht möglich. Im Rahmen dieser Prüfungen aber kann man jede beliebige
E-Mail-Adresse als Absender eintragen.
Nach dem Befehl DATA signalisiert der Server mit Code 354, daß er nun die
Übertragung des Mailinhalts erwartet. Die Mail wird zeilenweise übertragen, wobei auch Leerzeilen möglich
sind. Die Übermittlung der Mail wird mit einer einzelnen Zeile, die nur aus einem Punkt besteht, beendet.
Beinhaltet die Mail ihrerseits Zeilen, die nur aus einem Punkt bestehen, oder die mit einem Punkt
beginnen, so ist ein zweiter Punkt voranzustellen.
Warum tauchen innerhalb der E-Mail wieder Absender- und Empfängeradressen auf?
Ähnlich wie bei der Briefpost unterscheidet man auch bei E-Mail zwischen der Transporthülle, dem Briefumschlag,
und dem eigentlichen Brief. Und wie bei guter Geschäftskorrespondenz üblich, stehen Absender und Empfänger nicht
nur außen auf dem Umschlag, sondern auch auf dem Brief selbst, wo auch Datum, Geschäftszeichen, Betreff und andere
Informationen notiert werden.
Die bei MAIL und RCPT übermittelten Daten entsprechen
dem Umschlag, das nach DATA gesendete ist die eigentlich E-Mail. Darin sind die
Zeilen bis zur ersten Leerzeile die sogenannten Headerzeilen, der Briefkopf. Die Angaben im Briefkopf
müssen nicht unbedingt mit den Angaben auf dem Umschlag übereinstimmen.
In der Regel sorgt die Software, mit der man Mails verschickt, dafür, daß die Angaben auf dem Umschlag
mit den Headerzeilen übereinstimmen. Wenn man aber einen Empfänger als "bcc" (blind carbon copy, d.h.
Durchschlag schicken, ohne die eigentlichen Empfänger dies merken zu lassen) einträgt,
so wird dessen Adresse nur auf den Umschlag geschrieben, nicht in die Headerzeilen der Mail. Insofern ist
die Tatsache, daß die Angaben auf dem Umschlag und in den Headerzeilen voneinander abweichen können,
nichts Ungewöhnliches.
|
 |
Offene und sichere Mail-Relays
Zu jeder Domain, die am E-Mail-Verkehr teilnimmt, ist mindestens ein Server definiert, der E-Mails für
diese Domain annimmt. Bei den bisherigen Beispielen wurde jeweils direkt dieser Server angesprochen.
Bei T-Online ist dies mailin00.sul.t-online.de, bei aol.com heißt der Mailserver mailin-01.mx.aol.com und
für Domains, die bei dem Provider Strato liegen, heißt der empfangende Mailserver mailin.webmailer.de.
Der direkte Verbindungsaufbau zu den empfangenden Mailserver bedeutet übertragen auf die Briefpost,
daß man persönlich zum Empfänger hinfährt und einen Brief in dessen Briefkasten einwirft. In der Regel
stellt man seine Briefe aber nicht selbst zu, sondern übergibt sie einem Postunternehmen (in
Deutschland der Deutschen Post AG), die sich dann um den weiteren Transport kümmert.
Auch dies findet seine Entsprechung im E-Mail-Verkehr: Man stellt E-Mails in der Regel nicht selbst
zu, sondern liefert sie bei einem Mailserver seines Providers ein, der sich dann um den Weitertransport
kümmert. Der Mailserver des Providers findet dann heraus, welcher Server die Mail für den Empfänger
entgegennimmt und leitet sie entsprechend weiter. Wenn Sie z.B. Kunde bei T-Online sind, so schicken Sie
Ihre ausgehenden E-Mails an mailto.t-online.de oder an smtprelay.t-online.de, von wo sie dann weiterverschickt
werden. Diese Server werden auch als Relayserver bezeichnet, denn sie dienen nur als Zwischenstation
(Relay) für die E-Mails. Wenn Sie in einem größeren Unternehmen sitzen, haben Sie vielleicht einen eigenen
Mailserver im internen Netz. Dann liefern Sie die E-Mails dort ab, sie gehen dann weiter zu einem
Mailserver Ihres Providers und dieser verteilt dann die E-Mails weltweit an die Mailserver der Empfänger.
Es sind in der Regel verschiedene Server, mit denen Post verschickt und empfangen wird: Der Server
mailto.t-online.de nimmt E-Mails nur von T-Online-Kunden an und verteilt sie weltweit im Internet. Der
Server mailin00.sul.t-online.de nimmt E-Mail aus dem weltweiten Internet an, sofern sie an T-Online-Kunden
adressiert sind, und ordnet die E-Mails den Kunden zu.
Als "offene Relays" bezeichnet man Mailserver, die aufgrund einer fehlerhaften Konfiguration Mails
aus dem weltweiten Internet entgegennehmen und auch wieder weltweit weiterverschicken. Spam-Versender
verschicken ihre E-Mails bevorzugt über offene Relays, um damit die Herkunft der Werbemails zu verschleiern.
Zudem kann ein Versender von Massenmails seinen eigenen Zeitaufwand erheblich reduzieren, wenn er die
Mails nicht direkt zustellt, sondern einem offenen Relay übergibt. Mit einem Übertragungsvorgang kann
er eine Mail mit vielen unterschiedlichen Empfängeradressen versehen. Die Weiterverteilung, d.h. das
Herausfinden des jeweiligen Mailservers der einzelnen Empfänger und die Zustellung an jeden einzelnen
Empfänger, übernimmt der als offenes Relay konfigurierte Mailserver.
Richtig konfigurierte Mailserver nehmen entweder nur E-Mails der eigenen Kunden entgegen und leiten
diese weiter, oder nehmen Mails von überall an und leiten diese nur an die eigenen Kunden weiter.
Übergibt man zum Beispiel dem Server von AOL, mailin-01.mx.aol.com, eine Mail an die
Adresse beispiel.adresse@magik.de, die bei Strato verwaltet wird, so lehnt er deren Transport ab:
telnet mailin-01.mx.aol.com 25
220-rly-yg04.mx.aol.com ESMTP mail_relay_in-yg4.6
220-America Online (AOL) and its affiliated companies do not
220- authorize the use of its proprietary computers and computer
220- networks to accept, transmit, or distribute unsolicited bulk
220- e-mail sent from the internet. Effective immediately: AOL
220- may no longer accept connections from IP addresses which
220 have no reverse-DNS (PTR record) assigned.
HELO daniel
250 rly-xj06.mx.aol.com OK
MAIL FROM:<xyz@example.org>
250 OK
RCPT TO:<beispiel.adresse@magik.de>
550 INCORRECT DOMAIN IN MAIL/RCPT COMMAND
DATA
503 BAD SEQUENCE OF COMMANDS
QUIT
221 SERVICE CLOSING CHANNEL
Die genauen Texte der Fehlermeldungen können je nach Server unterschiedlich sein. Die Zahlencodes
sind jedoch in der Spezifikation des Protokolls SMTP festgelegt, lauten also bei allen Mailservern gleich.
Mails an AOL-Benutzer nimmt der Mailserver von AOL natürlich entgegen:
telnet mailin-01.mx.aol.com 25
220-rly-yg04.mx.aol.com ESMTP mail_relay_in-yg4.6
220-America Online (AOL) and its affiliated companies do not
220- authorize the use of its proprietary computers and computer
220- networks to accept, transmit, or distribute unsolicited bulk
220- e-mail sent from the internet. Effective immediately: AOL
220- may no longer accept connections from IP addresses which
220 have no reverse-DNS (PTR record) assigned.
HELO daniel
250 rly-xj06.mx.aol.com OK
MAIL FROM:<xyz@example.org>
250 OK
RCPT TO:<example@aol.com>
250 OK
DATA
354 START MAIL INPUT, END WITH "." ON A LINE BY ITSELF
Subject: E-Mail Demonstration
This is a test mail.
.
250 OK
QUIT
221 SERVICE CLOSING CHANNEL
Hier sieht man auch wieder recht deutlich, daß eine Prüfung der Absenderadresse generell gar nicht möglich
ist. Die Absenderadresse xyz@example.org habe ich bei der Kommunikation mit dem AOL-Mailserver tatsächlich
so angegeben und sie ist akzeptiert worden. Denn ich selbst bin nicht Kunde von AOL, sondern ein
Außenstehender, der eine E-Mail an den AOL-Kunden mit der Adresse example@aol.com abgibt. Der Mailserver von AOL weiß
nichts über mich und hat deshalb auch keine Möglichkeit der Prüfung, ob xyz@example.org meine Adresse ist oder
nicht. Zwar könnte der Mailserver meines Providers meine Angaben prüfen, wenn ich ihn mit dem E-Mail-Transport
beauftrage. Liefere ich aber (wie hier) die Mail direkt beim Mailserver des Empfängers ab, so kann es
gar keine Prüfung meiner Absenderangabe geben. Außerdem habe ich auch jederzeit die Möglichkeit, meinen
Provider, der meine E-Mail transportiert, zu wechseln - im Internet weltweit.
Auch hier gibt es wieder eine direkte Entsprechung zur gewohnten Briefpost: Selbst dann, wenn die Deutsche
Post AG Briefe nur noch nach Prüfung des Absenders entgegennähme, so würde dies nicht bedeuten, daß ich mich auf
die Absenderadressen der Briefe, die in meinem Hausbriefkasten landen, verlassen kann. Denn die Deutsche
Post AG muß auch Briefe aus dem Ausland entgegennehmen, wo sie gar keine Möglichkeit zur Prüfung des
Absenders hat. Außerdem ist mein Briefkasten nicht nur für den Briefträger der Deutschen Post AG zugänglich.
Auch andere Postunternehmen, Botendienste oder Zeitschriftenverteiler können dort Briefe und andere Sendungen
einwerfen. Schließlich steht es auch jedem Absender frei, seine Post gar keinem Unternehmen anzuvertrauen, sondern
sie eigenhändig in meinen Briefkasten einzuwerfen. Wie soll ich da noch prüfen können, ob die Absenderangabe
auf dem Umschlag wirklich der Name des Absenders ist? Die einzige Alternative wäre, den Briefkasten
abzuschrauben und gar keine Post mehr entgegenzunehmen.
|
 |
Der Transportweg einer E-Mail
Ich habe erläutert, daß man bei der Übertragung einer E-Mail eine beliebige Absenderadresse
eintragen kann, so wie man auf einen Brief frei nach seiner Phantasie jeden Namen als Absender
auf den Umschlag schreiben kann. Bei Briefen kann man jedoch anhand des Poststempels nachvollziehen,
an welchem Tag und in welchem Ort (bzw. im Bereich welchen Postzentrums) der jeweilige Brief
eingeliefert wurde.
Solche Kennzeichnungen gibt es auch im Internet: Allerdings werden diese nicht auf den Umschlag
geschrieben, sondern in die Headerzeilen. Und die Kennzeichnung erfolgt nicht nur bei der
Einlieferung der E-Mail am ersten Server, sondern jeder einzelne Server, der via SMTP am Transport
beteiligt ist, schreibt eine Art Poststempel in die Headerzeilen. Man kann es vergleichen mit einem
großen Unternehmen und dessen interner Hauspost: Jeder ankommenden Brief wird geöffnet und mit
einem Posteingangsstempel versehen. Dann wird der Brief wieder in den Umschlag gepackt und an die
richtige Abteilung weitergeleitet. Diese holt den Brief wieder aus dem Umschlag und drückt wieder
einen Posteingangsstempel auf das Papier, bevor der Brief dann der richtigen Person ausgehängt wird,
die vielleicht auch wieder ein Namenskürzel draufschreibt.
Die Informationen des Umschlags, also die bei den SMTP-Befehlen MAIL
und RCPT übermittelten Adressen, werden unverändert von Server zu Server
weitergereicht. In der Regel schreibt der letzte am Transportweg beteiligte Server diese Adressen
mit der Bezeichnung "X-Envelope-From" und "X-Envelope-To" in die Headerzeilen der E-Mail.
Die Kennzeichnungen für die Beteiligung am Mailtransport, die den Poststempeln oder
Posteingangsstempeln entsprechen, stehen unter dem Namen "Received" in den Headerzeilen. Ähnlich wie
bei einer klassischen Aktenordnung die neuen Blätter oben abgeheftet werden (so daß die aktuellsten
Informationen immer vorne stehen), werden auch ergänzte Headerzeilen immer oben ergänzt. Die
Headerzeilen sind also in ihrer zeitlichen Chronologie von unten nach oben zu lesen.
Die Anzeige der Headerzeilen einer E-Mail erfolgt je nach verwendeter E-Mail-Software unterschiedlich.
In Mozilla-Mail beispielsweise erhält man Einblick in den E-Mail-Header mit dem Tastenkürzel "Steuerung-U",
in Outlook-Express mit "Steuerung-F3". In anderen Mailprogrammen erfährt man die Headerzeilen unter Menüpunkten
wie "Header anzeigen", "Kopfzeilen", "Mail-Optionen" oder "Mail-Quelltext".
Zu beachten ist, daß die verschiedenen Server, die am Transport von E-Mails beteiligt sind,
völlig unterschiedliche Software verwenden können. Demnach ist auch die genaue Syntax und der
Informationsgehalt der Received-Zeilen im Header unterschiedlich.
Auch muß nicht jede dieser Zeilen vertrauenswürdig sein. Der Versender einer Spam-Mail kann seine
E-Mail mit echt aussehenden Headerzeilen versehen, die einen Versand über irgendwelche Server in Deutschland
vortäuschen, die E-Mail dann aber über ein offenes Relay beispielsweise in Fernost oder Lateinamerika
versenden. Vertrauenswürdig ist zunächst nur die oberste der Received-Zeilen im Header, denn diese stammt
vom Mailserver des Empfängers. Für die nachfolgenden Zeilen muß man sich im Einzelfall ein Urteil
bilden, ob diese zueinander plausibel sind.
|
 |
Software zur Kommunikation mit Mailservern
In meinen Beispielen habe ich stets das Programm telnet benutzt. Auf der Folgeseite zeige ich
ein kleines Java-Programm, mit dem man ohne viel Tipparbeit das SMTP-Protokoll nachvollziehen kann
und gebe in einem Formular die Gelegenheit, zu einer Domain den empfangenden E-Mail-Server
herauszufinden.
|
 |
|
 |
 |
 |
 |
|