[Diese Seite ist Teil der Homepage www.daniel-rehbein.de]

Transport von E-Mails - RFC 2821


 
 Spam & Adressensammler
(Navigation 2.Ebene)  Die Thematik
(Navigation 3.Ebene)  Spam/UBE/UCE
(Navigation 4.Ebene)  Mail-Transport
(Navigation 4.Ebene)  Demo-Mailserver
(Navigation 4.Ebene)  Spam für Sie?
(Navigation 3.Ebene)  Harvester/Spider
(Navigation 3.Ebene)  RFC 2606
(Navigation 2.Ebene)  Harvester täuschen
(Navigation 2.Ebene)  Adreßlisten vergiften
(Navigation 2.Ebene)  Weitere Informationen

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.

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.

Weiterführende Informationen

Eine detailiertere Beschreibung der Headerzeilen von E-Mails und eine Anleitung zum Nachvollziehen des Laufwegs empfangener E-Mails finden Sie auf der Webseite

http://www.th-h.de/faq/headerfaq.html
 

Beispiele für Spam-Mails

Einblick in ein Postfach, in dem täglich viel Spam ankommt, können Sie nehmen auf der Webseite

http://www.mein-rechenzentrum.de/postoffice.html

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.



[Abrufstatistik]  Homepage  Impressum