CBlog

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...

Mit etwas Verspätung (wegen Zeitmangel), dafür aber mit Grüßen vom Osterhasen veröffentliche ich heute die SQL-Abfragen, um die Mailkonfiguration von Qmail / Plesk nach Postfix mit MySQL-Backend zu migrieren. Einige der Queries haben durchaus Chancen auf den Longest-SQL-Query-of-the-year-Award ;-)

Alle Queries wurden bei einer echten Migration getestet und funktionieren. Zur Verwaltung der Mailkonfiguration nach der Migration zu Postfix empfehle ich Postfixadmin (RPMs), bei dem ich auch seit einiger Zeit mitprogrammiere.

A bit late (because a lack of time), but with greetings from the easter-bunny, I publish the SQL queries that are needed to migrate from Qmail / Plesk to Postfix with MySQL backend. Some of the queries have good chances to win the longest-SQL-query-of-the-year award ;-)

All queries were tested while a real server migration and work. To manage your mail addresses after migrating to postfix, I recommend Postfixadmin (RPMs) on which I'm co-developer since some time.

Die SQL-Queries und einige Details stehen im vollständigen Artikel - bitte weiterlesen...

The SQL queries and some more details are available in the full article - read on...