Mailbounces monitoren mit rsyslog und mysql

Zurück zum Absender

Mailbounces beobachten und kontrollieren

Unter Mailbounces versteht man Mail, die nicht zugestellt werden können und wieder beim Absender landen.

Kann ein Mailserver eine Mail nicht zustellen, schickt er die Mail sowie einen kurzen Bericht an den Absender zurück. Die häufigsten Ursachen für Mailbounces sind fehlerhafte E-Mail-Adressen des Empfägers. Die Mailserver informieren den Absender dann mit Statusmeldungen wir diesen: „User unknown“ oder „Host unknown“ . Bei ersterem konnte ein Mailserver auf der Empfängerseite kontaktiert werden, aber es wurde keine passende Mailbox gefunden. Bei zweiter Fehlermeldung wurde keine passende Gegenstelle gefunden.

Mailbounces sind nicht weiter tragisch und die Mailserver verarbeiten die unzustellbaren Mails automatisch. http://de.wikipedia.org/wiki/Bounce_Message

Dem Benutzer obliegt die Verantwortung Mailbounces zu vermeiden, indem möglichst wenig fehlerhafte Mailadressen verwendet werden. Aber auch das gelingt nicht immer, denn eine Mailadresse kann jederzeit ungültig werden, wenn zum Beispiel der Empfänger sein Mailkonto auf seinem Mailserver löscht.

In Zeiten der ständig zunehmenden Anzahl von Spammails sind Mailbounces bei den großen Mailprovidern nicht gern gesehen. Spammer generieren millionenfach zufällige E-Mail-Adressen, in der Hoffnung dabei irgendwann eine existierende Mailbox zu erreichen. So entsteht eine Flut an Mailbounces, und die großen Mailprovider bestrafen die Absender, indem sie alle Mails des sendenen Mailserver als spamverdächtig einstufen. AOL spricht in seinen Postmaster-FAQs eine klare Sprache. Zu viele Mailbounces machen einen Mailserver verdächtig und stufen seine Vertrauenswürdigkeit herunter.

GMX.de sagt zu Mailbounces u.A. Folgendes:

Die Mails landen im entweder im Spamfolder des Empfängers oder der empfangende Mailserver verweigert komplett die Annahme von weiteren Mails des Senders, der zu viele Bounces produziert hat. Da E-Mails ja in fast jeder Firma zu einer geschäftkritischen Komponente geworden sind, sollte jeder Administrator dafür sorgen, dass der eigene Mailserver wenig Bounces produziert und damit eine gute Reputation bei den Mailprovidern genießt. Der erste Schritt zur Vermeidung von Bounces ist das Monitoring der Bounces. Wie viele Mail kann mein Mailserver nicht zustellen? Bei zu vielen unzustellbaren Mails müssen Gegenmaßnahmen ergriffen werden. Dazu gehört die kontinuierliche Bereinigung der Adressbücher und Kundendatenbanken.

Da ein funktionierendes Mailsystem in fast jeder Firma zu einer geschäftkritischen Komponente geworden ist, sollten die Mailbounces immer beobachtet werden. Denn zu viele unzustellbare Mails, sind in den meisten Fällen ein Indiz für einen Fehler der leicht zu Umsatzverlust führen kann. Zum Beispiel Webportale sind darauf angewiesen, dass die Mails zuverlässig beim Kunden landen. Wenn der fast überall gebräuchliche Anmeldelink nicht ankommt, ist der Kunde verloren. Produziert das Versenden der Anmeldelinks massenhaft Bounces, sollten die Alarmglocken läuten.

Mailbounces monitoren

Mailbounces zu monitoren und immer eine aktuelle Liste der nicht erreichbaren Mailadressen zu pflegen ist nicht schwer. Linux hat alle Mittel und Werkzeuge dafür an Bord. Kombiniert man Mailserver wie Postfix, Sendmail oder Exim mit einer halbwegs aktuellen Version von rsyslog und einer SQL Datenbank wie MySQL, erhält man eine stets aktuelle Übersicht der Zustellraten und Mailbounces. Eine sauber strukturierte Tabelle gibt Auskunft darüber, welche Mail bei welchem Empfänger „gebounced“ hat. Ein paar einfache Datenbanktrigger können die Bounces pro Minute oder das Verhältnis zwischen zustellbaren und unzustellbaren Mails berechnen. {{Hinweis|Die beispielhafte Anleitung beschränkt sich auf rsyslog und MySQL. Ein ähnliches Setup ist aber auch mit syslog-ng und einer anderen Datenbank wie zum Beispiel PosgreSQL möglich. Beide Syslog-Daemons unterstützen zahlreiche Datenbanken.} Rsyslog wertet die Logmeldungen des Mailservers aus und speichert die relevanten Informationen in getrennte Spalten einer Tabelle. Die Logmeldungen aller Mailserver sind so aufgebaut, dass sie mit regulären Ausdrücken einfach in Teilstücke zu zerlegen sind. Beispiel: So meldet Postfix, dass eine Mail nicht zugestellt werden konnte.

Jun 20 10:14:52 gate2 postfix/smtp[32266]: 
1517D3C906: to=<unbekannt@lin4.de>, relay=mail.n4d.org[87.230.10.219]:25, 
delay=1.7, delays=0/0/0.09/1.6, dsn=5.1.1, 
status=bounced (host mail.n4d.org[87.230.10.219] said: 550 5.1.1 <unbekannt@lin4.de>: 
Recipient address rejected: User unknown in virtual alias table (in reply to RCPT TO command))

Bei sendmail sieht die Meldung ähnlich aus:

Jun 20 09:11:31 localhost sendmail[2769]: o5K7BUaJ002767: 
to=<nicht-existent@lin4.de>, ctladdr=<root@localhost.localdomain> (0/0), 
delay=00:00:01, xdelay=00:00:01, mailer=esmtp, 
pri=120374, relay=mail.n4d.org. [87.230.10.219], 
dsn=5.1.1, stat=User unknown 

Alle Mailserver protokollieren den Status jeder versendeten Mail über den lokalen Syslog-Daemon. Für die Auswertung der Zustellraten sind Textdateien nicht optimal. Erst wenn die Protokolle in einer Datenbank gespeichert sind, ist ein effizientes Auswerten der Zustell- und Bounceraten möglich. Moderne Syslog-Server sind in der Lage verschiedenen SQL-Datenbanken mit den Logmeldungen zu füttern. Der bei einigen Distributionen standardmäßig eingesetzte rsyslog ist einer von ihnen.

Die richtige Version von rsyslog wählen

Ziel unsere Konfiguration ist es, dass der Status jeder versendeten Mail in einer SQL-Tabelle protokolliert wird, wobei relevanten Informationen wie Empfängeradresse, Relayhost und Status in getrennten Spalten gespeichert werden. Es muss mindestens Version 3.19.5 von rsyslog vorliegen. Ältere Versionen verfügen nur über eine Eingeschränkte Implementierung von Regulären Ausdrücken und sind nicht in der Lage, Teilstücke einer Logmeldung zu speichern. Debian, Ubuntu und Fedora benutzen schon lange rsyslog als Standardlogdaemon, CentOS bzw. Red Hat liefern fertige RPMs zum Installieren von rsyslog mit. Leider sind in vielen aktuellen Distributionen alte Versionen von rsyslog enthalten.

Tabelle :

Distribution rsyslog-Version Alternativen
CentOS 5.3 2.06 Installation aus den Quellen
CentOS 5.4 2.0.6 Installation aus den Quellen
Debian 5 3.18.6 Debian Backports
Debian Testing 4.6.2 OK
Fedora 11 3.21.11 OK
Fedora 12 4.4.1 OK
Ubuntu 10.4 4.2.0 OK
Ubuntu 9.1 4.2.0 OK
Ubuntu 9.04 3.18.6 Installation aus den Quellen
Ubuntu 8.10 3.18.1 Installation aus den Quellen
Ubuntu 8.04 1.19.12 Installation aus den Quellen

Für Debian 5 steht im Repository der Backports eine aktuellere Version zur Verfügung. Wer die oben genannten Alternativen nicht nutzen kann, kann rsyslog entweder aus den Quellen installieren oder die Logs des Mailserver, anstatt auf lokalen Syslogdaemon auf einen entfernten rsyslog zu loggen, welcher über eine ausreichend aktuelle Version verfügt.

Siehe auch Rsyslog unter CentOS aus den Quellen installieren

Bounces und den kompletten Zustellstatus in MySQL oder PostgreSQL speichern

Neben rsyslog ab Version 3.19.5 braucht man noch die Erweiterung rsyslog-mysql oder rsyslog-psql, welche alle Distributionen und die Quellen mitliefern. Damit rsyslog eine Datenbank als Speicher der Logmeldungen nutzen kann, muss folgende Zeile in die Konfiguration eingetragen werden:

$ModLoad ommysql 

Debian und Ubuntu Benutzer tragen dies in /etc/rsyslog.d/mysql.conf ein. Unter CentOS erfolgt der Eintrag in /etc/rsyslog.conf.

Eine Datenbank anlegen

Als nächstes muss eine Datenbank und eine Tabelle für die Logmeldungen des Mailservers angelegt werden. Ob die Datenbank auf demselben Host wie rsyslog oder auf einem entfernten Host arbeitet, spielt keine Rolle. Der Aufbau der Tabelle sollte sich nach den Anforderungen richten. Ein Beispiel für eine MySQL-Tabelle wäre Folgendes:

CREATE TABLE `db_mail_log` (
  `from_host` varchar(100) NOT NULL,
  `priority` int(2) NOT NULL,
  `message` text NOT NULL,
  `device_reported_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  `received_at` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `syslog_tag` varchar(20) NOT NULL,
  `mail_to` varchar(200) DEFAULT NULL,
  `relay_host` varchar(200) DEFAULT NULL,
  `relay_host_ip` varchar(15) DEFAULT NULL,
  `status` varchar(20) DEFAULT NULL,
  KEY `mail_to` (`mail_to`),
  KEY `status` (`status`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

In die Datenbank loggen

Nun weisen wir rsyslog an, alle Meldungen des Mailserver in diese Tabelle zu schreiben. Mit regulären Ausdrücken wird die Logmeldung in Teilstücke zerlegt, welche dann in die einzelnen Spalten geschrieben werden. Das Verarbeiten von Logmeldungen erfolgt in rsyslog anhand sogenannter Templates. Die Templates werden in der Konfigurationsdatei von rsyslog gespeichert. Da die Logmeldungen der einzelnen Mailserver unterschiedlich aufgebaut sind, muss das Template auf den verwendeten Mailserver angepasst werden. Ein Template für oben genannte Tabelle und Postfix sähe dann so aus:

$template db_mail_log,"insert into db_mail_log (from_host, priority, message, device_reported_time, received_at, syslog_tag, mail_to, relay_host, relay_host_ip, status) values ('%HOSTNAME%', \
'%syslogpriority%', \
'%msg%', \
'%timereported:::date-mysql%', \
'%timegenerated:::date-mysql%', \
'%syslogtag%', \
'%msg:R,ERE,1,BLANK:<(.*)>, relay=(.*)[.*]--end%', \
'%msg:R,ERE,1,BLANK:relay=([0-9 a-z \. \-]+)--end%', \ '%msg:R,ERE,1,BLANK:relay=.*\[([0-9\.]+)\]--end%',\
'%msg:R,ERE,1,BLANK:status=([a-z]+)--end%')",SQL

Und mit folgender Direktive wird rsyslog angewiesen das obige Template zu nutzen.

:syslogtag, startswith , "postfix/smtp[" :ommysql:db_host,database_name,database_user,password;db_mail_log

Alle Logmeldungen die mit "postfix/smtp[" werden mit dem Template db_mail_log verarbeitet und in die angegebene Datenbank geschrieben.