FAQ: E-Mail-Header lesen und verstehen | Inhalt:
3. E-Mail-Headerzeilen im einzelnen
(a) Anschrift, Absender u. Verwandtes - kurz: der Briefkopf
(c) "Zustellvermerke": den Weg einer E-Mail nachvollziehen
4. Hilfreiche Tools für die Headeranalyse
(d) Programmpakete und Bezugsquellen
(e) Finger-Gateway auf info.belwue.de
5. Beschwerden über unerwünschte Massen-E-Mail
(a) Wo kann ich mich beschweren?
6. Headerzeilen anzeigen lassen
1. Vorwort
Zweck dieser FAQ ist es, grundlegende Informationen über den Aufbau einer Internet-E-Mail und die Bedeutung der einzelnen Headerzeilen zu vermitteln, um bspw. 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 ) gezielt an den richtigen Stellen beschweren zu können.
---
[1] wie in RFC 822 definiert (URL: http://www.faqs.org/rfcs/rfc822.html) (WWW)
[2] UBE: unsolicited bulk e-mail, unverlangte Massen-E-Mail
UCE: unsolicited commercial e-mail, unverlangte kommerzielle E-Mail
2. Aufbau einer E-Mail
Eine E-Mail besteht aus mehreren Teilen, und zwar dem Umschlag (SMTP-Envelope), den Kopfzeilen (Header) und dem eigentlichen Text oder Inhalt (Body).
(a) SMTP-Envelope
Diesen "Umschlag" bekommt man im Normalfall nicht zu sehen. Er enthält die für die Zustellung einer E-Mail relevanten Informationen und geht beim Einsortieren ins Postfach des Empfängers verloren. Man kann ihn mit einem konventionellen Briefumschlag vergleichen, der in der Poststelle einer Firma geöffnet und weggeworfen wird. Nur sein Inhalt, der Briefbogen, ereicht den Empfänger. (Manchmal werden die Daten aus dem Umschlag aber - zumindest teilweise - in den Header der E-Mail übernommen, so dass man den Inhalt des Umschlags nachvollziehen kann.)
Die Daten für den Umschlag erhält ein Mailserver ganz zu Anfang des SMTP-Dialogs, also bei der Verbindungsaufnahme mit dem Mailserver des Einlieferers. Dabei stellt der einliefernde Server sich vor (mittels HELO/EHLO ), 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. Wenn diese fertig übertragen ist, wird sie den genannten Empfängern entweder ins Postfach gesteckt (wenn sie schon "am Ziel" ist), oder, falls nötig, an den Server weitergeleitet, auf dem sich diese Postfächer finden.
--> Beispiel eines solchen Dialogs:
(in der obersten Zeile jeweils der sendende Mailserver, darunter die Antwort des empfangenden)
HELO ancalagon.rhein-neckar.de
250 pri.owl.de Hello ancalagon.rhein-neckar.de [193.197.90.30], pleased to meet you
Das ist die Begrüßung. 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 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ässt sich feststellen, welcher Name dieser Nummer zugeordnet ist. Allerdings sind diese Nummern inzwischen knapp; sie werden daher häufig dynamisch vergeben, das heißt einem bestimmten Rechner immer nur für die Dauer einer Online-Sitzung zugewiesen. Immerhin lässt sich aber feststellen, welchem Provider diese IP-Nummer (meist ein ganzer Nummernblock) zur Verfügung gestellt wurde, und dieser wiederum kann in seinen Log-Dateien feststellen, welcher Kunde zu einer bestimmten Zeit unter dieser Nummer online war.
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ässt sich nicht definitiv nachprüfen.
DATA
354 Enter mail, end with "." on a line by itself
Der "Umschlag" ist fertig, jetzt kommt der Briefbogen.
---
[1] SMTP steht für "Simple Mail Transfer Protokol", den Standard, nach dem E-Mail zwischen verschiedenen Servern ausgetauscht wird.
URL: [
http://www.faqs.org/rfcs/rfc821.html] (WWW)
[2] Auf HELO folgt der eigene Rechnername, bei HELO zusätzlich noch Parameter, die angeben, welche erweiterten Funktionen der Mailserver beherrscht.
(b) 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. Ich 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, dass man eine E-Mail erhält, die scheinbar an jemand ganz anderen adressiert ist.
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. Vorteil: bei 100 Teilnehmern muß bloß die Zeile "RCPT TO:<adresse@server.domain>" hundertmal (jedes Mal mit einer anderen Empfängeradresse) gesendet werden, die eigentliche E-Mail (den Briefbogen) braucht man aber bloß einmal zu übertragen. Um die Zustellung kümmert sich dann der empfangende Mailserver. Das spart natürlich immens Zeit und damit Geld. Genauso gehen aus demselben Grund auch Bulkmailer vor, die für ihre Zwecke gerne sog. "offene Relays" verwenden; daher findet man beim Empfang von UBE/UCE häufig nicht die eigene Mailadresse auf dem Briefbogen (in der Headerzeile "To:"), sondern eine fremde oder beliebige.
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.
---
[1] 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 bei kleineren Providern abzufangen; heute werden offene Relays missbraucht, um Bulkmail auszuliefern und landen deswegen auf "schwarzen Listen" mit der Folge, dass viele Systeme weltweit Mail von dort gar nicht mehr oder nur noch verzögert annehmen.
(c) Body
Nach einer simplen Leerzeile, die die Trennung zwischen Header und Body darstellt, folgt dann der eigentliche Text bzw. Inhalt der E-Mail.
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ässt.
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: <ANCL529471993@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.
(a) 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).
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 in der zusätzlichen Headerzeile "Sender:".
Organization: RWTH Aachen
Die Organisation (Firma, Hochschule, Verein ...) des Absenders.
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 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.
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.
(b) "Technische" Angaben
Message-ID: <35FFDA4F.2BC2A064@post.rwth-aachen.de>
References: <ANCL529471993@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 Indiz 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
Meist lässt sich aus dem Namen des Headers schließen, wofür er denn gedacht sein mag.
Der Hinweis, dass 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.
(c) "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.
Die "eigentlichen" Zustellvermerke sind die "Received:"-Headerzeilen, die jeweils vor dem Weiterschicken einer E-Mail vom Mailserver vorne angefügt werden. Man muss sie also rückwärts lesen. 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 vom 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, muss als nächstes eine Zeile folgen, in der B die Mail von C bekommen hat. Beachten muss man dabei allerdings, dass 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ässt sich das durch eine DNS-Abfrage (nslookup, vgl. Abschnitt 4a); in diesem Fall müssten dort beide Namen für denselben Rechner, d.h. dieselbe IP-Nummer, registriert sein.
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 muss 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.
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, dass 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 die 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, dass 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 glaubt 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 passt. Dazu gibt es bspw. das Tool "nslookup" (vgl. Abschnitt 4a).
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".
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 bezeichnen.
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 4a).
Aber weiter im Text - wir waren stehen geblieben bei der Feststellung, dass 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, dass 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" passt 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.
(d) 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 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 Überfluss auch noch mit der Telefonnummer identisch ist. In diesem speziellen Fall kann man eventuelle Nachfragen dann sogar telefonisch klären. ;-)
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 hinter steckt. Die wichtigsten Tools sollen hier kurz vorgestellt werden.
(a) 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
(b) whois
Mit Hilfe von whois lässt 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 dass von vornherein klar ist, dass Beschwerden dort keinen Erfolg haben werden.
(c) traceroute
Traceroute gibt den Weg an, den Datenpakete vom eigenen Rechner zum angegebenen Zielrechner zurücklegen. So lässt 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 auf daran denken, es eine Ebene höher zu probieren und sich an den Uplink zu wenden.
(d) 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 zusammengefasst (und häufig mit einer leicht bedienbaren grafischen Benutzeroberfläche versehen) sind. Die Programme sind im allgemeinen Free- oder Shareware.
Für Windows 95:
+ Sam Spade
[ http://www.blighty.com/products/spade/] (WWW)
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 vor allem 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.ping.be/cyberkit/] (WWW)
Bietet Ping, Traceroute, Finger, WhoIs, NS Lookup, QoD.
+ Internet Maniac:
[ http://www.csee.usf.edu/~birla/software/maniac.html] (WWW)
Bietet Host Lookup, Ping, Traceroute, Connect, Time, Finger, Whois, POP3, Listener, Scanner, Winsock, Raw connect, Speed check.
+ NetScan Tools for Windows 95
[ http://www.nwpsw.com/] (WWW)
Nslookup, Finger, Ping, Traceroute, Scanner, etc.
+ WinWhois96:
[ ftp://ftp.worldone.com/pub/windows/winwhois/whinwhois.zip] (WWW)
Bietet nur das Abrufen von Whois-Datenbanken wie Ripe, Internic, Arin, Apnic und anderen.
Für Amiga:
+ http://ftp.wustl.edu/systems/amiga/aminet/comm/tcp/ (WWW)
Für Ataris:
+ http://ftp.uni-erlangen.de/pub/atari/Index.html (WWW)
Für Macs:
+ MAC TCP Watcher:
http://www.share.com/stairways/ (WWW)
+ AGNetTools:
http://www.aggroup.com (WWW)
version 1.0 von 1997:
ping, traceroute, name lookup, finger whois, troughput tool, name scan, port scan, ping scan, service scan und network info
(e) 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
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, dass 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"(WWW) ).
(a) Wo kann ich mich beschweren?
(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, dass 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.
(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.
(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, dass für UCE u.ä. spezielle Beschwerdeadressen existieren.
Vereinfachen lässt 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).
(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ässt sich bspw. mit Hilfe des Tools "traceroute" (s. oben, Abschnitt 4c) herausfinden.
(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 Missbrauch. Insofern sollte man auch dort den zuständigen Postmaster auf den Missbrauch hinweisen und ihn bitten, seinen Mailserver relayfest zu machen.
Unter [ http://maps.vix.com/tsi/ar-test.html] (WWW) gibt es einen einfachen Test, um festzustellen, ob ein Mailserver für jedermann relayed oder nicht. Dort finden sich auch Hinweise, was man dagegen unternehmen kann.
(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.
(b) 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ässt 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).
Programm | Tastenkombinationen / Menüauswahlen |
Crosspoint | Taste <o> |
elm | Taste <h> |
Eudora 3.0 | 'BlahBlah'-Button in der Toolbar anklicken |
MS Outlook | "Ansicht", "Optionen" |
MS Outlook Express | "Eigenschaften", "Details" |
oder | Tasten <Strg>+<F3> |
mutt | Taste <h> |
Netscape 4.x | "Ansicht", "Seitenquelltext" |
Pegasus-Mail | Tasten <Strg>+<h> |
pine | Taste <h> |
The Bat! | "View", "Show Kludges" |
---
[1] 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:
cls
@ECHO OFF
:: Puffer mit Mails in Sicherheit bringen, da er bei ESC-Abbruch
:: gelöscht wird!
copy /B \XP\spool\*. \XP\backup\.
:: Mail kommt noch mal extra damit suchen schneller geht
copy /B \XP\spool\D-N*. \XP\backupN\.
:: MIMEs extrahieren hier
:: 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.
[2] 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.
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 (WWW)
E-Mail-Missbrauch:
- FAQ, Abkuerzungen: de.admin.net-abuse.mail
http://www.unix-ag.uni-hannover.de/faq/de.admin.net-abuse.mail.html (WWW) - Teergruben-FAQ
http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.html (WWW) - Newsgruppe de.admin.net-abuse.mail
news:de.admin.net-abuse.mail - vereinfachtes Auffinden der richtigen Beschwerdeadresse(n)
http://www.abuse.net/ (WWW)
Script zur Header-Analyse (online) inkl. Vorbereitung / Versenden von Beschwerden:
http://spamcop.net/ (WWW)
