Best Practice für redundante MTA

[jensc]

Moin zusammen,

ich bin auf der Suche nach ein paar guten Tipps oder Links zum Thema Redundanz bei MTAs.

Warum das ganze?

Da unsere Geschäfte sehr stark vom Mailversand und -empfang abhängig sind, planen wir eine Umstrukturierung unseres Mailsystems. Gegenwärtig betreiben wir das ganze auf einem Server "in House", der an ner 2 MBit Leitung nach draußen hängt. Aller ausgehender Verkehr geht über einen (na gut, es werden wohl eher ein paar mehr sein ;)) weiteren MTA, der von 1&1 betrieben wird. Eingehender Verkehr geht direkt an unseren Server, und der/die 1&1 MTA sind mit geringerer Preferenz in den MX-Records hinterlegt.

Drei Probleme können wir nun momentan beobachten:

1. Wenn unser interne MTA mal aus irgendwelchen Gründen Offline ist, ignorieren viele Gegenseiten die Backup-MX-Einträge und warten - mit Glück, manchmal lassen sie es auch bleiben - bis der primäre MTA wieder erreichbar ist.
2. Die Zustellung unser ausgehenden Mails ist extrem unzuverlässig, bzw. geschieht oft um bis zu 24h verzögert. Das Problem hat seine Ursache irgendwo, nachdem es unseren Einflussbereich verlassen hat.
3. Relativ viel Schrott - den unser Filter dann gleich wieder droppt - verstopft unsere schmale Außenleitung.

Was tun wir dagegen?

Im wesentlichen möchten wir unsere Backup-MTA sowie unsere Smarthost in Eigenregie nehmen. Es sind zwei Server in unterschiedlichen Rechenzentren bei unterschiedlichen Anbietern geplant, die dann primärer und sekundärer MTA spielen dürfen und - durch VPN Tunnel - Mails für unsere Domain in beide Richtungen "relayen" dürfen. Außerdem sollen unsere Mailfilter direkt auf den Frontendservern laufen. Dafür geht dann unser eigentlicher MTA wieder vom Netz und redet nur noch mit den beiden Frontends.

Und wo ist nun das Problem?

Soweit erstmal technisch und von der Umsetzung her alles kein Problem. Was mir allerdings völlig abgeht, ist wie ich Problem #1 beseitige. Eigentlich sollte die Verfügbarkeit der MTA in den Rechenzentren zwar höher liegen, als unsere hiesige, aber wenn die Gegenstellen das Backup einfach ignorieren, hab ich irgendwie keine Chance, wenn doch mal einer ausfällt oder zu Wartungszwecken außer Betrieb geht.

Wie geht man bei solchen Fällen am besten vor? Ließe sich sowas wie ein Failover zwischen den beiden Servern realisieren? Welche Erfolgschancen bringt das mit sich? Wie sieht das ganze unter Kostengesichtspunkten aus? Kennt Ihr irgendwas an Literatur, die das ganze Thema mal aus praktischen Gesichtspunkten beleuchtet? Und zum guten Schluss: Was haltet Ihr grundsätzlich von obigem Ansatz?

Danke & Gruß Jens

[anyware]

Hallo Jens,

der Betrieb eines Backup MX macht eigentlich nur noch unter bestimmten Bedingungen Sinn. Die eigentliche Aufgabe eines Backup MX ist es ja, Mails entgegen zu nehmen, wenn das primäre Mailrelay nicht verfügbar ist. Wenn der Backup MX dann keine Möglichkeit hat (oder haben soll) die Mails selbst auszuliefern, dann hilft dir das Ding eigentlich kaum. Final hängen dann die ankommenden Mails auf dem Backup MX in der Queue und warten auf den primären. Ohne Backup MX würden die Mails beim einliefernden Mailserver in der Queue hängen. Der Backup MX würde es dir dann lediglich ermöglichen schneller an die Mails zu kommen wenn der primäre wieder verfügbar ist, weil du die Queu flushen kannst.

Vereinfacht gesagt: Die Entscheidung für oder gegen einen Backup MX ohne eigene Auslieferungsmöglichkeit ist eigentlich eine Entscheidung über den "Ort der Warteschlange".

Wenn der Backup MX allerdings in der Lage ist die Mails direkt zuzustellen, dann muß man sich fragen warum er Backup MX ist. Wenn die Maschinen die identischen Möglichkeiten haben, dann macht es Sinn ihne auch die gleichwertige MX Priorität zu geben. Warum ? Zum einen hat man ein simples "Load Balancing" und zum anderen ist es bei Spammern gängige Praxis, direkt den zweiten MX anzusprechen. In extrem vielen Fällen werden Backup MXe nämlich nicht so gut gepflegt wie die primären Server und nehmen viel mehr Spam an. In der Regel nimmt aber der primäre Server alles vom Backup MX an, ohne viel nachzufragen => die Spammer kommen durch die Hintertür.

Das kann man sich allerdings auch zu Nutze machen indem man gezielt einen Backup MX aufbaut und den gleichen Antispamregelsatz fährt wie die primären Kisten. Du kannst eigentlich davon ausgehen, dass alles was dort aufschlägt Spam ist. Denn jeder normale MTA wendet sich zunächst mal an die primären. Über diesen Trick kannst du die primären Frontrelays ganz prima entlasten.

Lange Rede, kurzer Sinn: Richte zwei oder mehr gleichwerte Frontrelays ein und vergebe identische MX Prioritäten. Das ist einfacher in der Pflege und hat keine Nachteile.

[jensc]

Moin Anyware,

erstmal danke für Deine Ausführungen! Ich glaube aber, da hab ich bei meiner Fragestellung wohl etwas unpräzise formuliert und sollte nochmal weiter ausholen:

Gegenwärtig spielen die 1&1 Mailserver "Backup-MX". Hintergrund ist, daß der zentrale Mailserver für unsere Firma nicht in einem Rechenzentrum steht, sondern mit ner simplem 2MBit SDSL Leitung am Netz klemmt. Letztere ist die potentiell größte Schwachstelle auf unserem Kommunikationsweg, sprich die kann schnell mal weg sein. Insofern benötigt man bei einem solchen Setup ein Backup - zumindest in der Theorie. Da es sich zu einem ganz großen Teil um Angebotsanfragen oder um Durchführungsinformationen zu bestehenden Aufträgen handelt, ist es eher wichtig, daß sicher gestellt ist, daß Mails überhaupt ankommen. Der zeitliche Faktor ist beim Empfang zwar wichtig, aber eben nur sekundär.

Problematisch ist allerdings, daß ein zu großer Anteil der Server unserer Kunden - also die der jenigen, die uns Mails senden - diese Backup-Einträge ignorieren und eben Mails nicht zustellen, falls unser lokaler Mailserver mal down ist. Ich hab sogar mal unseren Mailserver mit zwei unterschiedlichen IPs u. virtuellen MTAs, sowie auf zwei unterschiedlichen Subdomains ans Netz geklemmt, und dann das ganze in die MX Records gehauen. Eine Analyse deutet sogar darauf hin, daß die Hauptlast immer auf dem MTA ankommt, den das DNS zuerst ausspuckt - ganz unabhängig von der Prio. Das ist aber - durch die Kürze des Test - nur zwischen den Zeilen gelesen.

Wir haben es hier also mit Gegenstellen zu tun, die die Standards nicht vernünftig implementieren.

Dieses Setup will ich nun abschaffen. Die Backup-MX fliegen raus, und dafür gibts zwei Frontserver, die einzig und alleine dafür da sind, eingehende Mails an den Server hinter der SDLS-Leitung zu relayen, und umgekehrt dessen Mails nach außen zu tragen. Identische Prio wäre dabei logisch.

Für mich ergeben sich damit aber drei Desaster-Szenarien:

1) SDSL down, beide Relays online
=> egal welches Relay ein Kunde anspricht, meine Mails kommen an. Das passiert zwar nur verzögert, aber es passiert. Der Versand geht während dieser Zeit nicht. Sollte sich eine längere Down-Zeit für die SDSL-Leitung ankündigen, geht mit ISDN oder UMTS-Backup immer noch genug um den Mailverkehr wieder flott zu kriegen. Eins von beiden kriegen wir immer im Rahmen unsere Recovery-Planzeiten hin.

2) SDSL up, zweites Relay down
=> wenn sich die Kunden jetzt wieder genauso falsch verhalten, wie beobachtet, dann kommt trotzdem die Post an. Verhalten sich die Kunden richtig, gibts auch kein Problem, weil ja alle im MX geführten Relays durch getestet werden. Das unser interne MTA immer auf das jeweils andere Relay nach außen ausweicht, kann icht sicherstellen, also wäre der Versand nicht betroffen. Ergebnis wäre ne minimale Verzögerung bei Empfang und keine beim Versand.

3) SDSL up, erstes Relay down
=> kein Problem wenn sich die Kunden richtig verhalten, aber keine Post wenn sie sich falsch verhalten. Unser Versand ist wieder nicht betroffen.

Mein Problem ist jetzt genau dieser in 3) geschilderte Fall. Ich hab schon erlebt, daß ganze Rechenzentren tot gelegen haben oder daß Hoster meinten umziehen zu wollen. Oder es muss ja garnicht an jemand anderem liegen. Es kann ja auch ein ganz normaler Plattencrash sein, oder der Admin macht mal selbst nen Fehler. Dagegen muss ich mich halt absichern und ich benötige Reaktionsszenarien für die Fälle, die trotzdem noch auftreten können.

Wie geht Ihr an sowas ran? Es werden sich ja nicht alle nen Servercluster mit redundanter Außenanbindung hinstellen, oder? Es muss doch möglich sein, die beiden Frontrelays in irgendeiner Form so abzusichern, daß man trotzdem noch einigermaßn vertretbare Kosten hat.

Ich hab ja sogar schon darüber nachgedacht, einfach in den DNS-Records die IP für die MTA-Subdomains zu modifizieren, wenn ein Host ausfällt, sowie grundsätzlich mit kleiner TTL zu arbeiten. Damit fahren wir dann aber gegen die Wand, wenn ein Kunde die ignoriert, bzw. einfach nur nen W2k3-Server für sein DNS verwendet (was im Mittelstand ja garnicht so ganz unverbreitet ist).

Irgendwo verrenn ich mich da glaub ich grade...

Gruß Jens

[anyware]

Irgendwo verrenn ich mich da glaub ich grade...

hmm ja ... irgendwie schon. Es liegt halt leider nicht mehr in deiner Hand. Wenn sich die Mailserver deiner Kunden nicht RFC-konform verhalten kann man wenig machen. Die Trickserei mit dem DNS wäre dafür eine Lösung gewesen. Wenn das mangels vernünftiger DNS-Server beim Kunden aber auch ausfällt, ist das natürlich Mist.

Bist du dir denn absolut sicher, dass die Kunden nicht den Backup-MX bei 1&1 ansprechen? Vielleicht sind die Mails die dort ankommen ja so ein Schrott, dass die Annahme einfach verweigert wird und deswegen nichts über den Weg zu dir kommt.