HanSolo: E-Mails trotz Domänenwechsel ohne Ausfall erreichbar

Hallo,

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. 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. 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. 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?

  1. Gibt es hier vielleicht irgendeine tolle Technik die mir helfen könnte dieses Problem zu umgehen?

    MX-Records mit verschiedenen Prioritäten sind die übliche vorgehensweise, ist einer nicht erreichbar, greift der andere - Stichwort "Backup MX".

    Dieser Backup-Mailserver behält die Mails in "alle Ewigkeit" auf und versucht sie in regelmäßigen Abständen an den primären MX weiterzuleiten - erst dann werden sie aus seiner Liste entfernt.

    1. MX-Records mit verschiedenen Prioritäten sind die übliche vorgehensweise, ist einer nicht erreichbar, greift der andere - Stichwort "Backup MX".

      Nachtrag:

      die vorgehensweise ist dann aber folgende: Mailserver behalten und Domain transferieren, nach erfolgtem Domaintransfer den Mailserver wechseln.

      Beides gleichzeitig ist wenig schlau - ich würde dir tendentiell dazu raten, es jemanden machen zu lassen, der sich mit "sowas" auskennt.

  2. Mahlzeit HanSolo,

    Ich kündige die Domäne beim alten Hoster und beantrage die gleiche Domäne sofort danach beim neuen Hoster.

    Das solltest Du besser nicht tun. Stattdessen solltest Du beim neuen Hoster einen sog. KK-Antrag stellen.

    Das was mir momentan Gedanken macht sind die E-Mails, die die einzelnen Mitarbeiter des Unternehmens haben (an die Domäne gebunden).

    Wieso? Die liegen doch sinnvollerweise auf dem Mailserver herum. Was sollte mit denen sein?

    Wenn ich die Domäne kündige, dann sind die E-Mails ja auch verschwunden

    Nein, ganz sicher nicht.

    und ich muß alle wieder neu beim neuen Hoster anlegen.

    Ach, Du meinst E-Mail-Konten? Ja, die müsstest Du in der Tat beim neuen Hoster wieder anlegen ... jedenfalls, wenn die Firma nur so ein Webspace-Paket "inkl. x E-Mail-Adressen" ihr eigen nennt.

    Natürlich müssen dann auch bei sämtlichen Kollegen wieder die POP bzw. SMTP Einstellungen angepasst werden.

    Sinnvollerweise solltest Du eher auf IMAP umstellen.

    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.

    Das kommt darauf an. Und zwar darauf, ob Du bzw. der neue Hoster den Umzug sinnvoll plant und durchführt. Darüber solltest Du Dich *VORHER* ausführlich informieren.

    MfG,
    EKKi

    --
    sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
  3. 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

  4. Hallo HanSolo

    Ich kündige die Domäne beim alten Hoster und beantrage die gleiche Domäne sofort danach beim neuen Hoster.

    Das könnte Probleme geben.
    Ich würde erst den Vertrag mit dem neuen Hoster machen, dort alles vorbereiten, und erst dann die Domain per KK-Antrag umziehen.

    Das was mir momentan Gedanken macht sind die E-Mails, …

    Mir geht es ähnlich. Ich traue mich nicht den Provider zu wechseln, weil ich nicht weiß, wie ich zuverlässig die Mailpostfächer umziehen kann. Es sind zwar keine Mitarbeiter-Postfächer aber mehrere eigene und ein paar von meinen Kindern (verschiedene Adressen für verschieden Zwecke). Teilweise sind es IMAP-Postfächer mit bis zu 0,5 GB Inhalt.

    Auf Wiederlesen
    Detlef

    --
    - Wissen ist gut
    - Können ist besser
    - aber das Beste und Interessanteste ist der Weg dahin!
    1. Seid gegrüßt!

      [..] Teilweise sind es IMAP-Postfächer mit bis zu 0,5 GB Inhalt.

      Sichere dir diese lokal auf deinem Rechner mit einem entsprechenden Client (Ich glaub Outlook kann das). Dann richtest du die Postfächer beim neuen Provider ein und sicherst die E-Mails zurück. Dauert ganz schön lang, geht aber.

      --
      Bis Später
      RuD
      ________________________________________________________________
      SelfCode: ie:% fl:( br:^ va:) ls:< fo:| rl:( n4:& ss:) de:> js:| ch:| mo:| zu:)
  5. Seid gegrüßt!
    Ich würde folgendermaßen vorgehen:
    Bestelle die Domain beim neuen Hoster. Dort wird i.d.R. alles eingerichtet, damit "nur noch die Domain" umziehen muss. Soll heißen der Server (auch die Mailserver) "kennen" diese Domain bereits und können damit arbeiten.

    Du richtest alle Mail-Adressen beim neuen Hoster ein und lässt du die MX-Einträge noch beim alten Provider auf die Mailserver des neuen Providers umleiten. Dies muss nicht sofort funktionieren (Stichwort: TTL / Nameserver-Aktualisierung). Lass dir dafür die MX-Einträge geben, welche auch nach einem Transfer funktionieren.

    Wenn die E-Mails -also alle- dann beim neuen Hoster ankommen, stellst du alle Clients um und die Clients greifen auf die eingerichteten Mailkonten zu und können -trotz noch nicht umgezogener Domain- die E-Mails bereits beim neuen Hoster bearbeiten.

    Zwischenzeitlicht kannst du ja auch schon die neuen Inhalte der Internetseite beim neuen Hoster hinterlegen, um die Downtime der Seite zu reduzieren.

    Jetzt erst kündigst du die Domain beim alten Hoster und lässt bei neuen Provider den Transfer der Domain einleiten.

    Die Domain zieht um und die E-Mails werden unverändert angenommen /  versendet.

    --
    Bis Später
    RuD
    ________________________________________________________________
    SelfCode: ie:% fl:( br:^ va:) ls:< fo:| rl:( n4:& ss:) de:> js:| ch:| mo:| zu:)
  6. Hallo,

    scheint ja keine ganz triviale Sache zu sein. Der Grund des Umzugs ist im Prinzip auf Typo3 zurückzuführen. Ich selbst hab eine Domäne bei all-inkl.com. Bin SEHR zufrieden mit dem Support und auch mit der Typo3-Unterstützung, deshalb der geplante Umzug.

    Wenn das allerdings ein so komplexes Unterfangen ist, wäre wohl das beste erstmal zu testen, ob der alte Hoster nicht eine ähnlich gute Typo3 Unterstützung hat, so das ich den Umzug vermeiden könnte. Was meint ihr dazu?

    1. Hi,

      Der Grund des Umzugs ist im Prinzip auf Typo3 zurückzuführen.

      Und nicht im Prinzip, sondern konkret gesprochen bedeutet das - was?

      Wenn das allerdings ein so komplexes Unterfangen ist, wäre wohl das beste erstmal zu testen, ob der alte Hoster nicht eine ähnlich gute Typo3 Unterstützung hat, so das ich den Umzug vermeiden könnte. Was meint ihr dazu?

      "Das Beste" wäre m.E., erst mal genau zu definieren und spezifizieren, welche Anforderungen an den Hosting-Service zu stellen sind - aktuell, und auch was evtl. geplante zukünftige Erweiterungen angeht.
      Dann mit dem aktuellen Hoster sprechen und ggf. verhandeln, ob und zu welchen Konditionen er diese zu erfüllen vermag.

      Denn ein jetzt auf Grund des Aufwandes gescheuter Wechsel, der dann in einem halben oder einem Jahr doch wieder nötig wird, weil sich seitens deiner Firma die Anforderungen erweitert haben (nicht mehr "nur" Typo3, sondern auch X, was seinerseits wieder besondere Bedingungen an eine Hosting-Umgebung stellt) - der hilft dir auf Dauer auch nicht weiter. (Höchstens in so fern, dass er dir mehr Zeit zur konkreten Planung gibt, im Gegensatz zu einem spontanen "Schnellschuss" zum jetzigen Zeitpunkt. Aber deshalb, s.o. - erst mal die exakten Anforderungen genauer definieren [lassen].)

      MfG ChrisB

      --
      Light travels faster than sound - that's why most people appear bright until you hear them speak.