MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Exchange Client Connections

Früher war es einfach. Ein Mail-Client verbindet sich mit einem Mail-Server und nutzt ein bekanntes Protokoll. Das ist heute nicht mehr so. Ich versuche den Stand Mai 2026 einmal zusammenzufassen

Übersicht

Dank Exchange - Autodiscover" kann Outlook mit dem passenden Service sehr dynamische und automatisch die Verbindung zu einem Mailsystem ermitteln. Damit sind Wechsel der Server-Adressen und Protokolle relativ einfach möglich. Über die Jahre haben sich die Protokolle mehrfach gewechselt. MAPI/RPC ist verschwunden, RPC/HTTP schon fast weg, MAPI/HTTP ist das aktuelle Protokoll für "Classic Outlook" aber nicht für Modern Outlook und mobile Clients nutzen das Hx-Protokoll/Microsoft Sync Technologie. In der Cloud gibt es die Graph API aber auch einige nicht von Microsoft dokumentierte Schnittstellen, während EWS ab Oktober 2026 nur noch für selbst betriebene Exchange Server verfügbar sein wird. In der Cloud wird EWS abgeschaltet.

Ich habe daher die sechs verschiedenen Clients für Exchange OnPremises und Exchange Online genommen, und deren Kommunikation mit Fiddler und Wireshark nachverfolgt, soweit ich es sehen konnte und hier aufgezeichnet:

 

Die Übersicht ist nie komplett, denn die meisten Clients verbinden sich natürlich noch zu anderen Diensten (CDN zum Download, Entra ID für Authentifizierung, Microsoft Graph etc.) und Microsoft kann dies auch jederzeit wieder ändern, da sie die meisten Clients selbst entwickeln und die nativen ActiveSync-Clients auf IOS/Android oder auch Thunderbird (IMAP4/POP3/EWS) schon sehr alte Protokolle nutzen, die quasi "ausentwickelt" sind und sich daher kaum ändern.

Tabelle

Bei der Tabelle ist es wichtig, genau die verschiedenen Clients, Betriebssysteme, Protokolle und Gegenstellen zu beachten. Es macht einen Unterschied, ob sie "New Outlook" auf Windows oder Mac nutzen und auch beim Mobilgeräten gibt es Unterschiede zwischen dem Nativen ActiveSync-Client von Apple und Android im Vergleich zu Outlook. Ich beschränke mich auf die Standardinstallation und berücksichtige nicht etwaige Erweiterungen. Gerade für Outlook Classic gab es früher eigene Transport und Storage-Dienste z.B. für Notes, Kopano u..a während moderne Clients wie Thunderbird sogar EWS und Graph ergänzen.

Client Exchange Online Exchange OnPremises Internet Provider
Classic Outlook/Win
MAPI/HTTP direkt
MAPI/HTTP direkt
IMAP4/POP3 und SMTP direkt
New Outlook/Win
REST/HTTP
Hx-Protokoll/Microsoft Sync Technologie

nicht möglich!

REST/HTTP über MSCloudProxy auf POP/IMAP/SMTP
New Outlook/Mac


REST/HTTP direkt
EWS/HTTP direkt

?
Outlook/IOS
Outlook/Android
REST/HTTP
Hx-Protokoll/Microsoft Sync Technologie
REST/HTTP über MSCloudProxy auf ActiveSync direkt

REST/HTTP über MSCloudProxy auf POP/IMAP/SMTP
AppleMail/IOS
GMail/&Android
ActiveSync direkt
ActiveSync direkt
IMAP4/POP3 und SMTP direkt. Manchmal ActiveSync direkt
Browser


OWA/HTTP direkt


OWA/HTTP direkt


WebMail/HTTP direkt
Thunderbird u.a.
Graph API/HTTP in Phase 3. Ansonsten POP/IMAP/SMTP
EWS/HTTP direkt, Ansonsten POP/IMAP/SMTP
IMAP4/POP3 und SMTP direkt
POP/IMAP-Clients
IMAP4/POP3 und SMTP direkt
IMAP4/POP3 und SMTP direkt
IMAP4/POP3 und SMTP direkt
TestConnectivity
EWS/HTTP direkt
EWS/HTTP direkt
EWS/HTTP direkt
Exchange Online Hybrid


Intern
EWS/HTTP direkt
entfällt
Exchange OnPremises
Graph API mit dedicated Hybrid App
EWS/HTTP direkt


entfällt

Beachten Sie insbesondere das rote und die gelben Felder, da Sie vielleicht überraschend sind.

Die meisten Clients nutzen natürlich "Autodiscover", was ich nicht explizit aufgeführt habe. Es gibt immer wieder Versuche von anderen Mailservern, einen Exchange Server nachzubilden. Die Tabelle macht auch keine Aussage zu den möglichen Authentifizierungsverfahren. Mit Exchange Online ist natürlich "Modern Authentication" per SAML/OAUTH gesetzt. OnPremises können Sie auch weiterhin Basic/NTLM/Kerberos nutzen aber auch hier ist Hybrid Modern Authentication (HMA) eine Option die Anmeldung z.B. per MFA abzusichern. Das gelingt natürlich nur, wenn alle Clients auch OAUTH unterstützen.

Client-Adressen

Eine TCP-Verbindung startet immer von einem Client und verbindet sich mit einem Server. Dazwischen stehen Firewalls, Proxy-Server etc., die entsprechende Verbindungen erlauben müssen und natürlich will man nur die absolut notwendigen Ziele für ausgewählte Quellen erreichbar machen. Denken Sie daran, dass Sie eigentlich nur vor ihrem eigenen Exchange Server eine Firewall und ReverseProxy-Systeme betreiben und konfigurieren können. Als Kunde können Sie keine Firewalls vor Exchange Online für ihren Mandanten oder einem gehosteten Mailsystem bei ihrem Provider aufbauen. Die Betreiber schützen natürlich ihre Systeme, so dass nur erforderliche Port wie 80,443,995,993 erreichbar sind aber ansonsten verlassen Sie sich komplett auf die Authentifizierung. Daher ist der Einsatz von OAUTH/SAML ja auch so wichtig, da der eigentliche Service das Token oder einen Session Cookie prüft und falsche Anfragen direkt ablehnen kann. Bei den Quellen sehe ich vier Bereiche, die Sie beim Zugriff auf ihren eigenen Exchange Server erlauben sollten:

Quelle  SourceIP-Adressen Beschreibung 

Clients

Any (oder VPN)

Sie können natürlich ihren lokalen Exchange Server hinter einem VPN verstecken und damit nur Clients eine Verbindung erlauben, die sich per IPSec, L2TP, AlwaysOn o.ä. schon am Netzwerk authentifiziert haben. Dann müssen Sie die Exchange Ports für diese Nutzung gar nicht anonym aus dem Internet erreichbar machen und schützen sich auch gegen Angriffe auf NTLM-Anmeldungen etc.

Wenn Sie aber auch "OWA" aus dem Internet erlauben wollen, dann funktioniert dies zumindest nicht mehr auf Port 443. Aber auch hier können Sie eine Preauthentication nutzen, um Exchange OnPremises besser zu sichern. Für ActiveSync können Sie ebenfalls z.B. Hybrid Modern Authentication (HMA) mit Conditional Access erzwingen.

Es gibt also schon Lösungen, dass das "From:ANY" kein Risiko wird

Exchange Online 

IP-Range1 

Anders sieht es aus, wenn ein Exchange Online Tenant im Hybrid Mode mit ihrem lokalen Server kommunizieren möchte. Das betrifft SMTP für den Mailfluss und EWS/HTTPS für Free/Busy-anfragen. Hinzu kommen aber auch Zugriffe von Teams. Die IP-Adressen hat Microsoft veröffentlicht:

Das sind aber nicht alle Adressen. Auf der Seite von Microsoft gibt es ganz unten einen Link auf "Other endpoints not included in the Microsoft 365 IP Address and URL Web service", welcher weitere IP-Adressen aufführt.

Ohne diese Adressen ist z.B. eine Mailboxmigration nicht möglich und auch für Hybrid Modern Auth sind weitere Quellen freizuschalten.

Mobile Proxy 

IP-Range2

Wer nur die IP-Range1 freigibt, wird Probleme beim Zugriff mit Outlook/IOS und Outlook/Android auf lokale Postfächer haben. Die Clients verbinden sich nicht mehr per ActiveSync/HTTP mit ihrem Exchange Server sondern per REST/HTTP mit einem Proxy in der Microsoft Cloud, welcher sich dann zu ihrem lokalen Server verbindet. Insbesondere der Abschnitt 10 ist hier zu beachten:

 

Der wird gerne übersehen und dann funktioniert die Anmeldung an Exchange OnPremises nicht.

TestConnectivity

IP-Range3

Wenn Sie gerne mal die Webseite https://testconnectivity.microsoft.com/ für Fehlersuchen nutzen, dann sollten Sie beachten, dass auch dieser Service nicht die gleichen IP-Bereiche wie Exchange Online nutzt.

 

Ziele

Bei den Zielen interessieren erst einmal nur die eigenen Exchange Server. Natürlich sollten Sie ausgehend ihren Clients die Verbindung zu Exchange Online nicht allzu schwer machen. Sie müssen hier abwägen, wie weit Sie Microsoft Vertrauen und ob sie vielleicht mit Conditional Access die Quell-IP-Adresse ihres Netzwerks mit einem Vertrauensvorschuss belegen. Aber es sind ja schon ihre eigenen Daten mit ihrer eigenen Anmeldung, die für den Zugriff erforderlich ist. Sie können maximal überlegen, ob Sie ausgehend einen HTP-Header "Restrict-Access-To-Tenants" (Siehe Office 365 und Proxy Server) addieren, so dass aus ihrem Netzwerk kein Zugriff auf andere Tenants möglich ist.

Der Zugriff auf ihren lokalen Exchange Server können Sie aber über die  Outlook über HTTP und ExternalURL je nach Protokoll auf unterschiedliche Pfade legen und einige Einstellungen, z.B. InterOrgRelationShip und MigrationEndpoints erlauben sogar eine statische Vorgabe eines Hostnamens an Autodiscover vorbei. Sie könnten also die unterschiedlichen Dienste ihres eigenen Exchange Servers durch unterschiedliche Namen, separate IP-Adressen oder Hostheadern und URL-Pfaden je nach Quelle erreichbar machen. Das ist aber dennoch kein Schutz gegen DoS und maximal ein etwas besserer Schutz gegen verschiedene andere Angriffe.

Ziel  Beschreibung 

Exchange Online

Diese Adressen sollten ihnen bekannt sein

Exchange OnPremises

Jeder Zugriff auf lokale Postfächer erfolgt über per "ExternalURL" und Autodiscover bekanntgemachten HTTP-Zugriffspunkte. Nur wenige Dienste wie Migrationendpunkte, InterOrgreplicationShips oder manuelle Konfigurationen auf Clients umgehen diese Logik.

Cloud Proxy

Ein "Modern Outlook" verbindet sich mit "https://outlook.office.com", auch wenn es sich zu einem IMAP4-Postfach eines anderen Providers verbindet. Der "Cloud Proxy" ist keine separate Plattfor, sondern eigentlich eine Funktion von Exchange Online, die Microsoft hier als Infrastruktur verwendet.

Weitere Links