„Liebe IT! Ich muss aus Gründen manchmal E-Mails von einer anderen Adresse versenden können. Die Mails sollen aber alle in meinem Postfach bleiben.„
Kommt Dir das bekannt vor? Mit Exchange Server kann dieses Thema durchaus Kopfschmerzen verursachen (wer kennt den IMAP-Trick?).
Mit Exchange Online geht das jedoch sehr leicht. Das ist einer der Vorteile der Cloud, da hier nach und nach solche nützlichen Funktionen nachgereicht werden. Exchange Server wird sich vermutlich in den nächsten Jahren auf Sicherheitsaktualisierungen beschränken.
Die (vermeintlich) einfache Lösung - Senden von Alias
Schon seit einigen Jahren bietet Exchange Online die Funktion „Senden von Alias“ an. Diese tut im Grunde, was der Name verspricht:
- Man fügt einem Postfach einen oder mehrere beliebige zusätzliche E-Mail-Adressen hinzu.
- Der Benutzer blendet bei sich in Outlook oder OWA das Feld „Von:“ ein, gibt die gewünschte Adresse ein und kann von dieser Mails versenden.
- Die gesamte E-Mail-Kommunikation über den Alias verbleibt im gleichen Postfach. Es sind keine zusätzlichen Maßnahmen wie bei einem freigegebenen Postfach nötig.
Konfiguration
Die Konfiguration dieser Funktion ist denkbar einfach:
- Exchange Online Admin Center aufrufen: Exchange admin center
- „Einstellungen > Nachrichtenfluss“
- Haken bei „Senden von Aliasnamen aktivieren“ setzen und „Speichern“
Das geht natürlich auch per PowerShell:
# Zu Exchange Online verbinden
Connect-ExchangeOnline -ShowBanner $False
# Senden von Alias aktivieren
Set-OrganizationConfig -SendFromAliasEnabled $true
Stolpersteine, die den Einsatz verhindern können
Solange ausschließlich Exchange Online eingesetzt wird, ist die Welt jetzt schon in Ordnung.
Viele Unternehmen verwenden jedoch hybride Umgebungen, bei denen der Nachrichtenfluss noch über die lokale Infrastruktur erfolgt. Hier gibt es einige Besonderheiten, die die Funktion ein wenig schmälern oder sogar für den Einsatz disqualifizieren können.
Die folgenden Kapitel zeigen einige Beispiele. Zunächst wird jedoch einmal kurz erklärt, wie der Nachrichtenfluss in hybriden Umgebungen funktioniert.
Nachrichtenfluss in hybriden Umgebungen
Bevor wir zu den Besonderheiten kommen, soll kurz erklärt werden, wie der Nachrichtenfluss in einer hybriden Exchange-Umgebung funktioniert:
Innerhalb einer hybriden Exchange-Organisation wird eine sogenannte Remoteroutingdomäne verwendet. Diese ist an der Syntax …mail.onmicrosoft.com erkennbar.
Jedes Postfach in der Organisation verfügt über einen Alias mit dieser Domäne. Exchange Server/Online kann anhand dieses Aliases die Mails korrekt weiterleiten, auch wenn sich das Postfach nicht in der gleichen Organisation (lokal oder Cloud) befindet.
Im Empfänger-Postfach wird die Adresse vom Alias wieder auf die primäre E-Mail-Adresse des Empfängers geändert. Auf diese Weise ist der Prozess für die Benutzer transparent und die Remoteroutingadresse nicht sichtbar.
Abwesenheitsnachrichten
Hat ein Mitarbeitender für sein Postfach den Abwesenheitsassistenten konfiguriert und versendet automatische Antworten an Sender, so wird dem Absender in der Abwesenheitsnachricht die Remoteroutingadresse (…mail.onmicrosoft.com) statt der primären E-Mail-Adresse des Postfachs (…@contoso.com) angezeigt.
Dies ist aus folgenden Gründen problematisch:
- Der Absender erhält eine Adresse, die nicht für den E-Mail-Versand bestimmt ist. Zwar kann der Absender auch an diese Adresse Nachrichten senden, allerdings entspricht dies nicht dem vorgesehenen Zweck.
- Microsoft hat bereits angekündigt, die produktive Verwendung solcher Domänen einzuschränken (Limiting Onmicrosoft Domain Usage for Sending Emails | Microsoft Community Hub). Es ist daher denkbar, dass das Senden von E-Mails von extern zu einem späteren Zeitpunkt nicht mehr funktionieren wird
- Es wird eine potenziell als sensibel einzustufende Information herausgegeben. Die Remoteroutingdomäne (contoso.mail.onmicrosoft.com) entspricht im Grunde der MOERA-Domäne (contoso.onmicrosoft.com; Microsoft Online Email Routing Address) des Mandanten, welche bei der Erstellung des Mandanten initial angelegt wird. Dies erlaubt daher Rückschlüsse auf den Mandanten und die Zugriffs-URLs für die Microsoft 365-Dienste (bspw. für das SharePoint Admin Center).
Hierfür gibt es aktuell keine funktionierende Umgehungslösung. Es bestehen nur die folgenden Möglichkeiten:
- Exchange Server ablösen und Mails direkt von Exchange Online versenden lassen bzw. Exchange Server nicht mehr als Mail-Relay einsetzen.
- Funktion „Senden von Alias“ deaktivieren, falls die Entfernung von Exchange Server nicht möglich ist.
E-Mail-Filterung in Exchange Online Protection und Defender for Office 365
Exchange Online bietet mit Exchange Online Protection (EOP) einen integrierten Schutz gegen Spam, Malware und Phishing. Defender for Office 365 (MDO) fügt noch einen Schutz gegen schädliche Links und Anhänge hinzu.
- Werden diese Dienste aktiv (anstelle oder zusätzlich zu Drittherstellerprodukten) genutzt, so werden üblicherweise entsprechende benutzerdefinierte Richtlinien erstellt.
- Da solche Richtlinien möglichst umfassend angewendet werden sollen, werden üblicherweise die unternehmenseigenen Domänen in diesen Richtlinien hinterlegt, wie auf dem nebenstehenden Bild beispielhaft zu sehen.
- Oft werden jedoch nur die benutzerdefinierten Domänen und nicht die MOERA- sowie die Remoteroutingdomäne hinzugefügt, da diese ja normalerweise nicht produktiv genutzt werden.
Ist die Funktion „Senden von Alias“ aktiviert, so wird jedoch die Empfängeradresse des Mitarbeitenden wie oben beschrieben nicht mehr angepasst, sondern verbleibt auf der Remoteroutingdomäne. Dies hat dann wiederum zur Folge, dass die Richtlinien in EOP und MDO nicht mehr angewendet werden und somit auch schadhafte Mails zugestellt werden können. Ist dann auch noch die Junk-E-Mail-Funktion in Outlook deaktiviert (wie es oft gehandhabt wird, wenn andere Lösungen zum Einsatz kommen), so besteht keinerlei Schutz mehr!
Dies lässt sich jedoch zum Glück dadurch lösen, dass die Remoteroutingdomäne und idealerweise auch die MOERA-Domäne allen Richtlinien entsprechend hinzugefügt werden. Dann greift der Schutz auch für diese Domänen (und Aliase).
