 |
INTERNET - Möglichkeiten und Dienste
Prof. Jürgen Plate |
FAQ: E-Mail-Header lesen und verstehen
Von Frank Ellermann
Posted-By: auto-faq 3.3 (Perl 5.006) [mod. by -thh]
Archive-name: de-net-abuse/email-header-faq
Last-modified: 2002-06-03
Version: 1.2.0
Posting-frequency: monthly
URL: http://www.th-h.de/faq/headerfaq.php3
FAQ: E-Mail-Header lesen und verstehen
======================================
Letzte Änderungen
=================
2002-06-03: Komplette Überarbeitung der FAQ.
Inhalt:
=======
1. Vorwort
2. Aufbau und Zustellung einer E-Mail
2.1 SMTP-Envelope
2.2 Header
2.3 Body
3.5 Vorgehen bei der Zustellung
3. E-Mail-Headerzeilen im einzelnen
3.1 Anschrift, Absender u. Verwandtes - kurz: der Briefkopf
3.2 "Technische" Angaben
3.3 "Zustellvermerke": den Weg einer E-Mail nachvollziehen
3.4 Spezielle Headerzeilen
4. Hilfreiche Tools für die Headeranalyse
4.1 nslookup
4.2 whois
4.3 traceroute
4.4 Programmpakete und Bezugsquellen
4.5 Finger-Gateway auf info.belwue.de
4.6 Online-Tools
4.7 abuse.net
5. Beschwerden über unerwünschte Massen-E-Mail
5.1 Wo kann ich mich beschweren?
5.2 Wie beschwere ich mich?
6. Headerzeilen anzeigen lassen
7. Weiterführende Hinweise
8. Credits
----------------------------------------------------------------------
1. Vorwort
==========
Zweck dieser 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 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 7.
Korrekturen, Ergänzungshinweise und Verbesserungsvorschläge nehme ich
gerne entgegen (<mailto:faq@usenet.th-h.de>).
[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>)
----------------------------------------------------------------------
2. 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).
2.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
den Inhalt des Umschlags 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.
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):
2.1.1 Die Begrüßung (HELO)
| HELO ancalagon.rhein-neckar.de
| 250 pri.owl.de 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; 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, ist es notwendig,
sich zeitnah an den betreffenden Provider zu wenden. Mehr Hinweise dazu
finden Sie weiter unten in Abschnitt 5.
2.1.2 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.de>
| 250 <karl-heinz@owl.de>... 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.
[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.de" die
dazugehörige IP-Adresse zu erfahren und den Server ansprechen zu
können) konsistent sein. Ein böswilliger Anbieter "a-provider.de", 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.de" verbinden, auch wenn
umgekehrt die Eingabe von "mail.a-provider.de" vorwärts zu der Nummer
193.197.90.30 führt und "mail.b-provider.de" 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.de" 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.de" registrieren.
2.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.de> adressieren, aber in einen Umschlag
stecken, der (wie oben) an <karl-heinz@owl.de> 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 3 ausführlich besprochen.
[8] Sinnvoll ist dieses Vorgehen bspw. für Mailinglisten: als Empfänger steht
dann bpsw. "Alle Teilnehmer der Taubenfutter-Mailingliste"
<taubenfutter@mailingliste.de> 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>" 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].
[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.
2.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.
2.4 Vorgehen bei der Zustellung
Wenn ein Mailserver eine E-Mail bekommt, ist seine 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.
[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.
----------------------------------------------------------------------
3. 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.de>
| Received: from mx3.gmx.net (qmailr@mx3.gmx.net [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.net
| Received: (qmail 27698 invoked by uid 0); 16 Sep 1998 15:36:02 -0000
| Received: from pbox.rz.rwth-aachen.de (137.226.144.252)
| by mx3.gmx.net with SMTP; 16 Sep 1998 15:36:02 -0000
| Received: from post.rwth-aachen.de (slip-vertech.dialup.RWTH-Aachen.DE
| [134.130.73.8]) by pbox.rz.rwth-aachen.de (8.9.1/8.9.0) with ESMTP
| id RAA28830 for <karl-heinz@gmx.net>; Wed, 16 Sep 1998 17:35:59
| +0200
| Message-ID: <35FFDA4F.2BC2A064@post.rwth-aachen.de>
| Date: Wed, 16 Sep 1998 17:33:35 +0200
| From: Heinz-Gustav Hinz <heinz-gustav@post.rwth-aachen.de>
| Organization: RWTH Aachen
| X-Mailer: Mozilla 4.05 [de] (Win95; I)
| To: Karl-Heinz Schmitt <karl-heinz@gmx.net>
| 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.de
| X-Resent-By: Global Message Exchange <forwarder@gmx.net>
| X-Resent-For: karl-heinz@gmx.net
| X-Resent-To: karl-heinz@ancalagon.rhein-neckar.de
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.
3.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.de>
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 2.1
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.net>
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 Zustimmung 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.de
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.
3.2 "Technische" Angaben
| Message-ID: <35FFDA4F.2BC2A064@post.rwth-aachen.de>
| In-Reply-To: <529471993@ancalagon.rhein-neckar.de>
| References: <529471993@ancalagon.rhein-neckar.de>
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 (ähnlich 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 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
werden von verschiedenen Programmen (oder auch Benutzern) beliebig
eingefügt. Ü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".
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 RFCs in Abschnitt 7 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 fast
schon überflüssig.
3.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 Fälschungsversuchen aufzusitzen.
| Return-Path: <heinz-gustav@post.rwth-aachen.de>
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.
3.3.1 "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.de heißen. Wenn derselbe Rechner auch
für das WWW und News zuständig ist, heißt er vielleicht auch noch
www.domain.de und news.domain.de - das ist aber immer noch derselbe
Rechner. Genauer feststellen läßt sich das durch eine DNS-Abfrage
(nslookup, vgl. Abschnitt 4); in diesem Fall müßten dort beide Namen für
denselben Rechner, d.h. dieselbe IP-Nummer, registriert sein.
3.3.2 "Received:"-Headerzeilen im einzelnen
| Received: from mx3.gmx.net (qmailr@mx3.gmx.net [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 meist, da es ja die einzelnen Empfänger
nichts angeht, wer die E-Mail sonst noch bekommen hat.
| Received: from mx3.gmx.net (qmailr@mx3.gmx.net [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". Außerdem ist angegeben,
wie dieser sich vorgestellt hat (die Angabe aus dem HELO) - hier
"qmailr@mx3.gmx.net". Das hat unser Mailserver brav überprüft und
festgestellt, daß die IP-Nummer tatsächlich zu "mx3.gmx.net" 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 4.1).
| 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.net
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.de (137.226.144.252)
| by mx3.gmx.net 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.net with SMTP; 16 Sep 1998 15:36:02 -0000
"mx3.gmx.net" 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 würde ich durchaus als vertrauenswürdig bezeichen.
| Received: from pbox.rz.rwth-aachen.de (137.226.144.252)
Bekommen hat er sie von "pbox.rz.rwth-aachen.de" 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 (HELO mailer1.themailmachaine.net)
> (205.162.108.87)by mx1.gmx.net 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 4.1). [11]
Aber weiter im Text - wir waren stehengeblieben bei der Feststellung,
daß GMX die Mail von "pbox.rz.rwth-aachen.de" hat.
| Received: from post.rwth-aachen.de (slip-vertech.dialup.RWTH-Aachen.DE
| [134.130.73.8]) by pbox.rz.rwth-aachen.de (8.9.1/8.9.0) with ESMTP
| id RAA28830 for <karl-heinz@gmx.net>; Wed, 16 Sep 1998 17:35:59
| +0200
"pbox.rz.rwth-aachen.de" wiederum hat sie von jemandem, der sich als
"post.rwth-aachen.de" vorgestellt hat, tatsächlich aber "slip-
vertech.dialup.RWTH-Aachen.DE" 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.net>
| X-Resent-For: karl-heinz@gmx.net
| 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.
[11] 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.
3.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 zunehmend auch die Headerzeile "X-Sender". Diese soll
ebenfalls den tatsächlichen Sender angeben. Zumindest bei T-Online-Kunden
funktioniert das anerkanntermaßen (natürlich nur, solange auch einer der
T-Online-Mailserver verwendet wird):
| X-Sender: 06221168783-0001@t-online.de
Die Angabe ist in diesem Fall die T-Online-Benutzerkennung, die bei
älteren Kunden zu allem Überfluß auch noch mit der Telefonnummer identisch
ist. In diesem speziellen Fall kann man eventuelle Nachfragen dann sogar
telefonisch klären. ;-) Auch sonst lassen sich über das bei T-Online
automatisch angelegte Impressum der Nutzer-Webseiten eventuell die
persönlichen Daten des Versenders ermitteln - wenn dieser Versender
private Webseiten bei T-Online hat: es findet sich dann unter
<http://home.t-online.de/home/NUTZERKENNUNG/.impressum.html>, im Beispiel
also unter <http://home.t-online.de/home/06221168783-0001/.impressum.html>.
Bitte beachten: auch ein X-Sender läßt sich natürlich fälschen, wenn die
E-Mail in Wahrheit gar nicht über einen Mailserer von T-Online verschickt
wurde. Für andere Mailserver hat diese Headerzeile keine spezielle
Bedeutung, so daß sie dafür jeden Wert akzeptieren.
----------------------------------------------------------------------
4. 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 unter 4.4.
4.1 nslookup
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 (HELO mailer1.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 2.1 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.
4.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 Doamin-
Namen steckt. Manchmal sind das bereits "alte Bekannte", so daß von
vornherein klar ist, daß Beschwerden dort keinen Erfolg haben werden.
So 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. Ggf. muß der
richtige Whois-Server befragt werden, wenn keine vernünftige Antwort
geliefert wird, siehe dazu auch die Online-Abfrageseiten unten unter 4.6.
Bei der Angabe eines Domainnamens statt einer IP-Nummer wird der
Eigentümer der entsprechenden Domain zurückgeliefert. Auch hier ist
natürlich der richtige Server zu befragen. - Die Eigentümer von
Subdomains, bspw. von "irgendwas.de.vu", lassen sich in der Regel nicht
ermitteln, jedenfalls nicht auf diesem Wege.
4.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.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.
Für Windows 95/98 (wahrscheinlich auch NT/2000):
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.
+ Cyber Kit
<http://www.cyberkit.net/>
Bietet Ping, Traceroute, Finger, WhoIs, NS Lookup, QoD.
Derzeit ist die o.g. Website nicht zugänglich; das Programm selbst wird
aber unter anderem bei <http://www.tucows.com/preview/195085.html> zum
Download angeboten.
+ Internet Maniac
<http://network-spy.com/maniac.php>
Bietet Host Lookup, Ping, Traceroute, Connect, Time, Finger, Whois,
POP3, Listener, Scanner, Winsock, Raw connect, Speed check.
+ 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.
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://frank.ellermann.bei.t-online.de/src/rxwhois.cmd>
Andere Programmpakete sind mir derzeit nicht bekannt.
Für Amiga:
+ <http://ftp.wustl.edu/systems/amiga/aminet/comm/tcp/>
Für Ataris:
(Zur Zeit keine URLs bekannt.)
Für MacOS 9:
+ IPNetMonitor:
<http://www.sustworks.com/site/prod_ipmonitor.html>
Shareware, $20
+ Interarchy (ehemals MAC TCP Watcher):
<http://www.interarchy.com/>
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.
4.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
4.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 7 dieser FAQ.
4.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:
Im WWW:
<http://www.abuse.net/lookup.phtml>
Per finger:
finger example.com@abuse.net
[mit der betreffenden Domain statt "example.com", natürlich]
Per whois:
whois example.com @whois.abuse.net
[mit der betreffenden Domain statt "example.com", natürlich]
----------------------------------------------------------------------
5. Beschwerden über unerwünschte Massen-E-Mail
==============================================
Der häufigste Grund, sich über den tatsächlichen Absender einer E-Mail
informieren zu wollen, ist der, 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. Womit sich 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.
5.1 Wo kann ich mich beschweren?
5.1.1 Beim Versender der UCE.
Wenig sinnvoll - meist sind die Absenderadressen gefälscht, und wenn die
Beschwerde ankommt, führt das im Zweifelsfall nur dazu, daß Deine
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.
5.1.2 Beim Hersteller o.ä. des 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.
5.1.3 Beim (tatsächlichen) Provider des UCE-Versenders.
Die meisten Provider mögen keine UCE-Versender unter ihren Kunden und
reagieren 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@.....;
sofern diese Adresse nicht existiert, ersatzweise postmaster@..... Darauf
sollte auf jeden Fall eine Antwort kommen, meist eine automatische
Bestätigung oder der Hinweis, daß für UCE u.ä. spezielle
Beschwerdeadressen existieren.
Vereinfachen läßt sich dieses Vorgehen über <http://www.abuse.net/>. 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 Weisen eine Antwort erfolgt, kann man noch
versuchen, sich an den "Administrative Contact" (Admin-C) der Domain zu
wenden. Dessen Erreichbarkeit (auch Telefon- und Faxnumemr sowie
Anschrift) läßt sich mittels des Tools "whois" herausfinden.
5.1.4 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 4.3) herausfinden.
5.1.5 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.
Unter <http://mail-abuse.org/tsi/ar-test.html> gab es einen einfachen Test
(zur Zeit wegen Mißbrauchs leider deaktiviert), um festzustellen, ob
ein Mailserver für jedermann relayed oder nicht; stattdessen finden sich
dort jetzt Verweise auf andere Testmöglichkeiten. Auch kann man (wenn man
Zugriff auf den betreffenden Server hat, d.h. sich dort mindestens als
User einloggen kann) mittels eines "telnet mail-abuse.org", ausgeführt auf
dem betreffenden 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 7 dieser
FAQ.
5.1.6 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.
5.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.
----------------------------------------------------------------------
6. 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).
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 an den
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. Zur Suche
empfiehlt es sich, die Message-ID bei "find" oder "grep" anzugeben,
es gibt auch kleines Tool, das einem die Suche von XP aus erlaubt.
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 <Ctrl>-<u> <g>
(im "Summary Buffer" auf der Zeile der Mail einzugeben) oder
<W> <v> (im "Summary Buffer")
Lotus Notes:
Die Lösung ist etwas kompliziert - folgende zwei Möglichkeiten bestehen:
(1) Für einzelne Headerzeilen:
Wenn die Mail in Notes zur Ansicht geöffnet ist, im Menü "Datei /
Eigenschaften: Dokument" auswählen, in dem erscheinenden Fenster
den zweiten Reiter von links ("Felder") auswählen: man sieht die
einzelnen Headerzeilen wie MessageID usw.
(2) Für den kompletten Header:
Wenn man sich im View (z.B. "Inbox") befindet: den Focus auf die
Mail stellen, "Datei / "Export..." auswählen und "Structured Text"
als Exportformat auswählen. Im nachfolgenden Dialog "Selected
Documents" auswählen und man erhält eine Klartext-Datei mit allen
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 als die
relevanten Header aus der "Properties"-Box einzeln zu kopieren.
MacSOUP:
Taste <h> oder Tasten Befehl+<h>
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 Formattierung.
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.
The Bat!:
"View", "Show Kludges" (oder <F9>)
----------------------------------------------------------------------
7. Weiterführende Hinweise
==========================
Einführung in das Thema E-Mail an sich:
-- E-Mail-Einführung
<http://www.fitug.de/bildung/e-mail/e-mail.html>
-- Mail - eine Einführung
<http://piology.org/mail/>
-- Reading Email Header
<http://www.stopspam.org/email/headers/headers.html>
-- RFC 2076: "Common Internet Message Headers"
<http://www.faqs.org/rfcs/rfc2076.html>
-- RFC 2822: "Internet Message Format"
<http://www.faqs.org/rfcs/rfc2822.html>)
-- RFC 2821: "Simple Mail Transfer Protocol"
<http://www.faqs.org/rfcs/rfc2821.html>)
E-Mail-Mißbrauch:
-- FAQ, Abkuerzungen: de.admin.net-abuse.mail
<http://home.snafu.de/laura/de.admin.net-abuse.mail.txt>
<http://www.cs.uu.nl/wais/html/na-dir/de-net-abuse/mail-faq.html>
-- Teergruben-FAQ
<http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.html>
-- Newsgruppe de.admin.net-abuse.mail
news:de.admin.net-abuse.mail
-- vereinfachtes Auffinden der richtigen Beschwerdeadresse(n)
<http://www.abuse.net/>
-- 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.
----------------------------------------------------------------------
8. Credits
==========
Die Idee zu dieser FAQ kam ursprünglich von Hermann Roth.
Für hilfreiche Tips, Hinweise und Korrekturen geht ein Dankeschön an
* Claus Assmann
* Florian Bannasch
* Jens Baumeister
* Theo Baumeister
* Stefan Bion
* Ralf Borchert
* Philipp Buehler
* Christoph Conrad
* Andreas Croll
* Matthias Damm
* Felix Deutsch
* Frank Ellermann
* Hubert Englmaier
* Daniele Frijia
* Ulf Herbers
* Ulli Horlacher
* Ludwig Huegelschaefer
* Jochen Klein
* Albert Koellner
* Helmut Reininger
* Hermann Roth
* Johannes Sempert
* Jörg Strohmayer
* Olaf Titz
* Rainer Zocholl
* Michael Zolk
Diese FAQ wird monatlich (am 15.) in de.admin.net-abuse.mail und
de.answers gepostet und steht auf <http://www.th-h.de/faq/headerfaq.php3>
in der jeweils aktuellen Fassung auch im WWW zur Verfügung.