Open Source im professionellen Einsatz

Newsletter abonnieren
Seite durchsuchen

HEFTARCHIV | NEWS | E-BIBLIOTHEK | VIDEO | BLOGS | WHITEPAPER | EVENTS | ACADEMY | ABO | SHOP

user friendly

  Home  »  Heft & Abo  »  Heftarchiv  »  2009  »  02  »  Mülltrennung  

RSS-Feed der aktuellen News von Linux-Magazin Online Folgen Sie Linux-Magazin Online auf Twitter
Diesen Artikel druckenDiesen Artikel weiterempfehlen Diesen Artikel kommentieren Newsletter abonnieren
Share/Bookmark

Datenempfang

Nach 10 Sekunden Stottern, das Hartgesottene auf bis zu 90 Sekunden erweitern können, läuft der SMTP-Dialog in normaler Geschwindigkeit weiter. Direkt nach der Client-Aufforderung »data«, die den zu übermittelnden Inhalt der E-Mail einleiten soll, bricht Spamd die Verbindung mit dem Fehlercode »451« jedoch ab: Temporary Failure (Listing 2).

Listing 2: Sitzungsprotokoll mit
dem Spamd

01 $ telnet smtp.yourdomain.org 25
02 Connected to smtp.yourdomain.org.
03 Escape character is '^]'.
04 220 smtp.yourdomain.org ESMTP spamd IP-based SPAM blocker; Thu Oct  9 16:52:31 2008
05 EHLO mydomain.org
06 250 Hello, spam sender. Pleased to be wasting your time.
07 MAIL FROM: <ichbins@mydomain.org>
08 250 You are about to try to deliver spam. Your time will be spent, for nothing.
09 RCPT TO: <andich@yourdomain.org>
10 250 This is hurting you more than it is hurting me.
11 data
12 451 Temporary failure, please try again later.
13 Connection closed by foreign host.

Hier setzt der klassische Greylister ein, der sich das Tupel aus Absender- und Empfängeradresse sowie Sender-IP in der Spamd-Datenbank merkt und auf den zweiten Zustellversuch wartet. Erfolgt dieser, biegt PF den Übermittlungsversuch erneut auf Spamd um, da die Sender-IP ja noch nicht gewhitelistet und damit nicht in der PF-Tabelle »<spamd-white>« eingetragen ist. Erst nachdem Spamd das identische Tupel mit dem Status »GREY« in der Datenbank findet, setzt es den Eintrag auf »WHITE« und aktualisiert die PF-Tabelle. Jede E-Mail von dieser Sender-IP marschiert nun direkt zum MX durch.

Auch an das Whitelisting für ausgehende Verbindungen haben die Entwickler gedacht: Der »spamdlogd«-Daemon beobachtet ausgehenden E-Mail-Verkehr und trägt Ziel-IPs in die Spamd-Datenbank ein. Falls die Empfängerseite denselben Server für ein- und ausgehenden E-Mail-Verkehr benutzt, sind Spamd und PF vorbereitet und stellen beispielsweise Antwort-E-Mails direkt zu. Aus Sicht einer per SMTP übermittelten Nachricht haben Empfänger- und Sender-IP zwar protokolltechnisch nichts gemein, aber die Praxis zeigt, dass einige sendende MTAs auf derselben IP auch Nachrichten annehmen.

Greyscanning

Einmal korrekt zustande gekommene Mailverbindungen landen also in der Whitelist. Zukünftige Nachrichten müssen sich somit nicht mehr der aufwändigen Untersuchung unterziehen. Da sich das Internet jedoch dynamisch verändert, gibt Spamd diesen Einträgen eine Lebensdauer von 36 Tagen, lang genug für monatlich versandte Newsletter. Eine neue Nachricht setzt diesen Timeout wieder zurück. Damit stellt Spamd sicher, dass nur inaktive IP-Adressen aus der Whitelist verschwinden.

Nachdem Spamd einen Zustellversuch nach dem Greylisting-Paradigma temporär abgelehnt hat, erwartet er den zweiten Zustellversuch frühestens in 25 Minuten und spätestens in 4 Stunden. Das sollten Mail-Admins ihren Nutzern möglichst mitteilen. Das bedeutet nämlich, dass etwa eine Bestätigungsmail von einer Anmeldung im Web frühstens nach dieser Zeit eintrifft, wenn der Dienst noch nicht in der Whitelist steht. Auch dieser Wert ist jedoch einstellbar.

Die so gewonnene wertvolle Zeit bis zur zweiten Verbindung nutzt der Spamd, um Informationen über das gespeicherte Tupel von IP-Adressen sowie Namen von Empfängern und Absendern einzuholen. OpenBSD erlaubt es, eigene Skripte einzubinden. Es gibt aber außerdem erprobte Werkzeuge wie etwa das Greyscanner-Skript von Bob Beck, dem Spamd-Entwickler. Das nicht standardmäßig in OpenBSD enthaltene Tool installiert der Systemverantwortliche in »/stand/greyscanner« [7]. Es benötigt einige Perl-Module, die er mit »pkg_add« von einem OpenBSD-Package-Mirror [8] nachinstalliert:

export PKG_PATH=ftp://mirror.switch.ch/pub/OpenBSD/$(uname -r)/packages/$(uname -m)
sudo pkg_add p5-Net-DNS p5-Email-Valid

Ein aktiver Greyscanner arbeitet sich durch alle Spamd-DB-Einträge und analysiert eine Reihe von formalen Kriterien der erhaltenen Tupel. So prüft er, ob die Domain des Versenders einen A- oder MX-Record eingetragen hat und ob alle Adressen korrekt formatiert sind. Optional fragt er ab, ob der Empfänger lokal überhaupt bekannt ist. Schließlich berechnet er eine Statistik, wie viele Nachrichten eine bestimmte IP an unterschiedliche Domains addressiert. Wer zu viele ähnliche Nachrichten an viele Domains verschickt, macht sich verdächtig.

Um dieses Verhältnis zu bestimmen, muss er während der Wartezeit von Spamd mindestens zweimal die Datenbank durchsuchen. Standardmäßig passt das Scan-Intervall von 10 Minuten zum Spamd-Default von 25 Minuten. Wer diesen Wert verringert, muss deshalb ebenfalls das Scan-Intervall des Greyscanners reduzieren. Er startet ihn dann mit »/stand/greyscanner«.

Findet der Greyscanner nun einen nicht-konformen Eintrag in der Datenbank, die Spamd führt, ändert er die zugehörige Sender-IP vom Status »GREY« zu »TRAP«. Ab sofort fängt er alle Zustellversuche dieser IP ab (Trapping). Getrappte IP-Adressen werden nicht nur für 10 Sekunden verzögert, sondern bleiben mindestens 24 Stunden lang im Tarpit (der Teergrube) hängen - bis sie irgendwann entnervt abbrechen. So gehen dem Spammer Zeit und Ressourcen verloren. Da sich der Absender damit nicht RFC-konform verhält, schätzt Spamd die Wahrscheinlichkeit hoch ein, dass dieser ein Spammer ist.

In so einem Fall kehrt Spamd die Beweispflicht um: Erst wenn sich die IP nach frühestens 24 Stunden RFC-konform verhält, wird Greyscanner sie nicht mehr trappen - und E-Mail von dieser IP erreicht ihr Ziel. Natürlich ist es genauso möglich, dass eine Fehlkonfiguration eines eigentlich legitimen Senders im Tarpit landet. Hier hilft es, den Postmaster freundlich auf den Fehler hinzuweisen. Erfahrungsgemäß nehmen die angeschriebenen Admins solche Hinweise dankbar auf und setzen sie schnell um. Die Wahrscheinlichkeit ist nämlich groß, dass auch andere Mailserver die verschickten E-Mails nicht wie gewünscht zustellen.

Praktische Erfahrungen des
Autors

"Wir haben Spamd bereits in verschiedenen Szenarien und auf verschiedene Weise bei Kunden implementiert. Die Erfahrung zeigt, dass eine Kombination aus initialem Stuttering, Greylisting, Greyscanning und Greytrapping effizient arbeitet. Die Rate der False-Positives, also IP-Adressen, die Spamd fälschlicherweise trappt, liegt unter einem Promille. Natürlich gibt es eine theoretische Dunkelziffer, da inkorrekt oder nach dem veralteten RFC 821 arbeitende Absender die Zustellung eventuell ohne Bounce abbrechen.

Aber: Je mehr Spamd- oder Greylisting-Installationen es gibt, desto schwerer haben es solche SMTPs, ihre Mails zu übermitteln. Und das ist gut so. Greylisting übt Druck auf obsolete SMTP-Implementationen aus. Zusätzlich schafft es wertvolle Zeit, die gesammelten Tupel zu analysieren. Das klappt, zumindest solange nicht ständig neue Nachrichten eingehen, deren Analyse mehr Ressourcen in Anspruch nimmt, als ihre Eingangsfrequenz zulässt.

Das hochstilisierte Hauptproblem der initialen Verzögerung nehmen Anwender erfahrungsgemäß vor allem in den ersten Tagen nach Inbetriebnahme das Systems wahr. Dann gibt es nämlich noch keine Einträge in der Whitelist. "Ich bekomme zwar keinen Spam, aber E-Mail geht nicht", heißt es dann häufig. Dem kann der Admin entgegenwirken, indem er manuell eine Whitelist von einem vertrauenswürdigen Drittsystem einspielt.

Hohe Akzeptanz bei Anwendern

Wenn sich die Whitelist langsam füllt, empfinden die wenigsten Anwender die initiale Verzögerung als unbequem. Dies betrifft ohnehin fast nur selten genutzte Anwendungen, die auf die sofortige Auslieferung von E-Mails setzen. Bei den meisten überwiegt der Wunsch nach einer sauberen Inbox deutlich, sodass sie diese Maßnahme gerne in Kauf nehmen. Contentfilter können natürlich nachgeschaltet sein, um noch jene 1 bis 5 Prozent zu filtern, die die Spamd-Maßnahmen überstehen. Ein Versuch bei einem unserer Kunden, der Spam-Lage ausschließlich mit Content Filtering Herr zu werden, scheiterte nicht an der Fehlerquote des Dspam-Filters, sondern daran, dass Benutzer es als völlig inakzeptabel ablehnten, täglich durch 100 bis 300 Quarantäne-E-Mails browsen zu müssen, um die wenigen False-Positives zu retten. Spamd leistet auch hier sinnvolle Abhilfe.

Die oft angeführte Kritik, dass Greylisting in Kombination mit großen Mailprovidern wie Yahoo oder GMX Schwierigkeiten bereitet, ist nur theoretisch berechtigt. Es ist nicht sichergestellt, dass der zweite Zustellversuch von der gleichen IP aus erfolgt. Bei Mailservern mit nur moderatem Mailtraffic spielt dies in der Praxis keine Rolle, da genug E-Mails generiert werden und die Versender über kurz oder lang alle in der Spamd-Datenbank als WHITE landen. Server mit geringer Maillast können entsprechende IP-Bereiche manuell freischalten.

Die Zukunft von Greylisting, wie es das OpenBSD-Projekt mit Spamd implementiert, ist rosig. Es schindet Zeit für weitere Analysen und schadet Spammern bewiesenermaßen aktiv. Nach Einführung von Spamd bei Kunden ist stets ein Rückgang bei den SMTP-Verbindungen zu verzeichnen - ohne dass jedoch die Summe der legitimen E-Mails schrumpft. Mit anderen Worten: Spammer pflegen bereits Blacklists von Tarpits, ein Beweis für deren Erfolg."

Sie können diesen Artikel als PDF für 99 Cent kaufen. Klicken Sie dazu einfach auf eine der beiden Bezahloptionen Paypal oder ClickandBuy.


Diesen Artikel druckenDiesen Artikel weiterempfehlen Diesen Artikel kommentieren Newsletter abonnieren
Share/Bookmark
Ähnliche Artikel
Fit fürs elektronische Postamt LPIC-1-Vorbereitung - Teil 21: Mail Tranfer Agent
Agiler Urahn Konfigurationsverwaltung mit Cfengine2
Schöner schicken Perl-Skript tunnelt Mailverkehr auf Zuruf
Keine Magie Open VPN mit Aladdins E-Tokens in großen Umgebungen
Müllvermeidung Spam abwehren, bevor er den Filter erreicht
Tooltipps Werkzeuge im Kurztest
Whitepaper
The Role of Open Source in Data Integration

Obwohl in den letzten Jahren viele technische Fortschritte erzielt werden konnten, verfügen die meisten Datenintegrationsprozesse nach wie vor nur über eine sehr begrenzte Automatisierung. Das vorliegende White Paper von dem Industry Analyst Mark Madson wird zunächst ein grundlegendes Verständnis von Daten Integration vermitteln, die Vorzüge von Open Source Lösungen für Daten Integration erläutern und Ihnen professionelle Empfehlungen geben, damit Sie Ihre Integrationsjobs noch einfacher und produktiver gestalten können.

Download PDF (Registrierung erforderlich)
Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele (Folge 2)

Der zweite Teil des Open Source Datenintegration in der Praxis: Fallstudien und Anwendungsbeispiele White Papers beleuchtet anhand weiterer ausgewählter Case Studies die Implementierung von Open Source Datenintegration in der Praxis und benennt die daraus resultierenden Vorteile.

Download PDF (Registrierung erforderlich)
Kommentare (0)