Leslie Schnee – Blog

Frankfurt und Umgebung

Durchsuche Beiträge mit Schlagwörtern Qmail

..denn ab heute Abend ziehen wir über zehntausend Domains mit zehntausenden E-Mailadressen um auf die neuen Mailserver-Systeme. Es hat sich gezeigt, dass eine Hauruck-Aktion effektiver und trotz vieler zusätzlicher Stunden Arbeit schmerzloser ist, als ein Umzug nach und nach.

Das Ganze ist nicht ganz so einfach, immerhin handelt es sich um eine Migration vom bisherigen Qmail auf Postfix, im laufenden Betrieb. Das heißt, es muss für die Kunden sichergestellt sein, dass während der Umstellungen keine E-Mails verloren gehen. Zudem sollen die Kunden möglichst wenig Aufwand haben, d.h. idealerweise in Ihrem E-Mailprogramm nichts umstellen müssen.

Die größte Problematik dabei sind die vielen auf den bisherigen Mailservern gespeicherten E-Mails in Form von kleinen Dateien. Diese Millionen von Dateien, mehrere hundert Gigabyte an Daten, benötigen vermutlich sehr lange, bis sie auf die neuen Systeme kopiert sind. Daher kopieren wir zunächst nur die Konfiguration auf die neuen Mailserver, sodass Kunden weiterhin E-Mails senden und empfangen können. Haben sie E-Mails auf dem Server gespeichert, beispielsweise weil sie IMAP oder Webmail nutzen, sind diese Mails erst einmal weg und werden dann nach und nach wieder ins Postfach kopiert. Bis Montag ist hoffentlich alles abgeschlossen. Sollte aber klappen!

Spannend wirds! Und der gute alte turbohermes, unser bisheriger primärer Mailserver, steht kurz vor seiner wohlverdienten Rente. Wobei, vermutlich wird auch dieser recycled und einer neuen Verwendung, zum Beispiel als Webhosting-Server, zugeführt.

Leider kommt es auf unserem Mailrelay-Server sehr oft vor, dass beispielsweise über gehackte Formulare, Content-Management-Systeme oder sonstige PHP-Scripte Unmengen an Spam versendet werden.

Wir haben bei PS-Webhosting einen eigenen Mailserver, der von den einzelnen Webhosting-Servern die (Formular-)Mails bekommt und dann versendet. Die einzelnen Hosting-Server leiten also Mails, die zum Beispiel mit der mail Funktion von PHP verschickt werden (Anmeldebestätigungen von Foren, Mails aus Kontaktformularen) an diesen Server weiter. Üblicherweise werden so höchstens einige hundert Mails pro Minute versendet. Sind es einige Tausend, ist das erstmal verdächtig und deutet auf Spam hin[*]. Hierfür haben wir ein Script geschrieben, auf dessen Erläuterung ich jetzt mal verzichte. Es sollte aber für den Einen oder Anderen durchaus hilfreich sein, und wenn es nur als Denkanstoß dient:

#!/bin/bash
MSGSENT=0
LASTMCOUNTFILE="/var/run/mail.count"
let CURMCOUNT=`cat /var/log/qmail/current  | grep 'accepted' | grep -v '194.116.187.' | wc -l`+`qmailctl queue | head -1 | tr -d ' ' | cut -d: -f2`
if [ ! -f $LASTMCOUNTFILE ]
then
echo $CURMCOUNT > $LASTMCOUNTFILE
exit 1
fi
LASTMCOUNT=`head -1 $LASTMCOUNTFILE`
let DIFFMCOUNT=$CURMCOUNT-$LASTMCOUNT
if [ $DIFFMCOUNT -ge 1200 ]
then
if  [ $DIFFMCOUNT -ge 2600 ]
then
svc -d /service/qmail-send
ADDMESS="+-DELIVERSTOP-"
wget -O/dev/null -q "http://xxx.xxxxxxx.de/alertscript?from=Abuse&text=eMAIL-MENGENWARNUNG$ADDMESS+($DIFFMCOUNT+$HOSTNAME)"
MSGSENT=1
fi
if [ $MSGSENT -eq 0 -a `dig @194.116.186.1 +noall +answer txt mailcount-$HOSTNAME.1800s.timer.ps-server.net | tr -s '\t' ' ' | cut -d' ' -f2` -ge 1780 ]
then
wait 1
#wget -O/dev/null -q "http://xxx.xxxxxxx.de/alertscript?from=Abuse&text=eMAIL-MENGENWARNUNG$ADDMESS+($DIFFMCOUNT+$HOSTNAME)"
fi
fi
echo $CURMCOUNT > $LASTMCOUNTFILE

"http://xxx.xxxxxxx.de/alertscript" ist dabei ein externes Programm, welches uns die Meldung, dass der Mailserver angehalten wurde, auf unsere Pager schickt. Das Programm hat also erkannt, dass im Zeitraum X mehr als üblich E-Mails verschickt wurden und den Mailversand mit

svc -d /service/qmail-send

angehalten. Eingehende Mails werden aber weiter angenommen und landen in der Queue.

Die Queue und die einzelnen Mails darin finden wir in einer Standardinstallation unter /var/qmail/queue/mess. In diesem Ordner finden sich verschiedene Unterordner, in denen sich die Mails als Textdatei befinden. Wir schauen uns eine der Mails mit less an und versuchen nun zunächst die Ursache ausfindig zu machen. Praktischerweise werden bei uns bei Formular-Mails die UID des Kunden und der Server immer in den Mailheader geschrieben, sodass man anhand der Server-Logfiles die Ursache recht schnell ermitteln kann.

Anschließend stoppen wir auf dem Mailserver Qmail komplett (wichtig!!) mit

qmailctl stop

damit die Queue beim Löschen nicht durcheinander kommt. Falls noch nicht vorhanden, installieren wir mit apt-get unter Debian-Linux qmail-remove und rufen es wie folgt auf der Konsole auf:

qmail-remove -p Suchbegriff

(Suchbegriff aus der Spam-Mail, also z.B. Viagra, Porn, Paypal..)

Dies listet erst einmal alle Treffer auf. Anschließend löschen wir endgültig mit:

qmail-remove -p Suchbegriff -r

-r verschiebt die E-Mails dann in einen Ordner /var/qmail/queue/yanked. Bei älteren Systemen dauert das mit dem Verschieben aber länger, deshalb kann man auch -d auswählen, dann werden die Spam-Mails direkt gelöscht.

Viel Erfolg!

[*] Das größte Problem bei dem oben genannten Spam-Erkennungs-Script liegt darin, dass zum Beispiel legale größere Newsletter von Kunden auch als Spam erkannt werden und der Mailserver anhält. Für diese vertrauenswürdigen Kunden haben wir wiederum ein eigenes System zum Versand der Newsletter eingerichtet.

Qmail…

Keine Kommentare

Gestern rief ein Kunde beim Support an und meinte, er könnte über die Webmail-Oberfläche von PS-Webhosting zwar noch Mails verschicken, diese würden aber nicht im "Gesendet"-Ordner gespeichert.

Haben wir uns einen Wolf nach der Ursache gesucht!

Nachdem wir erfolglos sämtliche Einstellungen seines Postfachs zurückgesetzt und X Testmails versendet hatten und auch die Quota-Einstellungen mehrfach überprüften, waren wir schon fast mit unserem Latein am Ende, bis Oliver auf eine bestimmte Datei im Mailverzeichnis der Kundendomain stiess:


turbohermes:~kundendomain.de/info/Maildir# ls -a
. .. .Drafts .Kunden .Sent .Spam .Stempel .Trash courierimaphieracl courierimapkeywords courierimapsubscribed courierimapuiddb cur maildirsize new tmp

Das Geheimnis liegt in der Datei "maildirsize", in der wirre, nicht aktuelle Zahlen offenbar zum Speicherplatzverbrauch gespeichert werden. Natürlich haben wir, wie erwähnt, mit "vmoddomlimits" versucht, die Quota anzupassen und auch für die einzelnen Postfächer entsprechende Werte gesetzt, was aber nichts gebracht hat. Die E-Mailpostfächer vor allem von langjährigen Kunden sind doch schon das eine oder andere Mal umgezogen und von der Konfiguration her umgestellt worden, sodass die Datei wohl ein Überbleibsel mit ärgerlicher Wirkung ist.

Wenn das in nächster Zeit häufiger Auftritt, sollten wir die Mailserver wohl mal nach "maildirsize" durchsuchen! :-)
Oder aber die Umstellung auf Postfix beschleunigen; was bei tausenden von Domains und ganz viel kleinen (Mail-) Dateien allerdings sehr lange dauert.