Linux Exchange Hybrid

Auf der Seite stelle ich eine Konfiguration vor, wie sie Exchange Online mit einem lokalen Linux-Server verbinden und quasi eine partielle "Hybrid-Bereitstellung" erreichen. Es gibt natürlich keine Frei/Belegt-Zeiten und eine Migration geht nur in Richtung Exchange Online aber das Mailrouting kann schon herausfordernd sein.

Diese Beschreibung gilt natürlich für jeden lokalen Mailserver, der nicht Exchange ist.

Worum geht es?

Der klassische Exchange Hybrid Ansatz ist ja klar: On Premises einen aktuellen Exchange Server, welcher mit dem Hybrid Configuration Wizard mit einem Exchange Online Tenant hinsichtlich Mailrouting, Frei/Belegt-Zeiten, OrgRelationShip etc. verbunden wurde wenn wenn man Microsoft folgt, dann senden die Exchange Online User ihre Mails auch selbst ins Internet.

Nun ist die Welt aber nicht ein abgeschottetes Microsoft-Ökosystem sondern es gibt auch noch andere Dienste und insbesondere Behörden, Schulen, Universitäten und auch Mittelständler, die gar kein Exchange "OnPremises" haben. Zwar gibt es wohl kaum noch GroupWise-Installationen und immer weniger Notes-Instanzen aber eine nicht unerhebliche Installation von verschiedenen Linux-basierten Umgebungen, die mit Exchange Online in trauter Koexistenz arbeiten sollen.

Oft ist die etablierte lokale Umgebung so "historisch" gewachsen, dass Sie lange bleiben soll und nur bedingt "kompatibel" mit Exchange Online ist. Daher sollen in meinem Beispiel auch alle Mails über das lokale System versendet werden. Nur so ist z.B. sichergestellt, dass besondere Konfigurationen im lokalen System erst einmal weiter funktionieren.

Ausgangssituation

Wir haben also eine Umgebung mit mehreren Servern und verbundenen Systemen. Hier ein Beispiel. Drehscheibe ist der Linux-basierte Mailserver, mit SMTPD und IMAP4D, welcher seine Informationen aus einem OpenLDAP-Server bekommt. So weiß er immer, welche Postfächer lokal sind und welche vielleicht eine Weiterleitung haben. Die Verbindung zum Internet erfolgt über die vorhanden Spamfilter und links gibt es sicher ganz viele wichtige Prozesse, die ihre Mails per SMTP einliefern. Denken Sie nur mal an Monitoring (Nagios, Icinga, CheckMK, PRTG, etc.) Scanner, Webformulare, CRM/ERP-Systeme etc.

Die Konfiguration im Backend erfolgt meist über ein Provisioning-System. So kenne ich das zumindest von großen Forschungsinstitutionen und Schulen, bei denen Prozesse eher automatisiert ablaufen. Wer will schon jedes Semester oder Schuljahr alle Schüler/Studenten/Professoren manuell löschen, anlegen und den Kursen zuordnen.

Exchange Online Einbindung

In diese Umgebung soll nun Exchange Online integriert werden. Beim Koexistenz-Betrieb gibt es drei Punkte zu beachten:

  • Verzeichnisabgleich
    Das Adressbuch, welches die OnPremises IMAP4-user per LDAP abfragen können, sollte in Exchange Online ebenfalls erreichbar sein. Das ist nicht nur ein Service für die Anwender sondern vor allem optimieren wir so das Mailrouting und verhindern Schleifen und NDRs
  • Mailrouting
    Beim Routing müssen wir sicherstellen, dass der Exchange Online die Mails vom Linux-System als "intern" ansieht, damit auch interne OOF-Meldungen und Regeln greifen können, die ansonsten blockiert sind. Richtung OnPremises darf Linux-System natürlich direkt nur von Exchange Online (Zertifikate, IP-Range) erreicht werden und muss sicherstellen, das nur der eigene Tenant die Vorzugsbehandlung erhält
  • Migration (IMAP4)
    Wenn bestehende Postfächer zu Exchange Online umgezogen werden sollen, dann wäre es nett, wenn die IMAP4-Migrationsunterstützung von Exchange Online genutzt werden kann.

Das Bild wird dann etwas komplexer, weil einige Connectoren dazu kommen, auf die ich gleich noch eingehe. 

Auch beim Provisioning gibt es mehrere Optionen. Ich habe hier das Szenario skizziert, bei dem es ein lokale Active Directory gibt und das Provisioning auch im lokalen AD schon die Mailadresse an die Benutzer anfügt. Idealerweise macht das Provisioning dies schon über die Exchange Management Shell, die auch ohne Exchange Server funktioniert. Diese Information über Mailuser (Postfach auf Unix) oder RemoteMailbox (EXO-Postfach) kann aber EntraID Connect oder Cloud Sync auslesen und ins EntraID und damit auch Exchange Online replizieren.

Wenn Sie kein lokale AD haben und daher auch keinen Microsoft Verzeichnisabgleich nutzen, dann können Sie das ganze Provisioning natürlich auch direkt per Graph machen und die Microsoft 365 Benutzer auch als "Cloud Only"-Konten verwalten.

Das ist aber eher die Minderheit, da die meisten Firmen auch ohne lokales Exchange dennoch ein Active Directory haben, zum die Anmeldung an den Windows Clients und den Zugriff auf andere Dienste per Kerberos, die Client Konfiguration per Gruppenrichtlinien etc. zu vereinfachen.

Anforderungen

Für eine Kopplung eines lokalen Mailsystem mit einem Exchange Online Tenant gelten eigentlich immer die gleichen Anforderungen:

  • Sicher gegen Missbrauch z.B. Relay oder Fremdeinlieferung
  • Sicher gegen Identitätsdiebstahl, z.B. Impersonation
  • Zuverlässig
  • Einfach und Verwaltbar

Dazu müssen bei beiden Systemen jeweils konfiguriert werden.

  • Exchange Online eingehend von OnPremises
    Die Mails vom lokalen Server zu Exchange Online müssen von Exchange Online sicher als "intern" erkannt werden, damit auch die Absender als Intern aufgelöst werden.
  • Exchange Online eingehend aus dem Internet
    Wenn man eingehende Mails nur über OnPremises annehmen will, muss man den Empfang in Exchange Online korrekt unterbinden
  • OnPremises darf nur dem eigenen Exchange Online Tenant vertrauen
    Exchange OnPremises nutzt dazu das Zertifikat der Cloud und die Absenderdomain. Eine IP-Adressfilterung und das Zertifikat reichen hier nicht aus. Man muss schon die Absender/Empfängerdomain oder besser die TenantId zu prüfen.

Connectoren

Vermutlich werden Sie sich nun fragen, warum ich in dem Bild so viele Connectoren eingezeichnet habe. Selbst Exchange Hybrid richtet ja nur zwei Connectoren ein, wie mein Labor-Tenant zeigt:

 

Diese Konfiguration ist ja auch ausreichend, wenn ihre Exchange Online Postfächer selbst Mails direkt in das Internet empfangen dürfen und sie auch kein Problem damit haben, dass jemand direkt an Exchange Online zustellt, z.B. indem er einfach die MOERA-Adresse nutzt. Das passt aber in meinem anfangs skizzierten Gesamtbild nicht. Ich möchte ja über OnPremises die Mails bekommen und auch senden. Der Inbound Connector hat folgende Defaults:

PS C:\> Get-InboundConnector in* | fl

Enabled                        : True
ConnectorType                  : OnPremises
ConnectorSource                : HybridWizard
SenderDomains                  : {smtp:*;1}
RequireTls                     : True
RestrictDomainsToIPAddresses   : False
RestrictDomainsToCertificate   : False
CloudServicesMailEnabled       : True
TreatMessagesAsInternal        : False
TlsSenderCertificateName       : EX01.uclabor.de
EFSkipLastIP                   : False
EFSkipIPs                      : {}
EFSkipMailGateway              : {}
EFUsers                        : {}

Schon wenn ich mit den "Inbound Connector" anschaue, dann sind einige Einstellungen falsch:

  • CloudServicesMailEnabled
    Exchange Online "erkennt" den OnPremises Exchange Server und behandelt die Mails dann als "Intern" mit Folgen für die Anzeige in Outlook (ohne SMTP-Adresse), Regeln und OOF-Meldungen. Ein Linux-System kann aber nicht die "erweiterten Funktionen" des Exchange SMTP-Protokolls und profitiert daher nicht davon
  • EF
    Enhanced Filtering ist ausgeschaltet. Exchange Online würde dann die IP-Adresse des einliefernden Linux-Servers für die SMTP-Prüfung heranziehen. Auch hier muss ich gegensteuern.

Wenn Sie aber keine lokale Exchange Installation haben, können Sie auch keinen HCW - Hybrid Configuration Wizard nutzen. Daher müssen wir die Connectoren manuell anlegen. Da über das Exchange Admin Center nicht alle Optionen erreichbar sind, mache ich das direkt per Exchange Online PowerShell für folgende Connectoren

Sie sollten in ihrem Tenant keine Inbound/Outbound-Connectoren haben, die per HCW angelegt wurde. Die folgende Konfiguration gilt nur für einen Tenant der noch keine Connectoren hat.

Connector: Linux zu EXO

Wir kümmern uns zuerst einmal um den Weg von OnPremises zu Exchange Online. Jeder Tenant in Exchange Online hat zwei Domain, die Microsoft nach einem bestimmten Schema bereitstellt

<tenantname>.onmicrosoft.com
<tenantname>.mail.onmicrosoft.com

Jeder Exchange Empfänger bekommt zumindest eine Adresse in der Domain "<tenantname>.onmicrosoft.com".

Damit ist dies auch immer die Zieladresse, wenn Sie Mails von einem OnPremises System an eine Exchange Online Mailbox senden wollen. Im lokalen System konfigurieren Sie für diese Empfänger daher eine Umleitung zu Exchange Online und routen diese Domain zu Exchange Online. Damit ist der erste Connector beschrieben:

Route mails an "*@<tenantname>.onmicrosoft.com" an MX-Record (oder über Smarthost an MX)

Das Ziel ist nun die Frage: Microsoft veröffentlicht MX-Record für die onmicrosoft.com-Domain ihres Tenants.

Wenn ihr lokales System direkt Exchange Online über Port 25 erreichen und per DNS auflösen kann, dann ist dies der ideale Weg. Wenn Sie noch den klassischen Aufbau mit einem Relay in einer DMZ davor nutzen, dann muss ihr Mailsystem alle Mails an das Relay zustellen, welches dann die Verbindung zu Exchange Online aufbaut.

Ratschlag: Wenn Sie können, dann sollten Sie auf der ausgehenden Verbindung zwingend STARTTLS aktivieren, damit die "internen Mails" verschlüsselt übertragen werden.

Die Konfiguration solcher Routen ist vom eingesetzten Mailsystem und Relay abhängig. Bitte konsultieren Sie dazu ihre Dokumentation 

Connector: Inbound OnPremises "OnPrem2EXO"

Auf der anderen Seite kommt ihr Server nun bei Exchange Online mit seiner IP-Adressen und idealerweise auch mit einem Zertifikat an aber für Exchange Online erfährt ihr lokales System erst einmal keine Sonderbehandlung. Dazu müssen wir mittels eines "Inbound Connector" in Exchange Online eine abweichende Behandlung definieren. Wir benötigen dafür die IP-Adresse oder besser das Zertifikat, mit dem sich ihr Mailserver oder Relay bei Exchange meldet.

Wenn Sie statt eines Zertifikats eine IP-Adresse als Kriterium nutzen, sollte diese Adresse nicht von anderen Systemen nutzbar sein. Eine generische NAT-Adresse, die von allen ausgehenden Verbindungen verschiedener Systeme genutzt wird, ist eine sehr schlechte Idee, da diese immer dem eigenen Tenant zugeordnet wird und viele Rechte hat.

Damit können wir Exchange Online dazu bringen, die Mails vom lokalen Mailsystem als "vertrauenswürdig" anzusehen. Dazu legen wie einen OnPremises-Connector mit folgenden Daten an:

  • Name: OnPrem2EXO
  • ConnectorType: OnPremise
  • TreatMessagesAsInternal:$true
    Damit betrachtet Exchange jede Mail über diesen Connector als "Internal", wenn der Absender aus einer Accepted Domain ist. Wenn ich den bei der Anlage schon angebe, dann brauche ich "CloudServicesMailEnabled" nicht explizit auf $false setzen.
  •  SenderIPAddresses "80.66.20.0/24"  -SenderDomains "*"
    Ich habe in meinem Lab mich auf den OnPremises IP-Bereich beschränkt. Das ist genau genommen zu freizügig. In einer produktiven Umgebung würde ich immer mit Zertifikaten arbeiten. d.h. der Linux-Server meldet sich mit einem öffentlichen Zertifikat, welches Exchange prüft. Mit IP-Adressen könnten sich auch andere Server hinter der gleichen NAT-Firewall das Vertrauen erschleichen und Exchange Online als Relay verwenden!
  • EFSkipLastIP:$true
    So sage ich Exchange, dass er nicht die IP-Adresse des einliefernden System für den SPF-Check nutzen soll, sondern die "Received-By"-Zeilen zurück laufen soll. Wenn sie OnPremises selbst öffentliche Adressen verwenden, dann sollten Sie hier besser über den Parameter "EFSkipIPs" ihre OnPremises-Adressen aufführen.

Microsoft beschreibt die Funktion von "TreatMessagesAsInternal" als:

Came into Exchange Online via an inbound connector with TreatMessagesAsInternal set to “true” and the sender is an accepted domain.
Quelle: https://techcommunity.microsoft.com/blog/exchange/demystifying-and-troubleshooting-hybrid-mail-flow-when-is-a-message-internal/1420838 

New-InboundConnector `
   -Name "OnPrem2EXO" `
   -ConnectorType OnPremise `
   -TreatMessagesAsInternal:$true `
   -RestrictDomainsToIPAddresses $true `
   -SenderIPAddresses "80.66.20.0/24" `
   -SenderDomains "*" `
   -EFSkipLastIP:$true

 

Hier dann die Einstellungen im Exchange Admin Center.

Die Checkbox bei "Retain internal Exchange Mail Headers" ist für die Funktion nicht weiter relevant, da der lokale Linux-Server sowieso keine "X-MSExchange-*"-Header addiert, die beibehalten werden müssten.

Analog sollten Sie nun auf dem Linux-System natürlich einen Connector zu Exchange Online einrichten, denn die Empfängerdomain auf "<tenantname>.onmicrosoft.com>" oder "<tenantname>.mail.onmicrosoft.com>" verweist.

Achtung:
Routen sie bitte nicht "*" zu diesem Exchange Online Service, denn jeder, der die Kriterien erfüllt, kann in der Standardkonfiguration über Exchange Online als Relay ins Internet senden.

Wenn Sie dann vom lokalen Server eine Mail mit ihrer Absender-Domain an einen Exchange Online Empfänger senden, sollte dieser in Outlook oder OWA der Absender keine SMTP-Adresse enthalten. Hier zwei Beispiele vom gleichen Server vor und nach Einrichtung des Connectors:

Die hintere Mail zeigt durch die SMTP-Adresse an, das die Mail "anonym" eingeliefert wurde während bei der vorderen Mail (Grün) Exchange die Absenderadresse sogar auf den Displaynamen aufgelöst hat. Sie können und sollten das auch im Header der Mail kontrollieren:

# Interne Mail"
X-MS-Exchange-Organization-MessageDirectionality: Originating 
X-MS-Exchange-Organization-AuthAs: Internal 
X-MS-Exchange-Organization-AuthSource: TreatMessagesAsInternal-FR3PEPF00000487.DEUP281.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=<guid>;Ip=[80.66.20.16];Helo=[uclabor.de] 
X-MS-Exchange-CrossTenant-AuthAs: Internal 
X-MS-Exchange-CrossTenant-AuthSource: TreatMessagesAsInternal-FR3PEPF00000487.DEUP281.PROD.OUTLOOK.COM 
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem

Damit wissen Sie, dass die Konfiguration passt. Folgende Zeilen zeigen eine anonyme Mail:

# Anonyme Mail
 
X-MS-Exchange-Organization-MessageDirectionality: Incoming
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-AuthSource: FR3PEPF00000487.DEUP281.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet

Ihr Ziel ist, dass Mails vom Absendern auf ihrem lokalen Linux Server als "Internal" gewertet werden aber externe Mails weiterhin als "extern" zählen.

Achtung: Wenn der Absender nicht auflösbar ist, dann landet die Mail mit vielen Warnungen eventuell in Junk-E-Mail. Ein vollständiger Verzeichnisabgleich ist ratsam:

Connector: Inbound Partner BlockInet2EXO

Der zweite Connector hat das Ziel, den Hintereingang zum Tenant zu verschließen. Ohne diese Vorkehrungen könnte jemand den MX-Record ignorieren, wenn er weiß, dass Sie einen Microsoft 365 Tenant haben oder er sendet direkt an die MOERA - Microsoft Online Email Routing Address. Das ist auch in Firmen ein Thema, wenn Sie bei ihrem eigenen Spamfilter z.B. SMIME/PGP-Decryption machen, Warnungen/Disclaimer addieren oder z.B. ein JournalArchiv  angebunden haben.

Diese Einstellung verhindert, dass jemand direkt an ihren Exchange Online Tenant Mails zustellt, wen sie nicht über den vorher angelegten Connector "OnPrem2EXO" ankommen.

Hier kommt es nun etwas auf ihre individuelle Konfiguration an denn in meinem Beispiel kommt sowohl interne Mails vom lokalen Linux als auch Mails aus dem Internet über das Linux-System über den gleichen Quellserver mit der gleichen IP-Adresse und dem gleichen Zertifikat. Ich kann aber keinen "Partner Connector" für den Adressraum "*" und den gleichen Bedingungen wie den Connector "OnPrem2EXO" anlegen.

# Das geht nicht !!

New-InboundConnector `
   -Name "BlockInet2EXO" `
   -ConnectorType partner `
   -RestrictDomainsToIPAddresses:$true `
   -SenderIPAddresses "80.66.20.0/24" `
   -SenderDomains "*" `
   -EFSkipLastIP:$true

Ich kann es versuchen, aber das Ergebnis ist aber eine Warnung

Der Connector kommt so also nicht zur Wirkung, denn der vorher angelegte OnPremises-Connector "OnPrem2EXO" belegt schon diesen Eintrag. Das ist aber kein Problem, denn alle Mails aus dem Internet kommen schon über den Weg an und ich kann einfach einen Connector anlegen, der eine IP-Adresse oder einen Namen nutzt, der nie verwendet wird. Ich bevorzuge einen Namen.

# Das ist besser

New-InboundConnector `
   -Name "BlockInet2EXO" `
   -ConnectorType Partner `
   -RestrictDomainsToCertificate:$true `  `
   -TlsSenderCertificateName "noentry.msxfaqlab.onmicrosoft.com" `
   -RequireTls:$true `
   -SenderDomains "*" `
   -EFSkipLastIP:$true

Wenn Sie allerdings von anderen Systemen, z.B. einem vorgelagerten Spamfilter Mails direkt in Exchange Online annehmen wollen, dann sollten hier hier das Zertifikat des einliefernden Systems hinterlegen und bei mehreren Systemen entsprechend mehrere Connectoren. Wenn wir aber die Mails wie auf der Musterkonfiguration dieser Seite sowieso nur vom OnPremises Server bekommen sollen, dann ist die Blockade die richtige Konfiguration

Connector: Outbound OnPremise EXO2OnPrem

Dieser Connector sorgt dafür, dass alle Mails an die eigenen Domains, die keinen Empfänger in Exchange Online haben, den Weg zum lokalen Linux-Server finden. Wäre lokal ein Exchange Server, dann könnte dieser mit den Exchange SMTP-Erweiterungen und der Auswertung von Exchange Headern von weiteren Vorteilen profitieren. Das ist hier aber nicht der Fall. Dennoch möchte ich sicherstellen, dass Mails an den lokalen Server auf jeden Fall TLS-gesichert übertragen werden.

New-OutboundConnector `
   -Name "EXO2OnPrem" `
   -AllAcceptedDomains:$true `
   -ConnectorType OnPremises `
   -Enabled:$true `
   -SmartHosts hybrid.uclabor.de `
   -UseMXRecord:$false `
   -TlsSettings CertificateValidation

Verwenden Sie hier bitte nicht "*" als Addressraum für den OnPremises-Connector. Exchange blockiert dies, wenn Sie nicht zugleich die Option "RouteAllMessagesViaOnPremises:$true" setzen.

Damit laufen Sie aber in Probleme des Centralized Mail Transport, dass dann alle Mails über OnPremises geroutet werden, wenn diese "anonym" eingeliefert werden. Bei einem Partner-Connector ist dies wieder problemlos möglich. Exchange Online wird sich dann bei dem angegeben Smarthost mit "protection.outlook.com" melden. OnPremises sollten Sie den Empfang wie folgt absichern:

  • Firewall:-Source-IP 
    Die Verbindung zu ihrem Mailserver "hinter" ihrer Spamfilter-Lösung sollte nicht aus dem Internet erreichbar sein. Daher sollten Sie eingehende Verbindungen auf Port 25 über die Firewall auf die IP-Adressen von Exchange Online beschränken.
  • TLS-Prüfung
    Wenn möglich sollten Sie auch das Client-Zertifikat von Exchange Online prüfen, ehe sie Exchange Online "vertrauen".
  • TenantID
    Mit den beiden Einstellungen könnte aber immer noch jeder Tenant direkt ihre OnPremises Server erreichen. Prüfen Sie daher im SMTP-Header die "X-MS-Exchange-CoressTenant-Id" auf die GUID ihres eigenen Tenants und blockieren sie alle anderen "Direktzusteller".

    Senden sie einfach eine Mail aus ihrem Tenant an einen externen Empfänger und holen Sie sich den Wert auf dem Header. Das gilt natürlich nur, wenn regulär eingehende Mails einen anderen Weg über ihren Spamfilter nutzen.

Wenn Sie den vierten Connector einrichten, den ich gleich beschreibe, dann brauchen Sie diesen Connector eigentlich nicht. Allerdings richte ich ihn dennoch lieber ein, denn SMTP-Routing kann sich ja auch einmal ändern und der Connector EXO2OnPrem ist wirklich nur für die interne Kommunikation von Exchange Online zum OnPremises System zuständig.

Connector: Outbound Partner EXO2OnPrem2Inet

Am Anfang habe ich ja geschrieben, dass in meinem Beispiel auch die Mails ins Internet über die OnPremises-Umgebung gehen sollen. Dazu muss ich nun natürlich noch einen entsprechenden Connector einrichten:

Damit der Connector funktioniert, müssen Sie OnPremises natürlich ihren Exchange Online Tenant als "Relay" erlauben. Hier sind die frei Filter-Kriterien des vorherigen Abschnitts, (Source-IP, EXO-Zertifikat und Tenant-Id

Für die Konfiguration dieses Routings gibt es zwei Möglichkeiten, die unterschiedliche Vor- und Nachteile haben:

  • Outbound Connector Adressraum "*"
    Sie können einen Partner Connector für alle Domains einrichten.
  • Outbound Connector mit Transportregel
    Sie legen einen Connector mit Smarthost zu ihrem lokalen Linux-System an, welcher durch eine Transportregel adressiert wird. Über die Transportregel können Sie dann sehr viel feiner steuern, ob alle oder nur ausgewählte Mails zum OnPremises-Server gehen sollen.

Wenn sie wirklich alle Mails zu jeder Zeit über den OnPremises Server routen wollen, dann ist ein Partner-Connector mit dem Adressraum "*" am sichersten und einfachsten.

New-OutboundConnector `
   -Name "EXO2OnPrem2Inet" `
   -RecipientDomains * `
   -ConnectorType Partner `
   -Enabled:$true `
   -SmartHosts hybrid.uclabor.de `
   -UseMXRecord:$false

Wenn die diesen Connector nicht anlegen, dann sendet Exchange Online eigenständig die Mail über den MX-Record an das Ziel und umgeht ihre OnPremises Welt. Denkbar ist auch ein Smarthost bei einem Spamfilter, der ihre Mails dann ins Internet sendet und den lokalen Mailserver umgeht,

Es gibt aber auch das Risiko von Schleifen, wenn Sie in der lokalen Umgebung ähnliche "*"-Routings nutzen. Hier sind Transportregeln flexibler, wenn Sie erst einmal mit "Alle externen Mails" anfangen wollen aber schon absehbar ist, dass sie doch je nach Ziel oder Quelle vielleicht unterschiedliche Versandwege einschlagen wollen.

IMAP4 Migration

Zuletzt bleibt die Frage der Postfachinhalte. Wenn Sie Postfächer zwischen dem lokalen Linux-SMTP/POP/IMAP-Server und Exchange Online verschieben wollten, dann können Sie mit Bordmitteln nur eine Migration zu Exchange Online recht elegant ausführen.

Ihr IMAP4-Server muss dazu natürlich aus dem Internet oder zumindest von Exchange Online erreichbar sein und eine einfache Anmeldung per "Basic" oder "NTLM" unterstützen. Sie legen dann einen "IMAP4-Migration Endpoint" zu ihrem OnPremises Server an und übergeben eine Liste der IMAP4-Adressen samt Zugangsdaten.

Exchange Online verbindet sich dann mit der Quelle und synchronisiert alle Mails in die Exchange Online Postfächer. Der Prozess ist vereinfacht:

  1. Exchange Online Postfächer anlegen
    Damit dieIMAP4-Migration ein Ziel hat. Wenn Sie verhindern wollen, dass dort schon Mails landen, sollten Sie eine Weiterleitung zum Quellpostfach konfigurieren
  2. IMAP4-Migration/Synchronisation
    Mit Exchange Online lassen Sie alle Mails der Quelle ins Ziel synchronisieren. Der Anwender kann weiterhin lokal weiterarbeiten
  3. Umschaltung
    Die Entfernen die Weiterleitung im Ziel und tragen stattdessen in der Quelle eine Weiterleitung ins Ziel. Idealerweise auf die MOERA - Microsoft Online Email Routing Address ein. Sie informieren den Anwender, dass neue Mails nur noch im neuen Postfach ankommen und er seinen Client entsprechend umstellt.
  4. Rückbau
    Die Exchange Migration repliziert die letzten lokalen Updates, ehe Sie dann das lokale Postfach entfernen.

Natürlich können Sie den Umzug auch durch den Anwender selbst durchführen lassen. Die meisten IMAP4-Programme erlauben die Einbindung von zwei Postfächern und der Anwender verschiebt einfach die Mails, die er behalten möchte. Es gibt auch 3rd Party Programme zur Migration. Mit denen können Sie dann auch in die Gegenrichtung migrieren.

Zusammenfassung

Mit der richtigen Konfiguration seitens Exchange Online aber auch dem lokalen Linux-System können Sie eine problemlose und sichere Verbindung zwischen einem lokalen Linux-Mailsystem und Exchange Online herstellen, bei denen die Verbindungen per TLS verschlüsselt sind, die Mails vom Linux-System in Exchange Online als "Intern" angesehen werden, so dass Regeln, OOF, Absenderbuchanzeige funktionieren und interne Mails auch beim Linux-System sicher empfangen werden können.

Es gibt aber keine Unterstützung durch einen Hybrid Configuration Wizard oder Dokumentationen bei Microsoft und die Migration per IMAP4 geht nur in Richtung Cloud. Eine Zusammenarbeite mit Frei/Belegt-Zeiten in Kalendern geht ebenso wenig wie ein Zugriff von Microsoft Teams auf ein OnPremises IMAP4-Postfach.

Dennoch ist die Konfiguration schnell und sicher möglich. Sie müssen sich aber um das Provisioning und den Verzeichnisabgleich kümmern, damit Exchange Online auch die lokalen Postfächer kennt und die Absender zuordnen kann. Ansonsten landen doch wieder viele Mails in Junk-E-Mail.

Weitere Links