Prinzipiell ist die Einrichtung eines Backup-MX Servers für eine
Domain eine gute Sache.
… Es sei denn, man ist der Betreiber des Backup-Servers (Meist der ISP der Domain)

Der Hauptgrund für den Betrieb eines Backup-MX Servers ist die Absicherung der
Erreichbarkeit einer Domain per Email bei Ausfall des Primären Mailservers.

Im DNS werden dazu in der Regel 2 oder mehr Server als MX’er hinterlegt.

Beispiel:

Fällt der primäre Mailserver aus (MX’er mit der kleinsten Priorität), muss der sendende Server laut RFC versuchen, die Email an den nächten im DNS hinterlegten MX’er (nächsthöhere Priorität) zuzustellen.

Der Backup-MX Server ist entsprechend konfiguriert und nimmt dann stellvertretend die Email entgegen.

Der Backup-MX Server versucht nun in einem konfigurierten Intervall (ca. 10min)
die Email an den primären Server zuzustellen. Sobald der primäre Server wieder erreichbar
ist, werden dann die zwischengespeicherten Emails vom Backup-MX Server an den primären Server zugestellt.

… soweit die Theorie.

In der Praxis ist der Betrieb eines Backup-MX Servers mittlerweile aufgrund der aktuellen Spamproblematiken zu überlegen, denn es ergeben sich zu den Vorteilen eine Reihe von Nachteilen bzw. Probleme:

Verifizierung der Empfängeradressen
Da die einzelnen Emailadressen zumeist nur auf dem primären Server konfiguriert sind (insbesondere wenn der Provider den Backup-MX für einen Kunden-Emailserver betreibt) lassen sich die verwendeten Empfängeradressen nicht überprüfen. Es muss somit vom Backup-MX jede Emailadresse in der Domain akzeptiert werden.

Spammer benutzen meist nur den Backup-MX Server
Dies ist eines der grössten Probleme.
Ein Spammer der etwas auf sich hält, benutzt natürlich gezielt den Backup-MX Server, um tausende von Emails an eine Domain zu senden, da diese in der Regel nicht so stark gesichert sind und alles für die Domain annehmen. Das füllt wunderbar die Queue auf dem Backup-MX Server und als Spammer ist man seinen Müll schnell los, da die Backup-MX Server meistens auch sehr performant angebunden sind. Insbesondere, wenn man einmal das Glück hat, von einer Bot-Army heimgesucht zu werden, kann dies bis zum völligem Systemstillstand auf dem Backup-MX Server führen.(http://cbl.abuseat.org berichtete Ende Oktober von einer Bot-Army von ca. 300.000 Rechnern, die durch das Internet zog)

Unsolicited Bounces
Wird eine Email vom Backup-MX Server angenommen und später, nachdem der primäre Server die Mail abgewiesen hat, wieder an den Absender zurückgesendet bezeichnet man dies als
Unsolicited Bounces. Ein Mailserver darf laut RFC eine Email, die einmal akzeptiert wurde, später nicht wieder zurücksenden (bouncen). Mit derartigem Verhalten bekommt der Postmaster des Backup-MX Servers schnell Post von Spamcop.

Spam-Reporting auf dem primären Server
Wird auf dem primärem Server das Reporting an Anti-Spamlisten aktiviert (was man als Betreiber des Backup-MX Servers garantiert als letztes erfährt) landet man unter Umständen selbst in den Listen einschlägiger Antispam-Listen, da der Backup-MX Server bedingt durch seine Grundfunktion eine hohe Anzahl von Spam an den primären Server ausliefert könnte und dann vom primären Server als potentielle Spamquelle angeschwärzt wird.

Lösungsansätze
Um dieser Probleme Herr zu werden gibt es eine Reihe von Ansätzen, die sich in der Praxis aber “noch” nicht wirklich als Lösung herausgestellt haben.

Das der Backup-MX Server entsprechend konfiguriert ist, um im Vorfeld schon eine Grosszahl von Spam abzuwehren, wird einmal vorrausgesetzt.

Prüfen der existenten Empfängeradressen
In der Praxis schwer bzw. nur bei einzelnen Domains durch manuelle Access-Listen umzusetzen. Für den Postfix-MTA existiert zwar das Verify-Modul (http://www.postfix.org/ADDRESS_VERIFICATION_README.html), aber selbst mehrmaliges Nachfragen beim primären Server wird von manchen MTA’s schon mit einer kompletten Sperre quittiert. Ausserdem steht der primäre Server bei Ausfall ja auch nicht zur Verfügung

Verzicht auf einen Backup-MX Server
Da normalerweise jeder Emailserver (also auch die sendenden) selbst einen Caching-Mechanismus verwenden, um nicht sofort zustellbare Emails später noch einmal zu senden, könnte man rein theoretisch auf einen Backup-MX Server verzichten. Leider ist dies in der Praxis bei weitem nicht so, bzw. ist der Caching-Zeitraum recht kurz eingestellt, so dass viele Emails schon nach kurzer Zeit an den Absender zurückgesendet werden.

Eine weitere Möglichkeit wäre, die Internet-Anbindung des primären Servers entsprechend redundant zu gestalten und die Hardware des Servers selbst zu Clustern.
Dies bedeutet aber vor allem in kleineren Umgebungen einen recht hohen Kostenaufwand.

Eine wirkliche Lösung des eigentlichen Problems ist bisher leider noch nicht in Sicht.

Nichtsdestrotrotz gehen manche Firmen mittlerweile dazu über, keinen 2. MX’er im DNS einzutragen.

os