Ein idealer M365-Tenant lebt, was E-Mail angeht, komplett in der Cloud. Ein- und ausgehende Nachrichten werden durch Exchange Online Protection (EOP) auf Spam und Malware überprüft. Alle Anwendungen mit Zugriff auf E-Mail und Kalender sind cloudintegriert und interagieren mittels Microsoft Graph oder wenigstens Exchange Web Services (EWS) mit den Daten des Tenants, inklusive der Postfachinhalte. Leider setzen viele Organisationen noch herkömmliche, nicht an die Cloud angepasste Anwendungen ein. Andere sind Regularien in Bezug auf E-Mail-Sicherheit unterworfen oder haben eigene Vorstellungen darüber, wie ihr Umgang mit dem Medium E-Mail aussehen soll.

Das wohl am häufigsten auftretende "problematische" Nutzungsszenario im Exchange-Online-Mailtransport betrifft Multifunktionsdrucker mit Scan-to-Mail-Funktion oder andere Vorrichtungen, die gern mittels SMTP E-Mails versenden. Dazu gehören üblicherweise Monitoringsysteme, die E-Mail als Medium für die Alarmierung nutzen. Aber auch ERP- und Zahlungssysteme verwenden bisweilen E-Mails, um Dokumente oder sogar Zahlungsanweisungen auszutauschen.

Mit dem Umzug von einem lokalen Mailserver in die Cloud offenbaren viele dieser Systeme deutliche Schwächen, die den weiteren Einsatz erschweren. In seltenen Fällen beherrschen Multifunktionsdrucker oder andere Systeme kein DNS und der Zielserver für SMTP muss in Form einer IP-Adresse hinterlegt werden. Was vor Ort kein großes Problem darstellt, ist in der Cloud natürlich ein nahezu unüberwindbares Hindernis, da der Provider die tatsächlichen Mailserver innerhalb des definierten IP-Adressbereiches jederzeit ändern kann.

Viel häufiger sind Systeme, die auch heute noch kein sicheres SMTP beherrschen – weder STARTTLS noch Forced TLS. Und bei einigen Produkten, die TLS für SMTP als solches anbieten, endet die Unterstützung für das TLS-Protokoll bei Version 1.0 oder 1.1. Diese Versionen sollten in Exchange Online ursprünglich bereits 2019 abgeschaltet werden. Aufgrund der Corona-Pandemie hatte Microsoft diese Maßnahme bis Oktober 2020 ausgesetzt, danach allerdings wieder gestartet, sodass Sie heute sicherstellen müssen, dass Ihre Systeme TLS 1.2 sprechen, wenn sie direkt mit Microsoft-Diensten kommunizieren sollen. Dies betrifft übrigens nicht ausschließlich E-Mail, sondern gilt für alle Protokolle, die TLS verwenden, einschließlich HTTPS.

Als besonders problematisch stellt sich angesichts der angespannten Bedrohungslage die Aufgabe heraus, das Einliefern von E-Mails mit Authentifizierung zu versehen. Die meisten Systeme, die SMTP sprechen, beherrschen heutzutage nur die SMTP-Authentifizierung. Diese möchte Microsoft allerdings gerne zugunsten der "Modern Authentication" loswerden, denn bei SMTP AUTH überträgt der Client, wie bei jeder Ausprägung der "Basic Authentication", die Anmeldedaten des Benutzers im Klartext.

Gerade bei M365-Business-Tarifen, die keine Azure-AD-Premium-Lizenzen und somit keine Conditional Access Policies beinhalten, sind Admins sehr gut beraten, die "Security Defaults" in ihren Mandanten zu aktivieren. Damit ist die Basis-Authentifizierung inklusive SMTP AUTH jedoch mandantenweit deaktiviert. Wenn Sie bereit sind, auf Security Defaults zu verzichten, können Sie SMTP AUTH global deaktivieren und nur für diejenigen Postfächer wieder einschalten, die tatsächlich zum Mailversand per SMTP verwendet werden. Diese Vorgehensweise ist unter [1] beschrieben.

Für das "Multifunktionsdrucker-Szenario" bietet Microsoft einen Workaround [2] an. Dafür wird in O365 ein "Connector" erstellt (als Exchange-Admin erkennen Sie darin sofort einen Empfangsconnector), der E-Mails von Ihrer Organisation empfangen soll. Die Organisation wird dabei lediglich anhand der IP-Adresse erkannt, die mit den Servern von Exchange Online kommuniziert; eine weitere Authentifizierung ist nicht gefordert. Die im SMTP-Dialog übermittelte Absenderadresse muss lediglich aus einer der akzeptierten Domains des Mandanten stammen.

Da lokal in der Regel NAT zum Einsatz kommt, könnte damit jedes interne System theoretisch E-Mails über Exchange Online versenden – sowohl an Empfänger innerhalb des eigenen Mandanten als auch an Externe. Es ist daher Ihre Aufgabe als Administrator, mittels geeigneter Firewallregeln den ausgehenden SMTP-Verkehr auf diejenigen Systeme zu beschränken, die dafür vorgesehen sind. Doch auch mit dieser Maßgabe genügt ein solcher Mailflow nicht den höchsten Sicherheitsanforderungen, denn damit ist beispielsweise die Absenderidentität nicht gewährleistet. Jeder, der sich Zugang zur SMTP-Konfiguration eines Systems auf der "SMTP-Erlaubnisliste" verschaffen kann, ist in der Lage, E-Mails im Namen eines beliebigen internen Absenders zu verschicken. Das öffnet zusätzlichen Angriffsvektoren wie "CFO-Fraud" unter Umständen Tür und Tor.

Existiert Ihre Exchange-Online-Organisation nicht ausschließlich in der Cloud, sondern als Teil einer Hybrid-Bereitstellung, stehen Ihnen vielfältige Optionen zur Verfügung, um den Anwendungsfall "Multifunktionsdrucker" und weitere Sonderfälle, die wir noch beleuchten werden, zuverlässig und sicher zu behandeln. Eine Hybridstellung sieht traditionell einen lokalen Exchange-Server vor, mit dessen Administrationsoberfläche Sie die E-Mail-relevanten Attribute der synchronisierten AD-Objekte verwalten können.

Seit Exchange 2019 CU12 haben Sie die Möglichkeit, diesen "Hybrid-Server" loszuwerden, damit sind Sie jedoch für die Pflege der AD-Attribute auf ein neues PowerShell Snap-in angewiesen, und Ihre Automatisierungsskripte müssen vermutlich angepasst werden. Solange Sie jedoch für Ihre Hybridbereitstellung vom lokalen Exchange-Server abhängig sind, können Sie diesen auch dafür nutzen, um problematische Mailflow-Szenarien wie die Multifunktionsdrucker anzugehen.

Die SMTP-Kommunikation zwischen dem lokalen Exchange-Server und Exchange Online ist nämlich per se vertrauenswürdig. Sie ist durch Zertifikate abgesichert, die die Exchange-Organisationen beim Einrichten der Hybridstellung miteinander austauschen.

So ist sichergestellt, dass alle E-Mails, die Exchange Online vom lokalen Exchange-Server eingeliefert bekommt, zur Verarbeitung angenommen und hoffentlich auch zugestellt werden.

Auf der lokalen Seite können Sie trotz Hybridstellung alle Register ziehen, die ein Exchange-Server in puncto Einreichen von E-Mails zu bieten hat: Empfangsconnectoren mit oder ohne Authentifizierung, Verwenden von SMTP AUTH, Einschränkung auf bestimmte IP-Adressen, angepasste TCP-Ports, intern vertrauenswürdige Zertifikate oder gar keine TLS-Verschlüsselung. So ist es möglich, den Mailversand durch interne Systeme flexibel zu gestalten und dennoch die Mailströme so zu kanalisieren, dass die Gefahr von Spam, Phishing und "CFO-Fraud" möglichst gering bleibt.

Auf der Exchange-Online-Seite sind nach dem Einrichten der Hybridstellung keine zusätzlichen Einstellungen nötig. Beachten Sie, dass Sie in Ihren Systemen E-Mail-Absender konfigurieren müssen, die in Ihrer Exchange-Organisation tatsächlich existieren. Ist der verwendete Absender ein Cloudpostfach, werden im Gegensatz zum lokalen Exchange die per SMTP versandten E-Mails im Ordner "Gesendete Objekte" dieses Postfachs gespeichert. Diese Elemente zählen zum Postfach-Quota dazu. Deswegen müssen Sie Vorkehrungen treffen, damit das Postfach nicht überläuft und der Versand dadurch gestört wird.

Meist kommt hierfür eine Aufbewahrungsrichtlinie zum Einsatz, die die Elemente nach einer gewissen Zeit aus dem Postfach löscht. In M365 können Sie dies an zwei Stellen erledigen:

1. Im klassischen Exchange-AdminCenter: Hier erstellen Sie wie gewohnt Retention Policy Tags, fokussieren diese spezifisch auf den "Sent Items"-Ordner und bauen sie in eine Retention Policy für die Absender-Postfächer Ihrer lokalen Systeme ein.

2. Im Compliance-Center: Die hier erzeugten Policies sind weniger granular konfigurierbar, können sich dafür aber auf weitere Dienste wie SharePoint oder Teams erstrecken.

Das moderne Exchange-AdminCenter hingegen bietet derzeit keine Möglichkeit, Aufbewahrungsrichtlinien zu erstellen und zu verwalten.

Die herkömmliche Topologie eines vor Ort betriebenen Mailsystems sieht in nahezu allen Fällen ein oder mehrere Gateways am Perimeter vor, die zwischen den eigentlichen Mailservern (beispielsweise Exchange) und dem Rest der Welt stehen. Die Funktionen dieser Gateways sind vielfältig:

- Scan eingehender und gegebenenfalls auch ausgehender Nachrichten auf Malware und Spam,

- Archivierung eingehender Nachrichten, bevor sie zugestellt werden,

- Ablage ein- und ausgehender Nachrichten in Dokumentenmanagement-Systemen,

- Verschlüsseln und Signieren ausgehender Nachrichten, Entschlüsselung eingehender Nachrichten,

- Versand der als E-Mail übermittelten Nachrichten per SMS oder Fax sowie

- Anfügen von Signaturen und Disclaimern an ausgehende Nachrichten.

Manchmal erfüllen die Appliances am Perimeter noch eine weitere Funktion: Deren öffentlichen IP-Adressen dienen vertrauten Kommunikationspartnern als zusätzliches Identifizierungsmerkmal. So können Partnerorganisationen beispielsweise die eingehenden E-Mails von der Spamerkennung ausschließen oder Verschlüsselung mit gesonderten Zertifikaten erzwingen, wenn sie von der IP-Adresse des jeweils anderen Partners stammen. Solche und weitere Vorrichtungen am Perimeter weisen bereits eine lange Erfolgsgeschichte auf. Es ist daher nicht überraschend, dass Unternehmen und Organisationen viele Geschäftsprozesse mithilfe von Funktionen gestaltet haben, die von E-Mail-Gateways unterschiedlichster Art angeboten werden. Eine weitere Möglichkeit, Drittanbieter-Funktionen in die Verarbeitung von E-Mails einzubinden, bietet Exchange in Form von Transportagenten. Da diese auf jede Nachricht, intern wie extern, zur Anwendung kommen, sind solche Agenten extrem mächtig und haben in den lokalen Exchange-Organisationen ebenfalls eine große Verbreitung erfahren.

Es liegt in der Natur von Software-as-a-Service, so auch bei Exchange Online, dass kundenspezifische Third-Party-Transportagenten, die auf jedem Server mit der Hub-Transport-Rolle zu installieren wären, in der Cloud nicht umsetzbar sind. Doch auch die Perimeter-Gateways sind nicht so einfach mit Exchange Online zu verzahnen, denn der Perimeter hat sich in der Cloud etwas "nach innen" verschoben und ist teilweise mit dem Kernservice verschmolzen. Für die Untersuchung der E-Mail-Kommunikation auf Spam und Malware stellt Microsoft nämlich die "Exchange Online Protection" (EOP) bereit.

EOP bildet eine Schutzschicht zwischen Exchange Online und der Außenwelt und sichert auch die Kommunikation zwischen unterschiedlichen Exchange-Online-Mandanten ab. Damit agiert EOP sowohl innerhalb der Exchange-Cloud als auch an deren Außengrenze. Setzt Ihre Organisation Exchange Online "in Reinform" ein und der MX-Eintrag für Ihre Maildomain zeigt auf "<domain-token>.mail.protection.outlook.com", ist EOP automatisch Ihr Perimeterschutz. Nach der Prüfung auf Spam und andere Bedrohungen werden die eingehenden E-Mails von EOP direkt an Server von Exchange Online weitergereicht, die die Korrespondenz in das Zielpostfach zustellen. Dies funktioniert sowohl mit reinen Cloudbereitstellungen als auch in Hybridszenarien. In Letzteren wird EOP die E-Mails direkt zu Ihrem lokalen Exchange-Server routen, wenn das Empfängerpostfach der Nachrichten dort liegt.

Falls es die Geschäftsprozesse oder Compliance-Richtlinien Ihrer Organisation erfordern, dass alle E-Mails durch ein Gateway oder einen Agenten verarbeitet werden, müssen Sie den standardmäßigen Nachrichtenfluss zwischen Exchange Online, dem lokalen Exchange und EOP aufbrechen und die E-Mails durch Systeme außerhalb der Microsoft-Cloud routen. Dafür bestehen mehrere Möglichkeiten [3].

In einer hybriden Exchange-Bereitstellung haben Sie eine Option zur Verfügung, die die Logik des Mailflows komplett umdreht – zumindest im Fall von Nachrichten, die aus Cloudpostfächern oder aus dem Internet stammen. Solche E-Mails werden bei aktiviertem "Centralized Mail Transport" (CMT) nicht direkt an ihren Empfänger zugestellt, sondern stets an die lokalen Systeme der Organisation gesendet. Dort können Sie weiterhin die benötigten Transportagenten einsetzen oder die E-Mails sogar Gateways durchlaufen lassen. Die einzige Voraussetzung dabei ist, dass diese Vorrichtungen keine Felder aus dem SMTP-Header entfernen. Exchange Online fügt nämlich spezielle Felder zum Header hinzu, die beim Routen der E-Mail zurück nach Exchange Online die erneute Verarbeitung durch CMT verhindern und so einen Mail-Loop vermeiden.

Um CMT zu aktivieren, führen Sie den Hybrid Configuration Wizard (HCW) aus und klappen in dem Schritt, wo Sie die Wahl zwischen Client Access Server und Edge Transport Server tätigen, den Bereich "Advanced" auf. Dort können Sie den Haken bei "Enable centralized mail transport" nach Ihrem Bedarf setzen.

Sie können CMT auch per PowerShell konfigurieren, obwohl der HCW von Microsoft für diese Aufgabe nachdrücklich empfohlen wird. Dafür verbinden Sie sich mit der Exchange Online PowerShell und setzen den Parameter "RouteAllMessagesViaOnPremises" des ausgehenden hybriden Connectors auf "$true":

Das Deaktivieren erfolgt ähnlich, hier müssen Sie den Parameter natürlich auf "$false" setzen. Obwohl das Aktivieren des CMT in einer hybriden Organisation sehr schnell erledigt ist und die gefürchteten Mail-Loops damit vermieden werden, ist CMT nicht ohne Tücken. Ein für viele Admins unerwartetes Manko des CMT ist nämlich der Umstand, dass Nachrichten zwischen Cloudpostfächern nicht durch das On-Premises-Exchange geroutet werden.

Dass CMT keine Cloud-to-Cloud-Mails nach on-premises routet, liegt daran, dass alle Connectoren in Exchange Online auf Perimeterservern, also denen von EOP, definiert werden. Der Mailverkehr innerhalb des Cloudteils einer hybriden Organisation erreicht diese Server nie und so bleibt der veränderte Mailflow für diese E-Mails wirkungslos.

Erfahrene Exchange-Admins wissen, dass der einzige Weg, interne Mails mit Bordmitteln zu beeinflussen, die Transportregeln (Nachrichtenflussregeln) sind. In Exchange Online steht Ihnen die Aktion "durch diesen Connector routen" zur Verfügung. Damit können Sie einen Mailflow nach Ihren Erfordernissen bauen, indem Sie die passenden Connectoren vom Typ "Partner Connector" mit den Regeln kombinieren, die für die Auswahl des jeweiligen Connectors sorgen. Da alle Transportregeln auf Bedingungen (Conditions) basieren, nennt sich diese Technik in Exchange Online "Condition Based Routing" oder kurz CBR.

Zu den Vorteilen von CBR gehört, dass es nicht von einer hybriden Bereitstellung abhängt und damit auch in Organisationen ohne On-Premises-Exchange funktioniert. So können Sie beispielsweise ein Antimalware- oder ein Verschlüsselungs-Gateway in Ihren Mailflow integrieren, selbst wenn Ihre Exchange-Online-Organisation ausschließlich in der Cloud angesiedelt ist. Viele klassische Anbieter von Mail-Gateways wie Cisco, Barracuda, Zertificon oder seppMail stellen ihre Appliances als Ressourcen in Azure, AWS oder anderen Public Clouds zur Verfügung. In den meisten Fällen können Kunden ihre für den lokalen Betrieb erworbenen Lizenzen dieser Anbieter in die Cloud mitnehmen (Bring Your Own License). Auf diese Weise bilden Sie einen komplexen Mailflow, den Sie benötigen, komplett in der Cloud ab. Beachten Sie, wenn Sie so etwas planen, dass weder die für den Betrieb des Gateways benötigte Rechenleistung noch das zu übertragende Datenvolumen in den Lizenzen enthalten sind.

Im Gegensatz zum CMT hat CBR keine eingebaute Intelligenz, um ein falsches Routing oder Mail-Loops effektiv zu vermeiden. Sie müssen daher mit einer gezielten Wahl von Bedingungen in Ihren CBR-Regeln selbst dafür sorgen, dass E-Mails von jeder Regel nur einmal verarbeitet werden. Dafür gibt es mehrere Ansätze:

- Verwenden des Header-Feldes "X-Originator-Org" (sofern Sie nur eine CBR-Regel in Ihrem Mailflow nutzen),

- Verwenden eigener Header-Felder (die CBR-Regel fügt ein Feld mit einem bestimmten Wert hinzu und prüft gleichzeitig, dass dieses Feld nicht auf diesen Wert gesetzt ist) oder

- Modifizieren des Nachrichtenbetreffs.

Eine gute Gegenüberstellung von CBR und CMT inklusive wertvoller Troubleshooting-Tipps bietet [4].

Ein Sonderfall des Exchange-Mailflows ist die Journal-Archivierung. Für Journaling-Nachrichten werden alle Transportregeln ignoriert, denn häufig ist die Revisionssicherheit der E-Mail-Archivierung davon abhängig, dass diese Nachrichten ungehindert in die Journal-Postfächer zugestellt werden. In einer herkömmlichen Exchange-Bereitstellung liegen die Journal-Postfächer in der gleichen Exchange-Organisation wie die Absender beziehungsweise Empfänger der Nachrichten, sodass die Zustellung in der Tat sehr robust funktioniert.

In Exchange Online lässt Microsoft es nicht zu, dass Journal-Postfächer eines Mandanten in Exchange Online liegen – sei es im gleichen oder in einem anderen Tenant. Anbieter von Archivsystemen wie REDDOXX oder Mithi haben auf diese Einschränkung reagiert und bieten eigene SMTP-Domänen und mandantenspezifische Zielpostfächer an, an die Exchange Online die Journaling-Kommunikation richten kann.

Für komplexere Mailflow-Szenarien ist es derzeit hilfreich, eine Hybrid-Bereitstellung mit Exchange Online und lokalem Exchange zu betreiben. Damit können Sie den Centralized Mail Transport einsetzen und so von den bisherigen Transportagenten und Gateways profitieren. Mittels Condition Based Routing designen Sie den Mailflow auch ohne Hybrid-Exchange und sprechen beispielsweise Cloud-Gateways an. Dabei müssen Sie selbst dafür Sorge tragen, dass keine Mail-Loops entstehen.