Skip to content

systemd-Unit für srsd unter Debian

Ich fürchte, das wird einer dieser Beiträge, bei dem die notwendige Vorrede bald länger wird als der Beitrag selbst …

Aber fangen wir einfach einmal vorne an: Der Kampf gegen unerwünschte E-Mails, die einen mit Malware oder Angeboten für die Verlängerung oder Vergrößung verschiedenster Körperteile (neuerdings auch - noch sachnah - gerne für den Wechsel der Krankenkasse) beglücken, heutzutage meist als Spam bezeichnet, tobt seit Jahrzehnten. Nach den verschiedensten Filtern entstanden auch mehrere Ansätze, die gar nicht so sehr den Spam an sich bekämpfen, sondern weiter vorne - oder auch parallel - ansetzen und die (meist mit Spam verbundene) Fälschung von Absenderadressen verhindern bzw. umgekehrt eine (begrenzte) Garantie für die Echtheit des Absenders übernehmen wollen.

"systemd-Unit für srsd unter Debian " vollständig lesen

reCAPTCHA v 2.0

Bereits vor rund zwei Wochen klagte ich über Spam über meine Kontaktformulare und kündigte an, von meiner bisherigen Lösung - einfache Rechenaufgabe - auf reCAPTCHA von Google zu wechseln.

Für die besonders betroffenen Formulare habe ich das jetzt umgesetzt.

"reCAPTCHA v 2.0" vollständig lesen

Spammer im Web rüsten auf

Spam ist eine Pest - und beschränkt sich schon lange nicht mehr auf E-Mail und Newsgroups. Auch Webforen, Gästebücher, Wikis, Blogs und Kontaktformulare werden vollgemüllt; letztere vermutlich in der irrigen Annahme, es handele sich um eine Kommentarmöglichkeit.

Damit umzugehen ist ein zweischneidiges Schwert: einerseits ist es unbefriedigend, Spam ständig zu löschen und hinterherzuräumen; andererseits haben Gegenmaßnahmen wie insbesondere CAPTCHAs auch ihre Nachteile, namentlich die dadurch entstehende zusätzliche Hürde für legitime Nutzer, insbesondere solche mit Sehbehinderung.

"Spammer im Web rüsten auf" vollständig lesen

RBLs, RBL-Checks und "sie wissen nicht, was sie tun"

RBLs (Realtime Blackhole Lists) sind mittlerweile über ein Jahrzehnt alt und eine weitverbreitete Methode der Filterung unerwünschter E-Mails. In diese Listen, die über das DNS propagiert werden, trägt der jeweilige Betreiber nach seinen Kriterien die IP-Adressen von Hosts ein, die gefiltert werden sollen. Manche dieser Listen sind sinnvoll, andere sind es nicht; manche zählen Spam-Quellen auf, offene Proxies und Relays, von Malware befallene Systeme, andere jedes System, dessen Betreibers Nase dem RBl-Provider nicht passt. Wer RBLs einsetzt, muß sich also informieren, welche Policy eine RBL verfolgt, und wie zuverlässig sie das tut.

Neben den RBLs gibt es auch Anbieter, die prüfen, ob bestimmte Systeme auf diesen RBLs landen; das sollte jeder Admin größerer Mailsysteme eigentlich selbst tun, um ggf. (das für die Listung ursächliche Problem zu beheben und dann) die Löschung von der jeweiligen RBL zu veranlassen, aber für diejenigen, die das nicht tun können oder möchten, sind solche Angebote sicher interessant. Nur sollten diese Anbieter von RBL-Checks auch wissen, was sie da eigentlich tun, was wohl nicht immer sichergestellt ist …

Ich bekam jedenfalls dieser Tage (mal wieder) einen Hinweis, eines meiner Systeme sei in der RBL hostkarma.junkemailfilter.com gelandet; wie der Name andeutet, versucht deren Betreiber Mailserver in gute, schlechte oder neutrale einzuteilen. Wie zuvor habe ich daraufhin mein System auf den Webseiten des RBL-Betreibers geprüft und bekam - wie immer - als Antwort, das System sei nicht gelistet. Diesmal bin ich der Sache nachgegangen und habe festgestellt, daß der RBL-Check-Anbieter grundsätzlich Recht hat: meine Maschine war tatsächlich in der RBL eingetragen! Aber warum bestreitet das der RBL-Provider dann? Nun, meinem System war dort der Wert "127.0.0.1" zugewiesen. Und der RBL-Provider meint zu diesem Wert folgendes:

127.0.0.1 - whitelist - trusted nonspam

Danke, keine weiteren Fragen mehr.

Once again: Spam gegen Spam

Spam ist ein seit gut 10 Jahren bekanntes Übel, und Spam, der durch Spamfilter rutscht, leider auch nicht so selten, daß er einen Blogeintrag wert wäre. Spam, in dem Spam-Bekämpfung beworben wird, ist allerdings hinreichend selten, dafür aber umso dreister - und wenn die beworbene "Lösung" so (vermutlich unfreiwillig) humoristisch angehaucht ist wie in diesem Fall, dann sollte man diese Verbindung aus Unverschämtheit und unfreiwilliger Komik auch entsprechend würdigen.

Das angepriesene Werk will dem durchschnittlichen Nutzer in drei Schritten nahebringen, wie er Spam vermeiden kann, ja wie Spam geradezu ausgerottet wird, wenn nur jeder diese Schritte befolgt. Kurz gefaßt umfaßt dabei Schritt 1 die Auswahl einer passenden E-Mail-Adresse. In der aus einschlägigen Teleshoppingsendungen und (Tv-)Ratgebern bekannten Sprache erfahren wir auf 53 Seiten, was Spam ist, und daß wir eine E-Mail-Adresse auswählen sollen, die möglichst schwer zu erraten ist; am besten sollen wir dazu mit Papier und Stift in Ruhe unserer Kreativität freien Lauf lassen. Zwar ist richtig, daß damit das Erraten der Mailadresse erschwert oder unmöglich gemacht wird, aber so richtig zielführend mag die Übung dann nicht erscheinen. Garniert wird das (für Fortgeschrittene und Firmen) dann noch mit dem tollen Tip, leicht erratbare Adressen (info@, support@, …) abzuschalten und dort nur einen Autoresponder mit Verweis auf ein Webformular einzurichten (also collateral spam zu produzieren). Daß auch über ein Webformular gespamt werden könnte, scheint dem Autor noch nicht begegnet zu sein (oder es geht über den Horizont des 175-Seiten-Buches hinaus, daß sich gezielt auf E-Mail-Spam beschränken will).

"Once again: Spam gegen Spam" vollständig lesen