Sven Rautenberg: E-Mails trotz Domänenwechsel ohne Ausfall erreichbar

Beitrag lesen

Moin!

ich habe die Ehre, die Webseite meiner Firma neu erstellen zu dürfen. Die aktuelle Domäne soll natürlich beibehalten werden. Aus mehreren Gründen will ich aber den Hoster wechseln.

Dann beachte, dass Hosting von Web (HTTP), Mail-Empfang bzw. -Versand (SMTP) und Postfächern (POP3, IMAP) nichts miteinander zu tun haben muss, und insbesondere unabhängig von dem Verwaltungsort des Nameservers ist.

Grundsätzlich ist das ja kein Problem. Ich kündige die Domäne beim alten Hoster und beantrage die gleiche Domäne sofort danach beim neuen Hoster.

Mit DER Vorgehensweise riskierst du, dass die Domain flöten geht. Domains gehören nie gekündigt, sondern direkt zum neuen Domainprovider transferiert. Bei .de-Domains beispielsweise mit KK-Antrag, bei com/net/org ist das Verfahren etwas anders und leicht komplexer, funktioniert aber ebenfalls. Kontaktiere den neuen Hoster im Vorfeld dazu.

Das was mir momentan Gedanken macht sind die E-Mails, die die einzelnen Mitarbeiter des Unternehmens haben (an die Domäne gebunden). Wenn ich die Domäne kündige, dann sind die E-Mails ja auch verschwunden und ich muß alle wieder neu beim neuen Hoster anlegen.

Du verwechselst hier zwei paar Dinge: Die Konfiguration des Mailservers einerseits (mit darauf existierenden Accounts für die Mitarbeiter), und die Location des DNS-Servers andererseits.

Logischerweise muss, wenn der Mailserver gewechselt werden soll, der neue Server so konfiguriert werden, dass der alte Zustand wieder erreicht wird. Das ist aber unabhängig davon, was der DNS-Server über die Zuständigkeit des Mailservers aussagt.

Natürlich müssen dann auch bei sämtlichen Kollegen wieder die POP bzw. SMTP Einstellungen angepasst werden. In der Übergangsphase (nach der Kündigung der alten Domäne und bevor auf der neuen die gleichen E-Mails wie vorher angelegt sind und alles an den jeweiligen Workstations umgestellt ist) ist das Unternehmen ja dann im Prinzip nicht per Mail zu erreichen. Diesbezüglich habe ich irgendwie ein ungutes Gefühl. Gibt es hier vielleicht irgendeine tolle Technik die mir helfen könnte dieses Problem zu umgehen?

Ein Umzug von mehr als nur HTTP auf einen neuen Server ist ein komplexes Unterfangen und erfordert in jedem Fall einen gewissen Parallelbetrieb von alten und neuen Servern (Plural für den Fall, dass mehrere Maschinen im Einsatz sind - Server-Daemons sind es in jedem Fall).

Sprich: Die neue Maschine wird geordert und ist schon mal verfügbar, um konfiguriert zu werden. Wenn das alles prima funktioniert (testbar, indem man lokal, z.B. via hosts-Datei, die DNS-Angaben überschreibt), kann der DNS-Server umgeschwenkt werden auf die neue IP. Das entweder gleichzeitig mit dem Wechsel des DNS-Servers, also als Domain-Transfer, oder nacheinander.

Wenn der alte Provider keine manuelle Konfiguration des DNS zuläßt (indem man dort die IP des neuen Servers für alle benötigten Dinge eintragen kann), aber der neue, dann wäre ein Weg, dem neuen Domainhoster erstmal die IP des alten Servers für alle notwendigen Domains zu konfigurieren, die Domain zu transferieren, und danach bei Fertigstellung aller Arbeiten umzuschwenken. Umgekehrt (nur der alte Provider erlaubt freie IPs) wäre die Reihenfolge logischerweise genau umgekehrt, wenngleich ich das als Verschlechterung der Leistung ansehen würde. Wenn beide die Option anbieten, bist du in deiner Wahl komplett frei, und wenn keiner das macht, hast du nur die Chance, durch den Domaintransfer auch den DNS umzuschwenken. Weil Domaintransfers aber nun mal eine gewisse Zeit benötigen (auch wenn man sich wünscht, dass das instant sofort ginge), hast du in diesem Fall einen gewissen Kontrollverlust über den Vorgang. Insbesondere könnte er einstweilig scheitern oder sich hinauszögern, weil irgendeine beknackte Info doch noch nicht vorhanden ist (bei .de eher nicht, das KK-Verfahren läuft sehr robust und mehrheitlich automatisiert, andere TLDs haben dazu aber das Potential).

Damit nun keine Mails verlorengehen, die über einen gewissen Zeitraum während der Umstellung je nach Lebensdauer der DNS-Einträge von Mailservern noch ans alte Ziel zugestellt werden könnten, sind zwei Methoden vorstellbar.

Methode 1 wäre der sanfte Weg: Der alte Mailserver wird als zweitrangiger MX im DNS eingetragen, der neue Mailserver als primärer MX. Das sorgt dafür, dass fast alle Mailserver der Welt bei Kenntnis dieser DNS-Eintragung den neuen Mailserver ansprechen. Alle Mailserver, die den alten MX-Eintrag noch kennen, senden die Mails an den alten Server, deshalb muss der so konfiguriert werden, dass er die empfangenen Mails direkt zum neuen erstrangigen MX (dem neuen Mailserver) weiterleitet.

Methode 2 muss angewendet werden, wenn die Konfiguration des alten Mailservers zum Forwarder nicht funktioniert. Dann wird nur der neue Server als MX eingetragen, und den alten Server muss man einfach hart abschalten, oder falls dies nicht geht, die Annahme von Mails mit temporärem Fehlerstatus verweigern. Die einliefernden Mailserver werden dann über einen längeren Zeitraum versuchen, die Mails erneut zuzustellen, und irgendwann durch den neuen DNS-Eintrag beim neuen Mailserver landen, und erfolgreich sein.

Davon unabhängig muss natürlich der Transfer der Postfächer der Mitarbeiter erfolgen. Dieser Vorgang wird sich nicht komplett ohne Unterbrechung der Verfügbarkeit erledigen lassen, kann aber beispielsweise in eine Zeit der Nichtnutzung (Wochenende) gelegt werden, sofern die Herrschaft über das DNS-System besteht. Auch ein Parallelbetrieb beider Server ist denkbar - eigentlich jedes vernünftige Mailprogramm sollte in der Lage sein, mehr als einen POP3- bzw. IMAP-Account zu verwalten. In diesem Fall sind halt zwei DNS-Namen für die beiden Server anzulegen.

Insgesamt sehe ich eigentlich keinen Grund, dass der Vorgang nicht funktionieren sollte - aber abhängig von dem Level an Einflussmöglichkeit auf die DNS-Konfiguration kann es halt in "alles auf einmal" ausarten - und das möchte man eventuell vermeiden.

- Sven Rautenberg