CBlog

Prosit Neujahr und alles Gute für 2010! Dieser Artikel enthält einiges, das ich schon 2009 bloggen wollte, und außerdem eine kleine Neujahrsüberraschung von SpamAssassin ;-)

Happy New Year! This article contains some things I wanted to blog about in 2009 already, and a little new year surprise from SpamAssassin ;-)

• PostfixAdmin 2.3 wurde im Oktober 2009 releast, RPMs gibt es natürlich im openSUSE Build Service
  PostfixAdmin 2.3 was released in october 2009, RPMs are available in the openSUSE Build Service


• Postfixadmin 2.4 (oder 3.0?) wird Smarty für die Templates verwenden
  PostfixAdmin 2.4 (or 3.0?) will use smarty for the templates


• PostfixAdmin 2.3.1 (alle Bugfixes seit dem 2.3-Release, aber ohne Smarty) ist in Arbeit
  PostfixAdmin 2.3.1 (with all bugfixes since 2.3 release, but without smarty) is under development


• openSUSE 11.2 wurde im November 2009 releast, und auch gleich von uns (Jan, Jan-Simon und mir) auf der Open Source Expo in Karlsruhe präsentiert
  openSUSE 11.2 was released in november 2009, and presented by us (Jan, Jan-Simon and me) at the Open Source Expo in Karlsruhe


• und die Neujahrsüberraschung von SpamAssassin: 2010 bekommt jede Mail erstmal 3.188 Punkte... - Bugreport
  and the new year surprise from SpamAssassin: every mail in 2010 gets 3.188 points... - Bugreport
  

Zur Spamabwehr gibt es diverse Möglichkeiten. Seit einiger Zeit habe ich versuchsweise einen "Faulpelz-MX" laufen, der als Backup-MX eingetragen ist und den ganzen Tag nur Mails mit der temporären Fehlermeldung »I'm a "Faulpelz, please use the primary MX« abweist.

Das Ergebnis in Form einer Reject-Statistik für einen Tag:

There are several ways to fight spam. Since some time I'm using a "Faulpelz-MX" (a "Faulpelz" is a sluggard) which does nothing else than rejecting mails with a temporary error message »I'm a "Faulpelz, please use the primary MX« all the day.

The results in the reject statistics for one day:

- 18.000 ix.dnsbl.manitu.net blacklist (5xx)
- 12.000 zen.spamhaus.org blacklist (5xx)
- 13.000 Faulpelz-MX (4xx)
-    600 Greylisting (4xx)

Sprich: Rund ein Drittel der Spammer probiert es beim Backup-MX, der aber den ganzen Tag nur auf der faulen Haut liegt und keine Mails annimmt ;-)  Im Gegenzug ist insbesondere Greylisting stark entlastet, die Blacklisten natürlich auch. Und einen billigeren Check als eine RegEx-Prüfung auf .* wird es kaum geben *g*

Die Menge an abgewiesenen Mails insgesamt hat sich übrigens seit Einsatz des Faulpelzes nicht erhöht - die Spammer sind also immer noch zu faul, um es bei mehreren MXen zu probieren. Nur ein paar "echte" Mailserver, die ins Greylisting laufen, probieren es zusätzlich auch beim Faulpelz - die sind aber zahlenmäßig zu vernachlässigen.

Die nötige Postfix-Konfiguration gibt es im vollständigen Eintrag...

About one third of the spammers try to deliver their mails to the backup MX - which simply rejects all the mails. This reduces the load especially on greylisting, but also on blacklists. And you won't find a "cheaper" check than checking against the .* regex *g*

BTW: The total number of rejected mails didn't change since I use the Faulpelz as backup MX - the spammers are still too lazy to retry at the primary mailserver. Only some "real" mailservers that hit greylisting retry at the Faulpelz - but these can be ignored numerically.

Read the full article to see the required postfix configuration...

Bounces von Spam-Mails, die mit gefaktem Absender verschickt wurden, sind nicht schön. Es gibt aber Ausnahmen - diesmal hat eine Benachrichtigung über die Zustellverzögerung eher für Erheiterung bei mir gesorgt. Aber lest selbst...

Receiving bounces for spam mails with faked sender address is not nice. But there are exceptions - today a mail delivery delay notification somewhat exhilarated me. But please read yourself...

Subject: Warning: message 1Jloab-000J5Z-0j delayed 3936 hours
From: Mail Delivery System <Mailer-Daemon@free1.firehosting.nl>
To: [faked sender address @cboltz.de]

This message was created automatically by mail delivery software.
A message that you sent has not yet been delivered to one or more of its
recipients after more than 3936 hours on the queue on free1.firehosting.nl.
[...]
The date of the message is:    Tue, 15 Apr 2008 21:05:01 +0400
[...]
No action is required on your part. Delivery attempts will continue for
some time, and this warning may be repeated at intervals if the message
remains undelivered. Eventually the mail delivery software will give up,
and when that happens, the message will be returned to you.

Man achte auf die genannte Verzögerungszeit - immerhin kann man dem Provider nicht vorwerfen, dass er bei der Mailzustellung vorschnell aufgibt ;-)

Please notice the delay time - at least you can't argue the provider gives up on mail delivery too early ;-)

Weihnachten - das ist die Zeit von Ruhe und Besinnlichkeit.

Es sei denn, man ist Admin eines Servers, der sich just an Heiligabend verabschiedet. Dann wird es nämlich recht hektisch.

So "durfte" ich dann kurzerhand die Postfächer von rund 100 Domains auf einen anderen Server umziehen. Dazu noch ein paar datenbanklastige Webseiten (Typo3 und ein paar Spezialitäten). Naja, immerhin war ich vor der Bescherung fertig *g*

Das Gute daran: Der Umzug hat recht schmerzfrei geklappt (die nötigen SQL-Queries hatte ich zum Glück schon vor längerer Zeit vorbereitet) und die betroffenen Kunden haben jetzt sogar ein (fast) spamfreies Postfach, was der vorherige Server (Plesk, Qmail) nicht geschafft hat. Und ich weiß jetzt, dass (entgegen meiner Erwartung und früherer Erfahrung) die meisten Spammer ihne DNS-Einträge nicht cachen - ich hatte nach der MX-Umstellung innerhalb einer Stunde eine Reject-Rate von 50 Mails/Minute statt vorher 3 ;-)

Das "Migration von Plesk zu Postfix/MySQL HOWTO" zur Migration der Mailuser-Datenbank gibt es demnächst an dieser Stelle. Soviel verrate ich jetzt schon: Hauptbestandteil ist eine SQL-Query, die eine DIN A4-Seite für sich braucht.

Was meint Ihr - soll ich das HOWTO auch im Plesk Forum posten? Wäre doch bestimmt ein Spaß ;-)

Trotz allem wünsche ich frohe Rest-Weihnachten und schonmal einen guten Rutsch!

Auch wenn das Aufkommen an Gästebuchspam aktuell zurückgeht (im April nur noch 1/5 dessen, was zwischen November und März monatlich an Spameinträgen reinkam), wird es Zeit, dass ich mal wieder ein Update meines Gästebuch-Spamfilters veröffentliche.

Eine reine Filterung auf "<a href=...>" und "[url]" reicht leider nicht mehr aus, aber es gibt ja noch mehr Möglichkeiten. Aktueller Stand:

preg_match_all("@http://@", $eintrag, $http_count_tmp);
preg_match_all("@%@", $www, $prozent_count_tmp);
if (
    preg_match ( "/\[URL=.*\]|<a[^>]*href|^abc123$/i", trim($eintrag))
    || ( count($http_count_tmp[0]) > 3 )
    || ( $leerfeld != "" )
    || ( ( $name == $ort ) && ( $name != "" ) )
    || ( count($prozent_count_tmp[0]) > 10 )
) {
    echo "Verp*** dich, Spammer!";
    die;
}

Gefiltert wird also auf folgende Kriterien:

• der Eintrag enthält "<a href=...>" oder "[url]"
• lustigster Filter: der Eintrag lautet "abc123" - scheinbar lieben die Spammer solche Kurzeinträge ;-)
• im Eintrag kommt mehr als dreimal "http://" vor
• das Leerfeld (ein per CSS display:none ausgeblendetes Eingabefeld) wurde ausgefüllt
• die Homepage mehr als 10 %-Zeichen enthält (gern verwendet bei "Fremdhosting" von Spam, aka unsichere, gecrackte Forensoftware u. ä.)
• zwei Felder mit gleichem Eintrag

Die aktuelle Trefferquote liegt sehr nahe an 100%. Insbesondere das Leerfeld hat mir in letzter Zeit gute Dienste geleistet, weil viele Spammer nur noch einen kurzen Text (englisch, italienisch oder in kaputtem deutsch) ohne Links eintragen.

UPDATE 17.8.2007:
Filter auf >10 Prozentzeichen und auf Felder mit gleichem Eintrag hinzugefügt (ist schon seit einiger Zeit im Gästebuch-Spamfilter enthalten - seitdem ist wieder Ruhe.)

Im Gästebuch der Landjugend RheinhessenPfalz habe ich ein paar Zeilen PHP-Code verwendet, um Gästebuch-Spam abzufangen. Das Funktionsprinzip war recht einfach: wenn der Eintrag nach Spam aussieht, setze $_POST['firstname'] = "". Das Gästebuch hat dann den fehlenden Vornamen beklagt ;-) und den Eintrag zuverlässig abgewiesen.

Nach dem Update auf Typo3 4.0 funktioniert das so nicht mehr - scheinbar wird $_POST von Typo3 gecacht.

Der Einfachheit halber habe ich jetzt doch ve_guestbook gepatcht:

--- pi1/class.tx_veguestbook_pi1.php_ORIG   2006-10-22 03:07:02.000000000 +0200
+++ pi1/class.tx_veguestbook_pi1.php        2006-10-22 02:56:52.000000000 +0200
@@ -947,6 +947,11 @@  function checkForm() {
                        }
                }

+               if (!empty($this->postvars['entry'])) {
+                       if (preg_match ( "/\[url=.*\]|<a[^>]*href/i", $this->postvars['entry']))
+                           $error .= "<li>Bitte keinen Spam posten!</li>\n";
+               }
+
                if ($this->config['email_validation'] && !empty($this->postvars['email'])) {

                        if (t3lib_div::validEmail($this->postvars['email']) == false) {

Der Feature Request für eine offizielle "Eintrag Blacklist" Konfiguratonsoption in ve_guestbook, die ganz normal übers Typo3-Backend konfiguriert werden kann, ist übrigens auch schon beim Autor eingereicht ;-)

 

UPDATE (17.11.2006)

Der Fehler lag woanders - Typo3 4.0.2 cacht ve_guestbook zu aggressiv.

Das führte zum Einen dazu, dass mein Hack, $_POST zu verändern, nicht mehr funktioniert hat, und zum anderen dazu, dass keine neue Gästebucheinträge akzeptiert wurden - die Bestätigungsseite wurde gechacht und der Eintragen-Code im Gästebuch wurde deshalb nicht mehr ausgeführt :-(

Die Lösung: Die Seite komplett vom Cachen ausschließen (nicht wirklich empfehlenswert) oder im Typoscript plugin.tx_veguestbook_pi1 = USER_INT eintragen. (Quelle)

Und schon kann man wieder $_POST missbrauchen ;-)

Vor ein paar Tagen habe ich einen Spamfilter ins Gästebuch von Landjugend-Insheim.de eingebaut, nachdem eine Handvoll Spameinträge aufgeschlagen war.

Weil das Gästebuch nur Plain Text-Einträge erlaubt, ist das Funktionsprinzip einfach: ich kann auf <a href=...> und [url=...]filtern. Die Spammer sind immer so nett, diese Tags in reichlicher Anzahl in ihre Einträge zu packen ;-)

Technisch gesehen sieht das so aus:

<?php
if ( preg_match ( "/\[URL=.*\]|<a[^>]*href/i", $eintrag)) {
    echo "Verp*** dich, Spammer!";
    die;
}
?>

Naja, die echte Fehlermeldung ist etwas freundlicher - es könnte ja auch mal jemand einen "guten" Eintrag schreiben und auf aktiviertes HTML hoffen. Der bekommt dann natürlich nach Entfernen der Links eine zweite Chance.

Gestern und heute hat mir dieser Filter reichlich Arbeit gespart - innerhalb von 36 Stunden hat er mir 170 Spameinträge vom Hals gehalten...