Greylisting – die neue Waffe gegen Spam

Frank Richter, URZ, TU Chemnitz
<frank.richter@hrz.tu-chemnitz.de>

Vortrag zur 2. Mailserver-Konferenz in Magdeburg, 20. Mai 2005

Spam - unerwünschte, meist dubiose Massen-E-Mail - nervt Internet-Benutzer und Administratoren gleichermaßen. Bisherige Gegenstrategien, wie Blacklists oder Inhaltsanalyse konnten die Plage noch nicht wirksam eindämmen. Das "Greylisting" ist eine neue, versprechende Methode. Wirkungsweise, Risiken und Nebenwirkungen werden erläutert und mehrmonatige Erfahrungen an der TU Chemnitz ausgewertet.

Wir Postmaster sind wirklich nicht zu beneiden. Wir stecken all unsere Energie in ein System, damit wirklich jede E-Mail an den korrekten Adressaten zugestellt wird, sorgen uns um unsere Benutzer, damit diese möglichst leicht und sicher an Ihre E-Mail herankommen - und was ist das Ende vom Lied? Wir hören verzweifelte Klagen über volle Mailboxen durch unverlangten E-Mail-Müll, unsere Mail-Server ächzen unter der Last - und schließlich vermehren sich auch noch per E-Mail versandte Viren, Würmer und anderes Ungeziefer.

In unserer Not entwickeln und nutzen wir DNS-basierte Sperrlisten, installieren intelligente Inhaltsfilter und Bewertungssysteme, Virenchecker sowieso - unsere Mail-Server werden zu dicken Festungen auf wackligem Fundament. Wir schulen unsere Benutzer und hoffen auf Deckung durch Gesetze und deren wirkungsvolle Durchsetzung. Und auf jeder Fachtagung hören wir von Rechtsexperten, auf welch dünnem juristischen Eis wir uns mit unseren Mail-Filtern bewegen.

Durch zum Teil fragile Konfiguration unserer Server leidet sogar die Zuverlässigkeit, voller Bangen erwarten wir die nächste Denial-of-Service-Attacke durch Virenschleudern oder Spammer-Netze. Schon leidet die Akzeptanz unserer geliebt-gehassten "Electronic Mail". Endlich beginnen Internet-Gremien, sich dem Problem anzunehmen. Und da taucht ein neues, so unglaublich einfaches Verfahren zur Eindämmung unserer E-Mail-Plagen auf: Greylisting - der neue Strohhalm?

Greylisting - das Prinzip

Das Ziel von Spam-Versendern besteht darin, in kurzer Zeit möglichst unerkannt und ohne großen Aufwand Nachrichten an eine Vielzahl von Empfängern zu schicken. Reguläre Mail-Server dagegen wollen E-Mails sicher zustellen, und scheuen für diese Ziel keinen Aufwand (Queues, Retry-Mechanismen). Diesen feinen Unterschied bemerkte Evan Harris und entwickelte daraus 2003 ein Verfahren, das er "Greylisting" nannte [1].

1. die IP-Adresse des Sende-Rechners
2. die Envelope-Absender-Adresse
3. die Envelope-Empfänger-Adresse(n)

Diese drei Daten werden als Tripel mit einem Zeitstempel abgespeichert. Bei mehreren Empfängern werden jeweils einzelne Tripel gespeichert.

Ist dem empfangenden Mail-Server dieses Tripel unbekannt ("schwarz"), wird die Annahme der E-Mail für eine Weile mit temporärem Fehler abgewiesen. Ist das Tripel von einem vorangegangenen Zustellversuch ("grau") oder einer bereits erfolgreichen Zustellung ("weiß") schon bekannt, wird die E-Mail wie gewohnt angenommen. Dazu wird das Tripel in der Datenbasis mit langer Gültigkeit versehen ("weiß"), so dass ein weiterer E-Mail-Austausch ohne Verzögerung stattfinden kann.

Bild: Beispiel eines SMTP-Dialogs mit Greylisting

• Reguläre und dem Standard RFC 2821 entsprechende Mail-Server werden nach einen temporärem Fehler 451 die Übertragung erneut versuchen. Die Zeitspanne bis dahin ist nicht standardisiert, liegt aber i.a. zwischen 15 und 30 Minuten. Es kommt also bei einer ersten Übertragung zu einer gewissen Verzögerung und Belastung für den Sende-Server.
• Spam-Versender funktionieren in den meisten Fällen nach der "Fire-and-Forget-Methode" - ein doch recht aufwändiges Wiederholen nach einen temporärem Fehler passiert nicht. D.h. nach dem initialen, vom Empfangs-Server abgewiesenen Zustellversuch erfolgt mit hoher Wahrscheinlichkeit kein weiterer Versuch - wir empfangen die Spam-Mail nicht.
• Das in heutigen E-Mail-Würmern eingebaute SMTP-Handling funktioniert nach ähnlich einfachen Verfahren - mit temporärem Fehler wird nicht umgegangen. Deshalb funktioniert Greylisting auch wirksam bei der Abwehr von E-Mail-Würmern!
• Bei unbekanntem Tripel verweigert der Empfänger-Server nur mit einem temporärem (4XX), nicht mit einem permanten (5XX) Fehler. Und das sogar bandbreitenschonend bevor die eigentliche E-Mail übertragen wird. Solange sich reguläre Sender an den Standard halten, werden wir niemals eine E-Mail abweisen - keine fälschlicherweise abgewiesenen "guten" Nachrichten!
• Greylisting findet auf SMTP-Level statt, muss also vom Betreiber des Mail-Servers eingerichtet werden. Für einen Benutzer ist Greylisting weitestgehend transparent, er hat mit dem Mail-Programm keine Einflussmöglichkeit.

Datenbasis und Parameter

Initiale Wartezeit bei unbekanntem Tripel ("schwarz"):

So lange soll der Empfang einer E-Mail mit bislang unbekannten Partnern noch unterdrückt werden, d.h. die initiale Wartezeit wird mindestens so lang sein. In [1] wird 1 Stunde empfohlen, an der TU Chemnitz verwenden wir moderatere 15 Minuten.

Gültigkeit eines Tripels ("grau") ohne Mailaustausch:

So lange wird der Zustellversuch in der Datenbank gehalten, d.h. der Sender hat eine gewisse Zeit, den Zustellversuch zu wiederholen. [1] schlägt 4 Stunden vor, wir geben kulanterwiese 2 Tage Zeit.

Gültigkeit eines Tripels ("weiß") mit erfolgtem Mailaustausch:

Wenn in dieser Zeitspanne weitere E-Mails mit den Tripel-Daten eintreffen, werden sie ohne Verzögerung angenommen. In [1] wird diese Zeit auf 36 Tage gesetzt.

Eine Diskussion mit Abwägung von Vor- und Nachteilen dieser Parameter ist in [1] zu finden.

• Lokale Rechner des eigenen Netzes und authentisierte Absender sollten vom Greylisting ausgenommen werden.
• Wenn ein externer Mail-Server regen E-Mail-Verkehr mit unseren Servern hat (es also viele "weiße" Tripel mit seiner IP-Adresse gibt), kann davon ausgegangen werden, dass es ein regulärer Mail-Server ist, den ich dann von der Wartezeit befreien kann. Durch ein solches automatisches Whitelisting werden die Mail-Server von Providern oder E-Mail-Anbietern (wie GMX, Web.de, T-Online ...) nach kurzer Zeit freigeschaltet. Weil auf diesem Wege auch "hartnäckige" Spam-Sender auf die Whitelist kommen können, muss über eine Säuberungsstrategie nachgedacht werden (z.B. durch regelmäßigen Abgleich mit einer DNS-basierte Blacklist).
• Natürlich kann der Mail-Administrator eine solche Whitelist auch selber pflegen, um z.B. Server/Domains der Geschäftspartner vom Greylisting auszunehmen. Oder andersherum: Nur "verdächtige" IP-Adressbereiche müssen durch Greylisting ...
• Sende-Server, die sich nicht RFC-konform verhalten, mit denen wir aber E-Mail-Austausch haben müssen, sollten auch auf der Ausnahme-Liste stehen. Das trifft auch für bestimmte Absenderadressen zu, z.B. für Mailing-Listen-Server, die bei jedem Versuch eine andere Absende-Adresse verwenden.
• Die eigenen Mail-Server merken sich die Sender-Empfänger-Beziehungen schon bei aus unserer Domain ausgehender E-Mail. Kommt dann eine E-Mail mit vertauschten Absender/Empfänger-Adressen "rein", nehmen wir die ohne Wartezeit an - das ist dann mit hoher Wahrscheinlichkeit eine Antwort.
• Den Parameter für die initiale Wartezeit kann man vielleicht auch variabel gestalten, kurz für bekannte und sehr lang für "verdächtige" IP-Adressbereiche (die z.B. auf einer strengen DNS-basierten Blacklist stehen).

Die zu speichernden Datensätze enthalten also implementationsabhängig neben den eingangs beschriebenen Tripeln (IP-Adresse, Absende-Adresse, Empfänger-Adresse) noch weitere Daten, wie Zeitpunkt des ersten Zustellversuches, Gültigkeit bei erfolgreicher Zustellung, Sperrzeiten usw.

Zur Speicherung dieser Datensätze bietet sich natürlich ein Datenbank-System an. Unbedingt zu beachten ist, dass dieses System von allen MX-Servern benutzt wird, weil sich sonst die Zustellverzögerung u.U. addieren kann. Diese Datenbank ist natürlich dann ein "single point-of-failure" und ist deshalb möglichst robust auszulegen.

Es ist ohnehin sehr ratsam, dass sich alle für eine Domain zuständigen MX-Server (auch sog. "Fallback-Server") an eine einheitliche Spam-Policy halten. Viele Spam-Versender benutzen nämlich gerade die MX-Server mit geringer Priorität (also hoher Preference), in der Hoffnung, dass diese weniger "streng" konfiguriert sind.

Ein Einwand zu Greylisting ist die Vermutung, dass sich die Spammer anpassen und Gegenstrategien entwickeln werden. Das ist sicher möglich, steht aber gegen deren Ziele - die Spammer müssten einigen Aufwand betreiben und dazu noch die gleiche IP-Adresse behalten, um nach der initialen Wartzeit erneut zu senden. Bei infizierten PCs, die als "Spamschleudern" missbraucht werden und via DSL angebunden sind, ist dies durchaus denkbar. Während der initialen Wartezeit können diese Sender jedoch identifiziert werden, so dass andere Spamschutz-Verfahren wirken, z.B. DNS-basierte Blacklists. Große Mail-Server mit hohem Mail-Aufkommen könnten die Greylisting-Datenbasis benutzen, um solche Spam-Attacken zu erkennen und die Verursacher bei den Blacklists zu melden.

Greylisting zum Einsatz bringen

Greylisting muss in den Mail-Servern zum Einsatz kommen, die für eine Domain die E-Mails aus dem Internet entgegennehmen. Es gibt inzwischen viele freie und kommerzielle Implementationen für eine Vielzahl von Mail-Servern. Eine Übersicht enthält [2]. Man sucht sich eine für seine konkrete Umgebung passende heraus und testet die. Für unsere mit Exim betriebenen Mail-Server haben wir uns für die Implementation von Alun Jones, University of Wales, Aberystwyth [3] entschieden. Diese ist in Perl geschrieben, nutzt eine MySQL-Datenbank, ist modular und übersichtlich aufgebaut und stellte sich als sehr robust heraus.

Vor dem Einsatz sollte man versuchen, die Anforderungen an die Datenbank abzuschätzen. Pro eintreffender Mail ist mindestens eine Datenbank-Operation erforderlich. Durch Analyse der Mail-Server-Logfiles kann man auch den Speicherbedarf der Datenbank veranschlagen.

Wir nutzten die Installation zunächst einige Wochen im "Trockentest": Das Greylisting-Modul schreibt schon die Datensätze, der Mail-Server lehnt aber noch keine Annahme temporär ab. Somit füllt sich die Datenbank, man kann die Anforderungen realistisch einschätzen und bereits einige interessante Auswertungen vornehmen. Allerdings lässt sich die Wirksamkeit als Schutz nur schwer beurteilen. Diese bereits mit einigem Wissen über E-Mail-Beziehungen gefüllte Datenbank kann man natürlich benutzen, um eine besonders "weiche Einführung" des Greylisting zu erreichen - regelmäßige Kontakte werden ohne initiale Wartezeit auskommen und somit gar nichts bemerken. Da die Datenbank jedoch auch durch die "Spam-Beziehungen" verschmutzt ist, ist es doch eher ratsam, das Greylisting mit einer leeren Datenbank zu aktivieren. Vor den heißen Start sollte man natürlich die Ausnahmen vom Greylisting in einer manuellen Whitelist definieren.

Erfahrungen an der TU Chemnitz

Greylisting fügt sich in die bereits existierenden Anti-Spam-Maßnahmen ein (siehe [4]). Diese Methoden können von jedem unserer ca. 15.000 Benutzer einfach über ein Web-Formular ein- oder ausgeschaltet werden:

Neu eingerichtete E-Mail-Benutzer erhalten eine Voreinstellung und eine Information darüber. Mit dieser individuellen Einstellmöglichkeit glauben wir, juristische Probleme zu vermeiden. Erfahrene Benutzer können individuell anhand von Header-Zeilen filtern - für Greylisting funktioniert dies natürlich nicht. Darüberhinaus kann sich jeder Benutzer via WWW einen Überblick über gesendete, empfangene, abgewiesene oder durch Greylisting verzögerte Nachrichten verschaffen - quasi ein "Einzelverbindungsnachweis" für E-Mail.

Mit der Einführung von Greylisting Ende April 2004 verringerte sich das Spam-Aufkommen in den Mailboxen unserer Benutzer deutlich. Das führte sogar zu irritierten Anrufen der Art "Ist da was faul, ich bekomme so wenige Mails!". Bei genauerem Hinsehen "vermissten" diese Benutzer ihren täglichen Spam ... Natürlich wurden auch die anfänglichen Verzögerungen bemerkt, die sich durch das automatische Whitelisting entschärften. Unsere folgende "Greylisting-Statistik" zeigt deutlich diesen Anfangsverlauf bis zu einem "eingeschwungenen Zustand":

Bild: Tagesstatistik für Greylisting

Recht bald bemerkten wir den schönen Effekt, dass Greylisting auch gegen die Verbreitung von Mail-Würmern wirkt. So wurden unsere Virenchecker am Mail-Relay entlastet, da weniger E-Mails mit gefährlichen Inhalten unsere Server erreichen.

Der wenige trotzdem noch "durchkommender" Spam ist nun wieder gezielter behandelbar. So haben wir für unseren Spamschutz "Textanalyse" (wegen der großen Menge vorher ausgeschaltete) aufwändigere Optionen für SpamAssassin eingeschaltet (z.B. Abfrage von URL-Blacklists), was diesen Schutzfilter verbessert.

Mit folgenden Probleme hatten oder haben wir zu kämpfen:

• Sehr bald stellen sich "untaugliche" Sende-Server heraus, die das Senden nach temporärem Fehler nicht oder in unangemessenen Zeitabständen wiederholen. Diese Sende-Server pflegen wir in einer manuellen Whitelist. Eine solche Liste ist unter [5] erhältlich.
• Für zeitkritische Anwendungen, z.B. ein "Börsenspiel" per E-Mail, ist die initiale Wartezeit zu lang. Solange dies nur wenige Benutzer betrifft, sollten diese in der entsprechenden Zeit individuell den jeweiligen Spamschutz abstellen.
• Einige unsere Benutzer haben Mail-Adressen bei anderen Anbietern und lassen sich dort eintreffende E-Mails an die TU-Adresse weiterleiten. In diesem Falle hilft Greylisting nicht - die Mail-Server dieser Anbieter versenden E-Mails zuverlässig oder stehen meist schon auf der automatischen Whitelist. Hier müssen die Spamfilter der Anbieter benutzt werden. Auf unserer Seite ist hier nur der Spamschutz "Textanalyse" (SpamAssassin) wirksam.

Grundsätzlich sind die Erfahrungen mit Greylisting so positiv, dass wir den Einsatz empfehlen können. Die Beschwerden der Benutzer gehen deutlich zurück, und das Mail-Aufkommen sinkt (anfangs fast erschreckend) - Mail-Administratoren und -Server atmen auf!

Bild: Rückgang der eingehenden E-Mail nach Einführung von Greylisting

• Wir bemerken eine gewisse "Verschmutzung" der Greylisting-Datenbasis. So gelangen z.B. reguläre Mail-Server mit DSL-Zugang in die automatische Whitelist. Zu einer anderen Zeit kann sich hinter der "DSL-IP-Adresse" jedoch ein Spamversender befinden - er hat dann freien Zugang ... Hier hilft das regelmäßige Prüfen der Einträge gegen strengere DNS-basierte Blacklists, z.B. bl.spamcop.net.
• Gegen spammerfreundliche Provider hilft Greylisting nicht.
• Diverse Sicherheitsfirmen sagen neue Spam-Attacken voraus: Infizierte PCs werden die Massenversendung nicht mehr direkt an unsere Server senden (da wirkt Greylisting), sondern werden die regulären Mail-Server der Provider verwenden - Greylisting ist hier chancenlos.

1. statische Blacklists, typische Muster in HELO, Gültigkeit der Empfängeradresse
2. zuverlässige DNS-basierte Blacklists
3. Greylisting
4. Textanalyse, Viren-Check

Bild: Auswirkungen verschiedener Spamschutz-Maßnahmen:

1. Verschärfte HELO-Tests 2. Greylisting 3. Neue DNSBL sbl-xbl.spamhaus.org 4. Erweiterter Empfänger-Test 5. Neue SpamAssassin-Version 3.0.X

• Installieren Sie regelmäßig Upgrades der eingesetzten Software oder Datenbasen.
• Studieren Sie Ihre Server-Logfiles, sie bieten manche Überraschung.
• Suchen und pflegen Sie Kontakt zu Kollegen, verfolgen Sie aktuelle Entwicklungen, z.B. bei der Anti-Spam Research Group [6] oder zu SPF / Sender ID [7].

Weitere Informationen

[1] The Next Step in the Spam Control War: Greylisting by Evan Harris
     [http://projects.puremagic.com/greylisting/]

[2] Links to Implementations and Information [http://projects.puremagic.com/greylisting/links.html]

[3] Spam tools by Alun Jones, University of Wales, Aberystwyth [http://users.aber.ac.uk/auj/spam/]

[4] Automatische Schutzfilter für E-Mails an der TU Chemnitz
     [http://www.tu-chemnitz.de/urz/mail/filter/]

[5] Greylisting.Org: Whitelisting [http://greylisting.org/whitelisting.shtml]

[6] ASRG - Anti-Spam Research Group [http://asrg.sp.am/]

[7] SPF - Sender Policy Framework [http://spf.pobox.com/]