Einen Mailserver in einem produktiven Umfeld zu migrieren bedeutet auch, dafür zu sorgen dass es möglichst wenig Ausfall / Downtime gibt. Am einfachsten kann man das mit Hilfe einer Parallelinstallation erreichen. Wir möchten also sowas:

Eigentlich ganz einfach, oder? Naja.

Routing

Zu beachten ist das “Mail routing”. Wie werden Mails zwischen dem einen und anderen Mailserver verschickt? Beide Mailserver – wenn man sie gerade frisch installiert hat – halten sich ja erst einmal für den Chef der Domain. Damit ist jede Mailbox, die nicht auf dem lokalen Mailserver vorhanden ist, quasi nicht vorhanden. Aber dieses Szenario besteht, wenn man bereits einige Mailboxen auf den “neuen” Mailserver migriert hat und der größte Teil noch auf dem “alten” arbeitet. Wobei die Größe der Teilmengen dabei natürlich egal ist. Ob nun zwei Mailboxen auf einem anderen Mailserver sind oder das Verhältnis 50:50 – das macht vom Mail routing her keinen Unterschied.

Man muss sicherstellen, dass alle Mailboxen allen Mailservern bekannt sind – und wo. So können prinzipiell beide Mailserver entscheiden ob eine eMail abgewiesen oder zugestellt wird.

Exchange

Da der Exchange Server der aktuelle Master ist, soll er doch – eigentlich ganz einfach – die eMail von bereits umgezogenen Benutzern an den neuen Mailserver weiterleiten. Tja, da waren sie wieder meine drei Probleme. Vielleicht geht das auch irgendwie anders, aber ich habe nur folgende Möglichkeit gefunden:

Damit ein Exchange Server eine Mail zu einem externen Account weiterleitet, muss man einen sogenannten “Kontakt” im Verzeichnis erstellen. Dieser Kontakt besitzt eine externe eMailadresse. Dann kann man über den Account des Benutzers “Exchange erweitert | Zustelloptionen | Weiterleitung” den Namen des neu angelegten Kontaktes angeben – fertig. Die Mails werden dann also über einen lokalen Kontakt nach extern weitergeleitet. Ich hätte mir durchaus vorstellen können eine externe Adresse direkt bei “Weiterleitung” eintragen zu können.

Warum überhaupt extern? Naja, für den Exchange Server ist der neue Mailserver ein externer Server.

Achtung! Stolperfallen!

Der Exchange den ich hier zu verarzten habe, hatte bei dieser Aktion dann noch eine Überraschung für mich übrig. Der Exchange arbeitet so, dass er quasi die Namen vor der Domain abgleicht und wenn er dafür einen Treffer hat, dann wird die Mail zugestellt. Soll heißen: landet die Mail linux-aha@foo.bar auf dem Server und es gibt eine Mailbox mit Namen linux-aha, dann wird sie dem Benutzer linux-aha zugestellt. Landet eine Mail mit linux-aha@dieseDomaingibtesgarnicht.dot auf dem Server, dann wird sie ebenfalls zugestellt. Er achtet wirklich nur auf den User Teil der Adresse. Man darf also als externe Migrationsadresse nicht einfach die Adresse des Benutzers mit einer anderen Domain nehmen, sondern muss sie auch ein wenig ändern. Ich habe einfach eine “2″ an jede Adresse an gehangen.

Die zweite Stolperfalle ist eigentlich nur ein Hinweis. Es gibt einen Haken “Nachricht an Empfänger und alternativen Empfänger übermitteln”. Eigentlich bedeutet dieser nur, dass Mails nicht nur weitergeleitet, sondern auch in der lokalen Mailbox gespeichert werden. Leider hat dieser Haken zur Folge, dass manche (ich habe kein Muster gefunden) eMail doppelt auf dem neuen Mailserver zugestellt werden. Warum auch immer.

Zusammengefasst

Um das routing auf der Exchange Seite zu realisieren habe ich also folgendes gemacht:

  • eine Migraionsdomain im DNS anlegen (migr.DOMAIN.de), sie zeigt auf den neuen Mailserver
  • für jede Mailbox, die auf den neuen Server umzieht, einen Kontakt anlegen – ich habe diese xmigr<USERNAME> genannt
  • die Mailadresse des Kontakts zeigt auf <MAILADRESSE>2@migr.DOMAIN.de (die 2 ist kein Tippfehler -> siehe Stolperfalle)
  • in den Benutzereinstellungen -> Exchange erweitert -> Zustelloptionen -> Weiterleitung den Namen des Kontakts eintragen

Damit schickt der Exchange Server die Mails für die konfigurierten Accounts an migr.DOMAIN.de. Da sollte dann der neue lauschen.

Postfix

Auf der Postfix Seite ist es ein wenig – … – naja, sagen wir mal logischer ;-) Postfix ist installiert mit der eigentlichen Domain. Fühlt sich also dafür zuständig. Nun bekommt er Mails für @migr.DOMAIN.de. Damit er diese nicht abweist, muss er die Migrations Domains kennen. Diese werden in der main.cf hinter den Verweisen auf die Datenbank eingetragen:

virtual_mailbox_domains = proxy:mysql:$config_directory/mysql_virtual_domains_maps.cf,migr.linux-aha.de

Die eMails an @migr.linux-aha.de müssen nun beim Empfang auf @linux-aha.de umgeschrieben werden. Das passiert in der recipient_canonical_map. Darin befindet sich für jede eMailadresse eine Konfigurationszeile, in der die @migr.DOMAIN.de in @DOMAIN.de umgeschrieben wird.

ronny.becker2@migr.linux-aha.de                ronny.becker@linux-aha.de

Damit werden die Adressen umgeschrieben und der Mailserver fühlt sich auch wieder zuständig.

Der zweite Schritt ist, dem neuen Mailserver die auf dem Exchange bekannten Mailadressen bekannt zu machen. Das geht auch recht einfach mit Hilfe der “transport” Datei. In der transport muss für jede Mailbox die sich noch auf dem Exchange befindet ein Eintrag gemacht werden aus dem hervorgeht, wo Postfix diese Mailbox findet. Also:

sacha.nowak@linux-aha.de                  smtp:exchange.linux-aha.de

Mit jedem Umzug muss der passende Eintrag aus der transport gelöscht werden. Um diese Daten zu erstellen bietet sich die Datenbank an, die ich im letzten Artikel beschrieben habe. Diese ist leicht zu aktualisieren und man kann stets aktuelle recipient maps, bzw. transport Dateien erstellen (mit ein wenig scripten und SQL).

Zusammengefasst

Die Anpassungen in Postfix sind also recht übersichtlich. Die beiden Datenbanken pflegen und gut ist. Notwendig ist das ganze nur während der Migration und mit der Datenbank aus dem letzten Artikel als Lieferant der Inhalte, ist es auch recht einfach die Dateien neu zu erstellen.