PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Notwendigkeit eines Backup-MX



fladi.at
11.01.07, 09:21
Hallo,

Auf der Courier-Mailingliste bin ich heute über ein Statement von Sam Varshavchik (Entwickler von Courier) gestolpert, in dem er sich gegen die Verwendung von Backup-MX in Mailsystemen äußert.

Get rid of your backup MX. A backup MX is no longer needed on the modern Internet.
Was haltet ihr davon? Was spricht denn für oder gegen die Verwendung von Backup-MX? Nachdem ja der sendende SMTP-Server die Mail bei einem nicht zu erreichenden SMTP-Server über einen längeren Zeitraum zuzustellen versucht, finde ich, ist an der Aussage schon was wahres dran.

RichieX
11.01.07, 09:32
Das würde mich auch mal brennend interessieren. Seit dem ich einen Backup-MX eingerichtet habe, habe ich mehr Probleme wie vorher (siehe Thread (http://www.linuxforen.de/forums/showthread.php?t=229161))

RichieX

himbeere
11.01.07, 10:17
Backup-MX ist in den meisten Fällen tatsächlich Unsinn.

BedriddenTech
11.01.07, 14:21
Ein paar Begründungen wären gut. :) Ich selbst besitze zwar keinen Backup-MX, verstehe aber nicht ganz, wieso man keinen definieren sollte.

Roger Wilco
11.01.07, 15:21
Ein gut gewarteter Sekundärer (oder Tertiärer oder Quad...ähm...) MX Host ist sinnvoll und erhöht die Ausfallsicherheit.
Ein schlecht gewarteter schadet hauptsächlich. Leider ist letztere Gattung weiter verbreitet.
Die Backup MX Hosts nehmen dann blind alle Mails für die betreffenden Domains an, ohne Spam-Abwehrmaßnahmen und ohne zu überprüfen, ob es den Empfänger überhaupt gibt.

bla!zilla
12.01.07, 08:54
Sehe ich auch so. Ein gut konfigurierter Backup-MX ist kein Problem. Nur lassen viele Kunden ihrem Backup-MX nicht die gleiche Aufmerksamkeit zukommen wie ihrem primären MXer. Teilweise ist es auch so das der Backup-MX beim ISP gehostet wird und nur alle eingehenden Mails queued. Sobald der primäre MX wieder verfügbar ist, werden alle Mails auf einmal zugestellt.

RichieX
12.01.07, 09:07
Ein gut konfigurierter Backup-MX ist kein Problem.
Das leuchtet ein. Nur das zu erreichen ist aufwendiger wie ein pri-MX. Oder kennst du eine bessere Lösung wie dieses Monstrum (http://www.linuxforen.de/forums/showpost.php?p=1480160&postcount=5)

RichieX

bla!zilla
12.01.07, 09:28
Das leuchtet ein. Nur das zu erreichen ist aufwendiger wie ein pri-MX. Oder kennst du eine bessere Lösung wie dieses Monstrum (http://www.linuxforen.de/forums/showpost.php?p=1480160&postcount=5)


In letzter Zeit treffe ich häufig auf Mail-Appliances die als Cluster laufen, so wie z.B. Appliances von IronPort (http://www.ironport.com/de/). Da sparen sich die Kunden oft den Backup-MX und legen Mailgateway und Anbindung redundant aus.

RichieX
12.01.07, 09:40
In letzter Zeit treffe ich häufig auf Mail-Appliances die als Cluster laufen, so wie z.B. Appliances von IronPort (http://www.ironport.com/de/). Da sparen sich die Kunden oft den Backup-MX und legen Mailgateway und Anbindung redundant aus.

Ja, auch eine Möglichkeit. Die Verhältnismäßigkeit Kosten/Nutzen passt dann aber gar nicht (für mich). Und genau da ist jetzt auch der springende Punkt: Die Kosten sind einfach zu hoch für einen sicheren sec-MX gegenüber dem Nutzen, egal welche Lösung ich letztendlich bevorzuge. Bis jetzt hatte ich keinen längeren Ausfall des pri-MX, sodass evtl. Mails verloren gegangen wären.

RichieX

bla!zilla
12.01.07, 10:46
Es ist halt immer die Frage "Was mich ein Ausfall". Diese Frage muss der Kunde beantworten.

fladi.at
12.01.07, 12:56
Also erstmal danke für die vielen Antworten.
Vorweg, bei meinem System handelt es sich um ein privates, also ist ein Ausfall (zwar mit Zähneknirschen) auch mal verkraftbar.

Mein Problem mit dem Backup-MX war das, dass ich es nicht geschafft habe, die Spam-Filter zwischen Primary und Backup synchron zu halten. Was dazu geführt hat, dass ich bei falsch klassifizierten Mails erstmal nachschauen musste, wo denn die Mail angenommen wurde. Spammer nutzen in den letzten Wochen verstärkt die Backup-MX ist mir aufgefallen.
Ich werde also die Konsequenz daraus ziehen, und den Backup offline nehmen.