|
Die zunehmende Größe der Botnets , die mitunter für den Spamversand verwendet werden, macht ISPs in den letzten Monaten wegen massiv gestiegenem Spam-Aufkommen deutlich zu schaffen. Während die einen ihre Hardware aufstocken - der Webhoster manitu reagierte im Mai 2007 mit einer Verdoppelung der Leistung seiner Spamfilter-Systeme - sperren andere ISPs fremde Mailserver. Das passierte bspw. bei T-Online, dessen Abuse-Team selektiv externe Mailserver (wegen massenhaft Bouncemails) schonmal für 24 Std. gänzlich blockieren ließ.
Das globale Spam-Problem wird sich höchstens auf Sicht mehrerer Jahre abschwächen lassen: die Einführung von Techniken zur E-Mail-Identifikation - wie bspw. DKIM - dürfte Zombie-Rechner zuverlässiger enttarnen, wird letztlich aber auch nur eine weitere Hürde im Wettlauf von Spammern und Anti-Spammern darstellen. Insofern stellt sich die Frage, wie ISPs auf die gestiegenen Anforderungen reagieren können. Neben dem oben dargestellten, harten Blockieren und der Erweiterung der dedizierter Spamfilter-Hardware können auch freie Kapazitäten verteilter Systeme zur Spamfilterung verwendet werden. Früher setzten wir ein solitäres Mailfilter-System neben Mailserver und Webservern ein, das irgendwann an Grenzen stieß. Auf den daneben betriebenen Webservern gibt es nur wenig Last mit seltenen Lastspitzen. Insofern liegt es nahe, die Idle-Time der Webserver für die Spam-Filterung zu nutzen. Allerdings muss dabei gewährleistet sein, dass die teils benutzerspezifische Konfiguration sowie die Bayes-Tokens allen Spam-Filtern auf allen Servern einheitlich und aktuell zur Verfügung stehen. Spamassassin bietet die Möglichkeit, Benutzereinstellungen (benutzerspezifische, domainspezifische und globale), die Bayes-Tokens sowie eine Auto-Whitelist in einer Datenbank zu halten. Einzelne Spamassassin-Daemons können auf verteilten Servern (Spamassassin-Worker) mit Zugriff auf den Datenbankserver installiert werden. Um die entsprechenden Systeme nicht zu überlasten, kann jeder Daemon unter einem geringen nice-Level gestartet werden und akzeptiert nur Verbindungen vom Mailserver. Nachdem globale Spamassassin-Konfigurationen nicht von der zentralen Datenbank abgefragt werden können, sondern zu Beginn von spamd von der Platte eingelesen werden, ist es vorteilhaft, eine zentrale Konfiguration bei Änderungen per Netzwerk-Filesystem auf die einzelnen Spamassassin-Worker zu verteilen und infolge einen gesammelten Reload der Spamassassin-Daemons zu vollziehen. Der aufrufende Spamassassin-Client, spamc, erhält per DNS-Round Robin mehrere IP Adressen für den Domainnamen des Filter-Clusters zurück und wählt zufällig eine IP aus. Ist der zugehörige Spamassassin-Daemon nicht erreichbar, werden bis zu zwei weitere Daemons kontaktiert. Damit können im Spamassassin-Cluster bis zu zwei Daemons ohne Auswirkung auf die Spam-Filterung ausfallen. Um des Weiteren die Verfügbarkeit der zentralen Datenbank zu erhöhen, ist denkbar, diese zu replizieren. Wir geben gerne unsere Erfahrungen weiter und stehen für Beratungsprojekte zur Verfügung. Auch können wir Providern unser Spamassassin-Cluster zur Erweiterung der eigenen Kapazitäten bereitstellen. Fragen Sie bei uns an. |
