BenBE's humble thoughts Thoughts the world doesn't need yet …

Eines der größten Probleme, wenn man einen eigenen Mailserver betreibt, ist Spam. Das zweitgrößte ist, festzustellen, wie effektiv die Gegenmaßnahmen greifen. Aber gut, dafür gibt es ja Unterstützung. Eines der Hausmittel, die mir dabei helfen, ist das Debian-Paket mailgraph, Dieses hat sich bereits auf meinem alten Server bewährt und mir sogar bereits mehrfach geholfen, Fehlkonfigurationen zu erkennen. Was aber etwas komplizierter ist, ist dieses Paket in einer Mehrbenutzer-Webserver-Umgebung sauber zu konfigurieren. Hier stell ich einfach mal folgende Anleitung bereit, die für die meisten Zwecke ausreichen sollte.

Das erste, was man tun muss, ist das Paket mailgraph zu installieren. Nutzt man auf seinem Server zudem suexec, wie es z.B. bei Confixx und ispCP der Fall ist, sollte man zudem von apache2-suexec auf apache2-suexec-custom umsteigen, da sich damit die Konfiguration von suexec etwas flexibler gestalten lässt.

Ist dieser schritt getan, so beginnt mailgraph bereits nach der Installation im Hintergrund die Maillogs auszuwerten und in RRD-Dateien seine Ergebnisse zu speichern. Das ist insofern erstmal nicht schlecht, dass man bereits jetzt erste Daten bekommt, jedoch fehlt hier ein wenig was an der Konfiguration des Startup-Scripts. Um dies zu korrigieren, sucht man sich unter /etc/init.d/ das Start-Script für mailgraph (gleichnamig) und sucht dort den Bereich start) und ergänzt auf der start-stop-daemon-Zeile am Ende die beiden Argumente –rbl-is-spam und –virbl-is-virus.

case "$1" in
  start)
    echo -n "Starting Postfix Mail Statistics: $NAME"
    start-stop-daemon -S -q -b -p $PID_FILE -x $DAEMON -- -l $MAIL_LOG -d --daemon_rrd=$RRD_DIR $IGNORE_OPTION --rbl-is-spam --virbl-is-virus
    echo "."
    ;;

Ist dies getan startet man den mailgraph-Daemon neu.

/etc/init.d/mailgraph restart

Absofort hat man auch RBLs korrekt als Spam in den Graphen aufgeführt. Fehlen diese Optionen, so werden nur von SpamAssassin oder AMaViS gefilterte Mails gewertet.

Bliebe noch die Geschichte mit dem Installieren auf der eigenen Homepage. Hierfür ist nun ein wenig mehr Arbeit nötig, da ein paar kleinere Anpassungen an die lokalen Gegebenheiten nötig sind. Hierfür sollte man sich auf jeden Fall schon mal die Logfiles von suexec und seine error.log des Apache raussuchen, da man diese wahrscheinlich konsultieren muss.

Aber alles der Reihe nach. Als nächster Schritt ist es nötig, in seiner Webverwaltungsoberfläche (Confixx oder ispCP) dafür zu sorgen, dass allgemein CGIs ausgeführt werden können – ohne dies geht es nicht. Sobald diese Änderung übernommen ist, sucht man sich aus /usr/lib/cgi-bin die mailgraph.cgi und kopiert sich diese in sein lokales cgi-bin-Verzeichnis. Anschließend sollte man auf seiner lokalen Kopie die BErechtigungen und Eigentumsrechte entsprechend setzen (User und Gruppe sauber übernehmen, X-Rechte setzen).

Nun bleibt nur noch eine kleine Änderung im Script auszuführen, um die Anzeige der Graphen zu ermöglichen. Hierzu muss die Zeile folgende Zeile entsprechend den örtlichen Gegebenheiten angepasst werden:

my $tmp_dir = '/var/lib/mailgraph'; # temporary directory where to store the images

Andere Konfigurationseinstellungen können zusätzlich geändert werden, sind aber für den reinen Betrieb nicht nötig.

Eine weitere Alternative wäre das Verbiegen der Apache-Konfiguration für das Proxying solcher Script-Aufrufe auf das Systemweite cgi-bin-Verzeichnis, was jedoch den Nachteil hat, dass dann keine Nachvollziehbarkeit der Einbruchsursache im Falle des Falles ermittelt werden kann, da der Webserver u.U. mehr Rechte im Dateisystem besitzt, als der CGI-User dieses einen speziellen Accounts.

Wenn nun alles gut gegangen ist, sieht das Ergebnis so hier aus. Was mich dazu bringt, warum man damit Fehlkonfigurationen erkennen kann …

Nunja, ich hatte an meinem Mailserver mehrfach Änderungen an der Konfiguration vornehmen müssen, um die Spamflut etwas einzudämmen. Und u.a. hatte ich dabei auch einmal aus Versehen Mailversand generell nur mit SSL und Auth eingestellt, was dazu führte, dass jegliche Mails – also auch legitime Einsendungen, abgelehnt wurden. Da dies nun eine ganze Reihe von Hosts betraf, die mir Mails senden wollten, ließen sich zwei Dinge beobachten: 1. Ein Einknicken der empfangenen Nachrichten auf nahezu null und 2. ein Spike in den Spam-Nachrichten, da pünktlich alle 10 Minuten jegliche Mailversender erneut die Einlieferung versuchten.

Ferner sieht man am Vergleich zwischen Rejected und Spam recht schön, ob der Spamfilter greift: Im Normalfall sollte die Rejected-Linie nahezu auf verlaufen (Ausnahme Greylisting), wenn diese jedoch oberhalb der Spamlinie verläuft, so sollte man seine Filter nachkonfigurieren.