|
Archive-name: de-net-abuse/email-header-faq
Last-modified: 2005-01-11 Version: 1.3.0 Posting-frequency: monthly URL: http://th-h.de/faq/headerfaq.php See reader questions & answers on this topic! - Help others by sharing your knowledge ****** E-Mail-Header lesen und verstehen ******
***** Letzte �nderungen *****
2005-01-11:
Komplette �berarbeitung (prim�r Layout, aber mit inhaltlichen
Erg�nzungen und �nderungen).
***** Inhalt *****
I. Vorwort
II. Aufbau und Zustellung einer E-Mail
1. SMTP-Envelope
2. Header
3. Body
4. Vorgehen bei der Zustellung
III. E-Mail-Headerzeilen im einzelnen
1. Anschrift, Absender u. Verwandtes - kurz: der Briefkopf
2. "Technische" Angaben
3. "Zustellvermerke": den Weg einer E-Mail nachvollziehen
4. Spezielle Headerzeilen
IV. Hilfreiche Tools f�r die Headeranalyse
1. nslookup (host/dig)
2. whois
3. traceroute
4. Programmpakete und Bezugsquellen
5. Finger-Gateway auf info.belwue.de
6. Online-Tools
7. abuse.net
8. Blacklists auswerten
V. Beschwerden �ber unerw�nschte Massen-E-Mail
1. Wo kann ich mich beschweren?
2. Wie beschwere ich mich?
VI. Headerzeilen anzeigen lassen
1. Mailclients
2. Webmail
VII. Weiterf�hrende Hinweise
VIII. Credits
IX. Lizenz
***** I. Vorwort *****
Zweck dieser im September 1998 begonnenen FAQ ist es, grundlegende
Informationen �ber den Aufbau einer Internet-E-Mail [1] und die
Bedeutung der einzelnen Headerzeilen ("Kopfzeilen") zu vermitteln, um
insbesondere den Weg einer E-Mail zur�ckzuverfolgen, den Absender bzw.
die beteiligten Mailserver herauszufinden und sich bei unerw�nschter
Massen-E-Mail (Bulkmail oder UBE/UCE [2]) oder anderen unerw�nschten
Zusendungen wie Viren oder W�rmern gezielt an den richtigen Stellen
beschweren zu k�nnen.
Nicht beabsichtigt ist eine Zusammenstellung der standardisierten
und/oder allgemein �blichen Headerzeilen und ihrer Bedeutung [3] oder
eine genaue technische Definition der jeweils erlaubten Inhalte [4]
(vielleicht noch einschlie�lich der h�ufigsten Verst��e dagegen durch
weitverbreitete Mailprogramme ;-)). Daf�r existieren bereits
entsprechende Quellen, vgl. dazu Abschnitt VII.
Nicht beabsichtigt sind ebenfalls weitergehende Hinweise zum Thema
Bulkmail, UBE/UCE oder "Spam", denkbaren Gegenma�nahmen usw. usf. Auch
hierzu gibt es bereits spezialisierte Quellen, die in Abschnitt VII
dieser FAQ aufgef�hrt sind. Namentlich die dort genannte FAQ von
de.admin.net-abuse.mail sei jedem Interessierten dringend ans Herz
gelegt.
Der Schwerpunkt der FAQ liegt somit auf den Abschnitten II und III,
die einigerma�en technisch gehalten sind - was in der Natur der Sache
liegt, weil die R�ckverfolgung des Laufwegs einer E-Mail eine nicht
ganz einfache technische Angelegenheit ist. Es wurde bei der
Formulierung aber Wert darauf gelegt, da� die Ausf�hrungen auch f�r
interessierte Laien verst�ndlich sind.
Korrekturen, Erg�nzungshinweise und Verbesserungsvorschl�ge nimmt der
Autor gerne entgegen ( thh@inter.net). Diese FAQ wird in
de.admin.net-abuse.mail und de.answers gepostet und steht auf
<http://www.th-h.de/ faq/headerfaq.php> in der jeweils aktuellen
Fassung auch im WWW zur Verf�gung.
**** Fu�noten ****
[1] wie in RFC 2822 definiert (URL:
http://www.faqs.org/rfcs/rfc2822.html)
[2] UBE: unsolicited bulk e-mail, unverlangte Massen-E-Mail
UCE: unsolicited commercial e-mail, unverlangte kommerzielle E-Mail
[3] RFC 2076: "Common Internet Message Headers" (URL:
http://www.faqs.org/rfcs/rfc2076.html)
[4] RFC 2822: "Internet Message Format" (URL:
http://www.faqs.org/rfcs/rfc2822.html)
***** II. Aufbau und Zustellung einer E-Mail *****
Eine E-Mail besteht aus mehreren Teilen. Wenn man den Vergleich mit
einem konventionellen Brief suchen m�chte, k�nnte man sagen, es gibt
einen Umschlag (den sog. "SMTP-Envelope"), einen Briefkopf (den sog.
"Header" oder die "Kopfzeilen") und den eigentlichen Brieftext oder
-inhalt (den sog. "Body").
**** 1. SMTP-Envelope [5] ****
Diesen "Umschlag" bekommt der Nutzer im Normalfall nicht zu sehen;
eigentlich gibt es ihn auch gar nicht wirklich. Man bezeichnet so die
f�r die Zustellung einer E-Mail relevanten Informationen, die einem
Mailserver (also dem f�r den Versand und Empfang von E-Mail
zust�ndigen Computerprogramm) beim Versand vor (!) der eigentlichen
E-Mail �bergeben werden. Diese Informationen gehen beim Einsortieren
ins Postfach des Empf�ngers normalerweise verloren, ganz analog zu
einem konventionellen Briefumschlag, der in der Poststelle einer
Firma ge�ffnet und dann weggeworfen wird. Nur sein Inhalt, der
Briefbogen (also Header und Body der Mail), erreicht den Empf�nger.
Gl�cklicherweise werden die Daten aus dem "Umschlag" oft aber -
zumindest teilweise - in den Header der E-Mail �bernommen, so da� man
Informationen auf dem Umschlag auf diese Weise nachvollziehen kann.
Die Daten f�r den Umschlag erh�lt ein Mailserver ganz zu Anfang der
Verbindungsaufnahme mit dem Einlieferer; diese Verbindung wird als
SMTP-Dialog [5] bezeichnet, also als Dialog zwischen den beteiligten
Mailservern, die sich dabei am "Simple Mail Transfer Protocol"
orientieren. SMTP ist wie die meisten derzeit (auch) im Internet
verwendeten Kommunikationsprotokolle menschenlesbar, besteht also aus
festgelegten (englischen) Schl�sselworten oder Befehlen, die in
bestimmter Folge verwendet werden. Dabei stellt der einliefernde
Server sich vor (mittels HELO/EHLO [6], gibt den Absender an
("Envelope-From") und nennt den oder die Empf�nger ("Envelope-To").
Danach folgt nach dem Kommando "DATA" der Briefbogen, also die E-Mail
mit Headern und Body. Ein einzelner Punkt alleine auf einer Zeile
signalisiert, da� die E-Mail fertig �bertragen ist. Jetzt wird der
empfangende Mailserver sie den genannten Empf�ngern entweder ins
Postfach stecken (wenn sie schon "am Ziel" ist), oder, falls n�tig, an
einen anderen Server weiterleiten, wenn er selbst f�r einen Empf�nger
nicht zust�ndig ist, dessen Postfach also anderswo liegt.
Die Angabe des einliefernden Servers nach "HELO" wird dabei weder
�berpr�ft noch hat sie heutzutage besondere Bedeutung. Der Absender
auf dem Umschlag, d.h. der Envelope-From, wird f�r die Generierung von
Fehlermeldungen u.�. verwendet, wenn die E-Mail bspw. unzustellbar
ist, aber regelm��ig ebenfalls nicht �berpr�ft. Der oder die
Empf�ngerangaben im Envelope-To werden zur Zustellung benutzt.
Ein Beispiel eines solchen Dialogs sei im Folgenden dargestellt (in
der obersten Zeile jeweils der sendende Mailserver, darunter die
Antwort des empfangenden):
*** a) Die Vorstellung (HELO) ***
Der Dialog beginnt damit, dass der sendende Mailserver (oder der
Mailclient) Kontakt mit dem empfangenden aufnimmt, worauf dieser sich
zun�chst meldet:
| 220 pri.owl.example ESMTP ready
Darauf folgt dann die eigentliche Vorstellung und Begr��ung:
| HELO ancalagon.rhein-neckar.de
| 250 pri.owl.example Hello ancalagon.rhein-neckar.de [193.197.90.30],
| pleased to meet you
Der sendende Mailserver stellt sich vor ("HELO.."), der empfangende
antwortet ("Hello ..., pleased to meet you"). Entscheidend sind dabei
f�r die Rechner nur der Statuscode (250), nicht der Text; dieser kann
frei gew�hlt werden.
Wichtig: Der sendende Mailserver kann �ber seinen Namen "l�gen";
deshalb schaut der Empf�nger-Server zumeist nach, wer denn wirklich da
gerade mit ihm "redet", und merkt sich die sog. IP-Nummer des
Einlieferers (hier 193.197.90.30). Dies ist eine eindeutige Nummer,
mit der man jeden am Internet teilnehmenden Rechner identifizieren
kann. Durch eine Abfrage beim DNS (Domain Name Server/Service) l��t
sich diese Nummer dann wieder in einen Rechnernamen r�ck�bersetzen;
h�ufig tut das der Mailserver auch direkt selbst und �bersetzt die
Nummer in einen Namen. Nicht immer ist eine solche R�ckaufl�sung
allerdings konfiguriert, und es ist m�glich, auch hier eine falsche
F�hrte zu legen. [7] Verlassen kann man sich daher nur auf die
IP-Adresse selbst; diese l��t sich einem bestimmten Provider (oder
einer Firma oder Institution) zuordnen, und dieser Provider wiederum
sollte sie seinerseits einem bestimmten Rechner oder Kunden zuordnen
k�nnen. Zu beachten ist dabei, da� IP-Nummer schon lange ein zu
knappes Gut sind, um jedem Kunden permanent eine Nummer zuzuordnen.
Sie werden daher h�ufig dynamisch vergeben, das hei�t einem
bestimmten Rechner immer nur f�r die Dauer einer Online-Sitzung
zugewiesen. Da die entsprechenden Log-Dateien nach einer gewissen
Zeit gel�scht werden (manche Provider erfassen sie gar nicht erst),
ist es notwendig, sich zeitnah an den betreffenden Provider zu
wenden. Mehr Hinweise dazu finden Sie weiter unten in Abschnitt V.
*** b) Absender- und Empf�ngerangabe ***
| MAIL FROM:<heinz-gustav@ancalagon.rhein-neckar.de>
| 250 <heinz-gustav@ancalagon.rhein-neckar.de>... Sender ok
| RCPT TO:<karl-heinz@owl.example>
| 250 <karl-heinz@owl.example>... Recipient ok
Der Sender gibt die Absenderadresse an, der Empf�nger best�tigt;
gleiches gilt f�r die Empfangsadresse. Die Absenderadresse kann auch
hier "gelogen" sein und l��t sich nicht definitiv nachpr�fen; statt
nur eines Empf�ngers k�nnen auch (nahezu) beliebig viele angegeben
werden, indem die RCPT-TO:-Angabe entsprechend wiederholt wird.
| DATA
| 354 Enter mail, end with "." on a line by itself
Der "Umschlag" ist fertig, jetzt kommt der Briefbogen, bestehend aus
Header und Body.
**** 2. Header ****
Der Header einer E-Mail bildet sozusagen den Briefkopf, dem man bspw.
Absender, Empf�nger, Datum und Betreff entnehmen kann. Wichtig dabei:
diese Angaben sind einerseits v�llig beliebig durch den Absender
einstellbar, andererseits m�ssen sie nicht mit den Angaben im Umschlag
�bereinstimmen. Man kann also, um im Bild zu bleiben, den Briefbogen
an <donald.duck@entenhausen.example> adressieren, aber in einen
Umschlag stecken, der (wie oben) an <karl-heinz@owl.example>
adressiert ist. An letzteren wird die E-Mail dann verschickt. So kann
es passieren, da� man eine E-Mail erh�lt, die scheinbar (!) an jemand
ganz anderen adressiert ist. [8]
Au�er dem "Briefkopf", der schon vom Absender mitgeschickt wird,
finden sich aber auch noch Headerzeilen, die von jedem an der
�bertragung beteiligten Mailserver eingetragen werden, wenn die E-Mail
bef�rdert wird, sozusagen Zustellvermerke (die sich bei einem
konventionellen Brief allerdings wohl eher auf dem Umschlag finden
w�rden :-)). *Diese* Headerzeilen sind f�r die R�ckverfolgung einer
E-Mail entscheidend.
F�r den Anfang soll dieser kurze �berblick gen�gen; die einzelnen
Header werden unten in Abschnitt III ausf�hrlich besprochen.
**** 3. Body ****
Nach einer simplen Leerzeile, die die Trennung zwischen Header und
Body darstellt, folgt dann der eigentliche Text bzw. Inhalt der
E-Mail. Dieser ist nicht mehr weiter untergliedert.
**** 4. Vorgehen bei der Zustellung ****
Wenn ein Mailserver eine E-Mail bekommt, ist es seine erste Aufgabe,
festzustellen, ob und (bei mehreren) wenn ja f�r welche Empf�nger er
selbst "zust�ndig" ist. Ist der Server selbst zust�ndig, legt er die
E- Mail dem entsprechenden Empf�nger (oder den Empf�ngern) ins
Postfach (bzw. �bergibt sie an ein anderes Programm auf derselben
Maschine, das f�r die Verwaltung der Postf�cher zust�ndig ist). Ist er
nicht zust�ndig (oder bleiben danach Empf�nger-Adressen �brig, f�r die
er nicht zust�ndig ist), ermittelt er den (oder ggf. die
verschiedenen) zust�ndigen Mailserver [10], stellt zu diesem Server
(oder diesen Servern) eine Verbindung her und liefert dann seinerseits
die E-Mail an diese(n) Server aus, auf dieselbe Weise, wie er sie
selbst bekommen hat, mit HELO/EHLO, MAIL FROM, RCPT TO und DATA.
**** Fu�noten ****
[5] SMTP steht f�r "Simple Mail Transfer Protokol", den derzeit
�blichen Standard, nach dem E-Mail im Internet zwischen verschiedenen
Servern ausgetauscht wird. Siehe dazu den RFC 2821: "Simple Mail
Transfer Protocol" (URL: http://www.faqs.org/rfcs/rfc2821.html)
[6] Auf HELO folgt der eigene Rechnername, bei EHLO zus�tzlich noch
Parameter, die angeben, welche erweiterten Funktionen der Mailserver
beherrscht.
[7] Die R�ckaufl�sung (aus der Nummer zum Namen) mu� nicht mit der
�blicherweise verwendeten Vorw�rtsaufl�sung (aus dem Namen zur Nummer;
notwendig, um bspw. aus dem Servernamen "www.provider.example" die
dazugeh�rige IP-Adresse zu erfahren und den Server ansprechen zu
k�nnen) konsistent sein. Ein b�swilliger Anbieter
"a-provider.example", der f�r den Server mit der IP-Nummer
193.197.90.30 zust�ndig ist, k�nnte in der R�ckw�rtsaufl�sung mit
dieser Nummer den Namen des Mailservers seines Konkurrenten,
"mail.b-provider.example" verbinden, auch wenn umgekehrt die Eingabe
von "mail.a- provider.example" vorw�rts zu der Nummer 193.197.90.30
f�hrt und "mail.b-provider.example" eine ganz andere IP-Adresse
ergibt. So k�nnen die Kunden jeweils mit der Angabe des Namens auf
den richtigen Server zugreifen, weil sie zu dem Namen die korrekte
IP-Nummer geliefert bekommen; wenn jedoch "mail.a- provider.example"
mit der Nummer 193.197.90.30 sich mit irgendeinem anderen Server
verbindet, wird dieser sowohl die IP-Nummer als auch den mit der
Nummer verbundenen (falschen!) Namen "mail.b-provider.example"
registrieren.
[8] Sinnvoll ist dieses Vorgehen bspw. f�r Mailinglisten: als
Empf�nger steht dann bpsw. "Alle Teilnehmer der
Taubenfutter-Mailingliste" <taubenfutter@mailingliste.example> oder
etwas anderes beliebiges im Header, die tats�chlichen Empf�nger
stehen nur auf dem Umschlag. Der Vorteil: bei 100 Teilnehmern mu�
blo� die Zeile "RCPT TO:<adresse@server.domain.example>" hundertmal
(jedesmal mit einer anderen Empf�ngeradresse) gesendet, die
eigentliche E-Mail (der Briefbogen) aber nur einmal �bertragen
werden. Um die Zustellung k�mmert sich dann der empfangende
Mailserver, der sozusagen aus der einen �bertragenen E-Mail 100
Kopien f�r 100 verschiedene Empf�nger macht. Das spart immens Zeit
und damit Geld. Daher gehen aus demselben Grund Bulkmailer (Spammer)
ebenso vor - letzten Endes bedienen sie ja auch nur eine
Mailingliste, allerdings eine Liste, deren unfreiwillige Teilnehmer
sich nicht f�r diesen Verteiler angemeldet haben... Daher findet man
beim Empfang von UBE/UCE h�ufig nicht die eigene Mailadresse auf dem
Briefbogen (in der Headerzeile "To:" bzw. "An:"), sondern eine fremde
oder beliebige. Spammer verwenden f�r ihre Zwecke dabei im �brigen
gerne sog. "offene Relays" [9] und in neuerer Zeit auch sog.
"Zombies" [9a].
[9] Ein offenes Relay ist ein Mailserver, der nicht nur Mail von
seinen eigenen Benutzern und Kunden an die ganze Welt und umgekehrt
Mail von �berall an die eigenen Kunden ausliefert, sondern von �berall
und jedermann Mail annimmt, die er auch nach �berall wieder
ausliefert. Fr�her war das eine nette Geste, um Serverausf�lle bspw.
bei kleineren Providern abzufangen; heute werden offene Relays gerne
mi�braucht, um Bulkmail auszuliefern und landen deswegen auf
"schwarzen Listen" mit der Folge, da� viele Systeme weltweit Mail von
dort gar nicht mehr oder nur noch verz�gert annehmen.
[9a] Zombies sind gekaperte oder "gehackte" Rechner von nichtsahnenden
Benutzern, auf deren System durch die Ausnutzung von Schwachstellen
oder durch einen Virus oder Wurm "Hintert�ren" installiert wurden, die
es einem Angreifer erlauben, das System fernzusteuern. Die Zahl der
solcherart kompromittierten Systeme d�rfte bei mehreren 100.000
liegen, die teilweise durch DSL- oder Kabelmodem breitbanding
angebunden sind und zum Versand von Spam oder Viren, zum Tausch von
"Warez", also Raubkopien, und anderen illegalen Medien, als
Ausgangspunkt f�r andere Angriffe oder auch zum Durchf�hren sog.
"denial of service"-Angriffe benutzt werden, um damit andere Systeme
aus dem Netz unerreichbar zu machen. Solche Angriffe durch Zombies
oder ganze Netze von mehreren zigtausend Maschinen, die weltweit
verteilt stehen, deren eigentliche Besitzer aber keine Kontrolle mehr
�ber sie haben, k�nnen sich gegen mi�liebige Personen oder
Institutionen richten oder auch zu Erpressungsversuchen genutzt
werden. Es ist nicht fernliegend, in diesem Bereich auch Strukturen
organisierter Kriminalit�t zu vermuten, die jedenfalls auch Ressourcen
f�r den Versand unerw�nschter Mails - gegen Bezahlung - bereitstellen.
Unter anderem deshalb, aber auch wegen der zunehmenden Verbreitung von
Viren und W�rmern, die sich selbst per E-Mail verbreiten, wird E-Mail
direkt von Endbenutzerrechnern (also solchen, die mit einer
dynamischen, bei der Einwahl jeweils neu vergebenen IP - auch via DSL
- unterwegs sind, und keine echte Standleitung mit st�ndiger
Netzverbindung haben) h�ufig nicht mehr angenommen, so da� Benutzer
ihre E-Mails �ber den Mailserver ihres Providers verschicken m�ssen.
[10] Dazu wird im DNS der Eintrag f�r den sog. Mail Exchanger (MX) f�r
die entsprechende Domain abgefragt. Als Antwort wird der Name eines
oder mehrerer Rechner, die f�r den Mailempfang f�r diese Domain
zust�ndig ist oder sind, zur�ckgeliefert, nach Priorit�t geordnet.
***** III. E-Mail-Headerzeilen im einzelnen *****
Zun�chst mal ein (schon etwas komplizierterer) Header "am St�ck". Die
folgende E-Mail wurde von Heinz-Gustav Hinz an seinen Bekannten
Karl-Heinz Schmitt verschickt. Letzterer hat eine Adresse bei dem
E-Mail- Forwarder GMX, von dem er sich die eingehenden Mails an seine
eigentliche Adresse weiterschicken l��t.
| Return-Path: <heinz-gustav@post.rwth-aachen.example>
| Received: from mx3.gmx.example (qmailr@mx3.gmx.example[195.63.104.129])
| by ancalagon.rhein-neckar.de (8.8.5/8.8.5) with SMTP id SAA25291
| for <karl-heinz@ancalagon.rhein-neckar.de>; Thu, 16 Sep 1998 17:36:20
| +0200 (MET DST)
| Received: (qmail 1935 invoked by alias); 16 Sep 1998 15:36:06 -0000
| Delivered-To: GMX delivery to karl-heinz@gmx.example
| Received: (qmail 27698 invoked by uid 0); 16 Sep 1998 15:36:02 -0000
| Received: from pbox.rz.rwth-aachen.example (137.226.144.252)
| by mx3.gmx.example with SMTP; 16 Sep 1998 15:36:02 -0000
| Received: from post.rwth-aachen.example (slip-vertech.dialup.RWTH-Aachen.EXAMPLE
| [134.130.73.8]) by pbox.rz.rwth-aachen.example (8.9.1/8.9.0) withESMTP
| id RAA28830 for <karl-heinz@gmx.example>; Wed, 16 Sep 1998 17:35:59
| +0200
| Message-ID: <35FFDA4F.2BC2A064@post.rwth-aachen.example>
| Date: Wed, 16 Sep 1998 17:33:35 +0200
| From: Heinz-Gustav Hinz <heinz-gustav@post.rwth-aachen.example>
| Organization: RWTH Aachen
| X-Mailer: Mozilla 4.05 [de] (Win95; I)
| To: Karl-Heinz Schmitt <karl-heinz@gmx.example>
| MIME-Version: 1.0
| Content-Type: text/plain; charset=iso-8859-1
| Content-Transfer-Encoding: quoted-printable
| Subject: Re: Hallo Nachbar!
| References: <529471993@ancalagon.rhein-neckar.de>
| Reply-To: hinz@provider.example
| X-Resent-By: Global Message Exchange <forwarder@gmx.example>
| X-Resent-For: karl-heinz@gmx.example
| X-Resent-To: karl-heinz@ancalagon.rhein-neckar.de
Eine Headerzeile beginnt immer mit einem Schl�sselwort, ihrem Namen,
gefolgt von einem Doppelpunkt und dem Inhalt. Sehr lange Headerzeilen
k�nnen sich �ber mehrere Textzeilen erstrecken; die zweite und jede
folgende Zeile beginnen dann mit Leerzeichen oder einem
Tabulatorzeichen (Fortsetzungszeilen). F�r die Auswertung setzen die
beteiligten Programme die einzelnen Textzeilen wieder zu einer
einzigen, langen Zeile zusammen.
Die Reihenfolge der Headerzeilen ist ziemlich beliebig und von der
verwendeten Software abh�ngig. Deshalb werde ich mich auch beim
"Auseinanderpfriemeln" der einzelnen Headerzeilen nicht an der
Reihenfolge, sondern am Sinnzusammenhang orientieren.
**** 1. Anschrift, Absender u. Verwandtes - kurz: der Briefkopf ****
Diese Headerzeilen sind weitgehend selbsterkl�rend:
| Date: Wed, 16 Sep 1998 17:33:35 +0200
Das Absendedatum, eingetragen vom Mailprogramm des Absenders (kann,
wenn fehlend, aber auch von einem der beteiligten Mailserver
nachgetragen worden sein, meistens dem ersten, den die Mail passiert).
| From: Heinz-Gustav Hinz <heinz-gustav@post.rwth-aachen.example>
Der Autor bzw. Absender. Wenn Autor und technischer Absender
unterschiedlich sind (eine Mail bspw. von einer Mailingliste
verschickt wird), steht der technische Absender ggf. in der
zus�tzlichen Headerzeile "Sender:". - Davon zu unterscheiden ist der
bereits in Abschnitt II erw�hnte "Envelope-From:", an den bspw.
automatische Fehlermeldungen gerichtet werden.
| Organization: RWTH Aachen
Die Organisation (Firma, Hochschule, Verein ...) des Absenders.
Merke: "There is no 's' in Organization". ;-)
| To: Karl-Heinz Schmitt <karl-heinz@gmx.example>
Der Empf�nger. Hier k�nnen auch mehrere oder viele Namen / Adressen
stehen, jeweils durch Kommata getrennt.
Au�erdem kann es noch die Headerzeile "CC:" geben, die angibt, wer
diese Mail in Kopie zur Kenntnisnahme erhalten hat. Der Unterschied
ist rein administrativ, �hnlich wie bei Rundschreiben mit "Empf�ngern"
und "Zur Kenntnis in Kopie an"; wie auch dort wird (vermutlich! - die
Angaben in To:/CC: sind nur informativ und haben f�r die Zustellung
keine Bedeutung!) an jeden Namen / jede Adresse in beiden Kategorien
jeweils ein Exemplar verschickt. Technisch gesehen werden beim Versand
einer normalen E-Mail die Adressen, die im Mailprogramm des Absenders
in die Felder "To:" und "CC:" eingetragen wurden, nicht nur zur
Generierung dieser beiden Headerzeilen benutzt, sondern auch beim
SMTP-Dialog als "RCPT TO:" �bertragen, also sozusagen f�r den Umschlag
abgeschrieben.
Die meisten Mailprogramm bieten noch ein "BCC:"-Feld f�r "blinde"
Kopien. Die hier eingegebene Adressen werden zwar in den Umschlag
�bernommen (jeder erh�lt ein Exemplar der Mail), erscheinen aber im
Header der E-Mail (auf dem Briefbogen) nicht; die anderen Empf�nger
wissen also nichts von den Empf�ngern dieser blinden Kopien.
Mailinglisten (oder auch Bulkmail / Spam) werden h�ufig auf diese oder
eine vergleichbare Weise verschickt.
| Subject: Re: Hallo Nachbar!
Der Betreff.
| Reply-To: hinz@provider.example
Die Adresse, an die geantwortet werden soll. Hier schickt Heinz-Gustav
Hinz die E-Mail von seinem Account an der RWTH Aachen ab, m�chte
Antworten aber an seine private Mailadresse haben.
Alle diese Zeilen k�nnen beliebig durch den Absender bestimmt werden
und sind demzufolge f�r eine R�ckverfolgung weitgehend wertlos.
**** 2. "Technische" Angaben ****
| Message-ID: <35FFDA4F.2BC2A064@post.rwth-aachen.example>
| In-Reply-To: <529471993@ancalagon.rhein-neckar.example>
| References: <529471993@ancalagon.rhein-neckar.example>
Die Message-ID ist eine eindeutige Kennung der E-Mail (vergleichbar
einer Seriennummer). Sie sollte aus einer unverwechselbaren
Zeichenfolge vor dem "@" (meistens Datum und Benutzerkennung in einer
kodierten Form) und einem Rechnernamen hinter dem "@" bestehen. H�ufig
wird die Message- ID bereits vom Mailprogramm des Absenders erzeugt;
ansonsten tragen die meisten Mailserver sie nach, soweit sie fehlt.
Sie ist demnach kein Beleg f�r den tats�chlichen Absender.
Wenn sich die E-Mail auf eine andere bezieht, diese also beantwortet,
findet sich deren Message-ID in der Headerzeile "References:" oder
"In- Reply-To:". Diese Angaben nutzen manche Mailprogramme, um die
einzelnen E-Mails, bspw. aus einer Mailingliste, zu sortieren und
einen "Thread", einen "Diskussionsfaden" (oder "-baum") daraus zu
bauen (wie bei einem Newsreader).
| MIME-Version: 1.0
| Content-Type: text/plain; charset=iso-8859-1
| Content-Transfer-Encoding: quoted-printable
Diese Angaben beschreiben, welcher Art der Inhalt der Mail ist. Hier
handelt es sich um reinen Text ("plain text") mit dem Zeichensatz
"iso-8859-1" und der Sonderzeichenkodierung "quoted-printable". Diese
Daten sind nur f�r das Mailprogramm notwendig, um bspw. Umlaute und
Sonderzeichen richtig anzeigen und Dateianh�nge u.�. erkennen und
behandeln zu k�nnen.
| X-Mailer: Mozilla 4.05 [de] (Win95; I)
Alle mit "X-" beginnenden Headerzeilen sind nicht standardisiert und
k�nnen von verschiedenen Programmen (oder auch Benutzern) beliebig
eingef�gt werden. �blich ist ein Header wie dieser, der die verwendete
Software angibt. Ein anderes Mailprogramm produziert stattdessen
vielleicht direkt mehrere X-Header, zum Beispiel
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-Mailer: Microsoft Outlook Express 4.72.3110.1
> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
M�glich ist auch die Verwendung des Headers "User-Agent" (der dann
einer standardisierten Form gen�gen mu�).
Bei weiteren Headern l��t sich meist aus dem Namen der jeweiligen
Headerzeile schlie�en, wof�r er denn gedacht sein mag; ansonsten
finden sich die entsprechenden technischen Dokumente (RFCs) in
Abschnitt VII aufgez�hlt.
Der Hinweis, da� alle diese Header vom Absender beliebig gew�hlt und
damit auch gef�lscht werden k�nnen, ist an dieser Stelle vermutlich
bereits fast �berfl�ssig.
**** 3. "Zustellvermerke": den Weg einer E-Mail nachvollziehen ****
Die noch verbleibenden Headerzeilen lassen sich f�r die R�ckverfolgung
einer E-Mail verwenden. Auch hierbei ist nat�rlich ein wenig Vorsicht
geboten, um nicht plumpen (und weniger plumpen) F�lschungsversuchen
aufzusitzen.
| Return-Path: <heinz-gustav@post.rwth-aachen.example>
Diese Zeile sollte, wenn sie existiert, ganz am Anfang der E-Mail
stehen. Sie enth�lt den Envelope-From (also die Absenderangabe aus dem
SMTP-Umschlag), die - wir erinnern uns - beliebig angegeben werden
kann. Bringt f�r eine R�ckverfolgung also herzlich wenig.
*** a) "Received:"-Headerzeilen ***
Die "eigentlichen" Zustellvermerke sind die "Received:"-Headerzeilen,
die jeweils vor dem Weiterschicken einer E-Mail vom Mailserver vorne
angef�gt werden. Man mu� sie also r�ckw�rts (!) lesen: die letzte
Received:-Zeile ist die oberste (!). Daraus resultiert zweierlei: die
oberste "Received:"- Zeile wurde vom eigenen Mailserver (bzw. dem des
Providers) erzeugt - sie ist also vertrauensw�rdig. Und: die �brigen
genannten Headerzeilen m�ssen normalerweise unterhalb der
"Received:"-Zeilen stehen, da sie ja schon bei der Einlieferung
vorhanden waren. Andererseits k�nnten nat�rlich auch vorgeschriebene
Headerzeilen bei der Einlieferung gefehlt haben, die dann erst sp�ter
von einem der empfangenden Mailserver erg�nzt wurden und daher �ber
der ersten "Received:"-Zeile stehen. Dennoch: Wenn "mittendrin" noch
einmal "Received:"-Zeilen auftauchen, handelt es sich mit hoher
Wahrscheinlichkeit um F�lschungen, die einfach vom Absender schon vor
dem ersten Versenden eingef�gt wurden.
Gleiches gilt, wenn sich "L�cken" zwischen einzelnen
"Received:"-Zeilen auftun. Eine "Received:"-Zeile gibt immer an, wer
die Mail von wem empfangen hat. Das hei�t: Wenn jetzt A die Mail von
B bekommen hat, mu� als n�chstes eine Zeile folgen, in der B die Mail
von C bekommen hat. Beachten mu� man dabei allerdings, da� ein und
derselbe Rechner durchaus mehrere "Namen" haben kann. So wird ein
Rechner, der den E-Mail-Verkehr erledigt, vielleicht
mail.domain.example hei�en. Wenn derselbe Rechner auch f�r das WWW
und News zust�ndig ist, hei�t er vielleicht auch noch
www.domain.example und news.domain.example - das ist aber immer noch
derselbe Rechner. Genauer feststellen l��t sich das durch eine DNS-
Abfrage (nslookup, vgl. Abschnitt IV); in diesem Fall m��ten dort
beide Namen f�r denselben Rechner, d.h. dieselbe IP-Nummer,
registriert sein.
Bevor wir weitere Kennzeichen f�r m�gliche F�lschungen er�rtern, ist
es aber notwendig, erst einmal den Aufbau einer
"Received:"-Headerzeile genauer kennenzulernen.
*** b) "Received:"-Headerzeilen im einzelnen ***
| Received: from mx3.gmx.example (qmailr@mx3.gmx.example[195.63.104.129])
| by ancalagon.rhein-neckar.de (8.8.5/8.8.5) with SMTP id SAA25291
| for <karl-heinz@ancalagon.rhein-neckar.de>; Thu, 16 Sep 1998 17:36:20
| +0200 (MET DST)
Jetzt geht's ans Eingemachte. :-) Diese Zeile mu� n�mlich wiederum in
ihre Einzelteile auseinandergepfl�ckt werden.
| by ancalagon.rhein-neckar.de (8.8.5/8.8.5) with SMTP id SAA25291
Der eigene Mailserver des Empf�ngers (hier
"ancalagon.rhein-neckar.de") hat diese E-Mail empfangen ("Received
by"). Die Angabe in Klammern gibt dabei (Namen und) Version des dort
laufenden Mailserver- Programmes (MTA) an. (Hier handelt es sich um
das Programm "sendmail".) Empfangen wurde per SMTP mit der internen
Kennnummer "SAA25291" (was f�r uns bedeutungslos ist).
| for <karl-heinz@ancalagon.rhein-neckar.de>; Thu, 16 Sep 1998 17:36:20
| +0200 (MET DST)
Freundlicherweise wird hier der Envelope-To wiedergegeben (also die
Anschrift auf dem SMTP-Umschlag). Au�erdem findet sich das Datum und
die Uhrzeit, zu dem die Mail einging. Ob diese Angaben hier stehen,
ist einmal vom verwendeten MTA und zum anderen davon abh�ngig, ob die
Mail nur an einen oder an mehrere Empf�nger auf demselben (!) Server
ging. Im letzteren Fall fehlt die Angabe des Empf�ngers aus dem
"Umschlag" meist, da es ja die einzelnen Empf�nger nichts angeht, wer
die E-Mail sonst noch bekommen hat, und die Liste ggf. auch etwas lang
w�rde. :)
| Received: from mx3.gmx.example (qmailr@mx3.gmx.example[195.63.104.129])
Hier steht jetzt, von welchem Mailserver die E-Mail empfangen wurde.
Das Format dieser Zeile ist leider nicht ganz einheitlich. Immer gilt:
die Nummer in (eckigen) Klammern ist die unverwechselbare IP-Nummer
des einliefernden Rechners - hier "195.63.104.129". [11] Au�erdem ist
angegeben, wie dieser sich vorgestellt hat (die Angabe aus dem HELO)
-hier "qmailr@mx3.gmx.example". Das hat unser Mailserver brav
�berpr�ft und festgestellt, da� die IP-Nummer tats�chlich zu
"mx3.gmx.example" geh�rt. Soweit also alles in Ordnung.
Wenn HELO und Realit�t �bereinstimmen, wird der HELO-Parameter
manchmal gar nicht angegeben. Dann findet sich nur die IP-Nummer und
der (als richtig festgestellte) Name des einliefernden Servers.
Andererseits geben manche MTA nur den (m�glicherweise gef�lschten)
HELO-Parameter und die (echte) IP-Nummer an, ohne den zugeh�rigen
Namen nachzuschauen. Dann ist der angegebene Name gerade *nicht* wahr.
Auch ist es m�glich, da� die Reihenfolge der Angaben genau umgekehrt
ist (zuerst HELO, dann tats�chliche Angabe). Schlie�lich - und am
schlimmsten :-( - gibt es �ltere MTAs, die noch an das Gute im
Menschen glauben und au�er dem (beliebig f�lschbaren) HELO �berhaupt
nichts festhalten. Da ist dann guter Rat teuer. In diesem Falle hilft
es nur noch, sich direkt an den Postmaster dieses Systems zu wenden,
der dann m�glicherweise �ber die automatisch gef�hrten Log-Dateien
noch weitere Informationen ermitteln kann.
Daher ergibt sich folgendes: Soweit man wei� oder ausprobiert hat, in
welchem Format der eigene MTA bzw. der des eigenen Providers die
Angaben in der Received:-Zeile macht, gibt es kein Problem. Wenn man
sich nicht sicher ist, welcher der Rechnernamen jetzt der echte ist,
hilft nichts anderes, als selbst nachzuschauen, welcher Name zu der
angegebenen IP-Nummer pa�t. Dazu gibt es bspw. das Tool "nslookup"
(vgl. Abschnitt IV).
| Received: (qmail 1935 invoked by alias); 16 Sep 1998 15:36:06 -0000
Diese Zeile ist eine Spezialit�t der bei GMX verwendeten
Mailserversoftware "qmail".
| Delivered-To: GMX delivery to karl-heinz@gmx.example
Auch dies eine Spezialit�t von GMX: eine E-Mail an diesen GMX-Kunden
wurde ausgeliefert.
| Received: (qmail 27698 invoked by uid 0); 16 Sep 1998 15:36:02 -0000
Wieder "qmail". Alle diese Software-spezifischen Zeilen sind f�r die
R�ckverfolgung zun�chst ohne Bedeutung.
| Received: from pbox.rz.rwth-aachen.example (137.226.144.252)
| by mx3.gmx.example with SMTP; 16 Sep 1998 15:36:02 -0000
Hier wird es jetzt spannend - diese Zeile wurde ja nicht mehr von
unserem vertrauensw�rdigen eigenen Mailserver erzeugt. Schauen wir
mal:
| by mx3.gmx.example with SMTP; 16 Sep 1998 15:36:02 -0000
"mx3.gmx.example" hat die Mail empfangen. Das ist der Rechner, der sie
dann an uns weitergereicht hat - stimmt also. Wundert eigentlich auch
wenig; den Mailserver von GMX darf man wohl durchaus als
vertrauensw�rdig bezeichnen.
| Received: from pbox.rz.rwth-aachen.example (137.226.144.252)
Bekommen hat er sie von "pbox.rz.rwth-aachen.example" mit der
IP-Nummer "137.226.144.252". GMX gibt bei �bereinstimmung von
HELO-Angabe und tats�chlichem Namen diesen nur einmal an.
Anderes Beispiel:
> Received: from hiper1-d87.cwnet.com (HELOmailer1.themailmachaine.net)
> (205.162.108.87) by mx1.gmx.example with SMTP; 10 Sep 1998 23:29:25-0000
Hier hat sich der einliefernde Rechner beim HELO als
"mailer1.themailmachaine.net" vorgestellt; tats�chlich hei�t er aber
"hiper1-d87.cwnet.com". Wenn man die IP-Nummer "205.162.108.87"
mittels "nslookup" nachschaut, kann man das feststellen. (N�heres dazu
weiter unten, Abschnitt IV). [12]
Aber weiter im Text - wir waren stehengeblieben bei der Feststellung,
da� GMX die Mail von "pbox.rz.rwth-aachen.example" hat.
| Received: from post.rwth-aachen.example (slip-vertech.dialup.RWTH-Aachen.EXAMPLE
| [134.130.73.8]) by pbox.rz.rwth-aachen.example (8.9.1/8.9.0) withESMTP
| id RAA28830 for <karl-heinz@gmx.example>; Wed, 16 Sep 1998 17:35:59
| +0200
"pbox.rz.rwth-aachen.example" wiederum hat sie von jemandem, der sich
als "post.rwth-aachen.example" vorgestellt hat, tats�chlich aber
"slip- vertech.dialup.RWTH-Aachen.EXAMPLE" hei�t. Da beides
Rechnerbezeichnungen der RWTH Aachen sind und der letztere Name
("dialup") darauf hindeutet, da� es sich hier um einen Einwahlport
handelt, dessen IP-Nummer dynamisch immer wechselnden Anrufern
zugewiesen wird, macht auch das keinen �berm��ig verd�chtigen
Eindruck. Auch der Zeitunterschied von nur 3 Sekunden zwischen "17:35:
59 +0200" und "15:36:02 -0000" pa�t ganz gut f�r die Entgegennahme und
direkt folgende Weiterleitung einer E-Mail.
Die E-Mail kam also von einem Einwahlport an der RWTH Aachen.
| X-Resent-By: Global Message Exchange <forwarder@gmx.example>
| X-Resent-For: karl-heinz@gmx.example
| X-Resent-To: karl-heinz@ancalagon.rhein-neckar.de
Diese unmittelbar aufeinander folgenden Header sind wiederum eine
Spezialit�t von GMX, die angeben, an welche GMX-Adresse die Mail
geschickt wurde, und an welche tats�chliche Adresse sie dann
weitergeleitet wurde. Auch sie sind f�r die R�ckverfolgung zun�chst
bedeutunglos.
F�r die Bewertung, welche "Received:"-Zeilen vertrauensw�rdig und
"normal" sind und welche nicht, ist es sinnvoll, sich - f�r jeden
E-Mail-Account, den man sein eigen nennt - zun�chst einmal zu
vergegenw�rtigen, wie denn eine legitime Mail aussieht und welche
Zeilen darin (am Ende, also oben) immer wieder vorkommen und damit
zum Mailsystem des eigenen Providers geh�ren. Dabei sollte man sich
nicht dadurch irritieren lassen, da� manche Provider "neutrale"
Rechnernamen f�r ihre Infrastruktur verwenden ("kundenserver.de"
bspw. bei Unternehmen der United-Internet-Gruppe wie 1&1 oder Schlund
oder Alturo) oder da� Rechnernamen Umbenennungen oder Fusionen von
Firmen oder Marken nicht mitgemacht haben (so da� bspw. die
Mailinfrastruktur von web.de Rechnernamen innerhalb der Domain
"cinetic.de" verwendet).
*** c) Indizien fuer gef�lschte "Received:"-Zeilen ***
Wer �ber den tats�chlichen Laufweg bzw. die wahre Herkunft einer
E-Mail t�uschen will, mu� bei den "Received:"-Zeilen ansetzen.
Versender unerw�nschter (Massen-)MAil h�ngen oft gef�lschte Zeilen
zus�tzlich unten an (setzen sie also an den Anfang der Kette), um die
Analyse zu erschweren und die Beschwerde-Abteilungen unbeteiligter
Provider zu blockieren. Je mehr unn�tige Beschwerden auftauchen,
desto weniger Ressourcen bleiben f�r die Bek�mpfung des tats�chlichen
Mi�brauchs �brig. Eine unr�hmliche Rolle spielen hier auch - schlecht
geschriebene - Programme, die Beschwerden automatisch m�glich machen
sollen.
Es gibt jedoch Indizien f�r solcherma�en gef�lschte
"Received:"-Zeilen, kleine oder nicht ganz so kleine
Ungew�hnlichkeiten und Implausibilit�ten, die einzeln, aber auch
zusammenh�ngend auftreten k�nnen. Keines dieser Indizien ist
allerdings zwingend.
Aufmerksam sollte man werden, wenn eine "Received:"-Zeile nur aus
einer �berlangen, d.h. mehr als 80 Zeichen langen Textzeile besteht.
Normalerweise sollte ein Mailserver diese lange Zeile in mehrere
Fortsetzungszeilen aufspalten, wobei die zweite und jede folgende
Zeile dann mit Leerzeichen beginnen. Statt
| Received: from c-67-170-28-227.client.comcast.example (c-67-170-28-227.client.comcast.example [113.56.119.16]) byh196.165.40.162.ip.alltel.example with SMTP id i2M5cXd3019578; Mon, 22Mar 2004 06:38:34 -0600
w�rde man vielmehr folgendes erwarten:
| Received: from c-67-170-28-227.client.comcast.example
| (c-67-170-28-227.client.comcast.example [113.56.119.16]) by
| h196.165.40.162.ip.alltel.example with SMTP id i2M5cXd3019578;
| Mon, 22 Mar 2004 06:38:34 -0600
Ungew�hnlich ist es auch, wenn die angegebene Zeitzone nicht zu dem
angeblichen Namen des Servers pa�t, der die Mail angenommen haben
soll:
| Received: from adsl-68-127-120-70.dsl.frsn02.pacbell.net
| (adsl-68-127-120-70.dsl.frsn02.pacbell.net [68.127.120.70]) by
| smtp1.belwue.de (8.12.10/8.12.8) with SMTP id i2E44Y75023435; Sat,
| 13 Mar 2004 23:05:16 -0500 (EST)
"smtp1.belwue.de" steht in Deutschland, man w�rde also
mitteleurop�ische Zeit ("+0100" oder "+0200"> erwarten, nicht jedoch
"-0500" und "EST", also "Eastern Standard Time".
Manchmal fehlt die Angabe der "(E)SMTP id", also die interne
Kennnummer des Servers, unter der er die E-Mail behandelt hat:
| Received: from pcp566694pcs.rthfrd01.tn.comcast.example
| (pcp566694pcs.rthfrd01.tn.comcast.example [182.181.169.48]) by
| simba.csa.example with SMTP; 26 Feb 2004 15:16:39 -0600
Stattdessen steht die "id" manchmal auch in spitzen Klammern:
| Received: from [72.193.48.203] by 129.143.2.12 with ESMTP id<065027-77135>
| for <framstag@bofh.belwue.example>; Mon, 22 Mar 2004 04:33:56 -0500
Oder sie besteht nur aus seltsamen alphanumerischen Zeichen:
| Received: from [56.194.200.218] by 24.8.12.192 with qepxtpax SMTP;
| Wed, 17 Mar 2004 02:51:00 -0600
In allen vorgenannten F�llen ist gleicherma�en auff�llig, da� f�r den
angeblich sendenden Server nur die IP in eckigen Klammern angegeben
wird und da� auch der angeblich annehmende Server nicht seinen Namen,
sondern nur seine IP-Nummer registriert.
Zeichen f�r eine erfundene "Received:"-Zeile kann es schlie�lich auch
sein, wenn das HELO, also die "Vorstellung" des angeblich
einliefernden Servers, nur aus Zeichengewirr besteht:
| Received: from [200.207.1.240] (helo=QRJATYDI)
| by gentoo.lithosting.example with smtp (Exim 4.21)
| id 1B3Wi8-0001cZ-6y; Wed, 17 Mar 2004 02:47:38 -0600
| Received: from (HELO 37jcl0h) [129.206.192.195] by
| 12-241-137-231.client.attbi.example with SMTP; Thu, 06 Nov 2003 07:40:50
| +0300
F�r die vorstehenden Ausf�hrungen (und nicht nur f�r diese) geht ein
Dankesch�n an Ulli Horlacher, der sie beigesteuert hat.
**** 4. Spezielle Headerzeilen ****
Einige recht h�ufig vorkommende Headerzeilen wurden noch nicht
genannt. So ist zum Beispiel
| Comments: Authenticated Sender is <....>
recht verbreitet (wobei statt "<....>" nat�rlich eine E-Mail-Adresse
steht). Eigentlich sollte diese Zeile einmal angeben, wer denn nun
tats�chlich der Absender dieser E-Mail war (wenn der Mailserver des
eigenen Providers verwendet wurde bspw. durch R�ckgriff auf die bei
der Einwahl ins System verwendete Nutzerkennung). Manchmal trifft das
auch noch zu; h�ufig - bei unerw�nschter Bulkmail nahezu immer - ist
diese Zeile aber zwecks Irref�hrung gef�lscht.
Beliebt ist oder war auch die Headerzeile "X-Sender", die ebenfalls
den tats�chlichen Absender angeben soll. Zumindest bei T-Online-Kunden
funktionierte das anerkannterma�en, solange auch einer der
T-Online-Mailserver verwendet wurde:
| X-Sender: 06221168783-0001@t-online.de
Die Angabe war in diesem Fall die T-Online-Benutzerkennung, die bei
�lteren Kunden zu allem �berflu� auch noch mit der Telefonnummer
identisch war. In diesem speziellen Fall konnte man eventuelle
Nachfragen dann sogar telefonisch kl�ren. ;-) Nachdem T-Online den
"X-Sender:" abgeschafft hat, ist das allerdings - leider - nur noch
von historischem Interesse.
Stattdessen gibt es jetzt eine "X-ID:"-Headerzeile, die allerdings
verschl�sselte Daten enth�lt, die nur noch T-Online selbst dem
�berlt�ter zuordnen kann. Bitte beachten Sie in jedem Fall, da� das
blo�e Vorhandensein einer "X-ID:"-Zeile aber nicht besagt, da� eine
E-Mail tats�chlich von einem T-Online-Kunden stammt. Man kann auch
diese Zeile beliebig hinzuf�lschen; es ist aber immer auch anhand der
"Received:"-Zeilen zu pr�fen, ob die E-Mail tats�chlich bei T-Online
eingeliefert wurde oder nicht.
**** Fu�noten ****
[11] "Immer" ist dabei etwas relativ zu sehen - oft hindert nichts den
einliefernden Rechner, sich beim HELO/EHLO nicht nur mit seinem Namen
vorzustellen, wie er es eigentlich sollte, sondern eine nahezu
beliebige Zeichenfolge abzukippen, die dann auch eckige Klammern
enthalten oder gar andere Bestandteile der Received:-Zeile vort�uschen
kann. Ggf. kann es dann - je nach verwendeter Server-Software
-vorkommen, da� das Ende der Received:-Zeile wegen des �berlangen
HELO/ EHLO abgeschnitten wird. Diesen fiesen Trick sollte man also
bei "seltsamen" Received:-Zeilen im Hinterkopf behalten.
[12] Solche Beispiele sind nat�rlich nichts anderes als eben Beispiele
und bleiben daher auch nicht allzeit g�ltig. Momentan (Juli 2001)
hei�t der betreffende Rechner mit der IP-Nummer "205.162.108.87" nicht
mehr "hiper1-d87.cwnet.com", sondern "hiper4b-d87.stk.cwnet.com", und
n�chsten Monat vielleicht schon wieder ganz anders. Klar werden soll
das Prinzip.
***** IV. Hilfreiche Tools f�r die Header-Analyse *****
Ganz ohne Hilfsprogramme ist auch die Analyse eines E-Mail-Headers
nicht m�glich. Wichtig ist es insbesondere, herauszufinden, welche
IP-Nummern welchen Namen zugeordnet sind, und wer hinter diesen
Nummern/ Namen tats�chlich hintersteckt. Die wichtigsten Tools sollen
hier kurz vorgestellt werden. Bezugsquellen f�r die Programme folgen
unten.
**** 1. nslookup (host/dig) ****
Dieses Tool erwartet die Angabe einer IP-Nummer oder eines
Rechnernamens und liefert durch die Anfrage bei einem DNS-Server die
fehlende Angabe zur�ck. Das geht nat�rlich nur online. Wir haben
beispielsweise folgende Headerzeile:
> Received: from hiper1-d87.cwnet.com (HELOmailer1.themailmachaine.net)
> (205.162.108.87)
nslookup liefert f�r hiper1-d87.cwnet.com zur�ck:
| [hiper1-d87.cwnet.com]
| Translated Name: hiper1-d87.cwnet.com
| IP Address: 205.162.108.87
Und eine Anfrage mit 205.162.108.87 ergibt:
| [205.162.108.87]
| Translated Name: hiper1-d87.cwnet.com
| IP Address: 205.162.108.87
Wie bereits im Abschnitt II in Fu�note [7] erw�hnt, mu� die
R�ckw�rtsaufl�sung von der Nummer zum Namen hin nicht unbedingt
funktionieren oder wahr sein. Es empfiehlt sich daher, sie ggf. durch
eine Vorw�rtsaufl�sung zu �berpr�fen: wenn "205.162.108.87" zum Namen
"hiper1-d87.cwnet.com" geh�ren soll, dann mu� umgekehrt die Abfrage
auf "hiper1-d87.cwnet.com" wieder die Nummer "205.162.108.87" liefern.
Hinweis: nslookup d�rfte zuk�nftig von "host" bzw. "dig" abgel�st
werden.
**** 2. whois ****
Mit Hilfe von whois l��t sich beispielsweise herausfinden, wem
bestimmte IP-Nummern, IP-Nummern-Bereiche oder Domains geh�ren. Auf
diesem Weg lassen sich nicht nur zus�tzliche Beschwerdeadressen
finden, interessant ist es h�ufig auch, festzustellen, wer hinter
einem bestimmten Domain-Namen oder einer bestimmten IP-Nummer steckt.
Manchmal sind das bereits "alte Bekannte", so da� von vornherein klar
ist, da� Beschwerden dort keinen Erfolg haben werden ...
Beispielsweise ergibt die Abfrage "whois 205.162.108.87" den
Verantwortlichen f�r diese IP-Nummer bzw. denjenigen, dem diese Nummer
respektive der ganze Nummernblock, zu dem diese Nummer geh�rt,
zugeteilt wurde. Bei der Angabe eines Domainnamens statt einer
IP-Nummer wird der Eigent�mer der entsprechenden Domain
zur�ckgeliefert: "whois domain.name" ergibt entsprechend die Daten
desjenigen, der diese Domain registriert hat. - Die Eigent�mer von
Subdomains, bspw. von "irgendwas.de.vu", lassen sich in der Regel
nicht ermitteln; jedenfalls nicht auf diesem Wege, sondern allenfalls
�ber den Zust�ndigen f�r die Haupt-Domain (Second- Level-Domain),
bspw. "de.vu".
Bitte beachten: es gibt viele verschiedene Whois-Server, die jeweils
nur f�r eine bestimmte Top-Level-Domain (bspw. "de" oder "at" oder
"com") zust�ndig sind, und auch die Zust�ndigkeit f�r die
IP-Nummern-Bereiche ist auf eine Handvoll Regional Internet
Registries (RIRs) verteilt, insb. die von ARIN (amerikanischer Raum),
RIPE (europ�ischer Bereich) und APNIC (asiatisch-pazifischer Raum).
Wenn daher keine vern�nftige Antwort auf eine Abfrage erfolgt, mu�
stattdessen ein anderer, sprich der zust�ndige Whois-Server befragt
werden. Man kann auch direkt einen der "intelligenten" Whois-Server
wie whois.thur.de verwenden; diese leiten die Anfrage dann an den
richtigen Server weiter. Als weitere Alternative siehe dazu auch die
Online- Abfrageseiten im WWW unten unter 4.6.
**** 3. traceroute ****
Traceroute gibt den Weg an, den Datenpakete vom eigenen Rechner zum
angegebenen Zielrechner zur�cklegen. So l��t sich der Uplink f�r den
Zielrechner ermitteln, also sozusagen der "Provider des Providers".
Falls Beschwerden beim Provider selbst st�ndig erfolglos und ohne
Antwort bleiben, kann man auch daran denken, es eine Ebene h�her zu
probieren und sich an den Uplink zu wenden.
**** 4. Programmpakete und Bezugsquellen ****
Auf UNIX-Rechnern stehen die genannten Tools meist unter eben diesem
Namen zur Verf�gung. Unter anderen Betriebssystemen ist das zumeist
nicht der Fall - aber auch dort gibt es inzwischen Programmpakete, in
denen die gebr�uchlichsten Tools zusammengefa�t (und h�ufig mit einer
leicht bedienbaren grafischen Benutzeroberfl�che versehen) sind. Die
Programme sind im allgemeinen Free- oder Shareware.
Nicht zu empfehlen sind hingegen "automatische" Auswertungsprogramme,
die eigenst�ndig Headerzeilen analysieren und fertige Beschwerden
erzeugen k�nnen; jedenfalls dann nicht, wenn ihnen eine hohe
Fehlerquote eigen ist, die haufenweise zu Beschwerden bei
Unbeteiligten f�hrt und damit ausgesprochen kontraproduktiv ist. Dazu
geh�ren bspw. "NUCEM" von <http://www.helpmesoft.com/> oder
"SpamKiller" von <http://www.mcafee.com/>.
*** a) F�r Windows 95/98 (wahrscheinlich auch NT/2000/XP): ***
Standardm��ig existieren "ping" und "tracert" (=traceroute). DOS-Box
�ffnen und "ping [hostname/IP]" oder "tracert [hostname/IP]"
eintippen.
Sam Spade
<http://samspade.org/ssw/>
Dieses Programm ist speziell zur R�ckverfolgung unerw�nschter
Bulkmail ausgelegt. Es bietet neben ping, nslookup, traceroute,
IP- Blocks und weiteren Tools auch eine "automatische"
Headeranalyse, die bei einem ersten Einstieg in die Materie
sicher hilfreich ist, und liefert daneben auch einige
hervorragende, allerdings englischsprachige FAQs, Links und
Step-by-step-Anleitungen f�r die Absenderfeststellung und
Beschwerde bei unerw�nschter Bulkmail mit.
NetScan Tools for Windows 95
<http://www.netscantools.com/nstmain.html>
Nslookup, Finger, Ping, Traceroute, Scanner, etc.
VisualRoute
<http://www.visualware.com/visualroute/>
Graphisches Traceroute mit Whois-Abfragen und Portscan.
*** b) F�r OS/2: ***
Es existieren standardm��ig "ping", "nslookup" und "finger" - diese
Programme hei�en auch so. "traceroute" hei�t hier "tracerte".
Desweiteren gibt es eine whois-implementation von Frank Ellermann zum
Download unter <http://purl.net/xyzzy/rxwhois.htm>.
Andere Programmpakete sind mir derzeit nicht bekannt.
*** c) F�r MacOS 9: ***
IPNetMonitor
<http://www.sustworks.com/site/prod_ipmonitor.html>
Shareware, $20
Interarchy (ehemals MAC TCP Watcher)
<http://www.interarchy.com/>
Filetransfer-Programm (FTP, SFTP, HTTP), das u.a. auch ping,
traceroute, DNS lookup unterst�tzt.
*** d) F�r MacOS X: ***
Es existiert serienm��ig das "Network Utility" bzw. "Network
Dienstprogramm", welches unter "Applications/Utilities" zu finden ist.
Funktionsumfang: Netstat, Ping, Lookup, Trace, Whois, Finger,
Portscan.
**** 5. Finger-Gateway auf info.belwue.de ****
Wer �ber keines dieser Programme verf�gt, aber Zugriff auf einen
finger-client hat, kann stattdessen das finger-Gateway auf
info.belwue.de verwenden. Eine Hilfe dazu gibt es, wenn man
help@info.belwue.de anfingert:
| BelWue finger-gateway, available services:
| ping,traceroute,whois,nslookup,dnslist,acronym,translate,schwob,dfn,
| date,test
|
| You may specify arguments by adding them with an ':', examples:
| finger traceroute@info.belwue.de
| finger traceroute:www.bofh.net@info.belwue.de
| finger whois:belwue.de@info.belwue.de
| finger acronym:RTFM@info.belwue.de
**** 6. Online-Tools ****
Schlie�lich gibt es die kleinen Helferchen inzwischen auch vielfach
als Formular im WWW, mit dem man entsprechende Anfragen stellen kann.
Eine Zusammenstellung vieler guter Tools findet sich auf
<http://www.samspade.org/>
Empfehlenswert auch der allgemeine whois-Dienst auf
<http://www.iks-jena.de/cgi-bin/whois> sowie der whois-Dienst von
<http:// www.geektools.com/cgi-bin/proxy.cgi>
Eine umfangreichere Liste findet sich in der FAQ der Newsgroup
de.admin.net-abuse.mail; vgl. dazu die weiterf�hrenden Hinweise in
Abschnitt VII dieser FAQ.
Auch hier ist abzuraten von <http://www.spamcop.com/> (nicht zu
verwechseln mit spamcop.net!) und <http://www.spam-rbl.com/>.
**** 7. abuse.net ****
Das "Network Abuse Clearinghouse", <http://www.abuse.net/>, sammelt
Kontaktadressen von Providern, unter denen man die jeweilige
Beschwerdestelle erreichen kann. Die Kontaktdatenbank l��t sich auf
dreierlei Weise abfragen:
o Im WWW: <http://www.abuse.net/lookup.phtml>
o Per finger: finger example.com@abuse.net [mit der betreffenden
Domain statt "example.com", nat�rlich]
o Per whois: whois example.com @whois.abuse.net [mit der betreffenden
Domain statt "example.com", nat�rlich]
Erg�nzungen dieser Datenbank kann jedermann einreichen; insbesondere
dann, wenn die - eigentlich vorgeschriebenen - Adressen "abuse" oder
"postmaster" nicht existieren, ist es interessant, welche anderen
Adressen bei dem betreffenden Provider f�r Beschwerden brauchbar sind.
Dazu gen�gt eine Mail an update@abuse.net, die die entsprechende(n)
Adresse(n) m�glichst in folgender Form enth�lt:
| domain.example: beschwerde.hier@domain.exampleweitere.beschwerde@domain.example
Wenn nicht direkt klar ist, woher diese Angaben stammen, sollte eine
kurze Begr�ndung angegeben werden, warum das Kontaktadressen f�r
Beschwerden �ber diese bestimmte Domain sind, bzw. wie man sie
gefunden hat - in Englisch, bitte. :-)
Mehr dazu unter <http://www.abuse.net/addnew.html>.
**** 8. Blacklists auswerten ****
Diverse Anbieter f�hren (schwarze) Listen, in denen bestimmte Rechner
(IP- Adressen) und/oder Domains gef�hrt werden, die bestimmte
Voraussetzungen erf�llen, insbesondere negativ aufgefallen sind. Eine
manuelle oder automatisierte Auswertung dieser Listen kann durchaus
sinnvoll sein - sei es, da� man feststellen m�chte, ob ein bestimmter
Rechner bereits als offenes Relay (vgl. dazu [9]) aufgefallen ist,
oder da� man darauf aufbauende automatische Filter verwenden m�chte,
die bspw. Mail von bestimmten Rechnern kennzeichnen oder gar nicht
mehr annehmen (zum Thema Mailfilterung wie auch �ber Blacklists siehe
die Verweise in der FAQ von de.admin.net-abuse.mail, genannt in
Abschnitt VII dieser FAQ).
Wichtig bei der Verwendung solcher Listen ist es aber, sich zuvor zu
informieren, nach welchen Kriterien dort Rechner gelistet werden, und
wie verl��lich die Anbieter sind. Es gibt Listen von Rechnern, �ber
die unerw�nschte Massenwerbung verschickt wurde, von Rechnern bei
Providern, die auf solche Beschwerden reagieren, von sog. offenen
Relays, aber auch Listen der IP-Nummern-Bereiche von Einwahlkunden
(die deshalb nicht notwendigerweise Spammer sind) oder von Providern,
die bestimmte Beschwerdeadressen nicht eingerichtet haben. Diese
Listen sind teilweise gut gepflegt, teilweise enthalten sie aber auch
falsche Eintr�ge oder werden gar f�r pers�nliche Feden zwischen dem
Betreiber und anderen Institutionen benutzt.
Die meisten dieser Blacklists sind �ber spezielle DNS-Server
realisiert: man fragt dort nach dem Namen eines bestimmten Rechners
oder einer Domain, und wenn ein Eintrag existiert, dann steht dieser
Rechner oder diese Domain in der jeweiligen Blacklist. Teilweise kommt
auch dem Inhalt der zur�ckgelieferten Antwort eine Bedeutung zu. Wie
nun genau diese Abfrage erfolgt, ist listenspezifisch; �blich ist die
Angabe der IP-Adresse in umgekehrter Reihenfolge der Ziffernbl�cke
oder des Domainnamens, jeweils gefolgt vom Namen der Blacklist. Um
also den Rechner mit der IP-Nummer "a.b.c.d"" bei der - inzwischen
abgeschalteten - Blacklist relays.osirusoft.com abzuchecken, verwendet
man eine Abfrage der Form "host d.c.b.a.relays.osirusoft.com" (oder
ein anderes Tool, wie nslookup, bzw. ein Programmpaket, was dies
beherrscht, siehe dazu Abschnitt IV). Ggf. mu� man zu einem
Rechnernamen erst noch die IP-Nummer(n) ermitteln, bevor man die
Abfrage starten kann:
| [thomas@xerxes thomas]$ host moutvdom.kundenserver.de
| moutvdom.kundenserver.de has address 195.20.224.131
| moutvdom.kundenserver.de has address 195.20.224.200
| moutvdom.kundenserver.de has address 195.20.224.149
| moutvdom.kundenserver.de has address 195.20.224.130
|
| [thomas@xerxes thomas]$ host 131.224.20.195.relays.osirusoft.com
| 131.224.20.195.relays.osirusoft.com has address 127.0.0.4
Die genaue Bedeutung des Abfrageergebnisses l��t sich in diesem Falle
der jeweiligen Webseite entnehmen.
Mit dem unter <http://rblcheck.sourceforge.net/> verf�gbaren Tool l��t
sich die Abfrage von solchen Listen vereinfachen. Alternativ verf�gen
die meisten Blacklists auch �ber WWW-Formulare f�r solche Abfragen.
Links dazu finden sich am ehesten in der FAQ von
de.admin.net-abuse.mail, die in Abschnitt VII referenziert ist.
***** V. Beschwerden �ber unerw�nschte Massen-E-Mail *****
Die h�ufigsten Gr�nde, sich �ber den tats�chlichen Absender einer
E-Mail informieren zu wollen, sind die, da� man den bzw. die
Verantwortlichen f�r eine unerw�nschte, massenhaft verschickte
(Werbe- )E-Mail ("unsolicited commercial/bulk email", kurz UCE bzw.
UBE) ausfindig machen m�chte, um sich dort zu beschweren, oder da�
man das Opfer eines Bombardements sich per E-Mail selbst
verbreitender Viren und W�rmer steht, in einem Fall also das Opfer
von B�swilligkeit, in einem anderen das von Farhl�sigkeit ist. Womit
sich in beiden F�llen die Frage stellt: Wo und wie beschwert man
sich?
Dazu sollen hier nur einige grundlegende Hinweise gegeben werden;
Verweise auf weitere Informationsquellen finden sich unten unter Punkt
7 ("Weiterf�hrende Hinweise"). Insbesondere die Lekt�re der FAQ der
Newsgroup de.admin.net-abuse.mail sollte f�r diese F�lle ein Mu� sein.
**** 1. Wo kann ich mich beschweren? ****
*** a) Beim (angeblichen) Versender der UCE bzw. der Viren. ***
Wenig sinnvoll - meist sind die Absenderadressen gef�lscht, und wenn
die Beschwerde ankommt, f�hrt das im Zweifelsfall nur dazu, da� Ihre
Absenderadresse als tats�chlich existent vorgemerkt wird (was zu einer
Vermehrung der Werbeflut f�hren kann). Ausnahmen kann man vielleicht
bei UCE aus deutschen Landen machen, insb. dann, wenn man ohnehin
rechtliche Schritte erw�gt, oder wenn man den Eindruck hat, der
Betreffende wisse gar nicht, was er gerade anrichtet. Das Risiko, die
eigene Adresse als "gut" zu best�tigen, bleibt.
Auch bei Viren und W�rmern wird die Absenderadresse inzwischen
praktisch immer gef�lscht. Es ist also nutzlos bis nervig, den
angeblichen Absender von einer angeblichen Infektion seines Rechners
zu informieren. Daher sollten unbedingt auch automatische
Benachrichtigungn des Absenders in Virenscannern deaktiviert werden!
Leicht wird man sonst durch die Benachrichtigungsfunktion zur
UBE-Schleuder wider Willen gemacht.
*** b) Beim Hersteller o.�. des per UCE beworbenen Produkts. ***
Auch das nur sinnvoll, wenn es sich um eine namhafte Firma handelt,
die entweder von dieser "Werbekampagne" gar nichts wei�, oder
zumindest keine Ahnung hat, wie sehr sie gerade ihrem Ruf schadet.
*** c) Beim (tats�chlichen) Provider des UCE-/Viren-Versenders. ***
Die meisten Provider m�gen keine UCE-Versender unter ihren Kunden und
reagieren darauf wie auch auf Vireninfektionen entsprechend mit
Verwarnungen, Accountentzug und/oder Vertragsstrafen, sofort oder im
Wiederholungsfall (manche allerdings auch gar nicht). Die Adresse f�r
Beschwerden ist (sollte sein) abuse@providername.example; sofern diese
Adresse nicht existiert, ersatzweise postmaster@providername.example,
wobei nat�rlich jeweils die E-Mail-Domain des Providers statt
"providername.example" einzusetzen ist, also bspw. "t-online.de".
Darauf sollte auf jeden Fall eine Antwort kommen, meist eine
automatische Best�tigung oder der Hinweis, da� f�r UCE u.�. spezielle
Beschwerdeadressen existieren. - Falls diese Adressen nicht
existieren, kann der betreffende Provider bei
<http://www.rfc-ignorant.org/> gemeldet werden; dort wird eine
(schwarze) Liste solcher Provider, die technische Standards (RFCs)
nicht befolgen, gef�hrt. Diese kann man nat�rlich auch selbst zuvor
abfragen, vgl. dazu die genannten Webseite und Abschnitt IV dieser
FAQ.
Vereinfachen l��t sich dieses Vorgehen �ber <http://www.abuse.net/>
(siehe dazu auch Abschnitt IV dieser FAQ). Dort wird eine Datenbank
mit Beschwerdeadressen gef�hrt; E-Mail an provider.domain@abuse.net
(bspw. aol.com@abuse.net) wird automatisch an die passenden
Beschwerdeadressen weitergeleitet. Bei Providern, die erfahrungsgem��
nicht reagieren, geht eine Kopie der Beschwerde an den Uplink (s.
unten).
Falls auf keine der genannten Vorgehensweisen eine Antwort erfolgt,
kann man noch versuchen, sich an den "Administrative Contact"
(Admin-C) der Domain zu wenden. Dessen Erreichbarkeit (auch Telefon-
und Faxnummer sowie Anschrift) l��t sich mittels des Tools "whois"
herausfinden.
*** d) Beim Uplink des Providers. ***
Wenn ein Provider l�ngere Zeit nicht reagiert, bleibt die M�glichkeit,
sich eine Stufe h�her beim Uplink (also dem "Provider des Providers")
zu beschweren. Wer das ist, l��t sich bspw. mit Hilfe des Tools
"traceroute" (s. oben, Abschnitt IV) herausfinden.
*** e) Bei offenen Relays. ***
UCE wird meist nicht direkt verschickt, sondern bei einem
(unbeteiligten) Mailserver "abgekippt", der so gutgl�ubig ist, nicht
nur E-Mail von eigenen Benutzern nach �berall und von �berall an die
eigenen Benutzer zuzustellen, sondern von �berall nach �berall
weiterzuleiten. Das mag einmal sinnvoll und hilfreich gewesen sein,
ist aber heutzutage nur eine Einladung zum Mi�brauch. Insofern sollte
man auch dort den zust�ndigen Postmaster auf den Mi�brauch hinweisen
und ihn bitten, seinen Mailserver "relayfest" zu machen. Entsprechende
Hinweisen f�r Administratoren finden sich auf
<http://www.mail-abuse.com/an_sec3rdparty.html>.
Wer Zugriff auf den betreffenden Server hat, d.h. sich dort mindestens
als User einloggen kann, kann mittels eines "telnet mail- abuse.org",
ausgef�hrt auf eben dem Mailserver, ebenfalls feststellen, ob dieser
relayfest ist. Es wird dann automatisch ein Relaytest gegen diesen
Server, von dem aus man sich eingeloggt hat, gefahren. Das eignet sich
in der Regel eher f�r Administratoren. Unter
<http://rblcheck.sourceforge.net/> l��t sich ein einfaches Tool
herunterladen, um zu pr�fen, ob der betreffende Server bereits in
eine Blacklist (bspw. als offenes Relay) eingetragen wurde. Das kann
ggf. einen eigenen Test ersparen. F�r eine tiefergehende Erl�uterung
und weitergehende Links verweise ich auf die FAQ der Newsgroup
de.admin.net-abuse.mail, vgl. Abschnitt VII dieser FAQ.
Das Problem der offenen Relays wird zunehmend durch das Problem der
viren- oder wurminfizierten und "gekaperten" Rechner abgel�st; bei
diesen werden dann - auch auf ganz normalen Endbenutzerrechnern, die
sonst nur zur Textverarbeitung und zum Surfen im Internet genutzt
werden! - heimlich ungesicherte Mailsysteme (eben offfene Relays)
installiert, ohne da� der Benutzer davon wei� oder dies bemerkt.
*** f) Bei E-Mail- und Webspace-Providern. ***
Die meisten Anbieter von (kostenlosen) E-Mail-Adressen, wie gmx.net,
hotmail.com etc. verbieten die Verwendung dieser Adressen in
Zusammenhang mit UCE, sei es als Absender, sei es als im Body
angegebene Adresse f�r weitere Infos, und l�schen auf Hinweis solche
Accounts ("Dropboxen") sofort. Auch manche Webspace-Provider
reagieren, wenn Webseiten per UCE beworben werden.
*** g) Bei Dritten (Firmen, Beh�rden, Instituionen). ***
In ganz bestimmten F�llen kann es auch sinnvoll sein, sich mit seiner
Beschwerde an Dritte zu wenden, bspw. dort, wo der Versand
unerw�nschter Werbe-E-Mail ordnungswidrig oder strafbar ist, an die
zust�ndige Beh�rde. Oder beim Bewerben von Raubkopien von Software an
den Hersteller oder einen Verband der Softwareindustrie. Oder bei
offensichtlichem Betrug (aber nur dann!) an eine Polizeidienststelle.
Oder bei Versuchen, Pa�worte auszuspionieren, bspw. f�r das
Onlinebanking, an die betroffene Bank.
Diese Institutionen haben oft ein eigenes Interessen, gegen den
Urheber vorzugehen, und teilweise andere rechtliche und/oder
tats�chliche M�glichkeiten als Otto Normalverbraucher.
Eine (englische) Liste beispielhafter Adressen findet sich auf
<http://banspam.javawoman.com/report3.html>.
**** 2. Wie beschwere ich mich? ****
Auf jeden Fall *h�flich*; der Provider kann meist nichts f�r seine
Kunden, und selbst wenn: durch Beschimpfungen erreicht man nichts.
Nach M�glichkeit *kurz*; meist kommt nicht eine Beschwerde, sondern
Dutzende bzw. Hunderte.
Immer unter Beif�gung des *vollst�ndigen Headers* - nur dann kann der
Beschwerde nachgegangen und etwas unternommen werden.
Im Zweifelsfall auf englisch.
Und letztlich: bitte immer beim *richtigen* Ansprechpartner, nicht
wahllos bei allen irgendwo in der E-Mail genannten Adressen und
Domains. In diesem Zusammenhang sei von der Verwendung "automatischer"
Beschwerde-Tools abgeraten.
***** VI. Headerzeilen anzeigen lassen *****
Bei vielen Mailclients werden standardm��ig gar keine oder zumindest
nicht alle Headerzeilen angezeigt. Wie man dennoch an den
vollst�ndigen Header einer E-Mail kommt, l��t sich normalerweise der
Dokumentation des Programms oder der Online-Hilfe entnehmen. Hier
finden sich dementsprechend nur kurze Hinweise f�r die
gebr�uchlichsten Programme (in alphabetischer Reihenfolge).
**** 1. Mailclients ****
*** AK-Mail: ***
| "Ansicht", "Kopf-Zeilen"
| Hinweis: Dieser Men�punkt steht nur zur Verf�gung, wenn der Mail-Body
| sichtbar ist.
*** Crosspoint: ***
| Taste <o>
| Hinweis: Crosspoint speichert den Header im ZConnect-Format; um anden
| originalen RFC-Header zu kommen, bedarf es eines Umwegs:
| (1) Unter edit boxen edit diverses
| Verschiedene Einstellungen
| Filter Eingang \XP\BACKUP.BAT $PUFFER
| eintragen.
| (2) Datei \XP\BACKUP.BAT anlegen mit folgendem Inhalt:
| @echo off
| cls
| REM :: Puffer mit Mails in Sicherheit bringen, da er bei
| REM :: ESC-Abbruch gel�scht wird!
| copy /B \XP\spool\*. \XP\backup\.
| REM :: Mail kommt noch mal extra damit suchen schneller geht
| copy /B \XP\spool\D-N*. \XP\backupN\.
| REM :: MIMEs extrahieren hier
| REM :: XP-Filter hier
| (3) Die Mails finden sich als einzelne Dateien in \XP\backupN\
| Das Verzeichniss sollte man von Zeit zu Zeit aufr�umen. ZurSuche
| empfiehlt es sich, die Message-ID bei "find" oder "grep"anzugeben,
| es gibt auch kleines Tool, das einem die Suche von XP auserlaubt.
*** elm: ***
| Taste <h>
*** XEmacs VM-Mail: ***
| (1) Taste <t>
| (2) Alternativ kann man in der $HOME/.emacs eine Zeile der Art
| (setq vm-invisible-header-regexp "X-.*")
| einfuegen. Dann werden alle Header bis auf die, die mit X-beginnen,
| angezeigt. Wirkt erst nach einem Neustart des emacs.
*** Eudora 3.0: ***
| 'BlahBlah'-Button in der Toolbar anklicken
*** Forte (Free) Agent: ***
| Taste <h>
*** Gnus: ***
| Tasten <Strg>-<u> <g>
| (im "Summary Buffer" auf der Zeile der Mail einzugeben) oder
| <W> <v> (im "Summary Buffer")
*** Lotus Notes (vor Version 6): ***
| Die L�sung ist etwas kompliziert - folgende zwei M�glichkeitenbestehen:
| (1) F�r einzelne Headerzeilen:
| Wenn die Mail in Notes zur Ansicht ge�ffnet ist, im Men� "Datei/
| Eigenschaften: Dokument" ausw�hlen, in dem erscheinendenFenster
| den zweiten Reiter von links ("Felder") ausw�hlen: man siehtdie
| einzelnen Headerzeilen wie MessageID usw.
| (2) F�r den kompletten Header:
| Wenn man sich im View (z.B. "Inbox") befindet: den Fokus aufdie
| Mail stellen, "Datei / "Export..." ausw�hlen und "StructuredText"
| als Exportformat ausw�hlen. Im nachfolgenden Dialog "Selected
| Documents" ausw�hlen und man erh�lt eine Klartext-Datei mitallen
| Headerzeilen und dem Body am St�ck. Funktioniert nur im View,nicht
| wenn die Mail zur Ansicht ge�ffnet ist! Aus dieser Datei die
| uninteressanten Notes-Header zu l�schen ist meist einfacher alsdie
| relevanten Header aus der "Properties"-Box einzeln zu kopieren.
*** Lotus Notes 6: ***
| F�r den Notes-6-Client gibt es eine einfachere L�sung:
| Die EMail bildschirmf�llend oeffnen (Doppelklick auf die EMail inder
| Inbox) und im (engl.) Menu dann "View" --> "Show" --> "Page View"
| anw�hlen. Die dann angezeigte Seite l��t sich problemlos in die
| Zwischenablage kopieren.
*** MacSOUP: ***
| Taste <h> oder Tasten Befehl+<h>
*** Mozilla: ***
| 1. "View", "Headers", "All"
| (funktioniert im Ggs. zu alten Netscape-Versionen besser;allerding
| werden m�glicherweise lange Headerzeilen am Zeilenendeabgeschnitten)
| 2. View", "Page Source"
| (Anzeige der Mail mit allen Headern im Editor)
| 3. Installation von mnheny (<http://mnenhy.mozdev.org/>) und dann
| entsprechende Konfiguration zus�tzlich anzuzeigender Header
| 4. Ctrl-U (bzw. Strg-U)
*** MS Outlook: ***
| "Ansicht", "Optionen"
*** MS Outlook 97: ***
| "Datei", "Eigenschaften", "Internet"
*** MS Outlook Express: ***
| "Eigenschaften", "Details"
| oder Tasten <Strg>+<F3>
*** mutt: ***
| Taste <h>
*** Netscape 4.x: ***
| "Ansicht", "Seitenquelltext"
| Hinweis: Netscape zermanscht bei eingeschalteten Headern ("View",
| "Headers", "All") die einzelnen Headerzeilen durch Einr�ckungen etc.zu
| einem wilden Brei. "View", "Page Source" ("Ansicht","Seitenquelltext")
| liefert den Header in lesbarer Formatierung.
*** Netscape 7.x: ***
| siehe "Mozilla"
*** Novell GroupWise: ***
| <http://www-lan.uni-regensburg.de/email/gw/header.html>
*** Pegasus-Mail: ***
| Tasten <Strg>+<h>
*** pine: ***
| Taste <h>
| Ggf. mu� man vorher die Option
| Main Menu -> Setup -> Config -> enable-full-header-cmd
| aktivieren.
*** Sylpheed Claws: ***
| "Ansicht", "Zeige alle Kopfzeilen"
| oder Tasten <Strg>+<h>
*** The Bat! 1.61: ***
| "Special", "View Source" (oder <F9>)
| "View", "RFC-822 header" aktivieren (oder <Shift>+<Strg>+<K>)
*** T-Online E-Mail: ***
| Im Kontextmen� "Alle Kopfzeilen anzeigen" w�hlen
| (also mit der Maus in die Mail klicken, rechte Maustaste,
| "Alle Kopfzeilen anzeigen").
**** 2. Webmail ****
Die zunehmende Nutzung von Webmail-Diensten l��t auch da die Frage
entstehen, wie man die Weboberfl�che dazu bewegen kann, die
vollst�ndigen Header herauszur�cken.
*** GMX ***
| - E-Mail �ffnen
| - Briefumschlag-Icon (rechts oben) mit Titel "Ausdruck der Header-
| Informationen" klicken
| - Zusatzfenster mit kompletten Header �ffnet sich
*** IMP 3 <http://www.horde.org/imp/> ***
| "Quelltext" oder "Message Source" in dem Zusatzmen� �ber dem
| Nachrichtenfenster anklicken (direkt �ber der Datumszeile).
*** web.de ***
| - E-Mail �ffnen
| - Klick auf "erweiterten Header anzeigen"
| - Reload der Seite, diesmal mit Anzeige der vollen Header
***** VII. Weiterf�hrende Hinweise *****
**** Einf�hrung in das Thema E-Mail an sich: ****
o E-Mail-Einf�hrung
<http://www.fitug.de/bildung/e-mail/e-mail.html>
o Mail - eine Einf�hrung
<http://piology.org/mail/>
o Reading Email Header
<http://www.stopspam.org/email/headers.html>
o Transport von E-Mails - RFC 2821
<http://www.daniel-rehbein.de/rfc2821.html>
o RFC 2076: "Common Internet Message Headers"
<http://www.faqs.org/rfcs/rfc2076.html>
o RFC 2822: "Internet Message Format"
<http://www.faqs.org/rfcs/rfc2822.html>
o RFC 2821: "Simple Mail Transfer Protocol"
<http://www.faqs.org/rfcs/rfc2821.html>
**** E-Mail-Mi�brauch: ****
o FAQ, Abkuerzungen: de.admin.net-abuse.mail
<http://www.irrlicht.net/~laura/de.admin.net-abuse.mail.txt> oder
<http://www.cs.uu.nl/wais/html/na-dir/de-net-abuse/mail-faq.html>
o Teergruben-FAQ
<http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.html>
o Newsgruppe de.admin.net-abuse.mail de.admin.net-abuse.mail
o vereinfachtes Auffinden der richtigen Beschwerdeadresse(n)
<http://www.abuse.net/>
o Script zur Header-Analyse (online) inkl. Vorbereitung / Versenden
von Beschwerden
<http://spamcop.net/>
Insbesondere die FAQ von de.admin.net-abuse.mail sei jedem, der sich
mit unerw�nschten Werbemails herumschl�gt, ans Herz gelegt. Es
erscheint mir nicht sinnvoll, die dortigen Informationen und
insbesondere Links hier alle zu wiederholen.
***** VIII. Credits *****
Die Idee zu dieser FAQ kam urspr�nglich von Hermann Roth.
F�r hilfreiche Tips, Hinweise und Korrekturen geht ein Dankesch�n an
o Claus Assmann
o Florian Bannasch
o Jens Baumeister
o Theo Baumeister
o Stefan Bion
o Ralf Borchert
o Philipp Buehler
o Georg Burkhard
o Christoph Conrad
o Andreas Croll
o Christoph Daldrup
o Matthias Damm
o Felix Deutsch
o Frank Ellermann
o Hubert Englmaier
o Daniele Frijia
o Ulf Herbers
o Ulli Horlacher
o Ludwig Huegelschaefer
o Jochen Klein
o Albert Koellner
o Helmut Reininger
o Hermann Roth
o Johannes Sempert
o Otto Stolz
o J�rg Strohmayer
o Olaf Titz
o Rainer Zocholl
o Michael Zolk
o und andere
***** IX. Lizenz *****
[Creative Commons-Lizenzvertrag by-nc-sa-2.0-de] Dieser Inhalt ist
unter einer Creative Commons-Lizenz lizenziert; er darf unter
Namensnennung der Autoren nicht-kommerziell weitergegeben und auch
bearbeitet werden, soweit das neue Werk gleichfalls wieder dieser
Creative-Commons-Lizenz unterliegt. Die Einzelheiten ergeben sich aus
dem Lizenzvertrag.
User Contributions:Comment about this article, ask questions, or add new information about this topic:
[ Usenet FAQs | Web FAQs | Documents | RFC Index ]
Send corrections/additions to the FAQ Maintainer: Thomas Hochstein <faq@usenet.th-h.de>
Last Update March 27 2014 @ 02:11 PM
|
[FAQ] E-Mail-Header lesen und verstehen <2005-01-11>
Search the FAQ Archives
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
[FAQ] E-Mail-Header lesen und verstehen <2005-01-11>
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Houses ]
I dream of hard sex. Write me on this site - is.gd/hw6aii
I dream of hard sex. Write me on this site - u.to/p-bKGw
I love oral sex! Write me - u.to/kvbKGw