Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!nycmny1-snh1.gtei.net!news.gtei.net!news-out.visi.com!petbe.visi.com!news.tele.dk!news.tele.dk!small.news.tele.dk!news.osn.de!newsfeed.completel.de!newsfeed.stueberl.de!uucp.gnuu.de!xerxes.akallabeth.de!not-for-mail From: Thomas Hochstein Newsgroups: de.admin.net-abuse.mail,de.answers,news.answers Subject: [FAQ] E-Mail-Header lesen und verstehen <2003-01-10> Supersedes: Followup-To: de.admin.net-abuse.mail Date: Fri, 14 Mar 2003 23:10:03 +0000 Organization: Ancalagon The Black Lines: 1374 Approved: news-answers-request@MIT.EDU Expires: 18 Apr 03 23:10:01 -0000 Message-ID: NNTP-Posting-Host: xerxes.akallabeth.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: xerxes.akallabeth.de 1047683405 18686 10.0.0.9 (14 Mar 2003 23:10:05 GMT) X-Complaints-To: abuse@akallabeth.de NNTP-Posting-Date: 14 Mar 2003 23:10:05 GMT Summary: Dieses Dokument beschreibt / erklaert E-Mail-Headerzeilen und gibt Hinweise zur Rueckverfolgung unerwuenschter Mail. German language only. X-PGP-Sig: 2.6.3ia From,Newsgroups,Subject,Supersedes,Followup-To,Date,Approved,Message-ID iQCVAwUBPnJhS+LKwJmCdsuZAQELCgP+NO7KEkTntVUUtl+5alRmfDcsl9eM+otW 42N4Co3fmsqEKlg8yENY5HGEFVxG87pyxXE9cGY036QSvsIz4LyMpgU3XGg9mdTx fiQtX8XG+ChQkJ8ycDvwOfU/a11xp/fM5kC4qV5366llSLaeC1ID4qcp9KXKeFCV O11meZ36EYA= =CDSO Content-Language: de X-Disclaimer: Approval for *.answers is based on form, not content. Content-Location: http://www.th-h.de/faq/headerfaq.html X-PGP-Key: faq@usenet.th-h.de Xref: senator-bedfellow.mit.edu de.answers:8491 news.answers:247825 Posted-By: auto-faq 3.3.thh (Perl 5.006) Archive-name: de-net-abuse/email-header-faq Last-modified: 2003-01-10 Version: 1.2.04 Posting-frequency: monthly URL: http://www.th-h.de/faq/headerfaq.html FAQ: E-Mail-Header lesen und verstehen ====================================== Letzte Änderungen ================= 2003-03-02: Punkt 6 aktualisiert (The Bat!). 2003-01-10: Vorwort ergänzt. 2003-01-10: Punkt 3.4 ergänzt. 2002-06-20: Punkt 5.1 ergänzt. 2002-06-20: Punkt 4.8 neu hinzugefügt. 2002-06-20: Punkt 4.7 ergänzt. 2002-06-20: Punkt 4.2 ergänzt und überarbeitet. Inhalt: ======= 1. Vorwort 2. Aufbau und Zustellung einer E-Mail 2.1 SMTP-Envelope 2.2 Header 2.3 Body 2.4 Vorgehen bei der Zustellung 3. E-Mail-Headerzeilen im einzelnen 3.1 Anschrift, Absender u. Verwandtes - kurz: der Briefkopf 3.2 "Technische" Angaben 3.3 "Zustellvermerke": den Weg einer E-Mail nachvollziehen 3.4 Spezielle Headerzeilen 4. Hilfreiche Tools für die Headeranalyse 4.1 nslookup (host/dig) 4.2 whois 4.3 traceroute 4.4 Programmpakete und Bezugsquellen 4.5 Finger-Gateway auf info.belwue.de 4.6 Online-Tools 4.7 abuse.net 4.8 Blacklists auswerten 5. Beschwerden über unerwünschte Massen-E-Mail 5.1 Wo kann ich mich beschweren? 5.2 Wie beschwere ich mich? 6. Headerzeilen anzeigen lassen 7. Weiterführende Hinweise 8. Credits ---------------------------------------------------------------------- 1. Vorwort ========== Zweck dieser FAQ ist es, grundlegende Informationen über den Aufbau einer Internet-E-Mail [1] und die Bedeutung der einzelnen Headerzeilen ("Kopfzeilen") zu vermitteln, um insbesondere den Weg einer E-Mail zurückzuverfolgen, den Absender bzw. die beteiligten Mailserver herauszufinden und sich bei unerwünschter Massen-E-Mail (Bulkmail oder UBE/UCE [2]) oder anderen unerwünschten Zusendungen gezielt an den richtigen Stellen beschweren zu können. Nicht beabsichtigt ist eine Zusammenstellung der standardisierten und/oder allgemein üblichen Headerzeilen und ihrer Bedeutung [3] oder eine genaue technische Definition der jeweils erlaubten Inhalte [4] (vielleicht noch einschließlich der häufigsten Verstöße dagegen durch weitverbreitete Mailprogramme ;-)). Dafür existieren bereits entsprechende Quellen, vgl. dazu Abschnitt 7. Nicht beabsichtigt sind ebenfalls weitergehende Hinweise zum Thema Bulkmail, UBE/UCE oder "Spam", denkbaren Gegenmaßnahmen usw. usf. Auch hierzu gibt es bereits spezialisierte Quellen, die in Abschnitt 7 dieser FAQ aufgeführt sind. Namentlich die dort genannte FAQ von de.admin.net-abuse.mail sei jedem Interessierten dringend ans Herz gelegt. Korrekturen, Ergänzungshinweise und Verbesserungsvorschläge nimmt der Autor gerne entgegen (). [1] wie in RFC 2822 definiert (URL: ) [2] UBE: unsolicited bulk e-mail, unverlangte Massen-E-Mail UCE: unsolicited commercial e-mail, unverlangte kommerzielle E-Mail [3] RFC 2076: "Common Internet Message Headers" (URL: ) [4] RFC 2822: "Internet Message Format" (URL: ) ---------------------------------------------------------------------- 2. Aufbau und Zustellung einer E-Mail ===================================== Eine E-Mail besteht aus mehreren Teilen. Wenn man den Vergleich mit einem konventionellen Brief suchen möchte, könnte man sagen, es gibt einen Umschlag (den sog. "SMTP-Envelope"), einen Briefkopf (den sog. "Header" oder die "Kopfzeilen") und den eigentlichen Brieftext oder -inhalt (den sog. Body). 2.1 SMTP-Envelope [5] Diesen "Umschlag" bekommt der Nutzer im Normalfall nicht zu sehen; eigentlich gibt es ihn auch gar nicht wirklich. Man bezeichnet so die für die Zustellung einer E-Mail relevanten Informationen, die einem Mailserver (also dem für den Versand und Empfang von E-Mail zuständigen Computerprogramm) beim Versand vor der eigentlichen E-Mail übergeben werden. Diese Informationen gehen beim Einsortieren ins Postfach des Empfängers normalerweise verloren, ganz analog zu einem konventionellen Briefumschlag, der in der Poststelle einer Firma geöffnet und dann weggeworfen wird. Nur sein Inhalt, der Briefbogen (also Header und Body der Mail), erreicht den Empfänger. Glücklicherweise werden die Daten aus dem "Umschlag" oft aber - zumindest teilweise - in den Header der E-Mail übernommen, so daß man den Inhalt des Umschlags nachvollziehen kann. Die Daten für den Umschlag erhält ein Mailserver ganz zu Anfang der Verbindungsaufnahme mit dem Einlieferer; diese Verbindung wird als SMTP-Dialog [5] bezeichnet, also als Dialog zwischen den beteiligten Mailservern, die sich dabei am "Simple Mail Transfer Protocol" orientieren. SMTP ist wie die meisten derzeit (auch) im Internet verwendeten Kommunikationsprotokolle menschenlesbar, besteht also aus festgelegten (englischen) Schlüsselworten oder Befehlen, die in bestimmter Folge verwendet werden. Dabei stellt der einliefernde Server sich vor (mittels HELO/EHLO [6]), gibt den Absender an ("Envelope-From") und nennt den oder die Empfänger ("Envelope-To"). Danach folgt nach dem Kommando "DATA" der Briefbogen, also die E-Mail mit Headern und Body. Ein einzelner Punkt alleine auf einer Zeile signalisiert, daß die E-Mail fertig übertragen ist. Jetzt wird der empfangende Mailserver sie den genannten Empfängern entweder ins Postfach stecken (wenn sie schon "am Ziel" ist), oder, falls nötig, an einen anderen Server weiterleiten, wenn er selbst für einen Empfänger nicht zuständig ist, dessen Postfach also anderswo liegt. Die Angabe des einliefernden Servers nach "HELO" wird dabei weder überprüft noch hat sie heutzutage besondere Bedeutung. Der Absender auf dem Umschlag, d.h. der Envelope-From, wird für die Generierung von Fehlermeldungen u.ä. verwendet, wenn die E-Mail bspw. unzustellbar ist. Der oder die Empfängerangaben im Envelope-To werden zur Zustellung benutzt. Ein Beispiel eines solchen Dialogs sei im Folgenden dargestellt (in der obersten Zeile jeweils der sendende Mailserver, darunter die Antwort des empfangenden): 2.1.1 Die Begrüßung (HELO) | HELO ancalagon.rhein-neckar.de | 250 pri.owl.de Hello ancalagon.rhein-neckar.de [193.197.90.30], | pleased to meet you Der sendende Mailserver stellt sich vor ("HELO.."), der empfangende antwortet ("Hello ..., pleased to meet you"). Entscheidend sind dabei für die Rechner nur der Statuscode (250), nicht der Text; dieser kann frei gewählt werden. Wichtig: Der sendende Mailserver kann über seinen Namen "lügen"; deshalb schaut der Empfänger-Server zumeist nach, wer denn wirklich da gerade mit ihm "redet", und merkt sich die sog. IP-Nummer des Einlieferers (hier 193.197.90.30). Dies ist eine eindeutige Nummer, mit der man jeden am Internet teilnehmenden Rechner identifizieren kann. Durch eine Abfrage beim DNS (Domain Name Server/Service) läßt sich diese Nummer dann wieder in einen Rechnernamen rückübersetzen; häufig tut das der Mailserver auch direkt selbst und übersetzt die Nummer in einen Namen. Nicht immer ist eine solche Rückauflösung allerdings konfiguriert, und es ist möglich, auch hier eine falsche Fährte zu legen. [7] Verlassen kann man sich daher nur auf die IP-Adresse; diese läßt sich einem bestimmten Provider (oder einer Firma oder Institution) zuordnen, und dieser Provider wiederum sollte sie seinerseits einem bestimmten Rechner oder Kunden zuordnen können. Zu beachten ist dabei, daß IP-Nummer schon lange ein zu knappes Gut sind, um jedem Kunden permanent eine Nummer zuzuordnen. Sie werden daher häufig dynamisch vergeben, das heißt einem bestimmten Rechner immer nur für die Dauer einer Online-Sitzung zugewiesen. Da die entsprechenden Log-Dateien nach einer gewissen Zeit gelöscht werden, ist es notwendig, sich zeitnah an den betreffenden Provider zu wenden. Mehr Hinweise dazu finden Sie weiter unten in Abschnitt 5. 2.1.2 Absender- und Empfängerangabe | MAIL FROM: | 250 ... Sender ok | RCPT TO: | 250 ... Recipient ok Der Sender gibt die Absenderadresse an, der Empfänger bestätigt; gleiches gilt für die Empfangsadresse. Die Absenderadresse kann auch hier "gelogen" sein und läßt sich nicht definitiv nachprüfen; statt nur eines Empfängers können auch (nahezu) beliebig viele angegeben werden, indem die RCPT-TO:-Angabe entsprechend wiederholt wird. | DATA | 354 Enter mail, end with "." on a line by itself Der "Umschlag" ist fertig, jetzt kommt der Briefbogen, bestehend aus Header und Body. [5] SMTP steht für "Simple Mail Transfer Protokol", den derzeit üblichen Standard, nach dem E-Mail im Internet zwischen verschiedenen Servern ausgetauscht wird. Siehe dazu den RFC 2821: "Simple Mail Transfer Protocol" (URL: ) [6] Auf HELO folgt der eigene Rechnername, bei EHLO zusätzlich noch Parameter, die angeben, welche erweiterten Funktionen der Mailserver beherrscht. [7] Die Rückauflösung (aus der Nummer zum Namen) muß nicht mit der üblicherweise verwendeten Vorwärtsauflösung (aus dem Namen zur Nummer; notwendig, um bspw. aus dem Servernamen "www.provider.de" die dazugehörige IP-Adresse zu erfahren und den Server ansprechen zu können) konsistent sein. Ein böswilliger Anbieter "a-provider.de", der für den Server mit der IP-Nummer 193.197.90.30 zuständig ist, könnte in der Rückwärtsauflösung mit dieser Nummer den Namen des Mailservers seines Konkurrenten, "mail.b-provider.de" verbinden, auch wenn umgekehrt die Eingabe von "mail.a-provider.de" vorwärts zu der Nummer 193.197.90.30 führt und "mail.b-provider.de" eine ganz andere IP- Adresse ergibt. So können die Kunden jeweils mit der Angabe des Namens auf den richtigen Server zugreifen, weil sie zu dem Namen die korrekte IP-Nummer geliefert bekommen; wenn jedoch "mail.a-provider.de" mit der Nummer 193.197.90.30 sich mit irgendeinem anderen Server verbindet, wird dieser sowohl die IP-Nummer als auch den mit der Nummer verbundenen (falschen!) Namen "mail.b-provider.de" registrieren. 2.2 Header Der Header einer E-Mail bildet sozusagen den Briefkopf, dem man bspw. Absender, Empfänger, Datum und Betreff entnehmen kann. Wichtig dabei: diese Angaben sind einerseits völlig beliebig durch den Absender einstellbar, andererseits müssen sie nicht mit den Angaben im Umschlag übereinstimmen. Man kann also, um im Bild zu bleiben, den Briefbogen an adressieren, aber in einen Umschlag stecken, der (wie oben) an adressiert ist. An letzteren wird die E-Mail dann verschickt. So kann es passieren, daß man eine E-Mail erhält, die scheinbar (!) an jemand ganz anderen adressiert ist. [8] Außer dem "Briefkopf", der schon vom Absender mitgeschickt wird, finden sich aber auch noch Headerzeilen, die von jedem an der Übertragung beteiligten Mailserver eingetragen werden, wenn die E-Mail befördert wird, sozusagen Zustellvermerke (die sich bei einem konventionellen Brief allerdings wohl eher auf dem Umschlag finden würden :-)). *Diese* Headerzeilen sind für die Rückverfolgung einer E-Mail entscheidend. Für den Anfang soll dieser kurze Überblick genügen; die einzelnen Header werden unten in Abschnitt 3 ausführlich besprochen. [8] Sinnvoll ist dieses Vorgehen bspw. für Mailinglisten: als Empfänger steht dann bpsw. "Alle Teilnehmer der Taubenfutter-Mailingliste" oder etwas anderes beliebiges im Header, die tatsächlichen Empfänger stehen nur auf dem Umschlag. Der Vorteil: bei 100 Teilnehmern muß bloß die Zeile "RCPT TO:" hundertmal (jedesmal mit einer anderen Empfängeradresse) gesendet, die eigentliche E-Mail (der Briefbogen) aber nur einmal übertragen werden. Um die Zustellung kümmert sich dann der empfangende Mailserver, der sozusagen aus der einen übertragenen E-Mail 100 Kopien für 100 verschiedene Empfänger macht. Das spart immens Zeit und damit Geld. Daher gehen aus demselben Grund Bulkmailer (Spammer) ebenso vor - letzten Endes bedienen sie ja auch nur eine Mailingliste, allerdings eine Liste, deren unfreiwillige Teilnehmer sich nicht für diesen Verteiler angemeldet haben... Daher findet man beim Empfang von UBE/UCE häufig nicht die eigene Mailadresse auf dem Briefbogen (in der Headerzeile "To:" bzw. "An:"), sondern eine fremde oder beliebige. Spammer verwenden für ihre Zwecke dabei im übrigen gerne sog. "offene Relays" [9]. [9] Ein offenes Relay ist ein Mailserver, der nicht nur Mail von seinen eigenen Benutzern und Kunden an die ganze Welt und umgekehrt Mail von überall an die eigenen Kunden ausliefert, sondern von überall und jedermann Mail annimmt, die er auch nach überall wieder ausliefert. Früher war das eine nette Geste, um Serverausfälle bspw. bei kleineren Providern abzufangen; heute werden offene Relays gerne mißbraucht, um Bulkmail auszuliefern und landen deswegen auf "schwarzen Listen" mit der Folge, daß viele Systeme weltweit Mail von dort gar nicht mehr oder nur noch verzögert annehmen. 2.3 Body Nach einer simplen Leerzeile, die die Trennung zwischen Header und Body darstellt, folgt dann der eigentliche Text bzw. Inhalt der E-Mail. Dieser ist nicht mehr weiter untergliedert. 2.4 Vorgehen bei der Zustellung Wenn ein Mailserver eine E-Mail bekommt, ist es seine erste Aufgabe, festzustellen, ob und (bei mehreren) wenn ja für welche Empfänger er selbst "zuständig" ist. Ist der Server selbst zuständig, legt er die E- Mail dem entsprechenden Empfänger (oder den Empfängern) ins Postfach (bzw. übergibt sie an ein anderes Programm auf derselben Maschine, das für die Verwaltung der Postfächer zuständig ist). Ist er nicht zuständig (oder bleiben danach Empfänger-Adressen übrig, für die er nicht zuständig ist), ermittelt er den (oder ggf. die verschiedenen) zuständigen Mailserver [10], stellt zu diesem Server (oder diesen Servern) eine Verbindung her und liefert dann seinerseits die E-Mail an diese(n) Server aus, auf dieselbe Weise, wie er sie selbst bekommen hat, mit HELO/EHLO, MAIL FROM, RCPT TO und DATA. [10] Dazu wird im DNS der Eintrag für den sog. Mail Exchanger (MX) für die entsprechende Domain abgefragt. Als Antwort wird der Name eines oder mehrerer Rechner, die für den Mailempfang für diese Domain zuständig ist oder sind, zurückgeliefert, nach Priorität geordnet. ---------------------------------------------------------------------- 3. E-Mail-Headerzeilen im einzelnen =================================== Zunächst mal ein (schon etwas komplizierterer) Header "am Stück". Die folgende E-Mail wurde von Heinz-Gustav Hinz an seinen Bekannten Karl-Heinz Schmitt verschickt. Letzterer hat eine Adresse bei dem E-Mail- Forwarder GMX, von dem er sich die eingehenden Mails an seine eigentliche Adresse weiterschicken läßt. | Return-Path: | 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 ; 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 ; 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 | Organization: RWTH Aachen | X-Mailer: Mozilla 4.05 [de] (Win95; I) | To: Karl-Heinz Schmitt | MIME-Version: 1.0 | Content-Type: text/plain; charset=iso-8859-1 | Content-Transfer-Encoding: quoted-printable | Subject: Re: Hallo Nachbar! | References: <529471993@ancalagon.rhein-neckar.de> | Reply-To: hinz@provider.de | X-Resent-By: Global Message Exchange | X-Resent-For: karl-heinz@gmx.net | X-Resent-To: karl-heinz@ancalagon.rhein-neckar.de Die Reihenfolge der Headerzeilen ist ziemlich beliebig und von der verwendeten Software abhängig. Deshalb werde ich mich auch beim "Auseinanderpfriemeln" der einzelnen Headerzeilen nicht an der Reihenfolge, sondern am Sinnzusammenhang orientieren. 3.1 Anschrift, Absender u. Verwandtes - kurz: der Briefkopf Diese Headerzeilen sind weitgehend selbsterklärend: | Date: Wed, 16 Sep 1998 17:33:35 +0200 Das Absendedatum, eingetragen vom Mailprogramm des Absenders (kann, wenn fehlend, aber auch von einem der beteiligten Mailserver nachgetragen worden sein, meistens dem ersten, den die Mail passiert). | From: Heinz-Gustav Hinz Der Autor bzw. Absender. Wenn Autor und technischer Absender unterschiedlich sind (eine Mail bspw. von einer Mailingliste verschickt wird), steht der technische Absender ggf. in der zusätzlichen Headerzeile "Sender:". - Davon zu unterscheiden ist der bereits in Abschnitt 2.1 erwähnte "Envelope-From:", an den bspw. automatische Fehlermeldungen gerichtet werden. | Organization: RWTH Aachen Die Organisation (Firma, Hochschule, Verein ...) des Absenders. - Merke: "There is no 's' in Organization". ;-) | To: Karl-Heinz Schmitt Der Empfänger. Hier können auch mehrere oder viele Namen / Adressen stehen, jeweils durch Kommata getrennt. Außerdem kann es noch die Headerzeile "CC:" geben, die angibt, wer diese Mail in Kopie zur Kenntnisnahme erhalten hat. Der Unterschied ist rein administrativ, ähnlich wie bei Rundschreiben mit "Empfängern" und "Zur Kenntnis in Kopie an"; wie auch dort wird (vermutlich! - die Angaben in To:/CC: sind nur informativ und haben für die Zustimmung keine Bedeutung!) an jeden Namen / jede Adresse in beiden Kategorien jeweils ein Exemplar verschickt. Technisch gesehen werden beim Versand einer normalen E-Mail die Adressen, die im Mailprogramm des Absenders in die Felder "To:" und "CC:" eingetragen wurden, nicht nur zur Generierung dieser beiden Headerzeilen benutzt, sondern auch beim SMTP-Dialog als "RCPT TO:" übertragen, also sozusagen für den Umschlag abgeschrieben. Die meisten Mailprogramm bieten noch ein "BCC:"-Feld für "blinde" Kopien. Die hier eingegebene Adressen werden zwar in den Umschlag übernommen (jeder erhält ein Exemplar der Mail), erscheinen aber im Header der E-Mail (auf dem Briefbogen) nicht; die anderen Empfänger wissen also nichts von den Empfängern dieser blinden Kopien. Mailinglisten (oder auch Bulkmail / Spam) werden häufig auf diese oder eine vergleichbare Weise verschickt. | Subject: Re: Hallo Nachbar! Der Betreff. | Reply-To: hinz@provider.de Die Adresse, an die geantwortet werden soll. Hier schickt Heinz-Gustav Hinz die E-Mail von seinem Account an der RWTH Aachen ab, möchte Antworten aber an seine private Mailadresse haben. Alle diese Zeilen können beliebig durch den Absender bestimmt werden und sind demzufolge für eine Rückverfolgung weitgehend wertlos. 3.2 "Technische" Angaben | Message-ID: <35FFDA4F.2BC2A064@post.rwth-aachen.de> | In-Reply-To: <529471993@ancalagon.rhein-neckar.de> | References: <529471993@ancalagon.rhein-neckar.de> Die Message-ID ist eine eindeutige Kennung der E-Mail (vergleichbar einer Seriennummer). Sie sollte aus einer unverwechselbaren Zeichenfolge vor dem "@" (meistens Datum und Benutzerkennung in einer kodierten Form) und einem Rechnernamen hinter dem "@" bestehen. Häufig wird die Message- ID bereits vom Mailprogramm des Absenders erzeugt; ansonsten tragen die meisten Mailserver sie nach, soweit sie fehlt. Sie ist demnach kein Beleg für den tatsächlichen Absender. Wenn sich die E-Mail auf eine andere bezieht, diese also beantwortet, findet sich deren Message-ID in der Headerzeile "References:" oder "In- Reply-To:". Diese Angaben nutzen manche Mailprogramme, um die einzelnen E-Mails, bspw. aus einer Mailingliste, zu sortieren (ähnlich einem Newsreader). | MIME-Version: 1.0 | Content-Type: text/plain; charset=iso-8859-1 | Content-Transfer-Encoding: quoted-printable Diese Angaben beschreiben, welcher Art der Inhalt der Mail ist. Hier handelt es sich um reinen Text ("plain text") mit dem Zeichensatz "iso- 8859-1" und der Sonderzeichenkodierung "quoted-printable". Diese Daten sind nur für das Mailprogramm notwendig, um Dateianhänge u.ä. erkennen und behandeln zu können. | X-Mailer: Mozilla 4.05 [de] (Win95; I) Alle mit "X-" beginnenden Headerzeilen sind nicht standardisiert und werden von verschiedenen Programmen (oder auch Benutzern) beliebig eingefügt. Üblich ist ein Header wie dieser, der die verwendete Software angibt. Ein anderes Mailprogramm produziert stattdessen vielleicht direkt mehrere X-Header, zum Beispiel > X-Priority: 3 > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook Express 4.72.3110.1 > X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Möglich ist auch die Verwendung des Headers "User-Agent". Bei weiteren Headern läßt sich meist aus dem Namen der jeweiligen Headerzeile schließen, wofür er denn gedacht sein mag; ansonsten finden sich die entsprechenden RFCs in Abschnitt 7 aufgezählt. Der Hinweis, daß alle diese Header vom Absender beliebig gewählt und damit auch gefälscht werden können, ist an dieser Stelle vermutlich fast schon überflüssig. 3.3 "Zustellvermerke": den Weg einer E-Mail nachvollziehen Die noch verbleibenden Headerzeilen lassen sich für die Rückverfolgung einer E-Mail verwenden. Auch hierbei ist natürlich ein wenig Vorsicht geboten, um nicht plumpen Fälschungsversuchen aufzusitzen. | Return-Path: Diese Zeile sollte, wenn sie existiert, ganz am Anfang der E-Mail stehen. Sie enthält den Envelope-From (also die Absenderangabe aus dem SMTP-Umschlag), die - wir erinnern uns - beliebig angegeben werden kann. Bringt für eine Rückverfolgung also herzlich wenig. 3.3.1 "Received:"-Headerzeilen Die "eigentlichen" Zustellvermerke sind die "Received:"-Headerzeilen, die jeweils vor dem Weiterschicken einer E-Mail vom Mailserver vorne angefügt werden. Man muß sie also rückwärts (!) lesen: die letzte Received:-Zeile ist die oberste (!). Daraus resultiert zweierlei: die oberste "Received:"- Zeile wurde vom eigenen Mailserver (bzw. dem des Providers) erzeugt - sie ist also vertrauenswürdig. Und: die übrigen genannten Headerzeilen müssen normalerweise unterhalb der "Received:"-Zeilen stehen, da sie ja schon bei der Einlieferung vorhanden waren. Andererseits könnten natürlich auch vorgeschriebene Headerzeilen bei der Einlieferung gefehlt haben, die dann erst später von einem der empfangenden Mailserver ergänzt wurden und daher über der ersten "Received:"-Zeile stehen. Dennoch: Wenn "mittendrin" noch einmal "Received:"-Zeilen auftauchen, handelt es sich mit hoher Wahrscheinlichkeit um Fälschungen, die einfach vom Absender schon vor dem ersten Versenden eingefügt wurden. Gleiches gilt, wenn sich "Lücken" zwischen einzelnen "Received:"-Zeilen auftun. Eine "Received:"-Zeile gibt immer an, wer die Mail von wem empfangen hat. Das heißt: Wenn jetzt A die Mail von B bekommen hat, muß als nächstes eine Zeile folgen, in der B die Mail von C bekommen hat. Beachten muß man dabei allerdings, daß ein und derselbe Rechner durchaus mehrere "Namen" haben kann. So wird ein Rechner, der den E-Mail-Verkehr erledigt, vielleicht mail.domain.de heißen. Wenn derselbe Rechner auch für das WWW und News zuständig ist, heißt er vielleicht auch noch www.domain.de und news.domain.de - das ist aber immer noch derselbe Rechner. Genauer feststellen läßt sich das durch eine DNS-Abfrage (nslookup, vgl. Abschnitt 4); in diesem Fall müßten dort beide Namen für denselben Rechner, d.h. dieselbe IP-Nummer, registriert sein. 3.3.2 "Received:"-Headerzeilen im einzelnen | Received: from mx3.gmx.net (qmailr@mx3.gmx.net [195.63.104.129]) | by ancalagon.rhein-neckar.de (8.8.5/8.8.5) with SMTP id SAA25291 | for ; Thu, 16 Sep 1998 17:36:20 | +0200 (MET DST) Jetzt geht's ans Eingemachte. :-) Diese Zeile muß nämlich wiederum in ihre Einzelteile auseinandergepflückt werden. | by ancalagon.rhein-neckar.de (8.8.5/8.8.5) with SMTP id SAA25291 Der eigene Mailserver des Empfängers (hier "ancalagon.rhein-neckar.de") hat diese E-Mail empfangen ("Received by"). Die Angabe in Klammern gibt dabei (Namen und) Version des dort laufenden Mailserver-Programmes (MTA) an. (Hier handelt es sich um das Programm "sendmail".) Empfangen wurde per SMTP mit der internen Kennnummer "SAA25291" (was für uns bedeutungslos ist). | for ; Thu, 16 Sep 1998 17:36:20 | +0200 (MET DST) Freundlicherweise wird hier der Envelope-To wiedergegeben (also die Anschrift auf dem SMTP-Umschlag). Außerdem findet sich das Datum und die Uhrzeit, zu dem die Mail einging. Ob diese Angaben hier stehen, ist einmal vom verwendeten MTA und zum anderen davon abhängig, ob die Mail nur an einen oder an mehrere Empfänger auf demselben (!) Server ging. Im letzteren Fall fehlt die Angabe meist, da es ja die einzelnen Empfänger nichts angeht, wer die E-Mail sonst noch bekommen hat. | Received: from mx3.gmx.net (qmailr@mx3.gmx.net [195.63.104.129]) Hier steht jetzt, von welchem Mailserver die E-Mail empfangen wurde. Das Format dieser Zeile ist leider nicht ganz einheitlich. Immer gilt: die Nummer in (eckigen) Klammern ist die unverwechselbare IP-Nummer des einliefernden Rechners - hier "195.63.104.129". Außerdem ist angegeben, wie dieser sich vorgestellt hat (die Angabe aus dem HELO) - hier "qmailr@mx3.gmx.net". Das hat unser Mailserver brav überprüft und festgestellt, daß die IP-Nummer tatsächlich zu "mx3.gmx.net" gehört. Soweit also alles in Ordnung. Wenn HELO und Realität übereinstimmen, wird der HELO-Parameter manchmal gar nicht angegeben. Dann findet sich nur die IP-Nummer und der (als richtig festgestellte) Name des einliefernden Servers. Andererseits geben manche MTA nur den (möglicherweise gefälschten) HELO-Parameter und die (echte) IP-Nummer an, ohne den zugehörigen Namen nachzuschauen. Dann ist der angegebene Name gerade *nicht* wahr. Auch ist es möglich, daß die Reihenfolge der Angaben genau umgekehrt ist (zuerst HELO, dann tatsächliche Angabe). Schließlich - und am schlimmsten :-( - gibt es ältere MTAs, die noch an das Gute im Menschen glauben und außer dem (beliebig fälschbaren) HELO überhaupt nichts festhalten. Da ist dann guter Rat teuer. In diesem Falle hilft es nur noch, sich direkt an den Postmaster dieses Systems zu wenden, der dann möglicherweise über die automatisch geführten Log-Dateien noch weitere Informationen ermitteln kann. Daher ergibt sich folgendes: Soweit man weiß oder ausprobiert hat, in welchem Format der eigene MTA bzw. der des eigenen Providers die Angaben in der Received:-Zeile macht, gibt es kein Problem. Wenn man sich nicht sicher ist, welcher der Rechnernamen jetzt der echte ist, hilft nichts anderes, als selbst nachzuschauen, welcher Name zu der angegebenen IP-Nummer paßt. Dazu gibt es bspw. das Tool "nslookup" (vgl. Abschnitt 4.1). | Received: (qmail 1935 invoked by alias); 16 Sep 1998 15:36:06 -0000 Diese Zeile ist eine Spezialität der bei GMX verwendeten Mailserversoftware "qmail". | Delivered-To: GMX delivery to karl-heinz@gmx.net Auch dies eine Spezialität von GMX: eine E-Mail an diesen GMX-Kunden wurde ausgeliefert. | Received: (qmail 27698 invoked by uid 0); 16 Sep 1998 15:36:02 -0000 Wieder "qmail". Alle diese Software-spezifischen Zeilen sind für die Rückverfolgung zunächst ohne Bedeutung. | Received: from pbox.rz.rwth-aachen.de (137.226.144.252) | by mx3.gmx.net with SMTP; 16 Sep 1998 15:36:02 -0000 Hier wird es jetzt spannend - diese Zeile wurde ja nicht mehr von unserem vertrauenswürdigen eigenen Mailserver erzeugt. Schauen wir mal: | by mx3.gmx.net with SMTP; 16 Sep 1998 15:36:02 -0000 "mx3.gmx.net" hat die Mail empfangen. Das ist der Rechner, der sie dann an uns weitergereicht hat - stimmt also. Wundert eigentlich auch wenig; den Mailserver von GMX würde ich durchaus als vertrauenswürdig bezeichen. | Received: from pbox.rz.rwth-aachen.de (137.226.144.252) Bekommen hat er sie von "pbox.rz.rwth-aachen.de" mit der IP-Nummer "137.226.144.252". GMX gibt bei Übereinstimmung von HELO-Angabe und tatsächlichem Namen diesen nur einmal an. Anderes Beispiel: > Received: from hiper1-d87.cwnet.com (HELO mailer1.themailmachaine.net) > (205.162.108.87)by mx1.gmx.net with SMTP; 10 Sep 1998 23:29:25 -0000 Hier hat sich der einliefernde Rechner beim HELO als "mailer1.themailmachaine.net" vorgestellt; tatsächlich heißt er aber "hiper1-d87.cwnet.com". Wenn man die IP-Nummer "205.162.108.87" mittels "nslookup" nachschaut, kann man das feststellen. (Näheres dazu weiter unten, Abschnitt 4.1). [11] Aber weiter im Text - wir waren stehengeblieben bei der Feststellung, daß GMX die Mail von "pbox.rz.rwth-aachen.de" hat. | Received: from post.rwth-aachen.de (slip-vertech.dialup.RWTH-Aachen.DE | [134.130.73.8]) by pbox.rz.rwth-aachen.de (8.9.1/8.9.0) with ESMTP | id RAA28830 for ; Wed, 16 Sep 1998 17:35:59 | +0200 "pbox.rz.rwth-aachen.de" wiederum hat sie von jemandem, der sich als "post.rwth-aachen.de" vorgestellt hat, tatsächlich aber "slip- vertech.dialup.RWTH-Aachen.DE" heißt. Da beides Rechnerbezeichnungen der RWTH Aachen sind und der letztere Name ("dialup") darauf hindeutet, daß es sich hier um einen Einwahlport handelt, dessen IP-Nummer dynamisch immer wechselnden Anrufern zugewiesen wird, macht auch das keinen übermäßig verdächtigen Eindruck. Auch der Zeitunterschied von nur 3 Sekunden zwischen "17:35:59 +0200" und "15:36:02 -0000" paßt ganz gut für die Entgegennahme und direkt folgende Weiterleitung einer E-Mail. Die E-Mail kam also von einem Einwahlport an der RWTH Aachen. | X-Resent-By: Global Message Exchange | X-Resent-For: karl-heinz@gmx.net | X-Resent-To: karl-heinz@ancalagon.rhein-neckar.de Diese unmittelbar aufeinander folgenden Header sind wiederum eine Spezialität von GMX, die angeben, an welche GMX-Adresse die Mail geschickt wurde, und an welche tatsächliche Adresse sie dann weitergeleitet wurde. Auch sie sind für die Rückverfolgung zunächst bedeutunglos. [11] Solche Beispiele sind natürlich nichts anderes als eben Beispiele und bleiben daher auch nicht allzeit gültig. Momentan (Juli 2001) heißt der betreffende Rechner mit der IP-Nummer "205.162.108.87" nicht mehr "hiper1-d87.cwnet.com", sondern "hiper4b-d87.stk.cwnet.com", und nächsten Monat vielleicht schon wieder ganz anders. Klar werden soll das Prinzip. 3.4 Spezielle Headerzeilen Einige recht häufig vorkommende Headerzeilen wurden noch nicht genannt. So ist zum Beispiel | Comments: Authenticated Sender is <....> recht verbreitet (wobei statt "<....>" natürlich eine E-Mail-Adresse steht). Eigentlich sollte diese Zeile einmal angeben, wer denn nun tatsächlich der Absender dieser E-Mail war (wenn der Mailserver des eigenen Providers verwendet wurde bspw. durch Rückgriff auf die bei der Einwahl ins System verwendete Nutzerkennung). Manchmal trifft das auch noch zu; häufig - bei unerwünschter Bulkmail nahezu immer - ist diese Zeile aber zwecks Irreführung gefälscht. Beliebt ist zunehmend auch die Headerzeile "X-Sender". Diese soll ebenfalls den tatsächlichen Sender angeben. Zumindest bei T-Online-Kunden funktioniert das anerkanntermaßen (natürlich nur, solange auch einer der T-Online-Mailserver verwendet wird): | X-Sender: 06221168783-0001@t-online.de Die Angabe ist in diesem Fall die T-Online-Benutzerkennung, die bei älteren Kunden zu allem Überfluß auch noch mit der Telefonnummer identisch ist. In diesem speziellen Fall kann man eventuelle Nachfragen dann sogar telefonisch klären. ;-) Auch sonst lassen sich über das bei T-Online automatisch angelegte Impressum der Nutzer-Webseiten eventuell die persönlichen Daten des Versenders ermitteln - wenn dieser Versender private Webseiten bei T-Online hat: es findet sich dann unter , im Beispiel also unter . Bitte beachten: auch ein X-Sender läßt sich natürlich fälschen, wenn die E-Mail in Wahrheit gar nicht über einen Mailserer von T-Online verschickt wurde. Für andere Mailserver hat diese Headerzeile keine spezielle Bedeutung, so daß sie dafür jeden Wert akzeptieren. Sie müssen also überprüfen, ob die E-Mail auch tatsächlich vom T-Online Mailserver an Sie ausgeliefert wurde. Ein Beispiel: | Received: from mailout06.sul.t-online.com ([194.25.134.19]) | by mail.server.meines.providers.example with esmtp (Exim 3.36 #1) | id 17WcWQ-00032C-00 | for meine.adresse@meines.providers.example; Wed, 01 Jan 2003 00:10:53 +0100 | Received: from fwd06.sul.t-online.de | by mailout06.sul.t-online.com with smtp | id 17WcWQ-0001nK-02; Wed, 01 Jan 2003 00:10:48 +0100 | Received: from (06221168783-0001@[123.124.125.345]) by fwd06.sul.t-online.com | with smtp id 17WcWQ-0DlTD4C; Wed, 01 Jan 2003 00:10:34 +0100 Die beiden unteren Received:-Zeilen sind typisch für eine Auslieferung über T-Online. Sie erkennen aus der untersten Zeile, unter welcher IP- Nummer der T-Online-Kunde eingewählt war (hier: 123.124.125.345, eine ungültige Fantasie-Nummer), und welche T-Online-Kennung er hat (hier: 06221168783-0001). Darauf können Sie sich aber nur dann verlassen, wenn auch die darüberliegende (hier: die oberste) Received:-Zeile bestätigt, daß die E-Mail überhaupt wirklich über T-Online ausgeliefert wurde (und wenn diese Zeile von einem vertrauenswürdigen Server erzeugt wurde, also bspw. von dem Ihres Providers, und nicht noch weitere angebliche Stationen dazwischenliegen). Also schauen wir uns das mal schnell an: die mitgeloggte IP-Nummer ist "194.25.134.19", und das ist, wie sich bspw. mittels nslookup schnell prüfen läßt, auch wirklich ein Server von T-Online: | [thomas@xerxes thomas]$ host 194.25.134.19 | 19.134.25.194.in-addr.arpa domain name pointer mailout06.sul.t-online.com. Also: stimmt, und der Übeltäter ist schnell identifiziert. ---------------------------------------------------------------------- 4. Hilfreiche Tools für die Header-Analyse ========================================== Ganz ohne Hilfsprogramme ist auch die Analyse eines E-Mail-Headers nicht möglich. Wichtig ist es insbesondere, herauszufinden, welche IP-Nummern welchen Namen zugeordnet sind, und wer hinter diesen Nummern/Namen tatsächlich hintersteckt. Die wichtigsten Tools sollen hier kurz vorgestellt werden. Bezugsquellen für die Programme folgen unten unter 4.4. 4.1 nslookup (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 2.1 in Fußnote [7] erwähnt, muß die Rückwärtsauflösung von der Nummer zum Namen hin nicht unbedingt funktionieren oder wahr sein. Es empfiehlt sich daher, sie ggf. durch eine Vorwärtsauflösung zu überprüfen: wenn "205.162.108.87" zum Namen "hiper1-d87.cwnet.com" gehören soll, dann muß umgekehrt die Abfrage auf "hiper1-d87.cwnet.com" wieder die Nummer "205.162.108.87" liefern. Hinweis: nslookup dürfte zukünftig von "host" bzw. "dig" abgelöst werden. 4.2 whois Mit Hilfe von whois läßt sich beispielsweise herausfinden, wem bestimmte IP-Nummern, IP-Nummern-Bereiche oder Domains gehören. Auf diesem Weg lassen sich nicht nur zusätzliche Beschwerdeadressen finden, interessant ist es häufig auch, festzustellen, wer hinter einem bestimmten Domain-Namen oder einer bestimmten IP-Nummer steckt. Manchmal sind das bereits "alte Bekannte", so daß von vornherein klar ist, daß Beschwerden dort keinen Erfolg haben werden ... Beispielsweise ergibt die Abfrage "whois 205.162.108.87" den Verantwortlichen für diese IP-Nummer bzw. denjenigen, dem diese Nummer respektive der ganze Nummernblock, zu dem diese Nummer gehört, zugeteilt wurde. Bei der Angabe eines Domainnamens statt einer IP-Nummer wird der Eigentümer der entsprechenden Domain zurückgeliefert: "whois domain.name" ergibt entsprechend die Daten desjenigen, der diese Domain registriert hat. - Die Eigentümer von Subdomains, bspw. von "irgendwas.de.vu", lassen sich in der Regel nicht ermitteln; jedenfalls nicht auf diesem Wege, sondern allenfalls über den Zuständigen für die Haupt-Domain (Second- Level-Domain), bspw. "de.vu". Bitte beachten: es gibt viele verschiedene Whois-Server, die jeweils nur für eine bestimmte Top-Level-Domain (bspw. "de" oder "at" oder "com") zuständig sind, und auch die Zuständigkeit für die IP-Nummern-Bereiche ist auf eine Handvoll Regional Internet Registries (RIRs) verteilt, insb. die von ARIN (amerikanischer Raum), RIPE (europäischer Bereich) und APNIC (asiatisch-pazifischer Raum). Wenn daher keine vernünftige Antwort auf eine Abfrage erfolgt, muß stattdessen ein anderer, sprich der zuständige Whois-Server befragt werden. Man kann auch direkt einen der "intelligenten" Whois-Server wie whois.thur.de oder whois.bofh.de verwenden; diese leiten die Anfrage dann an den richtigen Server weiter. Als weitere Alternative siehe dazu auch die Online-Abfrageseiten im WWW unten unter 4.6. 4.3 traceroute Traceroute gibt den Weg an, den Datenpakete vom eigenen Rechner zum angegebenen Zielrechner zurücklegen. So läßt sich der Uplink für den Zielrechner ermitteln, also sozusagen der "Provider des Providers". Falls Beschwerden beim Provider selbst ständig erfolglos und ohne Antwort bleiben, kann man auch daran denken, es eine Ebene höher zu probieren und sich an den Uplink zu wenden. 4.4 Programmpakete und Bezugsquellen Auf UNIX-Rechnern stehen die genannten Tools meist unter eben diesem Namen zur Verfügung. Unter anderen Betriebssystemen ist das zumeist nicht der Fall - aber auch dort gibt es inzwischen Programmpakete, in denen die gebräuchlichsten Tools zusammengefaßt (und häufig mit einer leicht bedienbaren grafischen Benutzeroberfläche versehen) sind. Die Programme sind im allgemeinen Free- oder Shareware. Für Windows 95/98 (wahrscheinlich auch NT/2000): Standardmäßig existieren "ping" und "tracert" (=traceroute). DOS-Box öffnen und "ping [hostname/IP]" oder "tracert [hostname/IP]" eintippen. + Sam Spade Dieses Programm ist speziell zur Rückverfolgung unerwünschter Bulkmail ausgelegt. Es bietet neben ping, nslookup, traceroute, IP-Blocks und weiteren Tools auch eine "automatische" Headeranalyse, die bei einem ersten Einstieg in die Materie sicher hilfreich ist, und liefert daneben auch einige hervorragende, allerdings englischsprachige FAQs, Links und Step-by-step-Anleitungen für die Absenderfeststellung und Beschwerde bei unerwünschter Bulkmail mit. + Cyber Kit Bietet Ping, Traceroute, Finger, WhoIs, NS Lookup, QoD. Derzeit ist die o.g. Website nicht zugänglich; das Programm selbst wird aber unter anderem bei zum Download angeboten. + Internet Maniac Bietet Host Lookup, Ping, Traceroute, Connect, Time, Finger, Whois, POP3, Listener, Scanner, Winsock, Raw connect, Speed check. + NetScan Tools for Windows 95 Nslookup, Finger, Ping, Traceroute, Scanner, etc. + VisualRoute Graphisches Traceroute mit Whois-Abfragen und Portscan. Für OS/2: Es existieren standardmäßig "ping", "nslookup" und "finger" - diese Programme heißen auch so. "traceroute" heißt hier "tracerte". Desweiteren gibt es eine whois-implementation von Frank Ellermann zum Download unter Andere Programmpakete sind mir derzeit nicht bekannt. Für Amiga: + Für Ataris: (Zur Zeit keine URLs bekannt.) Für MacOS 9: + IPNetMonitor: Shareware, $20 + Interarchy (ehemals MAC TCP Watcher): Für MacOS X: Es existiert serienmäßig das "Network Utility" bzw. "Network Dienstprogramm", welches unter "Applications/Utilities" zu finden ist. Funktionsumfang: Netstat, Ping, Lookup, Trace, Whois, Finger, Portscan. 4.5 Finger-Gateway auf info.belwue.de Wer über keines dieser Programme verfügt, aber Zugriff auf einen finger-client hat, kann stattdessen das finger-Gateway auf info.belwue.de verwenden. Eine Hilfe dazu gibt es, wenn man help@info.belwue.de anfingert: | BelWue finger-gateway, available services: | ping,traceroute,whois,nslookup,dnslist,acronym,translate,schwob,dfn, | date,test | | You may specify arguments by adding them with an ':', examples: | finger traceroute@info.belwue.de | finger traceroute:www.bofh.net@info.belwue.de | finger whois:belwue.de@info.belwue.de | finger acronym:RTFM@info.belwue.de 4.6 Online-Tools Schließlich gibt es die kleinen Helferchen inzwischen auch vielfach als Formular im WWW, mit dem man entsprechende Anfragen stellen kann. Eine Zusammenstellung vieler guter Tools findet sich auf Empfehlenswert auch der allgemeine whois-Dienst auf sowie der whois-Dienst von Eine umfangreichere Liste findet sich in der FAQ der Newsgroup de.admin.net-abuse.mail; vgl. dazu die weiterführenden Hinweise in Abschnitt 7 dieser FAQ. 4.7 abuse.net Das "Network Abuse Clearinghouse", , sammelt Kontaktadressen von Providern, unter denen man die jeweilige Beschwerdestelle erreichen kann. Die Kontaktdatenbank läßt sich auf dreierlei Weise abfragen: Im WWW: Per finger: finger example.com@abuse.net [mit der betreffenden Domain statt "example.com", natürlich] Per whois: whois example.com @whois.abuse.net [mit der betreffenden Domain statt "example.com", natürlich] 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 , 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 - in Englisch, bitte. :-) Mehr dazu unter . 4.8 Blacklists auswerten Diverse Anbieter führen (schwarze) Listen, in denen bestimmte Rechner (IP- Adressen) und/oder Domains geführt werden, die bestimmte Voraussetzungen erfüllen, insbesondere negativ aufgefallen sind. Eine manuelle oder automatisierte Auswertung dieser Listen kann durchaus sinnvoll sein - sei es, daß man feststellen möchte, ob ein bestimmter Rechner bereits als offenes Relay (vgl. dazu Fußnote 9) aufgefallen ist, oder daß man darauf aufbauende automatische Filter verwenden möchte, die bspw. Mail von bestimmten Rechnern kennzeichnen oder gar nicht mehr annehmen (zum Thema Mailfilterung wie auch über Blacklists siehe die Verweise in der FAQ von de.admin.net-abuse.mail, genannt in Abschnitt 7 dieser FAQ). Wichtig bei der Verwendung solcher Listen ist es aber, sich zuvor zu informieren, nach welchen Kriterien dort Rechner gelistet werden, und wie verläßlich die Anbieter sind. Es gibt Listen von Rechnern, über die unerwünschte Massenwerbung verschickt wurde, von Rechnern bei Providern, die auf solche Beschwerden reagieren, von sog. offenen Relays, aber auch Listen der IP-Nummern-Bereiche von Einwahlkunden (die deshalb nicht notwendigerweise Spammer sind) oder von Providern, die bestimmte Beschwerdeadressen nicht eingerichtet haben. Diese Listen sind teilweise gut gepflegt, teilweise enthalten sie aber auch falsche Einträge oder werden gar für persönliche Feden zwischen dem Betreiber und anderen Institutionen benutzt. Die meisten dieser Blacklists sind über spezielle DNS-Server realisiert: man fragt dort nach dem Namen eines bestimmten Rechners oder einer Domain, und wenn ein Eintrag existiert, dann steht dieser Rechner oder diese Domain in der jeweiligen Blacklist. Teilweise kommt auch dem Inhalt der zurückgelieferten Antwort eine Bedeutung zu. Wie nun genau diese Abfrage erfolgt, ist listenspezifisch; üblich ist die Angabe der IP-Adresse in umgekehrter Reihenfolge der Ziffernblöcke oder des Domainnamens, jeweils gefolgt vom Namen der Blacklist. Um also den Rechner mit der IP-Nummer "a.b.c.d"" bei der Blacklist relays.osirusoft.com abzuchecken, verwendet man eine Abfrage der Form "host d.c.b.a.relays.osirusoft.com" (oder ein anderes Tool, wie nslookup, bzw. ein Programmpaket, was dies beherrscht, siehe dazu Abschnitt 4.4). Ggf. muß man zu einem Rechnernamen erst noch die IP-Nummer(n) ermitteln, bevor man die Abfrage starten kann: | [thomas@xerxes thomas]$ host moutvdom.kundenserver.de | moutvdom.kundenserver.de has address 195.20.224.131 | moutvdom.kundenserver.de has address 195.20.224.200 | moutvdom.kundenserver.de has address 195.20.224.149 | moutvdom.kundenserver.de has address 195.20.224.130 | | [thomas@xerxes thomas]$ host 131.224.20.195.relays.osirusoft.com | 131.224.20.195.relays.osirusoft.com has address 127.0.0.4 Die genaue Bedeutung des Abfrageergebnisses läßt sich in diesem Falle der Webseite entnehmen. Mit dem unter verfügbaren Tool läßt sich die Abfrage von solchen Listen vereinfachen. Alternativ verfügen die meisten Blacklists auch über WWW-Formulare für solche Abfragen. Links dazu finden sich am ehesten in der FAQ von de.admin.net-abuse.mail, die in Abschnitt 7 referenziert ist. ---------------------------------------------------------------------- 5. Beschwerden über unerwünschte Massen-E-Mail ============================================== Der häufigste Grund, sich über den tatsächlichen Absender einer E-Mail informieren zu wollen, ist der, daß man den bzw. die Verantwortlichen für eine unerwünschte, massenhaft verschickte (Werbe-)E-Mail ("unsolicited commercial/bulk email", kurz UCE bzw. UBE) ausfindig machen möchte, um sich dort zu beschweren. Womit sich die Frage stellt: Wo und wie beschwert man sich? Dazu sollen hier nur einige grundlegende Hinweise gegeben werden; Verweise auf weitere Informationsquellen finden sich unten unter Punkt 7 ("Weiterführende Hinweise"). Insbesondere die Lektüre der FAQ der Newsgroup de.admin.net-abuse.mail sollte für diese Fälle ein Muß sein. 5.1 Wo kann ich mich beschweren? 5.1.1 Beim Versender der UCE. Wenig sinnvoll - meist sind die Absenderadressen gefälscht, und wenn die Beschwerde ankommt, führt das im Zweifelsfall nur dazu, daß Deine Absenderadresse als tatsächlich existent vorgemerkt wird (was zu einer Vermehrung der Werbeflut führen kann). Ausnahmen kann man vielleicht bei UCE aus deutschen Landen machen, insb. dann, wenn man ohnehin rechtliche Schritte erwägt, oder wenn man den Eindruck hat, der Betreffende wisse gar nicht, was er gerade anrichtet. Das Risiko, die eigene Adresse als "gut" zu bestätigen, bleibt. 5.1.2 Beim Hersteller o.ä. des beworbenen Produkts. Auch das nur sinnvoll, wenn es sich um eine namhafte Firma handelt, die entweder von dieser "Werbekampagne" gar nichts weiß, oder zumindest keine Ahnung hat, wie sehr sie gerade ihrem Ruf schadet. 5.1.3 Beim (tatsächlichen) Provider des UCE-Versenders. Die meisten Provider mögen keine UCE-Versender unter ihren Kunden und reagieren entsprechend mit Verwarnungen, Accountentzug und/oder Vertragsstrafen, sofort oder im Wiederholungsfall (manche allerdings auch gar nicht). Die Adresse für Beschwerden ist (sollte sein) abuse@.....; sofern diese Adresse nicht existiert, ersatzweise postmaster@..... Darauf sollte auf jeden Fall eine Antwort kommen, meist eine automatische Bestätigung oder der Hinweis, daß für UCE u.ä. spezielle Beschwerdeadressen existieren. - Falls diese Adressen nicht existieren, kann der betreffende Provider bei gemeldet werden; dort wird eine (schwarze) Liste solcher Provider, die technische Standards (RFCs) nicht befolgen, geführt. Diese kann man natürlich auch selbst zuvor abfragen, vgl. dazu die genannten Webseite und Abschnitt 4.8 dieser FAQ. Vereinfachen läßt sich dieses Vorgehen über (siehe dazu auch Abschnitt 4.7 dieser FAQ). Dort wird eine Datenbank mit Beschwerdeadressen geführt; E-Mail an provider.domain@abuse.net (bspw. aol.com@abuse.net) wird automatisch an die passenden Beschwerdeadressen weitergeleitet. Bei Providern, die erfahrungsgemäß nicht reagieren, geht eine Kopie der Beschwerde an den Uplink (s. unten). Falls auf keine der genannten Weisen eine Antwort erfolgt, kann man noch versuchen, sich an den "Administrative Contact" (Admin-C) der Domain zu wenden. Dessen Erreichbarkeit (auch Telefon- und Faxnumemr sowie Anschrift) läßt sich mittels des Tools "whois" herausfinden. 5.1.4 Beim Uplink des Providers. Wenn ein Provider längere Zeit nicht reagiert, bleibt die Möglichkeit, sich eine Stufe höher beim Uplink (also dem "Provider des Providers") zu beschweren. Wer das ist, läßt sich bspw. mit Hilfe des Tools "traceroute" (s. oben, Abschnitt 4.3) herausfinden. 5.1.5 Bei offenen Relays. UCE wird meist nicht direkt verschickt, sondern bei einem (unbeteiligten) Mailserver "abgekippt", der so gutgläubig ist, nicht nur E-Mail von eigenen Benutzern nach überall und von überall an die eigenen Benutzer zuzustellen, sondern von überall nach überall weiterzuleiten. Das mag einmal sinnvoll und hilfreich gewesen sein, ist aber heutzutage nur eine Einladung zum Mißbrauch. Insofern sollte man auch dort den zuständigen Postmaster auf den Mißbrauch hinweisen und ihn bitten, seinen Mailserver "relayfest" zu machen. Unter gab es einen einfachen Test (zur Zeit wegen Mißbrauchs leider deaktiviert), um festzustellen, ob ein Mailserver für jedermann relayed oder nicht; stattdessen finden sich dort jetzt Verweise auf andere Testmöglichkeiten. Auch kann man (wenn man Zugriff auf den betreffenden Server hat, d.h. sich dort mindestens als User einloggen kann) mittels eines "telnet mail-abuse.org", ausgeführt auf dem betreffenden Mailserver, ebenfalls feststellen, ob dieser relayfest ist. Es wird dann automatisch ein Relaytest gegen diesen Server, von dem aus man sich eingeloggt hat, gefahren. Das eignet sich in der Regel eher für Administratoren. Unter läßt sich ein einfaches Tool herunterladen, um zu prüfen, ob der betreffende Server bereits in eine Blacklist (bspw. als offenes Relay) eingetragen wurde. Das kann ggf. einen eigenen Test ersparen. Für eine tiefergehende Erläuterung und weitergehende Links verweise ich auf die FAQ der Newsgroup de.admin.net-abuse.mail, vgl. Abschnitt 7 dieser FAQ. 5.1.6 Bei E-Mail- und Webspace-Providern. Die meisten Anbieter von (kostenlosen) E-Mail-Adressen, wie gmx.net, hotmail.com etc. verbieten die Verwendung dieser Adressen in Zusammenhang mit UCE, sei es als Absender, sei es als im Body angegebene Adresse für weitere Infos, und löschen auf Hinweis solche Accounts ("Dropboxen") sofort. Auch manche Webspace-Provider reagieren, wenn Webseiten per UCE beworben werden. 5.2 Wie beschwere ich mich? Auf jeden Fall *höflich*; der Provider kann meist nichts für seine Kunden, und selbst wenn: durch Beschimpfungen erreicht man nichts. Nach Möglichkeit *kurz*; meist kommt nicht eine Beschwerde, sondern Dutzende bzw. Hunderte. Immer unter Beifügung des *vollständigen Headers* - nur dann kann der Beschwerde nachgegangen und etwas unternommen werden. Im Zweifelsfall auf englisch. Und letztlich: bitte immer beim *richtigen* Ansprechpartner, nicht wahllos bei allen irgendwo in der E-Mail genannten Adressen und Domains. ---------------------------------------------------------------------- 6. Headerzeilen anzeigen lassen =============================== Bei vielen Mailclients werden standardmäßig gar keine oder zumindest nicht alle Headerzeilen angezeigt. Wie man dennoch an den vollständigen Header einer E-Mail kommt, läßt sich normalerweise der Dokumentation des Programms oder der Online-Hilfe entnehmen. Hier finden sich dementsprechend nur kurze Hinweise für die gebräuchlichsten Programme (in alphabetischer Reihenfolge). AK-Mail: "Ansicht", "Kopf-Zeilen" Hinweis: Dieser Menüpunkt steht nur zur Verfügung, wenn der Mail-Body sichtbar ist. Crosspoint: Taste Hinweis: Crosspoint speichert den Header im ZConnect-Format; um an den originalen RFC-Header zu kommen, bedarf es eines Umwegs: (1) Unter edit boxen edit diverses Verschiedene Einstellungen Filter Eingang \XP\BACKUP.BAT $PUFFER eintragen. (2) Datei \XP\BACKUP.BAT anlegen mit folgendem Inhalt: @echo off cls REM :: Puffer mit Mails in Sicherheit bringen, da er bei REM :: ESC-Abbruch gelöscht wird! copy /B \XP\spool\*. \XP\backup\. REM :: Mail kommt noch mal extra damit suchen schneller geht copy /B \XP\spool\D-N*. \XP\backupN\. REM :: MIMEs extrahieren hier REM :: XP-Filter hier (3) Die Mails finden sich als einzelne Dateien in \XP\backupN\ Das Verzeichniss sollte man von Zeit zu Zeit aufräumen. Zur Suche empfiehlt es sich, die Message-ID bei "find" oder "grep" anzugeben, es gibt auch kleines Tool, das einem die Suche von XP aus erlaubt. elm: Taste XEmacs VM-Mail: (1) Taste (2) Alternativ kann man in der $HOME/.emacs eine Zeile der Art (setq vm-invisible-header-regexp "X-.*") einfuegen. Dann werden alle Header bis auf die, die mit X- beginnen, angezeigt. Wirkt erst nach einem Neustart des emacs. Eudora 3.0: 'BlahBlah'-Button in der Toolbar anklicken Forte (Free) Agent: Taste Gnus: Tasten - (im "Summary Buffer" auf der Zeile der Mail einzugeben) oder (im "Summary Buffer") Lotus Notes: Die Lösung ist etwas kompliziert - folgende zwei Möglichkeiten bestehen: (1) Für einzelne Headerzeilen: Wenn die Mail in Notes zur Ansicht geöffnet ist, im Menü "Datei / Eigenschaften: Dokument" auswählen, in dem erscheinenden Fenster den zweiten Reiter von links ("Felder") auswählen: man sieht die einzelnen Headerzeilen wie MessageID usw. (2) Für den kompletten Header: Wenn man sich im View (z.B. "Inbox") befindet: den Focus auf die Mail stellen, "Datei / "Export..." auswählen und "Structured Text" als Exportformat auswählen. Im nachfolgenden Dialog "Selected Documents" auswählen und man erhält eine Klartext-Datei mit allen Headerzeilen und dem Body am Stück. Funktioniert nur im View, nicht wenn die Mail zur Ansicht geöffnet ist! Aus dieser Datei die uninteressanten Notes-Header zu löschen ist meist einfacher als die relevanten Header aus der "Properties"-Box einzeln zu kopieren. MacSOUP: Taste oder Tasten Befehl+ MS Outlook: "Ansicht", "Optionen" MS Outlook 97: "Datei", "Eigenschaften", "Internet" MS Outlook Express: "Eigenschaften", "Details" oder Tasten + mutt: Taste Netscape 4.x: "Ansicht", "Seitenquelltext" Hinweis: Netscape zermanscht bei eingeschalteten Headern ("View", "Headers", "All") die einzelnen Headerzeilen durch Einrückungen etc. zu einem wilden Brei. "View", "Page Source" ("Ansicht", "Seitenquelltext") liefert den Header in lesbarer Formattierung. Novell GroupWise: Pegasus-Mail: Tasten + pine: Taste Ggf. muß man vorher die Option Main Menu -> Setup -> Config -> enable-full-header-cmd aktivieren. The Bat! 1.61: "Special", "View Source" (oder ) "View", "RFC-822 header" aktivieren (oder ++) ---------------------------------------------------------------------- 7. Weiterführende Hinweise ========================== Einführung in das Thema E-Mail an sich: -- E-Mail-Einführung -- Mail - eine Einführung -- Reading Email Header -- RFC 2076: "Common Internet Message Headers" -- RFC 2822: "Internet Message Format" ) -- RFC 2821: "Simple Mail Transfer Protocol" ) E-Mail-Mißbrauch: -- FAQ, Abkuerzungen: de.admin.net-abuse.mail -- Teergruben-FAQ -- Newsgruppe de.admin.net-abuse.mail news:de.admin.net-abuse.mail -- vereinfachtes Auffinden der richtigen Beschwerdeadresse(n) -- Script zur Header-Analyse (online) inkl. Vorbereitung / Versenden von Beschwerden Insbesondere die FAQ von de.admin.net-abuse.mail sei jedem, der sich mit unerwünschten Werbemails herumschlägt, ans Herz gelegt. Es erscheint mir nicht sinnvoll, die dortigen Informationen und insbesondere Links hier alle zu wiederholen. ---------------------------------------------------------------------- 8. Credits ========== Die Idee zu dieser FAQ kam ursprünglich von Hermann Roth. Für hilfreiche Tips, Hinweise und Korrekturen geht ein Dankeschön an * Claus Assmann * Florian Bannasch * Jens Baumeister * Theo Baumeister * Stefan Bion * Ralf Borchert * Philipp Buehler * Christoph Conrad * Andreas Croll * Matthias Damm * Felix Deutsch * Frank Ellermann * Hubert Englmaier * Daniele Frijia * Ulf Herbers * Ulli Horlacher * Ludwig Huegelschaefer * Jochen Klein * Albert Koellner * Helmut Reininger * Hermann Roth * Johannes Sempert * Jörg Strohmayer * Olaf Titz * Rainer Zocholl * Michael Zolk Diese FAQ wird monatlich (am 15.) in de.admin.net-abuse.mail und de.answers gepostet und steht auf in der jeweils aktuellen Fassung auch im WWW zur Verfügung. Thomas Hochstein * *