E-Mail-Header lesen und verstehen

Dieser Text wurde in der Newsgroup de.admin.net-abuse.mail gepostet und wendet sich dementsprechend auch an die Leser dieser Newsgroup. Er wird hier unverändert veröffentlicht.

Letzte Änderungen

2024-07-07

Überarbeitung. RFC-Clueless, SORBS, mailheader.org und der whois-Dienst von IKS-Jena bestehen nicht mehr. Beispiele und Links wurden angepasst.

2019-09-18

Headerzeilen anzeigen: Google Mail korrigiert

2017-04-20

Headerzeilen anzeigen: E-Mail Center (T-Online Webmail) korrigiert
T-Online-Team

Headerzeilen anzeigen: Outlook (MacOS X) ergänzt
Wulf-Burkhard Goehmann

2014-08-14:

Headerzeilen anzeigen: E-Mail Center (T-Online Webmail) und Yahoo korrigiert
T-Online-Team

2014-07-12:

Headerzeilen anzeigen: GMX korrigiert
T-Online-Team

2013-07-28:

Headerzeilen anzeigen: E-Mail Center (T-Online Webmail) korrigiert, Yahoo, mail.com ergänzt
T-Online-Team

Vorwort

Zweck dieser im September 1998 begonnenen FAQ ist es, grundlegende Informationen über den Aufbau einer Internet-E-Mail¹ 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²) 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³ oder eine genaue technische Definition der jeweils erlaubten Inhalte⁴ (gar noch einschließlich der häufigsten Verstöße dagegen durch weitverbreitete Mailprogramme). Dafür existieren bereits entsprechende Quellen, vgl. dazu den Abschnitt "Weiterführende Links".

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 im Abschnitt "Weiterführende Links" dieser FAQ aufgeführt sind. Namentlich die dort genannte FAQ von de.admin.net-abuse.mail sei jedem Interessierten dringend ans Herz gelegt, obschon dieses Werk leider seit 2004 nicht mehr aktualisiert worden ist.

Der Schwerpunkt der FAQ liegt somit auf den Abschnitten "Aufbau und Zustellung einer E-Mail" und "Headerzeilen im einzelnen", 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, dass die Ausführungen auch für interessierte Laien verständlich sind.

Korrekturen, Ergänzungshinweise und Verbesserungsvorschläge nehme ich gerne entgegen. Diese FAQ wurde früher in de.admin.net-abuse.mail und de.answers gepostet und steht auf dieser Webseite in der jeweils aktuellen Fassung zur Verfügung. Die Formatierung der ursprünglichen Textfassung wurde behutsam angepasst und die Inhalte regelmäßig aktualisiert; die FAQ kann aber ihr Alter von mittlerweile bald 20 Jahren nicht ganz verleugnen.

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").

SMTP-Envelope⁵

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 dass 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 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⁶), 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, dass 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):

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.de ESMTP ready

Darauf folgt dann die eigentliche Vorstellung und Begrüßung:

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 im DNS (Domain Name Server) lässt 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.⁷ Verlassen kann man sich daher nur auf die IP-Adresse selbst; diese lässt 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, dass IP-Nummern schon lange ein zu knappes Gut sind, um jedem Kunden permanent eine Nummer zuzuordnen. Sie werden daher häufig dynamisch vergeben, das heisst einem bestimmten Rechner immer nur für die Dauer einer Online-Sitzung zugewiesen. Da die entsprechenden Log-Dateien nach kurzer 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 im Abschnitt "Beschwerden über unerwünschte Massen-E-Mail".

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ässt 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.

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, dass man eine E-Mail erhält, die scheinbar (!) an eine ganz andere Person adressiert ist.

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 muss dann 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"⁸ und in neuerer Zeit auch sog. "Zombies"⁹.

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 im Abschnitt "E-Mail-Headerzeilen im einzelnen" ausführlich besprochen.

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 - im einfachsten Fall - nicht mehr weiter untergliedert.¹⁰

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¹¹, 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.

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-Anbieter GMX, von dem er sich die eingehenden Mails an seine eigentliche Adresse weiterschicken lässt.

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) with ESMTP
  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.

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 unter SMTP-Envelope 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.

"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 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 muss).

Bei weiteren Headern lässt 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) im Abschnitt "Weiterführende Links" aufgezählt.

Der Hinweis, dass 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.

"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. Sie bringt für eine Rückverfolgung also herzlich wenig.

"Received:"-Headerzeilen

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: 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 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.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ässt sich das durch eine DNS-Abfrage (nslookup, vgl. den Abschnitt "Hilfreiche Tools für die Headeranalyse"); in diesem Fall müssten 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.

"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 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, aber es dem Mailserverbetreiber erleichtern kann, in seinen Logdateien die richtige E-Mail aufzufinden).

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 finden 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.¹² 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, dass 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, dass die Reihenfolge der Angaben genau umgekehrt ist (zuerst HELO, dann tatsächliche Angabe). Schließlich - und am schlimmsten - gibt es (heutzutage sehr selten) ä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 Logdateien 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.

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 (HELO mailer1.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.¹⁴

Aber weiter im Text - wir waren stehengeblieben bei der Feststellung, dass 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) with ESMTP
    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, 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.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 bedeutungslos.

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, dass manche Provider "neutrale" Rechnernamen für ihre Infrastruktur verwenden (kundenserver.de bspw. bei Unternehmen der United-Internet-Gruppe wie 1&1 oder Schlund) oder dass Rechnernamen Umbenennungen oder Fusionen von Firmen oder Marken nicht mitgemacht haben (so dass bspw. die Mailinfrastruktur von web.de früher einmal Rechnernamen innerhalb der Domain cinetic.de verwendete).

Indizien fuer gefälschte "Received:"-Zeilen

Wer über den tatsächlichen Laufweg bzw. die wahre Herkunft einer E-Mail täuschen will, muss 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 belästigen. Je mehr unnötige Beschwerden auftauchen, desto weniger Ressourcen bleiben für die Bekämpfung des tatsächlichen Missbrauchs ü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. Keine dieser Indizien sind 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]) by h196.165.40.162.ip.alltel.example with SMTP id i2M5cXd3019578; Mon, 22 Mar 2004 06:38:34 -0600

würde man daher 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 passt, 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 (Sommer-)Zeit (+0100 oder +0200) erwarten, nicht jedoch -0500 und EST, also Eastern Standard Time.

Manchmal fehlt die Angabe der (E)SMTP id, also der internen 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, dass für den angeblich sendenden Server nur die IP in eckigen Klammern angegeben wird und dass 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.

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 lange Jahre 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 Überfluss 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 Übeltäter zuordnen kann. Bitte beachten Sie in jedem Fall, dass das bloße Vorhandensein einer "X-ID:"-Zeile aber nicht besagt, dass 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.

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 einzelnen Programme folgen dann im Anschluss.

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 (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 Die Vorstellung erwähnt, muss 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 muss umgekehrt die Abfrage auf hiper1-d87.cwnet.com wieder die Nummer 205.162.108.87 liefern.

(Statt nslookup wird man heutzutage üblicherweise host bzw. dig verwenden.)

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 Domain-Namen oder einer bestimmten IP-Nummer steckt. Manchmal sind das bereits "alte Bekannte", so dass von vornherein klar ist, dass 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). Moderne whois-Clients sollten automatisch den richtigen Server abfragen; wenn aber keine vernünftige Antwort auf eine Abfrage erfolgt, muss stattdessen ein anderer, sprich der zuständige Whois-Server befragt werden. Als weitere kommen auch die Online-Abfrageseiten im Web in Betracht.

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 auch daran denken, es eine Ebene höher zu probieren und sich an den Uplink zu wenden.

Programmpakete und Bezugsquellen

Auf UNIX-Rechnern bzw. unter Linux stehen die genannten Tools meist unter eben diesen 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.

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 sich damit als ausgesprochen kontraproduktiv erweist.

Unter Windows

Standardmäßig existieren ping und tracert (traceroute). Diese können in einer DOS-Box (cmd.exe) mit ping [hostname/IP] oder tracert [hostname/IP] aufgerufen werden.

Statt des Downloads spezialisierter Software kann sich ein Rückgriff auf die Online-Abfrageseiten im Web empfehlen.

Sam Spade

Dieses Programm war speziell zur Rückverfolgung unerwünschter Bulkmail ausgelegt. Es bot neben ping, nslookup, traceroute, IP-Blocks und weiteren Tools auch eine "automatische" Headeranalyse, die bei einem ersten Einstieg in die Materie sicher hilfreich sein konnte, und lieferte daneben auch einige hervorragende, allerdings englischsprachige FAQs, Links und Step-by-step-Anleitungen für die Absenderfeststellung und Beschwerde bei unerwünschter Bulkmail mit.

NetScanTools

ping, traceroute, nslookup, whois u.a.

VisualRoute

Graphisches traceroute mit Whois-Abfragen und Portscan

Unter OS/2

Es existieren standardmäßig ping, nslookup und finger - diese Programme heißen auch so. traceroute heißt hier tracerte.

Desweiteren hatte Frank Ellermann eine whois-implementation unter https://purl.net/xyzzy/rxwhois.htm zum Download bereitgestellt, die mittlerweile aber nicht mehr erreichbar ist.

Unter MacOS X

Es existiert serienmäßig das "Network Utility" bzw. "Network Dienstprogramm", welches unter "Applications/Utilities" zu finden ist. Zum Funktionsumfang gehören netstat, ping, lookup, trace[route], whois, finger und Portscans.

IPNetMonitor

ping, traceroute, nslookup, whois u.a.

Online-Tools

Schließlich gibt es die kleinen Helferchen inzwischen auch vielfach als Webformular, mit dem man entsprechende Anfragen stellen kann.

Eine Zusammenstellung vieler guter Tools fand sich auf https://web.archive.org/web/20061008144350/www.samspade.org/; derzeit ist die Website jedoch leider nicht mehr erreichbar.

Alle verbreiteten Tools bietet https://www.broadbandsearch.net/network-tools an.

Eine umfangreichere Liste von Tools (Stand 2004) findet sich in der FAQ der Newsgroup de.admin.net-abuse.mail; vgl. dazu die weiterführenden Hinweise im Abschnitt "Weiterführende Links" dieser FAQ.

6. abuse.net

Das Network Abuse Clearinghouse sammelt Kontaktadressen von Providern, unter denen man die jeweilige Beschwerdestelle erreichen kann. Die Kontaktdatenbank lässt sich auf zweierlei Weise abfragen:

• Im WWW: https://www.abuse.net/lookup.phtml
• Per finger: finger example.com@abuse.net
  (mit der betreffenden Domain statt "example.com", natürlich)
• Per whois: whois -h whois.abuse.net example.com
  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.example weitere.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 - auf Englisch, bitte.

Mehr dazu unter https://www.abuse.net/addnew.phtml.

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, dass man feststellen möchte, ob ein bestimmter Rechner bereits als offenes Relay aufgefallen ist, oder dass 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 im Abschnitt "Weiterführende Links" 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ässlich die Anbieter sind. Es gibt Listen von Rechnern, über die unerwünschte Massenwerbung verschickt wurde, 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 Blacklist sbl.spamhaus.org abzuchecken, verwendet man eine Abfrage der Form host d.c.b.a.sbl.spamhaus.org (oder ein anderes Tool, wie nslookup, bzw. ein Programmpaket, was dies beherrscht, siehe dazu den Abschnitt Programmpakete und Bezugsquellen). Ggf. muss man zu einem Rechnernamen erst noch die IP-Nummer(n) ermitteln, bevor man die Abfrage starten kann:

thh@thangorodrim:~$ host other.johnbastian.com
other.johnbastian.com has address 193.25.216.94

thh@thangorodrim:~$ host 94.216.25.193.sbl.spamhaus.org
94.216.25.193.sbl.spamhaus.org has address 127.0.0.9
94.216.25.193.sbl.spamhaus.org has address 127.0.0.3
94.216.25.193.sbl.spamhaus.org has address 127.0.0.2

Die genaue Bedeutung des Abfrageergebnisses lässt sich in diesem Falle der jeweiligen Webseite entnehmen. Hier steht die IP-Adresse in den Listen CSS (Combined Spam Sources) und DROP (Don't Route Or Peer), die beide auch in der SBL (Spamhaus Block List) enthalten sind.

Mit dem Multi-RBL Check des Anti-Abuse Project lassen sich über 50 Blacklists auf einen Schlag abfragen.

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, 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, oder dass 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 Fahrlä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 im Abschnitt "Weiterführende Links". Insbesondere die Lektüre der FAQ der Newsgroup de.admin.net-abuse.mail sollte für diese Fälle ein Muss sein.

Wo kann ich mich beschweren?

Beim (angeblichen) Versender der betreffenden E-Mail

Das ist wenig sinnvoll - meist sind die Absenderadressen gefälscht, und wenn die Beschwerde ankommt, führt das im Zweifelsfall nur dazu, dass 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 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 Benachrichtigungen des Absenders in Virenscannern deaktiviert werden! Leicht wird man sonst durch die Benachrichtigungsfunktion zur UBE-Schleuder wider Willen gemacht.

Beim Hersteller o.ä. des per UCE beworbenen Produkts

Auch dies ist 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. Halbseidene Anbieter, die bewusst unerwünschte Werbung versenden, freuen sich ansonsten nur über eine validierte E-Mail-Adresse.

Beim (tatsächlichen!) Provider des UCE-/Viren-Versenders

Viele Provider schätzen keine Spammer unter ihren Kunden und reagieren darauf - wie auch auf Vireninfektionen - entsprechend mit Verwarnungen, Accountentzug und/oder Vertragsstrafen, sofort oder im Wiederholungsfall. Manche reagieren 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, dass für UCE u.ä. spezielle Beschwerdeadressen existieren.

Vereinfachen lässt sich dieses Vorgehen über https://www.abuse.net/ (siehe dazu auch den Abschnitt "abuse.net 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 des Anbieters.

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ässt sich mittels des Tools "whois" herausfinden.

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. mithilfe des Tools traceroute herausfinden.

Bei offenen Relays

UCE wird meist nicht direkt verschickt, sondern über unbeteiligte Dritte versandt, bspw. 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 noch 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.

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 Mailsysteme installiert, ohne dass der Benutzer davon weiss oder dies bemerkt.

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.

Bei Dritten (Firmen, Behörden, Institutionen)

Die Freiwillige Selbstkontrolle Multimedia-Diensteanbieter (FSM) e.V. und eco – Verband der Internetwirtschaft e.V. betreiben als gemeinsames Projekt eine Internet-Beschwerdestelle. Dort sind Kontakt-E-Mail-Adressen genannt, an die unerwünschte Werbe-E-Mails weitergeleitet werden können. Dabei ist es natürlich erforderlich, die kompletten Header mitzusenden, da nur so eine Überprüfung und weitere Bearbeitung möglich ist.

Auch darüber hinaus kann es in ganz bestimmten Fällen 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, Passworte 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.

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 in englischer Sprache.

• 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.

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).

Mailclients

AK-Mail

"Ansicht", "Kopf-Zeilen"
Dieser Menüpunkt steht nur zur Verfügung, wenn der Mail-Body sichtbar ist.

Crosspoint:

Taste o
Crosspoint speichert den Header im ZConnect-Format.

elm

Taste h

XEmacs VM-Mail:

Taste t
Alternativ kann man in der $HOME/.emacs eine Zeile der Art

(setq vm-invisible-header-regexp "X-.*")

einfügen. Dann werden alle Header bis auf die, die mit X- beginnen, angezeigt, jedoch erst nach einem Neustart des emacs.

Eudora 3.0

"BlahBlah"-Button in der Toolbar anklicken

Evolution

Menü "Ansicht", "Nachrichtenanzeige", "alle Kopfzeilen anzeigen"
oder
Menü "Ansicht", "Nachrichtenanzeige", "E-Mail-Quelltext anzeigen"
oder (Evolution 2.4.0)
Menü "Ansicht", "Alle Nachrichtenköpfe"

Evolution kann die E-Mail auch komplett mit allen Headern weiterleiten:
Menü "Aktionen", "Weiterleiten als", "Beigelegt"

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")

Incredimail

"Datei", "Eigenschaften" oder Alt+Enter
Dort dann den Reiter "Einzelheiten" anwählen.

KMail 1.8.2

"Ansicht", "Vorspann", "Alle"

Lotus Notes (vor Version 6)

Die Lösung ist etwas kompliziert - folgende zwei Möglichkeiten bestehen:

Für einzelne Headerzeilen:
Wenn die Mail in Notes zur Ansicht geöffnet ist, im Menü "Datei / Eigenschaften: Dokument" auswählen, und in dem erscheinenden Fenster den zweiten Reiter von links ("Felder") auswählen. Man sieht nun die einzelnen Headerzeilen wie Message-ID usw.

Für den kompletten Header:
Wenn man sich im View (z.B. "Inbox") befindet: den Fokus auf die Mail stellen, "Datei / "Export…" auswählen und "Structured Text" als Exportformat auswählen. Im nachfolgenden Dialog "Selected Documents" auswählen; nun erhält man 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.

Lotus Notes 6

Für den Notes-6-Client gibt es eine einfachere Lösung:
Die E-Mail bildschirmfüllend öffnen (Doppelklick auf die E-Mail in der Inbox) und im (engl.) Menu dann "View" / "Show" / "Page Source" anwählen. Die dann angezeigte Seite lässt sich problemlos in die Zwischenablage kopieren.

MacSOUP

Taste h
oder
Tasten Befehl+h

Mail.app (Apple)

Menü "Darstellung", "E-Mail öffnen", "Lange Header"
oder
Tasten Apfel+Shift>+h>

Mozilla:

Die Angaben sind gleichermaßen auch für Thunderbird zutreffend.

"View", "Headers", "All" bzw. "Ansicht", "Kopfzeile", "Alle"
(funktioniert im Ggs. zu alten Netscape-Versionen besser; allerding werden möglicherweise lange Headerzeilen am Zeilenende abgeschnitten)

"View", "Page Source" bzw. "Ansicht", "Nachrichten-Quelltext"
(Anzeige der Mail mit allen Headern im Editor)

Installation von mnheny und dann entsprechende Konfiguration zusätzlich anzuzeigender Header.

Ctrl-U bzw. Strg-U

MS Entourage (Mac OS X)

"View", "Internet Headers"
oder
Tasten Shift+Apfel+h

mutt

Taste h

Netscape 4.x und älter

"Ansicht", "Seitenquelltext"
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 oben unter "Mozilla".

Opera (M2)

"Alle Kopfzeilen anzeigen" anklicken

Outlook (vor Outlook 97)

"Ansicht", "Optionen"

Outlook 97

"Datei", "Eigenschaften", "Internet"

Outlook 2000-2007

Rechtsklick auf die entsprechende Mail, "Optionen"
(dort dann unter der Überschrift "Internetkopfzeilen")

Outlook 2010

Mail in eigenem Fenster öffnen (Doppelklick), und dann
"Datei", "Eigenschaften"
(dort dann unter der Überschrift "Internetkopfzeilen")
oder
im Tab "Nachricht" in der Gruppe "Kategorien" den Erweiterungspfeil unten rechts anklicken
(dort dann unter der Überschrift "Internetkopfzeilen")

Outlook (MacOS X)

Rechtsklick auf die entsprechende Mail, "Quelle anzeigen"

Outlook Express

"Eigenschaften", "Details"
oder
Tasten Strg+F3

Pegasus-Mail

Tasten Strg+h

pine

Taste h
Ggf. muss vorher die Option "Main Menu" / "Setup" / "Config" / "enable-full-header-cmd" aktiviert werden.

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)

Thunderbird

Siehe oben unter "Mozilla".

T-Online E-Mail

Im Kontextmenü "Alle Kopfzeilen anzeigen" wählen (d.h. mit der Maus in die Mail klicken, rechte Maustaste, "Alle Kopfzeilen anzeigen").

Webmail

Die zunehmende Nutzung von Webmail-Diensten lässt auch dort die Frage entstehen, wie man die Weboberfläche dazu bewegen kann, die vollständigen Header herauszurücken.

AOL Webmail

E-Mail öffnen und auf "Details" im Kopf klicken; die Headerzeilen erscheinen dann in einem eigenen Fenster. Das funktioniert nicht bei E-Mails innerhalb von AOL!

Bluemail (Bluewin Webmail)

E-Mail öffnen und auf das Icon "Kopfzeile" in der Menüleiste klicken.

Google Mail (GMAil)

E-Mail öffnen, auf das Menü "Weitere Optionen" (drei übereinanderstehende Punkte, neben dem Symbol für "Antworten", in der Regel rechts oben) klicken und dort "Original anzeigen" auswählen. Es öffnet sich ein Zusatzfenster mit den kompletten Headerzeilen (und weiteren Informationen).

GMX

E-Mail öffnen und das Symbol (rechts oben neben der Anzeige des Versandzeitpunktes) anklicken. Ein Zusatzfenster mit den kompletten Headerzeilen öffnet sich.

Hotmail (hotmail.com, hotmail.de, live.com, live.de)

Rechtsklick mit der Maus auf eine E-Mail in der Übersicht, dann im Kontext-Menü "Quelltext anzeigen" auswählen. Ein Zusatzfenster mit den kompletten Headerzeilen öffnet sich.

IMP 3 https://www.horde.org/apps/imp/

"Quelltext" oder "Message Source" in dem Zusatzmenü über dem Nachrichtenfenster anklicken (direkt über der Datumszeile).

IMP 4 https://www.horde.org/apps/imp/

In der letzten Header-Zeile "Kopfeinträge: Alle" bzw. "Headers: Show All Headers" anklicken.
oder
"Quelltext" oder "Message Source" im Zusatzmenü über dem Nachrichtenfenster anklicken.

mail.com (englischsprachige Version)

Zur Anzeige des Headers (und des Quelltextes) im Mailanzeigefenster ggf. oben rechts auf [+] more info klicken, dann auf das Info-Symbol .

E-Mail Center (T-Online Webmail)

E-Mail per Doppelklick zum Lesen öffnen und dann bei gedrückter Alt-Taste mit der linken Maustaste in den Kopfbereich der Nachricht klicken.

web.de

E-Mail zum Lesen öffnen, dann auf die Schaltfläche links neben dem "Von:" und danach rechts auf den Link "Mehr Informationen" klicken.

Yahoo (deutschsprachige Version)

"Mehr …" / "Gesamten Header herunterladen"

Weiterführende Links

Einführung in das Thema E-Mail an sich:

• E-Mail-Einführung

• Transport von E-Mails - RFC 2821

• RFC 2076: "Common Internet Message Headers"

• RFC 5322: "Internet Message Format"

• RFC 5321: "Simple Mail Transfer Protocol"

• Message Headers
  (IANA-Registry gemäß RFC 3864)

• RFC 4021: Registration of Mail and MIME Header Fields

E-Mail-Missbrauch:

• FAQ, Abkuerzungen: de.admin.net-abuse.mail

• Teergruben-FAQ

• Newsgroup de.admin.net-abuse.mail

• vereinfachtes Auffinden der richtigen Beschwerdeadresse(n)

• Spam melden mit SpamCop

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.

Credits

Die Idee zu dieser FAQ kam ursprünglich von Hermann Roth.

Für hilfreiche Tips, Hinweise und Korrekturen geht ein Dankeschön u.a. an (in alphabetischer Reihenfolge)

• Claus Assmann
• Rene Auberger
• Florian Bannasch
• Jens Baumeister
• Theo Baumeister
• Stefan Bion
• Ralf Borchert
• Philipp Buehler
• Georg Burkhard
• Christoph Conrad
• Andreas Croll
• Christoph Daldrup
• Matthias Damm
• Felix Deutsch
• Frank Ellermann
• Hubert Englmaier
• Daniele Frijia
• Wulf-Burkhard Goehmann
• Ulf Herbers
• Stephan Hochhaus
• Ulli Horlacher
• Ludwig Huegelschaefer
• Jochen Klein
• Albert Koellner
• Helmut Reininger
• Hermann Roth
• Johannes Sempert
• Otto Stolz
• Jörg Strohmayer
• Olaf Titz
• T-Online-Team / T-Home-Team
• Rainer Zocholl
• Michael Zolk

und viele andere.

Korrekturen und Ergänzungen nehme ich gerne entgegen.