Meldestelle

Inhaltsverzeichnis

Spam versendende Bot-Netze sind derzeit keine Herausforderung mehr für Postmaster. E-Mails, die direkt von verseuchten PCs ausgehen, lassen sich relativ einfach erkennen und abweisen. Zu den Methoden gehören Verhaltensanalysen wie der „Pregreeting“-Test von Postfix, gewichtete Blacklist-Abfragen, Tests mit policyd-weight und nicht zuletzt das Greylisting. Das Blockieren verdächtiger Quellen während des SMTP-Dialogs spart nicht nur Ressourcen, sondern hat darüber hinaus den Vorteil, dass keine rechtsverbindliche Mailannahme stattfindet.

Spammer wissen um die Nachteile der Zombie-Mailer und weichen gezielt auf Alternativen aus. Freemail-Dienste und die Mailserver großer Zugangs-Provider arbeiten in der Regel RFC-konform, sind laufend gewartet und haben sich so eine gute Reputation erarbeitet. Solche Diensteanbieter sind daher selten auf Blacklists zu finden und deshalb ein begehrtes Ziel für Spammer, die im großen Stil neue Accounts anlegen oder per Phishing an bestehende Accounts gelangen. Hierüber lassen sich dann erfolgreich Spam-Kampagnen abwickeln und die Hürden beim Ziel-Mailserver überwinden. Zurzeit haben daher die Mailfilter vor allem mit Spam von Freemailern zu kämpfen.

Manche Anbieter haben ihre Kunden aber offenbar besser im Griff als andere. Eine mögliche Ursache dafür: Sie holen Rückmeldungen von Ziel-Mailservern ein, ob eine Mail dort als Spam klassifiziert wurde. Auf diese Weise kann der Anbieter nach einer gewissen Anzahl von Beschwerden handeln und den spammenden Account drosseln oder ganz sperren. Auch wenn es derzeit nicht den Anschein hat: AOL war eine der ersten Firmen, die solche Feedback-Loops (FBL) eingerichtet hat. Service-Provider können sich bei AOL registrieren und bekommen anschließend Beschwerden über E-Mails, die AOL als Spam erkennt. Mittlerweile bieten viele Mail-Provider diesen Service an, aber lange Zeit gab es keinen einheitlichen Standard für den konkreten Aufbau von Spam-Beschwerden oder zur Arbeitsweise von Feedback-Loops.

Seit August 2010 legt RFC 5965 die Struktur von Spam-Beschwerden fest. Die Anweisungen zum Betrieb von Feedback-Loops dokumentiert neuerdings RFC 6449. Der Autor Jesse David „J.D.“ Falk von der Messaging Anti-Abuse Working Group (MAAWG) starb kurz vor Veröffentlichung des Dokuments (siehe Kasten).

Mehr Infos

iX-TRACT

• Wer das Versenden von Spam und anderen Netzmissbrauch feststellt, muss den betroffenen Provider gezielt darüber informieren können, damit der schnell Gegenmaßnahmen ergreift.
• Für wirksame Beschwerden sind der richtige Kontakt und das Einhalten einer einheitlichen, automatisiert auswertbaren Form essenziell.
• Mit RFC 6449 gibt es neuerdings eine Richtlinie für den Betrieb von Feedback-Loops zwischen Spam-Empfänger und Absender-Provider.

RFC 6449 soll die existierenden Verfahren für Feedback-Loops standardisieren und beschreibt gemeinsame Vorgehensweisen. Zu unterscheiden sind im Wesentlichen die zwei beteiligten Parteien: Feedback-Anbieter und -Konsumenten. Als Anbieter gilt die Partei, die E-Mails empfängt und definiert, welche davon unerwünscht sind und vor allem, was genau „unerwünscht“ bedeutet. So kann ein Anbieter alle Mails an eine Spamfalle als unerwünscht deklarieren oder solche, die Nutzer eines Webmail-Dienstes als Spam markieren. Ein Filtersystem kann Spam oder auch nicht mehr gewünschte Newsletter automatisiert kennzeichnen.

Ein Konsument von Feedback-Loops kann diese Informationen dafür nutzen, Spam-versendende Kunden zu identifizieren. Sie können mithilfe dieser Informationen wiederum Newsletter-Abonnenten deaktivieren, Mail-Verteiler aufräumen oder ihren PC entseuchen. Damit aber der gesamte Prozess funktioniert, gilt es Anbieter und Konsumenten zusammenzubringen, denn der RFC schreibt vor, dass sich Konsumenten bei den Anbietern aktiv registrieren, bevor sie Rückmeldungen zu Missbrauch erhalten. Das soll sicherstellen, dass nur interessierte und identifizierbare Konsumenten die zum Teil reichlich fließenden Informationen erhalten.

Feedback-Anbieter sollten eine Webseite zur Verfügung stellen, die erläutert, wie die Rückmeldungen zu formatieren sind, von welcher IP-Adresse sie ausgehen und wer der Absender ist. Zusätzlich kann man häufig gestellte Fragen und Zusatzinformationen bereitstellen, die über die Arbeitsweise der FBL Auskunft geben. Ein Konsument kann das Feedback-Abonnement über eine E-Mail-Adresse oder per Weboberfläche beantragen. Dazu sollte immer ein persönlicher, stets aktueller Kontakt für administrative Belange zur Verfügung stehen, eine Kontaktadresse, an die die Meldungen gehen, sowie die potenziell unangenehm auffallenden Adressbereiche, über die der Konsument Beschwerden erhalten möchte. Hat der Anbieter die Rechtmäßigkeit des Abonnements überprüft, informiert er den Konsumenten über die Bereitstellung der FBL.

Ab diesem Zeitpunkt beginnt der Anbieter die Beschwerden direkt nach Maileingang an den Konsumenten zu versenden. Dazu hat sich das in RFC 5965 beschriebene, aus drei MIME-Abschnitten bestehende Abuse Reporting Format (ARF) durchgesetzt. Der erste Abschnitt ist ein für Menschen lesbarer Textblock, der in Worten den Vorfall kurz beschreibt und mindestens die betroffene IP-Adresse enthält. Im zweiten Abschnitt finden sich automatisiert auslesbare Schlüssel-Wert-Kombinationen, die mindestens die IP-Adresse, den Eingangszeitpunkt und den Missbrauchstyp umfassen. Der dritte und letzte Abschnitt umfasst entweder die komplette unveränderte Eingangsmail als Anhang oder aber nur den Header der Eingangsmail. Jede Beschwerde erfordert also eine eigene E-Mail, Sammelvorgänge sind nicht vorgesehen.

Ohne Ansprechpartner keine Abhilfe

Mit diesen Informationen kann eine rein manuell arbeitende Abuse-Abteilung der Beschwerde nachgehen, sie gewährleisten aber auch eine automatisierte Auswertung der Rückmeldungen. Ab einem gewissen Beschwerdeaufkommen ist eine Automatisierung mit geeigneter Analysesoftware unumgänglich. Die verifiziert zuallererst den Wahrheitsgehalt der Beschwerde und benötigt dafür Zugriff auf Mailserver-Logs und Kundeninformationen. Erst nach erfolgreichem Abgleich können statistische Verfahren greifen, die ab einem Schwellenwert weitere Maßnahmen zur Maßregelung von Kunden oder Endverbrauchern nach sich ziehen.

Beide Parteien müssen regelmäßig prüfen, ob ihre FBL funktioniert. So muss der Konsument seine Kontaktadressen stets aktuell halten und dem Anbieter Änderungen rechtzeitig mitteilen. Auf der anderen Seite hat der Anbieter zu kontrollieren, ob Beschwerden beim Konsumenten ankommen und Kontaktadressen erreichbar sind. Es steht einem Anbieter frei, die FBL abzuschalten, wenn sich zeigt, dass der Konsument die Daten missbräuchlich verwendet und nicht zur Vermeidung von weiterem Spamversand nutzt.

Ein FBL-Anbieter erwartet in der Regel drei Maßnahmen vom Konsumenten, die er in den Nutzungsbedingungen festlegen kann. Erstens darf die gleiche Art von E-Mail denselben Empfänger nicht ein weiteres Mal erreichen. Zweitens möge der Konsument die Ursache des unerwünschten Mailversands identifizieren und sie beheben. Drittens ist es nicht erforderlich, dem Anbieter eine Empfangsbestätigung, die getroffenen Maßnahmen oder Ursachen des Problems mitzuteilen, da Feedback-Loops in der Regel voll automatisiert sind.

Mit diesen Regeln in RFC 6449 sollten die beteiligten Parteien eigentlich unternehmensübergreifend und international ein Netzwerk zur Vermeidung von Spam bei großen und kleinen E-Mail- und Internet-Providern etablieren können. Leider sieht die Realität anders aus.

In Deutschland beispielsweise sind rechtliche Belange einzuhalten, die über die technische Realisierbarkeit hinausgehen. Ein Anbieter muss klären, ob er Kundenkommunikation – dazu zählt auch unerwünschte E-Mail – Dritten zur Verfügung stellen darf, eventuell mit verschleierten Mailadressen. Eine zu starke Verschleierung hindert wiederum den Konsumenten, dem Vorfall nachzugehen.

Auch ein FBL-Konsument muss rechtliche Gegebenheiten klären, ein Internet-Provider etwa, ob er auf Beschwerden hin den Internetzugang oder zumindest den Mailversand seiner Kunden sperren darf. Zumindest Provider können sich mittels entsprechender AGB-Passagen absichern.

Rechtliche Rahmenbedingungen klären

Im September 2011 gerieten die Mailserver von T-Online auf die Blacklists von Spamhaus und Spamcop, weil von geknackten Homepage-Accounts massenhaft Spam ausging und keine Gegenmaßnahmen erkennbar waren. Zu dieser Zeit hatte T-Online zwar technisch die Möglichkeit, E-Mails zu blockieren oder Zugänge ganz zu sperren, aber es fehlten die rechtlichen Voraussetzungen. Erst nach dem Ändern der Kundenverträge kann T-Online nun geeignete Maßnahmen ergreifen. Die Zahl der missbrauchten Homepage-Accounts ist bereits deutlich zurückgegangen.

Wie Feedback-Loops das Spam-Aufkommen radikal reduzieren können, zeigt NetCologne auf eindrucksvolle Weise. Der Kölner Regional-Provider kappt Kundenzugänge nach entsprechenden Beschwerden nicht komplett, sondern beschränkt sie zunächst auf ein restriktives Netzwerk, das eine Fehleranalyse und -behebung ermöglicht, etwa durch Herunterladen einer Anti-Viren-Software.

Auch in Brasilien gibt es vorbildliche – allerdings auch dringend notwendige – Anti-Spam-Maßnahmen. Locaweb Serviços de Internet S/A war noch 2010 bekannt für einen massiven Spam-Ausstoß, doch der Provider konnte das Aufkommen durch geschicktes Abuse-Management um Größenordnungen reduzieren.

Nachdem die Mail- und Zugangs-Provider jahrelang darauf bedacht waren, die Posteingänge der eigenen Kunden frei von Spam zu halten, ist es Zeit, einen Beitrag dazu zu leisten, den Posteingang anderer sauber zu halten. Die Spam-Bekämpfung an der Quelle hat gleich mehrere Vorteile für die Internet-Gemeinschaft. Zuerst reduziert sie das allgemeine Spam-Aufkommen und macht den Provider unattraktiv für weiteren Missbrauch. Zudem können E-Mail-Provider ihre eigenen Ressourcen schonen, wenn sie den Spamversand unterbinden können. Insgesamt fördert es die eigene Reputation, wenn man eine aktive Rolle im Kampf gegen Spam einnimmt.

Zurzeit sind ARF-basierte Beschwerden ausschließlich auf E-Mail-Verkehr zugeschnitten und ermöglichen es nicht, anderweitigen Netzmissbrauch zu melden. Daher hat sich unter der Leitung von abusix das X-ARF entwickelt, das auf dem Prinzip von ARF basiert, aber auch Missbrauch wie Login-Versuche, Hacking und Phishing umfasst. Auch kann es über geeignete Schemata mehr Informationen über einen Spamvorgang transportieren als ARF. Ob sich X-ARF durchsetzt und wann es den IETF-Prozess zum offiziellen RFC durchläuft, steht noch nicht fest.

Fazit

Jeder Internetanwender kann schnell einen eigenen E-Mail-Server in Betrieb nehmen und mit den bekannten Tools gegen eingehenden Spam schützen. Die eigentliche Herausforderung liegt heute im Bewältigen der ausgehenden Mails. Dazu zählen vor allem Maßnahmen wie die SMTP-Authentifizierung für Mail-Clients, das Blockieren von Port 25 für Nicht-Mailserver, Volumenbeschränkungen und dergleichen mehr. Genauso wichtig sind die Auswertung von Bounce-Nachrichten und der Logdateien zur Pflege von Adressbeständen, Newsletter-Abonnements und zur Früherkennung von Mailproblemen. Feedback-Loops erweitern die eigene Früherkennung, indem man die Erkenntnisse von Dritten zum eigenen Vorteil nutzt. Jedem Postmaster sei daher RFC 6449 ans Herz gelegt. Es bleibt nur noch die Suche nach einer Liste aller Anbieter öffentlicher FBLs.

Marcel Lohmann

ist Softwareentwickler bei der KWS SAAT AG in Einbeck und maßgeblich am iX-Projekt „NiX Spam“ beteiligt.

Alle Links: www.ix.de/ix1201097

Mehr Infos

Abuse-Reporting im großen Stil

Die Firma abusix betreibt ein weltweites Netzwerk aus Spamfallen, die Millionen Spam-Mails pro Tag empfangen. abusix sendet für jede eingehende Mail eine Beschwerde an die zuständige Stelle. Zu einer wahren Herausforderung gerät es dabei, die korrekten Beschwerde-Kontaktadressen zu der jeweiligen IP-Adresse zu ermitteln. In der Regel sollten entsprechende Adressen in den Whois-Datenbanken der Registrierungsorganisationen hinterlegt sein, aber diese Informationen sind nicht standardisiert, unvollständig und oft veraltet.

Um diesen Missstand aus der Welt zu schaffen, hat abusix die Abuse Contact Database ins Leben gerufen, die für nahezu jede IP-Adresse den korrekten Kontakt bereithält. Diese Informationen lassen sich wie eine Blacklist per DNS abfragen und bieten damit eine standardisierte Schnittstelle. Es fehlte eine Möglichkeit, die Daten dezentral zu pflegen und bereitzustellen. Daher gibt es Überlegungen bei den Regional Internet Registries, die Whois-Datenbank um Einträge zu erweitern, die den zuständigen Abuse-Kontakt enthalten. Das APNIC hat bereits Ende 2010 damit begonnen, alle neuen Adressbereiche mit diesen Informationen zu versehen und bei Aktualisierungen bestehender Bereiche diese Informationen einzufordern.

abusix nutzt die Daten aus seinen Spamfallen aber auch, um sie Dritten unter spamfeed.me zur Verfügung zu stellen. Die Daten lassen sich dafür nutzen, Spamfilter zu verbessern, die Reputation eines Provider-Netzes zu analysieren oder anderweitig zu verwerten. Abonnenten erhalten einen Datenstrom aus ARF-Reports, in dem nur die ursprünglichen Empfänger verschleiert sind.

Abuse Reports der DNSBL „NiX Spam“

Auch die Blacklist „NiX Spam“ unterhält eine automatisierte Feedback-Loop, die im Widerspruch zu RFC 6449 nicht unbedingt die Anforderung eines Konsumenten benötigt. So signalisiert das iX-Projekt jeden Spam-Eingang über IP-Adressen, die auf der internen Whitelist stehen, mit einem ARF-Bericht an den betreffenden Provider. Die passende Kontaktadresse der Abuse-Abteilung liefert abusix, falls nicht anderweitig bekannt.

Für die täglich eintreffenden Millionen E-Mails gehen „nur“ zwischen 3000 und 5000 Abuse Reports an die Provider. Da ein Großteil der Mails aus ausländischen Netzbereichen stammt, die nicht für erfolgreiches Abuse-Management bekannt sind, erübrigt sich hier die automatische Benachrichtigung. Auch für dynamische Adressbereiche ist es nur dann sinnvoll, Abuse-Meldungen zu generieren, wenn sichergestellt ist, dass der Provider schnell reagiert.

Unter den Empfängern von Abuse-Reports finden sich alle IP-Adressen von Mitgliedern, die der Certified Senders Alliance (CSA) des eco-Verbandes angehören. Einige Provider erhalten auf eigenen Wunsch Reports zu IP-Adressen, die nicht auf der Whitelist stehen, etwa die Deutsche Telekom, NetCologne und Versatel, die nun Informationen über Spam-Vorfälle in ihrem kompletten Kundennetz erhalten. Falls notwendig, reicht die Telekom Beschwerden an ihre Wiederverkäufer weiter.

Wenn auch andere Provider davon profitieren möchten, können sie sich unter support@ix-lab.de um eine Feedback-Loop bewerben.

Mehr Infos

J.D. Falk – unermüdlich gegen den Spam

J.D., mein Freund und langjähriger Kollege, war einer der ersten, mit denen ich gegen Spam zusammengearbeitet habe. Es begann im Jahr 1997, mit der Gründung der Coalition Against unsolicited Commercial Email (CAUCE).

Über die Jahre arbeitete J.D. bei vielen der wichtigsten Firmen mit E-Mail-Hintergrund, darunter Erols, Priori, Critical Path, MAPS, Yahoo, Microsoft und Return Path. Er war immer bestrebt, Industriestandards zu schaffen. Seine Arbeit mit der Internet Research Task Force (IRTF) und Internet Engineering Task Force (IETF), seine weise Vorausschau und tiefgründigen Gedanken führten zu bemerkenswerten Ergebnissen. In besonderer Weise von seiner Energie und seinem Intellekt profitierte die Message Anti-Abuse Working Group (MAAWG), wo seine Arbeit tiefgreifende Änderungen bewirkte.

Zuvorderst organisierte J.D. fast 20 MAAWG-Treffen mit links, als Ein-Mann-Veranstalter. Als wäre das nicht schon eine Meisterleistung, machte er die exponentiell wachsende Organisation zum herausragenden Anti-Abuse-Zusammenschluss. Nachdem er diese Rolle abgegeben hatte, überarbeitete er als Editor aller MAAWG-Dokumente den ständigen Fluss von Ergebnissen aus verschiedenen Komitees und Arbeitsgruppen. J.D. übernahm diese Arbeitsweise bei Return Path, Inc., wo sein bemerkenswerter Schreibstil unzählige Blog-Posts prägte – über aktuelle Themen der Anti-Abuse-Industrie und neue Verfahren. Seine Abhandlungen über DKIM sind das Beispiel schlechthin für seine besondere Fähigkeit, ein kompliziertes technisches Thema auf den Punkt zu bringen und für einen Laien verständlich zu machen.

J.D. starb 37-jährig am 16. November 2011. Die IETF beschleunigte die Veröffentlichung seines letzten RFC als eine passende Hommage an sein unermüdliches Wirken für die Internet-Gemeinschaft.

Seine Veröffentlichungen kann man nachlesen bei CircleID und bei Return Path.

Neil Schwartzman (CAUCE), aus dem Englischen übersetzt von Marcel Lohmann

(un)