Dieser Artikel ist größtenteils für alle Ubuntu-Versionen gültig.
In letzter Zeit kommt es häufiger vor, dass Leute Spam erhalten, der ihre eigene E-Mail-Adresse als Absender enthält. Viele bekommen dann erstmal Panik und vermuten, in ihren Rechner sei eingebrochen worden, und dieser würde jetzt zum Versenden von Spam missbraucht. Diese Annahme ist eigentlich immer grundfalsch. Die ganze Angelegenheit ist viel trivialer und auch nicht gefährlich, sondern bloß nervig. Dieser Artikel soll daher ein wenig erläutern, wie man die Kopfzeilen einer E-Mail lesen und deren Herkunft bestimmen kann.
Hier soll jetzt nicht der Eindruck erweckt werden, dass niemals in Linux-Rechner eingebrochen und nachfolgend darüber Spam verschickt wird. Das kommt insbesonders bei Root-Servern durchaus vor. Nur erkennt man das dann garantiert nicht daran, dass die eigene Mail-Adresse für den Versand missbraucht wird.
Um die folgenden Beispiele nachvollziehen zu können, sollte man zuerst in seinem E-Mail-Programm die Anzeige aller Kopfzeilen ("Header") aktivieren. Gerade die für den hier beschriebenen Zweck wichtigen Zeilen sind nämlich standardmäßig meist ausgeblendet. Jede Header-Zeile besteht aus dem Bezeichner, einem Doppelpunkt, und dem Inhalt des Headers, der den Rest der Zeile einnimmt. Ein Header kann sich auch über mehrere Zeilen erstrecken. In diesem Fall müssen die Folgezeilen mit einem Leerzeichen beginnen. Eine leere Zeile markiert das Ende des Header-Bereichs und den Beginn der eigentlichen Mail.
Grundsätzlich kann man die Kopfzeilen in zwei Gruppen unterteilen:
Jene, die vom Absender generiert werden: Das sind eigentlich fast alle, inkl. der standardmäßig angezeigten From:, To:, Subject:, Date:, usw. Da der Absender die Erstellung kontrolliert, sind diese Header nicht vertrauenswürdig und können bei der Suche nach dem Ursprung einer Spammail getrost vergessen werden.
Solche, die "unterwegs" von den Mailservern eingetragen werden, über die diese Mail gelaufen ist. In der Hauptsache sind das die Received:-Zeilen, anhand derer man den Verlauf der Zustellung nachvollziehen kann. Jede Zwischenstation ("Relay"), über die eine Mail geleitet wird, muss mindestens so eine Received:-Zeile eintragen, und zwar immer am Anfang der Mail. Alles, was oberhalb der ältesten (nicht gefälschten) Received:-Zeile steht, ist also vertrauenswürdig, alles darunter nicht.
Verwirrung herrscht manchmal auch über die Beziehung der From:- und To:-Header zur Auslieferung der Mail. Es gibt nämlich keine. Diese sind eher vergleichbar mit einem traditionellen Briefkopf. Relevant für den Briefträger ist aber die Adresse, die auf dem Umschlag steht, und auch bei der elektronischen Post gibt es so eine Art Umschlag, auf englisch Envelope genannt.
In deutsch lokalisierten E-Mail-Programmen werden die From:- und To:-Header meist als Von: und An: übersetzt, im Quelltext der Mail stehen sie aber stets auf Englisch, wie in den einschlägigen RFCs vorgeschrieben. Deswegen werden in diesem Artikel auch die standardisierten, englischen Bezeichner verwendet.
Die Nennung der Envelope-Adressen ist im SMTP-Protokoll vorgeschrieben und geschieht über die Befehle MAIL FROM: und RCPT TO:. (Näheres im Artikel Mailserver testen (Abschnitt „Mails-verschicken“).) Seriöse E-Mail-Clients sorgen natürlich dafür, dass die Adressen auf dem Envelope und im Header übereinstimmen, aber diese Übereinstimmung wird auf der Serverseite im Allgemeinen nicht erzwungen. Den Envelope-Absender kann man übrigens ebenfalls problemlos fälschen. Nur der Envelope-Adressat muss natürlich korrekt sein, damit die E-Mail am Bestimmungsort ankommt. Manche Mail-Server notieren abweichende Envelope- und Header-Adressen, indem sie der Mail einen Envelope-To:- respektive Return-Path:-Header hinzufügen. (Return-Path: bezeichnet die Adresse, wohin Fehlermeldungen geschickt werden können, welches der Envelope-Absender ist.)
Ein seriöses Anwendungsszenario für abweichende Adressen ist die BCC-Funktion ("Blind Carbon Copy"). Solche Blindkopien werden nur über entsprechende Envelopes versendet, ohne dass ein entsprechender Hinweis in den Kopfzeilen vermerkt wird. Versendet man eine reine BCC-Mail ohne To:-Header, ergänzt der Server die folgende Zeile:
To: undisclosed-recipients:;
Wie oben schon erwähnt, muss man die Received:-Zeilen lesen, um die Herkunft einer E-Mail zu ermitteln. Diese sehen z.B. so aus (E-Mailadressen und persönliche Daten verfremdet):
Return-Path: <system @ ubuntuusers.de> Received: from punkrock.otze ([unix socket]) by punkrock (Cyrus v2.1.18-IPv6-Debian-2.1.18-5.1) with LMTP; Tue, 30 Dec 2008 21:56:09 +0100 Received: from localhost (localhost [127.0.0.1]) by punkrock.otze (Postfix) with ESMTP id 8442B33F41 for <otzenpunk@localhost>; Tue, 30 Dec 2008 21:56:09 +0100 (CET) Received: from punkrock.otze ([127.0.0.1]) by localhost (punkrock.otze [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaEx9k10wxvZ for <otzenpunk@localhost>; Tue, 30 Dec 2008 21:56:06 +0100 (CET) Received: from pop.1und1.de (localhost [127.0.0.1]) by punkrock.otze (Postfix) with ESMTP id 4A89133F40 for <otzenpunk@localhost>; Tue, 30 Dec 2008 21:56:06 +0100 (CET) Delivery-Date: Tue, 30 Dec 2008 21:51:48 +0100 Received: from eshu.ubuntu-eu.org (eshu.ubuntu-eu.org [88.191.92.57]) by mx.kundenserver.de (node=mxeu22) with ESMTP (Nemesis) id 0MKr6C-1LHlZ53hyx-000hdT for otzenpunk@example.com; Tue, 30 Dec 2008 21:51:48 +0100 Received: from dongo.ubuntu-eu.org ([213.95.41.16]) by eshu.ubuntu-eu.org with esmtp (Exim 4.69) (envelope-from <system @ ubuntuusers.de>) id 1LHlZ5-0000D5-HK for otzenpunk@example.com; Tue, 30 Dec 2008 21:51:47 +0100
Da ein Mailserver seine Received:-Zeile immer an den Anfang der Mail schreibt, geben diese zusammen genommen den Verlauf der Mail rückwärts wieder:
Die Mail wurde auf dongo.ubuntu-eu.org erstellt und von dort am 30. Dezember um 21:51 Uhr auf eshu.ubuntu-eu.org eingeliefert.
eshu.ubuntu-eu.org hat die dann weitergeleitet an mx.kundenserver.de, den Posteingangsserver des Providers.
Von dort erhält ihn der Postfix auf punkrock.otze. (In Klammern ist als Quelle localhost [127.0.0.1] angegeben. Der Grund dafür ist, dass die Mail via Fetchmail abgeholt wurde, welcher auf dem Localhost läuft. Postfix hat also gemerkt, dass die Mail nicht wirklich von eshu.ubuntu-eu.org eingeliefert wurde.
Die restlichen Received:-Zeilen stammen auch alle vom selben Rechner, weil die Mail dort ein bisschen umhergeschoben wurde. Von Postfix zur Filtersoftware Amavis, wieder zurück zu Postfix und schlussendlich zum IMAP-Server Cyrus.
Der Envelope-Absender lautet <system @ ubuntuusers.de>.
Die Mail hatte also ihren Ursprung auf dongo.ubuntu-eu.org.
Leider sind Received:-Zeilen auch nicht komplett fälschungssicher. Zwar trägt jeder seriöse Mailserver, über den eine Mail gesendet wird, seine Daten nach bestem Wissen ein, aber er hat keine Möglichkeit, die Echtheit der bereits vorhandenen Received:-Zeilen zu überprüfen. Das bietet Spammern die Möglichkeit, am Anfang beliebige gefälschte Received:-Zeilen einzutragen.
Hier ein Beispiel von einer echten Spammail.
Return-Path: <poultice9 @ bugs.debian.org> Received: from punkrock.otze ([unix socket]) by punkrock (Cyrus v2.1.18-IPv6-Debian-2.1.18-5.1) with LMTP; Mon, 27 Oct 2008 11:30:09 +0100 Received: from localhost (localhost [127.0.0.1]) by punkrock.otze (Postfix) with ESMTP id 69B3A33F3D for <otzenpunk@localhost>; Mon, 27 Oct 2008 11:30:09 +0100 (CET) Received: from punkrock.otze ([127.0.0.1]) by localhost (punkrock.otze [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzNqf3Jt+FA2 for <otzenpunk@localhost>; Mon, 27 Oct 2008 11:30:09 +0100 (CET) Received: from pop.1und1.de (localhost [127.0.0.1]) by punkrock.otze (Postfix) with ESMTP id E376233F30 for <otzenpunk@localhost>; Mon, 27 Oct 2008 11:30:08 +0100 (CET) Delivery-Date: Mon, 27 Oct 2008 11:25:28 +0100 Received: from mail.geodezia.hu (mail.geodezia.hu [62.77.225.150]) by mx.kundenserver.de (node=mxeu2) with ESMTP (Nemesis) id 0MKpdM-1KuPHh08sd-000Zjm for otzenpunk@example.com; Mon, 27 Oct 2008 11:25:27 +0100 Received: from [62.77.225.150] by bugs.debian.org; Mon, 27 Oct 2008 11:25:27 +0100
Laut Envelope-Absender stammt die Mail von einem Account auf bugs.debian.org. Da das Debian-Projekt aber eine Linux-Distribution vertreibt und keine Genitalvergrößerungen, ist der wohl gefälscht.
Die folgenden Received:-Zeilen sind dieselben wie beim o.a. Beispiel, da die Mail vom Provider aus denselben Weg genommen hat.
mx.kundenserver.de, der (vertrauenswürdige) Mail-Server des Providers, hat die Mail von mail.geodezia.hu erhalten.
Die letzte Received:-Zeile ist gefälscht. Angeblich wurde die Mail von 62.77.225.150 (selbe IP wie mail.geodezia.hu) an bugs.debian.org gesendet, was natürlich völliger Quatsch ist, denn dann hätte sie danach ja von dort aus nach mx.kundenserver.de gehen müssen und nicht von mail.geodezia.hu aus.
Offensichtlich hat der Spammer (vergeblich) versucht, die Seriosität des Debian-Projektes zu nutzen, um whitelist- oder bayes-basierte Spamerkennungssysteme auszutricksen. Dieselbe Absicht steckt übrigens auch dahinter, wenn ein Spammer den Adressaten des Spams als Absender einträgt. Es wird davon ausgegangen, dass
man des öfteren E-Mails aus der eigenen Domain erhält (insbesonders in Firmen) und solche Absender deswegen schon häufig in vom Spamfilter ausgewerteten Nicht-Spam-Mails aufgetaucht sind.
ein nicht-existenter Absender aus derselben Domain aber evtl. auffallen und erst recht zu einer Einstufung als Spam führen würde. Die einfachste Möglichkeit, an eine gültige Adresse aus der Zieldomain zu kommen ist also, einfach den Adressaten selber dafür zu nehmen.
Wenn man Kunde bei einem großen Mailprovider ist, erhält man auch gelegentlich Spam, der anscheinend von jemandem mit einer ganz ähnlichen E-Mail Adresse stammt. Das ist derselbe Trick, bloß dass der Spammer eine lange alphabetische Liste an E-Mailadressen blockweise bespammt und dabei jeweils die erste Adresse als Absender benutzt. Das ist für den Betroffenen mitunter sehr ärgerlich, weil sein Postfach dann mit Nicht-Zustell-Benachrichtigungen überflutet wird und er u. U. wütende Beschwerden von wildfremden Leuten erhält, die keine Mail-Header lesen können und ihn fälschlicherweise für den Verursacher des Spams halten.
Daneben enthalten die Received-Zeilen auch Informationen zu den verwendeten Übertragungsprotokollen und damit darüber, ob die Übertragung verschlüsselt oder in Klartext stattfand. Das Thunderbird-AddOn Paranoia 🇬🇧⮷ bereitet daraus Informationen zur Transportwegverschlüsselung bei empfangenen E-Mails anschaulich auf.
Manchmal kann es sinnvoll sein, Spam an geeigneter Stelle zu melden. Wenn ein gecrackter Server zum Versenden genutzt wurde, sind die Betreiber vielleicht sogar dankbar darüber, wenn man sie auf das Problem aufmerksam macht. Seriöse Provider dulden auch keine Spammer unter ihren Kunden und gehen dagegen vor, wenn man sie benachrichtigt.
Auf der anderen Seite möchte man aber natürlich nicht den Spammer mit der Nase darauf stoßen, dass die eigene Mailadresse nicht nur gültig ist, sondern auch regelmäßig gelesen wird. Außerdem hat man im Allgemeinen auch nicht unbegrenzt Zeit für so was, es sei denn, man möchte die Beschäftigung mit Spam zum neuen Hobby machen.
Folgende Richtlinien könnten dabei nützlich sein:
Immer an den Provider wenden, nicht direkt an den Server-Betreiber. Letzterer ist entweder selber der Spammer oder oft nicht mal in der Lage, das Anliegen überhaupt zu verstehen bzw. das Problem zu beheben. Besonders Merkbefreite machen dann auch gerne mal den Überbringer der schlechten Nachricht für ihren Inhalt verantwortlich und drohen mit Strafanzeigen oder bepöbeln einen in ihrem Blog.
Welcher Provider zuständig ist, erfährt man durch eine whois-Abfrage nach der IP-Adresse. (Paket whois oder unter Gnome: "System → Systemverwaltung → Netzwerkdiagnose → Whois§)
Abuse.net 🇬🇧 bietet eine große Datenbank an Beschwerde-Adressen von Providern (wenn diese Information nicht sowieso schon in der Whois-Abfrage drin stand).
Manche Provider kümmern sich gerne um Abuse-Meldungen, weil sie ihren Laden sauber halten wollen, bei anderen stößt man dagegen auf taube Ohren, weil sie von jedem Geld nehmen. In so einem Fall kann man dann auch nichts weiter machen. Zu welcher Gruppe ein Provider gehört, lässt sich meist nicht ohne aufwändige Recherche feststellen. Grob gesagt ist es aber so, dass Beschwerden an deutsche Provider oder solche aus dem EU-Ausland sich oftmals lohnen, während man sich bei Spam aus Fernost den Aufwand von vornherein sparen kann. Ausnahmen bestätigen natürlich die Regel.
Verkehrssprache ist englisch. Deutschsprachige Mails an ausländische Provider (abgesehen natürlich von Österreich und der Schweiz) wandern verständlicherweise direkt nach "/dev/null".
Wer jemanden beschuldigt, Spam zu versenden, muss das auch beweisen können. Also bei der Beschwerde immer den kompletten Header mitschicken und anhand dessen detailliert darlegen, wie man dazu kommt, den Übeltäter ausgerechnet unter den Kunden dieses Providers zu vermuten. Außerdem unbedingt höflich bleiben und erstmal davon ausgehen, dass der Providerkontakt ebenfalls an einer Aufklärung interessiert ist und diese Aktivitäten ebenfalls unterbinden möchte.
E-Mail Header - Antispam Wiki 🇩🇪 - Vertiefender Artikel zu E-Mail-Header
Domain Dossier - owner and registrar information, whois and DNS records 🇬🇧 - Online-Tool zur Ermittlung von Informationen zu Besitzer und Registrierte einer IP-Adresse/Domain