Sinn eines Backup Mailservers

[LL0rd]

Hallo Leute,

ich frage mich gerade, ob es heute einen Sinn macht, einen Backup Mailserver zu betreiben. Bisher habe ich immer einen zweiten Mailserver betrieben, der außerhalb des regulären RZs stand, um trotz eines Ausfalls des primären Servers an die Mails empfangen zu können. Vor allem wollte ich mich nicht auf die Konfiguration des absendenden Servers verlassen, der Mails bei einem Ausfall eigentlich später zustellen soll.

Jetzt ist die Frage, ob so eine Konfiguration heute noch modern ist. Ich sehe heute an den Logs meines Servers, dass vor allem bei großen Versicherungsgesellschaften und Banken Greylisting betrieben wird. Und genau das ist ja nichts anderes, als ein emulierter Ausfall, der einen Mailserver dazu bringt die Mail später noch einmal zuzustellen.

Außerdem vertrete ich momentan die Meinung, dass derjenige, der bei mir Mails zustellen möchten, auch seinen Server nach den Spezifikationen konfigurieren muss.

Ich würde gerne eure Meinung dazu hören

 

[LinuxAdmin]

Der Vorteil eines secondary-MX ist, dass man ihn recht schnell in einen primary umwandeln kann, falls man es aus irgendwelchen Gründen nicht schafft, den ausgefallenen Server zeitnah wieder zum Laufen zu bringen.

 

[d4f]

Viele Spammer hoffen dass die Backup-Server weniger restriktiv mit Spams umgehen und laden deswegen ihre Fracht direkt bei diesen ab.

Ich meine ausserdem mal in einer c't oder iX gelesen zu haben dass man als Provider dann fuer die Email geradestehen muss da sie akzeptiert wurde und eine Nicht-Zustellung oder verspaetete Zustellung als geschaeftsschaedigend(?) angesehen werden kann.

Ich bin mir nicht sicher ob dies Standard-konform ist, aber du koenntest den Secondary erst ein paar MInuten nach Ausfall des Primary (mit gleicher MX-Prio?) starten, gleichzeitg den A-Record fuer SMTP und IMAP korrigieren und somit die Spam-Probleme vermeiden.
Sobald der Hauptserver wieder erreichbar ist wird dann der Secondary ausgeschaltet, die Mails synchronisiert und der Primary wieder gestartet.

dass vor allem bei großen Versicherungsgesellschaften und Banken Greylisting betrieben wird.

Viele Server sind heute greylist-gesichert und mit strikter RFC-Ueberpruefung. Nicht nur Banken

Und genau das ist ja nichts anderes, als ein emulierter Ausfall

Nicht ganz. Der Mailserver sagt nur dass der aktuell dem Benutzer keine Emails zustellen kann, nicht dass er global nicht erreichbar sei.
Eine weitere Konformitaetspruefung ist uebrigens das "Stuttering", das Antworten mit 1B/s fuer 10 Sekunden.

Jetzt ist die Frage, ob so eine Konfiguration heute noch modern ist.

-> dig MX gmail.com

 

[wstuermer]

Du willst auf jeden Fall das AZ 312 O 142/09 vom LG Hamburg berücksichtigen.

Siehe auch: https://www.haufe.de/recht/newsDetails?newsID=1265276102.36 und diverse andere über Suchmaschinen findbare Quellen

 

[LL0rd]

Der Vorteil eines secondary-MX ist, dass man ihn recht schnell in einen primary umwandeln kann, falls man es aus irgendwelchen Gründen nicht schafft, den ausgefallenen Server zeitnah wieder zum Laufen zu bringen.

Das meiner Meinung nach kein Argument, um einen secondary MX zu betreiben. Ich sichere Server mit einem SLA ab, der defekte Hardware innerhalb von max 4 Stunden ersetzt. Sollte tatsächlich das Betriebssystem defekt sein, so lässt es sich leicht innerhalb von wenigen Minuten aus Backups rekonstruieren. Im Worst Case würde ich auch auf EC2 zurückgreifen und dort schnell einen Mailserver aufsetzen. Die nötigen DNS Records sind dann auch schnell geändert.

Ich meine ausserdem mal in einer c't oder iX gelesen zu haben dass man als Provider dann fuer die Email geradestehen muss da sie akzeptiert wurde und eine Nicht-Zustellung oder verspaetete Zustellung als geschaeftsschaedigend(?) angesehen werden kann.

Ich weiß, was du ansprichst. Ich hatte mich mit meinem Anwalt über dieses Thema mal unterhalten. Es geht darum, dass viele Anbieter auf dem Secondary Mailserver einfach alle Mails annehmen, die ankommen - egal ob es ein Postfach gibt oder nicht, ob spam oder nicht. Wenn der Primary erreichbar ist, wird erst gefiltert. Der Spam wird dann gelöscht. Und genau das darf man nicht, ich darf keine fremden E-Mails nach Erhalt löschen, nur weil ich denke, das es Spam ist.

Viele Server sind heute greylist-gesichert und mit strikter RFC-Ueberpruefung. Nicht nur Banken

Meine Systeme sind es nicht. Denn greylisting verhindert Echtzeitkommunikation. Wenn jemand eine Mail schickt, dann möchte ich die sofort empfangen und nicht erst warten, bis der Mailserver diese freigibt. Aber das kann man auch anders sehen.

Nicht ganz. Der Mailserver sagt nur dass der aktuell dem Benutzer keine Emails zustellen kann, nicht dass er global nicht erreichbar sei.

Ja! Ich behaupte jetzt einfach mal, dass wenn ein Admin sein System so falsch einstellt, dass er die Mails nicht oft genug versucht zuzustellen, es auch mit dem Greylisting nicht klarkommt. Seien wir doch ehrlich, in der Regel sind es doch alte Exchange Kisten, die ******e bauen.

-> dig MX gmail.com

Die wollen sich einfach nicht DDoSen lassen. Stell dir mal vor, deren Server ist jetzt für ne Stunde down. Da wird sich so eine Mail Flut auftürmen, an der deren Mailserver lange arbeiten wird. Außerdem wird google wohl die über den secondary(ff.) empfangenen Mails direkt in eine DB zustellen.

 

[Roger Wilco]

Ich sichere Server mit einem SLA ab, der defekte Hardware innerhalb von max 4 Stunden ersetzt.

Genau, und weil klauen verboten ist, gibt es keine Diebstähle.

Sollte tatsächlich das Betriebssystem defekt sein, so lässt es sich leicht innerhalb von wenigen Minuten aus Backups rekonstruieren. Im Worst Case würde ich auch auf EC2 zurückgreifen und dort schnell einen Mailserver aufsetzen. Die nötigen DNS Records sind dann auch schnell geändert.

Das erfordert alles zu viel Handarbeit und manuelle Eingriffe sind fehleranfällig und teuer. Wenn dein Backup-MX sowieso läuft, kannst du dir diese sparen.

Denn greylisting verhindert Echtzeitkommunikation.

In der Regel blockiert die jeweilige Greylisting-Implementierung die E-Mails eines bestimmten Absenders für eine fest definierte Zeit. Damit ist es Echtzeit – vorhersagbare Verzögerungen.

Davon abgesehen stimmt das Argument nur teilweise, weil die meisten Greylisting-Implementierungen (die man benutzen will) nur die erste E-Mail verzögern. Wenn der Absender bekannt ist, wird kein Greylisting mehr durchgeführt.

Wenn jemand eine Mail schickt, dann möchte ich die sofort empfangen und nicht erst warten, bis der Mailserver diese freigibt.

Ich glaube du möchtest Instant Messaging. Dafür ist E-Mail aber das falsche Werkzeug.

 

[CentY]

Ich betreibe selbst auch einen Backup-MX, da es schon öfter vorgekommen ist, dass bei einem Ausfall des ersten Mailservers Mails nie mehr ankamen. Da manche Firmen keinen erneuten Zustellversuch unternehmen, wenn bei der Zustellung ein Connection refused kommt. Ob das RFC konform ist oder nicht sei dahingestellt. Fakt ist dass ich die E-Mails brauche Deswegen der zweite MX.

Wobei bei mir beide "Frontend"-MX quasi Backupmx sind. Die wirklichen Mailserver mit Postfächern sind andere Maschinen. Wie bei Google, GMX und co. auch.

Grüße

 

[LL0rd]

Genau, und weil klauen verboten ist, gibt es keine Diebstähle.

Sorry, aber das verstehe ich nicht.

Das erfordert alles zu viel Handarbeit und manuelle Eingriffe sind fehleranfällig und teuer. Wenn dein Backup-MX sowieso läuft, kannst du dir diese sparen.

Nee, kannst du dir nicht. Was genau ist ein "Mail-Server"? Es sind mehrere Dienste. Zum einen SMTP für den Mail Transfer + POP3 / IMAP zum Abrufen neuer Mails. Sollte der Haupt-Mailserver down sein, werden die Nutzer des Servers den Secondary nicht nutzen können, weil dort eben kein Dienst läuft, über den die Mails abgerufen werden können. Und auch wenn, sie müssten erst den Server im Mail-Programm umstellen.

In der Regel blockiert die jeweilige Greylisting-Implementierung die E-Mails eines bestimmten Absenders für eine fest definierte Zeit. Damit ist es Echtzeit – vorhersagbare Verzögerungen.

Leider nicht. Die Retry Einstellung des Servers ist eine umbekannte Variable in der Gleichung, die man nicht vorhersagen kann. Die Listen musst du auch irgendwann (zumindest teilweise) leeren, da die sonst die DB vollmüllen.

Ich betreibe selbst auch einen Backup-MX, da es schon öfter vorgekommen ist, dass bei einem Ausfall des ersten Mailservers Mails nie mehr ankamen. Da manche Firmen keinen erneuten Zustellversuch unternehmen, wenn bei der Zustellung ein Connection refused kommt. Ob das RFC konform ist oder nicht sei dahingestellt.

Ich finde, dass es ein Problem des Absenders ist, wenn sein Server falsch eingestellt ist. Ein Connection Refused kann verschiedene Ursachen haben, auf die du z.B. keinen Einfluss hast. Der DNS Server des Absenders kann Down sein oder seine Internetanbindung kann gestört sein. Macht es dann noch sinn wegen diesen wenigen Servern so einen Extra Aufwand zu betreiben?

Fakt ist, dass man den Secondary MX sicherheitstechnisch genauso aufsetzen und warten muss, wie den Primary. Und da denke ich, dass man lieber in die Ausfallsicherheit des Primary investieren. 2009 hatten wir eine gesamte Down Time von etwa 10 Minuten Tagsüber, weil das RZ Probleme hatte und etwa 2 Stunden in der Nacht bei eigenen Wartungsarbeiten.

 

[CentY]

Bei mir syncen die Server einfach Ihre Konfigurationen per rsync. Nachdem sie nur als Relay arbeiten ist das kein Problem. Und beide sind gleich sicher oder unsicher dadurch Wirklich Mehraufwand ist das nicht.

Und wegen dem Zustellproblem bei Connection refused, klar ist es das Problem des Senders. Aber mach das mal nem Kunden von dir klar

 

[cosimo.de]

Wir haben das auch so, daß die MX Relays die Configdaten der Kundensysteme per rsync bekommen und somit gleichwertig sind.

Wenn z.B. das Routing mal zu einem System (warum auch immer) nicht klappt versucht der Mailer es halt am Zweiten. Damit ist die Ursache der Störung zwar nicht behoben aber die Mail zugestellt.

Auch die Lastverteilung läßt sich somit beliebig skalieren.

 

[Roger Wilco]

Sorry, aber das verstehe ich nicht.

Normalerweise plant man für den Worst Case. Wenn es eine Möglichkeit gibt, mit vertretbarem Aufwand Ausfälle zu minimieren, wird diese genutzt.
So ist es zwar schön, dass du mit deinem Provider ein SLA vereinbart hast, aber das heißt nicht, dass dieses im schlimmsten Fall eingehalten wird.
Du schließt deine Haustür oder dein Auto doch trotzdem noch ab, obwohl Diebstahl verboten ist (also ein entsprechendes Agreement in der Gesellschaft existiert).

Was genau ist ein "Mail-Server"? Es sind mehrere Dienste. Zum einen SMTP für den Mail Transfer + POP3 / IMAP zum Abrufen neuer Mails.

Du schriebst ausschließlich von (d)einem Backup MX. Bei Setups, die einen Backup MX erfordern und bei denen das nicht nur eine Spielerei ist, kann man getrost davon ausgehen, dass Mailempfang und Mailspeicherung normalerweise getrennte Systeme sind.

Die Listen musst du auch irgendwann (zumindest teilweise) leeren, da die sonst die DB vollmüllen.

Wie gesagt, die Greylisting-Implementierungen, die man benutzen will, machen das richtig. Oder was ist daran, einen Timestamp in der Datenbank zu aktualisieren, so schwierig? So werden alle E-Mails von Absendern, mit denen man regelmäßig Kontakt hat, immer ohne Greylisting durchgewunken.

Wenn du von einem Absender nur alle 12 Monate eine E-Mail bekommst, machen die 15 Minuten Verzögerung beim Greylisting auch nichts aus.

Der DNS Server des Absenders kann Down sein oder seine Internetanbindung kann gestört sein.

In diesen Fällen erhält der sendende MTA aber sicherlich kein "Connection refused" von dem empfangenden MTA. Es hat übrigens einen Grund, warum alle MTA-Implementierungen eine Warteschlange und entsprechende Retry-Mechanismen enthalten.

Fakt ist, dass man den Secondary MX sicherheitstechnisch genauso aufsetzen und warten muss, wie den Primary.

Klar, aber das ist ja kein Problem.