Seit Spammer immun gegen das einstige Wundermittel Greylisting sind, suchen Mailadmins nach neuen Wirkstoffen, um die Dreckschleudern bereits vor der Mailzustellung zu bekämpfen. Das Linux-Magazin stellt zwei neue Techniken vor, die Spammer geduldig in die Flucht treiben.

Rund 90 Prozent aller E-Mails sind unerwünscht. Spamfilter versuchen diese Flut einzudämmen. Sie arbeiten allerdings ungenau und in einer juristischen Grauzone, da sie bereits zugestellten Müll mühsam sortieren. Viel cleverer ist es, Spammer bereits am Einliefern zu hindern. Lange Zeit galt Greylisting [1] als mögliche Lösung, es nutzt typische Verhaltensmuster der Spammer im SMTP-Verkehr. Leider hat Greylisting heftige Nebenwirkungen und ist inzwischen wirkungslos, da sich die Müllverteiler angepasst haben.

Das macht neue Verfahren nötig, die Spammer beim Versenden empfindlich stören, jedoch juristisch und technisch unbedenklich arbeiten. Die zweite Hälfte dieses Artikels stellt eine solche Technik vor, die bis zu 80 Prozent des Mülls von den eigenen Server fernhält. Die erste Hälfte widmet sich dem Verifizieren und Sammeln von Adressen (siehe Kasten “Adressenquellen”) und greift damit noch einen Schritt früher. E-Mail-Anschriften zu prüfen lohnt sich für Mailschleudern, weil viele Adressen nur kurze Zeit gelten.

Beispielsweise verfällt zum Ende des Studiums die E-Mail-Adresse an der Hochschule, mit den neuen Bachelor-Studiengängen schon nach drei Jahren. Ähnliches gilt in der Berufswelt. Wer den Job wechselt, verliert seine E-Mail-Adresse, das passiert im Schnitt alle vier bis fünf Jahre. Auch die Lebensdauer privater Adressen ist endlich, zum Beispiel weil viele User ihren Account deaktivieren, wenn zu viel Spam eintrifft oder weil ihre Webmail-Adresse während eines längeren Urlaubs verfällt [7]. Pro Jahr werden daher geschätzte 20 bis 30 Prozent der E-Mail-Adressen, die ein Spammer gesammelt hat, ungültig.

Kostenfalle

Je schneller Spammer ihre Werbung verbreiten und je weniger falsche Adressen sie beliefern, umso besser für sie. Das spart Kosten und verschafft ihnen im Wettlauf mit den Spamfiltern einen Zeitvorteil. Sie profitieren daher von E-Mail-Verifikatoren. Diese meist kostenlosen Tools verbinden sich zu dem SMTP-Server (Abbildung 1), der für die Empfängerdomain zuständigen ist, und senden jede zu testende Adresse als Envelope-To. Der Server reagiert in der Regel sofort mit einer Fehlermeldung, falls eine Adresse nicht existiert.

Abbildung 1: Im normalen E-Mail-Verkehr begrüßen sich Server und Client zunächst («Greeting» und «HELO»), danach teilt der Client die Envelope-From- und die To-Adressen mit. Sind diese gültig, antwortet der Server mit «250 Accepted» und der Client schickt den Mailinhalt.

Statt nur bekannte Adressen zu verifizieren, raten Spammer auch. Zum Beispiel mit Hilfe einer Telefonbuch-CD, aus der sie alle Kombinationen aus Vor- und Nachname gegen die großen Provider laufen lassen. Dagegen könnte helfen, sich eine kryptische Adresse zu wählen. Allerdings behindert das die Kommunikation sehr. Günstiger wäre es, automatische Tests zu erschweren.

Wie das geht, ist hinlänglich bekannt – nach einer festen Zahl von Fehlversuchen den Dienst einstellen. Wer je am Geldautomaten dreimal die falsche PIN eingegeben hat, kennt aber auch die lästigen Nebenwirkungen. Auf Rechner übertragen hieße es, die IP des Testers auf eine schwarze Liste zu setzen und künftig jeden Verbindungsversuch von dort zu blockieren. Dumm nur, dass auch seriöse Versender gelegentlich falsche oder veraltete Adressen erwischen.

Zeitstrafe

Vom Login an einem Rechner bekannt ist die Idee, die Ausgabe der Fehlermeldung mit jeder falschen Eingabe mehr zu verzögern. Das bremst einen Brute-Force-Angriff erheblich und macht ihn unattraktiv: Brute Force heißt wenig Hirn, aber viele Versuche. Deren Schnelligkeit hängt primär von der Netzwerkbandbreite ab. Auf dem lokalen Rechner gelingt es, 25 000 Adressen pro Minute zu verifizieren. Das muss jedoch nicht sein (siehe Abbildung 2).

Abbildung 2: Statt jede Antwort sofort zu liefern, kann sich ein Spam-geplagter Empfänger Zeit lassen und so das Verifizieren von Mailadressen erschweren. Wie langsam er reagiert, hängt vom Verhältnis falscher zu korrekten Adressen ab.

Doch auch hier gilt es, seriöse Versender von Massenmails zu schützen. Ein näher untersuchter Newsletter eines DAX30-Unternehmens, das noch nicht durch Spamming aufgefallen ist, kommt im Mittel pro monatlicher Aussendung auf drei bis vier Prozent falsche Zieladressen [3]. Meist hat der Empfänger seinen Account terminiert, ohne den Newsletter abzumelden. Besagter Newsletter hat bei den neun meistgenutzten Providern 1,4 Millionen Empfänger, das sind 40 Prozent seines Gesamtvolumens.

Der am häufigsten genutzte Provider allein ist für 323 000 Empfänger zuständig. Da sind vier Prozent falsche schon 12 920 Adressaten. Jede Fehlermeldung um eine Sekunde verzögert auszugeben, würde die Versandzeit allein bei diesem Provider um 3,5 Stunden verlängern.

Dazu kommt, dass es unsinnig wäre, nur bei falschen Adressen eine Verzögerung einzubauen. Dann könnten Spammer durch simple Zeitmessungen vorhersagen, ob eine Adresse gültig ist oder nicht. Im Beispiel würde sich die Versandzeit auf stolze 3,75 Tage verlängern, wenn der Provider jede Einlieferung (egal ob gültig oder nicht) um eine Sekunde verzögerte. Das ist nicht zumutbar und schädigt den Falschen.

Sendmail

Solche simplen Zeitstrafen hat der Mailserver Sendmail längst integriert. Die Konfiguration »define(`confMAX_RCPTS_PER_MESSAGE’,100)dnl« verhindert, dass der Absender seine Mail in einer Anweisung an mehr als 100 Empfänger gleichzeitig schickt, und die Einstellung »define(`confBAD_RCPT_THROTTLE’,3)dnl« teilt dem Server mit, nach dem dritten ungültigen Empfänger jede Antwort mit einer Zeitverzögerung von einer Sekunde auszugeben.

Angemessene Strafe

Statt stur eine feste Zeitstrafe zu vergeben, sollte lieber das Verhältnis aus gültigen und ungültigen Empfängern die Wartezeit beeinflussen. Denn Spammer erreichen bei Brute-Force-Angriffen Fehlerraten nahe 100 Prozent, während seriöse Versender den einstelligen Prozentbereich kaum verlassen.

Da Sendmail für die erstgenannte Option sowieso die Gesamtzahl der Empfänger zählt und für die zweite die Zahl der ungültigen Adressen, lässt sich das Verhältnis leicht ermitteln. Ein einzeiliges Patch für die Datei »srvsmtp.c«, in Sendmail 8.14.2 an Zeile 2548, ist die Lösung und ersetzt den bisher an dieser Stelle stehenden »sleep(1)«-Aufruf:

(void) usleep((int) 500000*((smtp.sm_nrcpts!=0) ? (n_badrcpts*2/smtp.sm_nrcpts) : 1));

Der ternäre Operator »?:« ersetzt eine Fallunterscheidung mit If-then-else, die eine Division durch null verhindert. Im schlimmsten Fall sendet der Spammer nämlich bereits als ersten Datensatz eine ungültige Mailadresse, dann bleibt »smtp_sm_nrcpts« bei null. Über den Einzeiler hinaus wäre es noch möglich, die Grundstrafzeit als Einstellmöglichkeit in »sendmail.mc« vorzusehen.

In der Grundform könnten Spammer den Schutz noch relativ leicht umgehen. Dauern die Serverantworten zu lange, brechen sie die Verbindung ab und öffnen sofort eine neue, um die Zähler zurückzusetzen. Die Attraktivität des Disconnect lässt sich aber leicht durch eine Verzögerung beim Verbindungsaufbau schmälern. Sendmail kennt dazu die »SMTP_GREET_TIME«.

Wirkung unklar

Leider lässt sich die Effizienz dieses Verfahrens kaum testen. Es erinnert an die Idee der Firma IKU [8], bei Spamverdacht sogar gültige Adressen mit »User unknown« zu quittieren, um diese Anschriften aus den Datenbanken der Spammer zu löschen. Bei einem Test im Linux-Magazin ließ sich der Effekt leider nicht nachweisen [9]. Noch schwieriger ist es, die Folgen einer verhinderten Verifikation zu bewerten. Dennoch komplettiert das hier vorgestellte Verfahren die Bemühungen, Spammern das Sammeln von E-Mail-Adressen zu vermiesen.

Da kaum zu erwarten ist, dass jemals eine Maßnahme Spam komplett aus der Welt verbannt, gehören Spamfilter auch in Zukunft zum Repertoire online kommunizierender Menschen. Die juristische Lage macht es den Providern schwer, diese Aufgabe zu übernehmen (siehe Kasten “Recht auf Spam”). Sie dürfen eine Mail nicht einfach unterdrücken.

Greylisting

Greylisting erschien vielen Mailserver- Admins als Ausweg aus der Misere ([1] und Abbildung 3). Mit dieser Technik verweigert ein Server bei unbekannten Quellen die Annahme und gibt sich erst beim zweiten Anlauf des Absenders aufnahmebereit. Die Idee: Während vollwertige Mailserver unbeeindruckt von dem vermeintlichen Ausfall des Empfängers ihre Mail nach kurzer Zeit erneut ausliefern, verzichten die Spammer auf solchen Luxus und geben sofort auf. Das funktionierte einige Jahre lang prima, Greylisting hielt bis zu 80 Prozent des Werbemülls fern.

Abbildung 3: Beim Greylisting reagiert der Server erst auf den zweiten Versuch eines SMTP-Clients, Mail einzuliefern. Damit kommen nur Clients durch, die eine Mailqueue implementieren. Bei jedem vollwertigen Mailserver gehört sie zur Standardausstattung. Spammer hatten jedoch aus Performancegründen lange Zeit darauf verzichtet. Heute greift der Trick kaum noch.

Mitte 2006 berichtete Charly Kühnast im Linux-Magazin, dass sein Greylister geknackt wurde und die Erkennungsrate deutlich gesunken sei [13]. Selbst [Greylisting.org] gibt zu, dass das Verfahren überholt ist, allerdings verschaffe es den Administratoren eine Gnadenfrist, um ihre Filter auf jede neue Spamwelle einzustellen. Die Kosten dafür trägt aber der Falsche: Weil sie mehr Versuche brauchen, um auch legitime Mail auszuliefern, müssen viele Provider ihre Systeme aufrüsten.

Teergruben

Die Idee, Spamschleudern bereits im SMTP-Verkehr auszubremsen, hat dennoch Charme. Das Ziel verfolgen auch SMTP-Teergruben, also speziell präparierte Server, die sehr langsam und wortreich auf eingehende Anfragen antworten. Das lässt sich mit den SMTP-Fortsetzungszeilen gut erreichen. Eigentlich sind sie dazu gedacht, die Antwort eines Servers näher zu erklären, doch kann man sie auch missbrauchen, um überflüssige Informationen zu senden.

Stottert die Antwort gemächlich Byte für Byte mit kurzen Denkpausen durch die Leitung, verschwendet der Empfänger absichtlich die Zeit des Absenders. Allerdings gehören die meisten Teergruben zu Antispammern, die sie auf speziellen Domains einrichtet, deren E-Mails sie eh nicht lesen. Das wissen auch die unter Zeitdruck stehenden Spammer, die kurzerhand die Verbindung abbrechen, wenn sie meinen, in einer Teergrube gelandet zu sein.

So tun als ob

Damit liegt die Idee nahe: Verhielte sich ein Mailserver wie eine SMTP-Teergrube, würden die Spammer schnell das Weite suchen (Abbildung 4). Seriöse Versender haben mit einer langsamen Leitung kaum ein Problem. Um dies zu testen, entwickelte der Autor dieses Artikels einen kleinen Perl-Proxy, der eingehende SMTP-Verbindungen annimmt, eine frei wählbare Anzahl Bytes der Serverantwort verzögert und danach alles mit voller Geschwindigkeit durchleitet.

Abbildung 4: Der stotternde Mailserver verhält sich zunächst wie eine SMTP-Teergrube. Spammer wollen nicht in die Falle tappen und brechen die Verbindung ab. Doch nach einigen Dutzend Bytes verhält sich der Server wieder normal – wer so lange durchgehalten hat, kann nun ungebremst einliefern.

Der Test zeigte: Je nachdem, wie viele Antwort-Bytes der Proxy stottert, flüchten zwischen 40 und 80 Prozent der Spammer frühzeitig. Optimal, also mit 80-Prozent-Quote, erwiesen sich Werte ab 90 oder 120 Byte. Längeres Stottern brachte keine Verbesserung.

Die mutmaßliche Erklärung: Sendmail beispielsweise bietet das Feature SMTP-Greet-Pause [14]. Damit verzögert der Server die Ausgabe der Begrüßungszeile um eine einstellbare Sekundenzahl. Schickt der Client in dieser Besinnungszeit schon Daten, schaltet Sendmail in den Null-Server-Modus, in dem er jedes Kommando mit einer Fehlermeldung quittiert. Spammer scheinen die Erziehungsmaßnahme verstanden zu haben und warten die erste Zeile ab. Die hat zwischen 60 und 70 Byte.

Doch ein Proxy hat Nachteile. Da er die eingehende Verbindung annimmt und sich zum Server mit seiner eigenen IP hin verbindet, kann der Server nicht mehr nach der IP des Versenders filtern. Unter Umständen verwandelt das den lokalen Mailserver sogar zum Open Relay, schließlich kommen alle Verbindungen vom selben Rechner.

Patchwork

Daher wuchs die Idee, statt einen Proxy einzusetzen gleich den Mailserver anzupassen. Dank Open Source kein Problem. Wer je die Konfigurationsdateien von Sendmail gesehen hat, wird zwar zweifeln, ob der Quellcode überhaupt verständlich ist. So jedenfalls ging es dem Autor. Doch Sendmail ist besser als sein Ruf, der Quelltext lässt sich von oben nach unten lesen, die Zustände des Mailservers erschließen sich spontan. Für Verwirrung sorgte nur der Ort für die Routinen, die Daten zum Client senden: Sie verstecken sich in »err.c«.

Da der Server nicht ewig stottern, sondern nur die ersten paar Bytes verzögern soll, ist eine neue Variable nötig, die die verlangsamt geschickten Bytes zählt:

long stutter_bytes_sent = 0;

Die Versendefunktion erhält ihre Daten häppchenweise, daher würde sie eine gewöhnliche automatische Variable bei jedem Aufruf zurücksetzen und unendlich stottern. Der Autor hat die Variable kurzerhand bei den globalen Funktionsprototypen deklariert – eine statische Deklaration innerhalb der Funktion sollte aber auch genügen.

Sendepause

Weiter unten in »err.c« folgt die Funktion »putoutmsg()«, die die Daten überträgt. Für die Ausgabe bedient sie sich ab Zeile 622 bei der Funktion »sm_io_fprintf()« (die Zeilennummer gilt für Sendmail 8.14.2). Hier ist eine Fallunterscheidung gefordert: genug gestottert oder den Spammer noch etwas hinhalten?

Im zweiten Fall muss Sendmail den übergebenen Buffer verzögert ausgeben. Das erledigt ein Patch, das in Listing 1 zu sehen ist. Ab Zeile 6 legt eine For-Schleife nach jedem übertragenen Byte eine kurze Pause ein. Sie nutzt dazu in Zeile 13 einen »usleep()«-Aufruf.

Hat es ausgestottert, prüft das Patch, ob schon alles übertragen wurde, also ob der Puffer kleiner oder gleich der maximalen Zahl von Stotterbytes ist (Zeile 15). Wenn nicht, schickt das Patch den Rest ungebremst durch die Leitung (Zeile 17). Der Code in Listing 1 ersetzt die Originalzeilen 622 bis 627.

Das Beispiel nutzt allerdings die Funktion »usleep()«. Die ist gefährlich, wenn das Programm länger als eine Sekunde ruhen soll. Einige Implementationen steigen bei 1 000 000 Mikrosekunden aus und verzögern eventuell gar nicht mehr. Dagegen hilft folgender Code:

void my_usleep(unsigned long msec) {
    div_t sec;
    sec = div (msec, 1000000);
    sleep (sec.quot);
    usleep (sec.rem);
}

Die Funktion ruft zunächst »sleep()« mit dem Ergebnis einer Ganzzahldivision der Schlafenszeit durch 1 000 000 auf und anschließend »usleep()« mit dem Rest der Division.

01 if (!DisConnected && (OpMode==MD_SMTP || OpMode==MD_DAEMON || OpMode==MD_ARPAFTP)) {
02     if (stutter_bytes_send <= TarpitSimBytes) {
03         // Weiter stottern
04         int stutter = 0;
05         int len = strlen(msg);
06         for (stutter=0;
07             ((stutter<len) && (stutter_bytes_sent<=TarpitSimBytes));
08             stutter++, stutter_bytes_sent++)
09         {
10             // Stottern bis der Puffer leer oder die Stottergrenze erreicht ist
11             sm_io_fprintf(OutChannel, SM_TIME_DEFAULT, "%c", msg[stutter]);
12             (void) sm_io_flush(OutChannel, SM_TIME_DEFAULT);
13             usleep(TarpitSimDelay);
14         } // end while
15         if (stutter < len) {
16             // Noch was uebrig? Raus damit.
17             memmove(&msg[0], &msg[stutter], len - stutter);
18         }
19         len -= stutter;
20         msg[len]='

Konfiguration

Das Patch nimmt an, dass in der globalen Variablen »TarpitSimBytes« steht, wie lange Sendmail stottern soll. Denkbar wäre, den Wert per »sendmail.mc« festzulegen oder ihn zufällig zu erzeugen. Zweiteres sollte nach dem Fork des jeweiligen Child-Prozesses erfolgen, weil der für je eine Verbindung zuständig ist. Pragmatisch realisieren lässt sich das, indem »err.c« diese Integer-Variable mit dem Wert -1 initialisiert und die Ausgabefunktion prüft, ob »TarpitSimBytes« noch -1 enthält. In diesem Fall sollte sie ihr einen Zufallswert zwischen 90 und zum Beispiel 200 zuweisen.

Der klare Vorteil der zufälligen Wartezeit ist: Spammer wissen nicht, wann das Gestottere endlich endet, sie können sich also nicht so leicht auf die neue Situation einstellen und echte Teergruben von Simulaten zu trennen. Wer lieber klare Verhältnisse schafft, kann in der »sendmail.mc« eine entsprechende Konfigurationsanweisung vorsehen. Dazu ist noch etwas mehr Patchwork nötig.

Ordnungsliebe

Zunächst muss der M4-Makroprozessor lernen, wie der Befehl heißt. Dazu in »cf/m4/proto.m4« eine Zeile einfügen:

OPTION(TarpitSimBytes, `confTARPIT_SIM_BYTES', `0')

Um die Option auch nutzen zu können, ist es nötig, die Zahl der Stotterbytes global für Sendmail zu definieren. Die hierfür passende Stelle ist »sendmail.h«, auch diese Datei wächst um eine Zeile:

EXTERN int TarpitSimBytes;

Jetzt muss Sendmail noch lernen, wie es »TarpitSimBytes« den Wert aus der »sendmail.cf« zuweist. Das erledigt in »readcf.c« ein länglicher Case-Block, der drei weitere Zeilen erhält:

case O_TARPITSIMBYTES:
TarpitSimBytes = atoi(val);
break;

Schlussendlich fehlen noch verbindende Informationen, die sagen, welcher Eintrag zu welcher Variablen gehört:

#define O_TARPITSIMBYTES 0xe0
  {"TarpitSimBytes", O_TARPITSIMBYTES,
  OI_SAFE},

Diese Zeilen gehören zu einem weiteren länglichen Block in »readcf.c«, der kompakt C-Präprozessor-Defines und die Initialisierung eines Array mischt.

Auch die Wartezeit zwischen den Bytes könnte fest konfiguriert oder zufällig gewählt sein oder individuell für jedes Byte. Ersteres wäre analog zu »TarpitSimBytes« zu implementieren. Für die zufällige Wahl spricht, dass Spammer sie nicht vorhersagen können. Mindestens eine halbe Sekunden pro Byte sollt es aber schon sein. Zu lange darf die Pause nicht werden, um anständige Versender nicht an einen Netzwerkausfall glauben zu lassen. In der Praxis haben sich 1,5 Sekunden als oberes Limit bewährt.

Um das Verfahren zu testen, hat der Autor zwei stark bespammte Domains auf den Teergruben-Simulator gelegt. Ohne Stotterserver erhielt jede Domain täglich 20 000 Müllmails. Anhand der Aufzeichnung, welche und wie viele Nachrichten der Server empfangen hat und wie oft die andere Seite den SMTP-Dialog vorzeitig abbrach, variierte er die Parameter “Anzahl der Stotterbytes” und “Stottertempo”. Dabei bestätigten sich die genannten Werte: Für 80 Prozent Spamabwehr genügen 120 gestotterte Bytes mit je einer halben Sekunde Pause.

Gerechte Strafe

Der Aufwand lohnt. Da sich die Pseudo-Teergrube für den Spammer nicht von echten Teergruben unterscheidet, hat er nur zwei Strategien: Die Zeitstrafe hinnehmen und damit auch in jede echte Teergrube tappen oder bei einer möglichen Teergrube aufgeben und damit auch lohnende Opfer verschonen. Mit Hilfe der Spieltheorie [15] wäre für beide Seiten das optimale Verhalten vorherzusagen. Auch wenn der Autor das noch nicht formal ermittelt hat, scheint es doch plausibel, dass je zufälliger die Stotterbytes und -zeiten sind, das Leben für Spammer umso schwerer ist.

Auch juristisch dürfte der Betrieb einer simulierten Teergrube schwer anzugreifen sein. Sie unterdrückt keine Nachrichten, da die E-Mail zum Zeitpunkt des Versandabbruchs noch nicht in den Herrschaftsbereich des Providers vorgedrungen ist. Die Situation gleicht der des entnervten Postkunden, der ob langer Schlangen vor dem Schalter das Weite sucht und seinen Brief gar nicht aufgibt. Dafür kann auch die Post (leider?) nicht strafrechtlich belangt werden. (fjl)