Beim Exchange Hybrid Mailflow kann man sagen, dass immer etwas schief gehen kann. Vor allem, wenn es die berühmten „historisch gewachsenen Strukturen“ betrifft. Was auch immer Microsoft dabei zum Besten gibt, trifft auf die meisten Organisationen, mit denen ich beruflich zu tun habe, nicht zu. Denn Microsoft spielt nun einmal mit Standard-Umgebungen. Welches Unternehmen, das es x Jahre gibt, hat aber so eine Umgebung? Und so muss man aufpassen, dass man nicht sagt: Reißt alles ein und baut es neu auf. Denn wem bringt das etwas?
Was ist mit Exchange Hybrid Mailflow gemeint?
Stellt euch mal vor, wie das Ganze seit Ausbruch der Pandemie läuft: Unternehmen wollen die Vorzüge der Cloud nutzen, ohne auf ihre Rechenzentren verzichten zu müssen. Die würden einen Teufel tun und ihre Daten vollständig in die Cloud verschieben. Und so wurden zum Teil riesige Hybrid-Gebilde aus dem Boden gestampft: Die Exchange Server, Domain Controller, Datenbanken etc. in den lokalen Rechenzentren, der Mailverkehr und Teams, Azure und all das in der Cloud.
Oftmals haben wir erlebt, dass es Unternehmen gibt, die denken, dass die Cloud in Form von Microsoft 365 am Rechenzentrum andockt. Das bedeutet aber „Hybrid“ nicht unbedingt. Vielmehr müssen Rechenzentren und Cloud „heiraten“. Sie müssen integriert werden. Im schlimmsten Fall bleiben es sonst zwei getrennte Welten. Wie soll denn damit ein gut funktionierender Exchange Hybrid Mailflow stattfinden, wenn Exchange immer tief in die Domänen-Gefilde eingreift?
Und so ist es doch zwangsläufig, dass es in so einer Umgebung immer wieder zu Problemen kommen kann. Nehmen wir nur einmal Skype For Business, das im Cloud-Umfeld durch Teams ersetzt wurde. Teams und Exchange Hybrid wird immer ein Thema für sich bleiben, wie ihr hier im Artikel lesen könnt. Darüber hinaus ist immer der Exchange Hybrid Mailflow ein großes Problem. Und hier will ich euch mal etwas erzählen.
Huch, da ist ja was im Spam
Stellen wir uns eine Organisation mit einigen 1000 Postfächern vor. Die Organisation hat Exchange Server als Mailbox Server und Exchange Online. Dazwischen sind diverse Security Boxen und Exchange Edge Transport Server. Letztere präsentieren das, was man als Clientzugriffspunkt kennt, also das mail.domain.org. Alle Postfächer befinden sich soweit in der Cloud. Nur ein kleiner Teil von Postfächern – nämlich für Apps und spezielle Abteilungen – sind noch on-premises.
Aus heiterem Himmel begann es irgendwann, dass sporadisch Emails an Postfächer. die noch auf den Servern liegen, in deren Junk transportiert wurden. Wir haben also die Kopfdaten der Emails ausgewertet, um herauszubekommen, wieso das passiert ist. Dafür bietet sich der Message Header Analyzer an. Dort fanden wir das da:
Authentication-Results: spf=fail (sender IP is xxx.xxx.xxx.xxx) smtp.mailfrom=microsoft.com; organization.mail.onmicrosoft.com; dkim=pass (signature was verified) header.d=microsoft.com;organization.mail.onmicrosoft.com; dmarc=pass action=none header.from=microsoft.com; Received-SPF: Fail (protection.outlook.com: domain of microsoft.com does not designate xxx.xxx.xxx.xxx as permitted sender)
Die IP-Adresse habe ich natürlich verfremdet. Denn hierbei handelte es sich um die Edge Transport Server. Aus irgendeinem Grund haben hier die Situation, dass genau diese Systeme nicht erlaubt wurden. Ernsthaft? Der Tenant der Organisation, hier „organization“ genannt, hat sie abgelehnt. Das Ganze konnte man in zwei parallelen Umgebungen exakt gleich nachvollziehen. Das ist blöd, wenn dadurch Registrierungen für die oben genannten Apps nicht mehr möglich sind, oder?
Was ist denn der Grund?
Wir haben vieles versucht. Natürlich denkt man erstmal an das Naheliegende. Bis es dann immer spezieller wird. Ich glaube, das ist überall so. Und deshalb haben wir erstmal so etwas versucht:
- Sind alle Ports und URLs so eingestellt, wie es Microsoft für den Exchange Hybrid Mailflow vorsieht? Dazu hilft diese Liste.
- Ist der Hybrid Configuration Wizard vielleicht fehlerhaft durchgelaufen? Dann holt man sich den aktuellen und lässt ihn die Hybrid-Connectoren inklusive Edge-Konfiguration durchlaufen.
- Wenn eine proxy.pac-Datei im Einsatz ist, ist es sinnvoll, diese mit Microsoft-Mitteln zu überprüfen.
- Es bietet sich auch an, den SPF-Eintrag zu kontrollieren, wie es Microsoft beschreibt.
- Und nicht vergessen, die Connectoren und Zertifikate zu überprüfen, wie es Andres Bohren hier beschreibt.
Ihr werdet lachen, das hat den Exchange Hybrid Mailflow in keinster Weise beeindruckt. Der hat nach wie vor random Emails, die an Postfächer auf den Servern geschickt wurden, in den Junk verschoben. Also mussten wir weiterschauen. Nachdem auch die Transport Agents nichts sinnvolles lieferten, wurde es langsam dünn mit den Optionen. Nachdem wir ja einen „spf=fail“ haben, muss es doch mit dem SPF-Eintrag zusammenhängen. Nö, irgendwie nicht:
v=spf1 include:spf.provider.com include:spf.appmail.provider.com include:spfa.org.com include:spfb.org.com include:spfc.org.com include:spfd.org.com include:spfe.org.com include:spf.protection.outlook.com -all
Und das Schönste an der gesamten Nummer war dann die gesamte Zeit: Die externen Empfänger – also die Kunden, Partner und wer weiß, wer sonst noch – haben von all dem nichts mitbekommen. Lediglich, wenn von außen irgendwas für diese Postfächer kam, bemerkten diese etwas, weil nämlich nie eine Antwort kam. Die Mails von ihnen landeten ja im Spam. Und Apps schauen dort halt nicht nach.
Der Provider der Kundenfirma war dann tätig geworden. Die haben auch allerlei Hampeleien durchgeführt. Bei ihnen waren auch keine Fehlkonfigurationen festzustellen. Gleichwohl haben sie aber auch einen „spf=fail“ beim Zustellen an unsere Kunden erhalten. Sie taten es ab mit „Failed by design“, eine Erklärung, die mir sehr gut gefällt.
Was bietet denn da Microsoft an?
Da wir nicht mehr weiter wussten, haben wir den Microsoft Cloud Support zu Rate gezogen. Um es kurz zu machen: Das hätten wir uns sparen können. Sie wiesen uns darauf hin, wie SPF eigentlich arbeitet, als ob wir das nicht wüssten. Und sie teilten uns mit, wie eine Connection Filter Policy arbeitet. Damit würden alle Spam-Prüfungen unterdrückt werden. Ernsthaft? Das kann es doch nicht sein. Es gab zu dem Zeitpunkt schlichtweg keine Lösung in Exchange Online Protection für die Konfiguration von „spf=fail“.
Alles deutete darauf hin, dass dort die Interpretation erfolgt und deshalb die Mails im Junk landen. Von Microsoft kam nichts mehr. Der Kunde hat gar noch mit „Set-InboundConnector -EFSkipLastIP“ versucht, den letzten Hop (also den Provider) zu überspringen, aber auch das führte zu nichts. Wir haben dann nochmal den Exchange Server Support von Microsoft kontaktiert. Und die meinten doch ernsthaft: Ihr habt doch schon eine Lösung vom Cloud Support, das geht uns nichts mehr an.
Wir haben dann mal die Liste der erlaubten IP-Adressen erweitert. Dort standen die Edge Transport Server nicht drin. So etwas hatte der Microsoft Supporter vom Exchange Server Support zwischen den Zeilen erzählt. Das Resultat war, dass die Mails jetzt nicht mehr mit einem harten „spf=fail“, sondern mit einem „spf=softfail“ gekennzeichnet wurden. Im Junk landeten sie nach wie vor. Das haben wir gemacht:
Set-HostedConnectionFilterPolicy "Default" -IPAllowList xxx.xxx.xxx.xxx
Wie ging es denn weiter?
Ich habe es noch nicht erzählt: Die Kunden-Organisation hat Centralized Mailflow eingerichtet. Das bedeutet, dass eben auch Mails auf Exchange Online zuerst über die Edge Transport Server gehen und von dort aus über den Provider verschickt werden. Wir haben dennoch mal die DKIM-Einstellungen überprüft. Da dort nichts zu finden war, was uns irgendwie hätte weiterhelfen können, haben wir dann folgendes getrieben, um den Exchange Hybrid Mailflow sicherzustellen:
- Manuell die internen SMTP Server in die Transport-Konfiguration geschrieben
- Die Transportdienste auf den Exchange Servern neu gestartet
- In Exchange Online die Hosted Connection Filter Policy so bearbeitet, dass alle On-Premises Exchange Server erlaubt wurden
Auch das führte letzten Endes zu nichts und wurde wieder zurück gebaut. Wir hatten dann auch die Mail-Verschlüsselung durch eine Appliance in Verdacht, weil diese uns in den Transport Connectivity Logs ausgeworfen wurde. Das hat sich nicht erhärtet. Wir hatten dann die Edge Subscription neu angelegt, um auch hier Fehler auszuschließen. Und weiter landeten Mails an Postfächer, die noch auf den Servern liegen, im Junk.
Ehrlich gesagt, haben wir nie abschließend herausfinden können, wieso das Alles passiert ist. Wir haben um die 30 Stunden Support für diesen Kunden geleistet, alles abgeklopft, auch Consultants auf die Umgebung losgelassen, denn vielleicht sehen andere Augen mehr. Wir konnten es nicht vollständig lösen. Das ärgert den Support immer.
Abschließende Worte
Nach über 30 Stunden, die über einen Zeitraum von einem halben Jahr angefallen sind, bleibt die Erkenntnis, dass es immernoch Probleme gibt, die man nicht lösen kann. Die Kundenumgebung ist ein hochkomplexes Konstrukt, das über einen Zeitraum von über 25 Jahren so gewachsen ist. Vielleicht grätschte die genannte Appliance dazwischen, weil sie Probleme mit Exchange Hybrid Mailflow hat. Vielleicht ist die kaskadierte Firewall nach innen und nach außen schuld. Wir wissen es nicht.
Es könnte am Ende am Zusammenspiel aller Komponenten gelegen haben. Schließlich habe ich im Hybrid-Umfeld einiges erlebt. Ich habe immer wieder erlebt, dass Exchange Server äußert zickige Diven sein können. Warum soll das beim Exchange Hybrid Mailflow nicht so sein? Da könnte es passieren, dass durch einen einzigen fehlenden Patch beim Load Balancer, der dazwischen hängen könnte, dazu kommt, dass gar keine Mails mehr transportiert werden.
Ja, ich höre es schon, dass doch die Organisation komplett in die Cloud gehen soll. Allerdings ist das aus verschiedenen Gründen eben nicht möglich. Wenn dann aber die Zustellung von Emails ohne Verhaltensmuster einfach mal schief geht, bleibt man leider ratlos. Vielleicht gibt es ja in Zukunft bessere Möglichkeiten, mit denen dann die Organisation auch gut leben kann. Denn so ist das leider unbefriedigend.