Office 365 Inbound Mailrouting

Auf mehreren Seiten, die unten bei Links aufgeführt sind, habe ich verschiedene Konstellationen des SMTP-Mailroutings mit Office 365 beschrieben. Diese Seite beschäftigt sich nun im Details, wie Office 365 bei einer eingehenden Mail die Verbindung und die Mails bewertet und routet.

Diese Informationen gelten für Exchange Online als auch für Firmen, die nur Exchange Online Protection ohne Postfächer nutzen.

Beachten Sie dazu auch die Seiten:

• Office 365 Message Attribution
  https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143
• Inbound connector: FAQ
  https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/inbound-connector-faq

Ist doch einfach, oder wo ist das Problem?

Fangen wir mit einer kleinen Firma an, die nur Postfächer in Office 365 nutzt und damit auch den MX-Record auf Office 365 leitet. Der Office 365 geht einfach auf das Admin Portal unter "Setup -Domains" und überträgt die DNS-Einträge zu seinem DNS-Anbieter.

Das ist einfach, in wenigen Sekunden gemacht und die eingehenden Mails laufen bei Office 365 auf. Genaugenommen landen Sie erst einmal bei Exchange Online Protection, dem Spamfilter vor dem eigentlichen Postfach. Sie sehen aber auch, dass der MX-Record nicht direkt auf IP-Adressen verweist, sondern auf Namen, die von Microsoft verwaltet werden:

PS C:\> Resolve-DnsName uclabor-de.mail.protection.outlook.com

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
uclabor-de.mail.protection.outlook.com         A      10    Answer     104.47.48.36
uclabor-de.mail.protection.outlook.com         A      10    Answer     104.47.50.36

Über eine Stichprobe habe ich verifiziert, dass diese Adressen nicht exklusiv für mich reserviert sind. Es gibt weitere Domänen, die zwar alle auf einen eigenen Namen verweisen, die aber auf die gleichen IP-Adressen zeigen. Nicht jeder Tenant hat daher seine eigenen "persönlichen" IP-Adressen sondern die Tenants einer geografischen Region nutzen die gemeinsamen eingehenden Mailserver. Das ist für die weitere Betrachtung relevant, da Office 365 daher nicht anhand der Ziel-IP unterscheiden kann, an welchen Tenant nun eine eingehende Mail tatsächlich zugestellt wird.

Aber die unterschiedlichen Namen sind dennoch erforderlich, denn es könnte ja sein, dass ein Absender eine Mail an zwei der mehr Empfänger in unterschiedlichen Tenants sendet. Dann muss der Absender natürlich getrennte Mails erstellen, damit Office 365 je nach Tenant andere Regeln anwenden kann.

Empfangsszenarien

Allerdings gibt es ja durchaus verschiedene Konstellationen, bei denen sich Office 365 auch unterschiedlich verhalten muss. Dazu gibt es in der Konfiguration die Möglichkeit zwei Connectoren anzulegen:

• Partner Connector
  Damit binden Sie andere Dienste ein, denen Sie ein höheres Vertrauenslevel oder strengere Vorgaben, z.B. TLS erzwungen, vorgeben. Es bleiben aber Spamfilter und andere Regeln in Kraft, d.h. muss die Absenderdomain angegeben werden, so dass ein Spoofing nicht möglich ist
• Organization Connector
  Damit verbinden Sie ihren Tenant mit ihrer On-Premises Umgebung, so dass möglichst viele Informationen ankommen, z.B. die Exchange-spezifischen Header erhalten bleiben. Über den Weg kann eine OmPrem-Umgebung Mails nicht nur an den eigenen Tenant in der Cloud senden sondern sogar darüber in das Internet

Zudem gibt es noch die übliche Connection-Filterung um bösartige Verbindungen, z.B. RBL-Listen, frühzeitig zu verhindern.

Wenn die Office 365 Server nun ihre eigenen dedizierten Server währen, dann ist so eine Regel ja einfach einzurichten. Aber die Server bedienen ja viele Domains und damit ist die "AcceptedDomain" für ihren Tenant bekannt aber in einem anderen Tenant zählt Sie als "Fremd". Das wird interessant, wenn es mehrere passende Einträge geben könnte. Neben den Domänen in der "MAIL FROM" und "RCPT TO"-Zeile gibt es noch weitere Kriterien zur Klassifizierung, z.B. das Zertifikat oder die Source-IP-Adresse, die ich in einem "Inbound Connector" spezifizieren kann oder muss.

Connection Filter: Allowlist/Blocklist

Nun ist es ja so, dass selbst die kleinste Firma z.B. Mails von bestimmten Quellen nicht im Spamfilter landen lassen will. Es geht als um das Allowlisting von z.B. einer eigenen statischen IP-Adresse um z.B. "vertrauenswürdige" Drittprodukte wie Scanner, ERP oder auch einen 3rd Party Spamfilter immer zuzulassen. Dazu gibt es in Office 365 Exchange Admin Center einen gesonderten Eintrag "Protection":

Über den Weg kann ich in meinem Tenant bestimmte IP-Adressen generell zulassen oder auch blocken. Beachten Sie, dass es nur eine "Default" Einstellung gibt und Sie hier maximal 24er Subnetze eintragen können:

Wenn Sie hier Änderungen vornehmen, dann sollten Sie Geduld mit bringen. Ich habe teilweise 2 Stunden und mehr gewartet, bis meine dynamische IP-Adresse des DSL-Anschluss über ein Allowlist überhaupt mitspielen durfte. Die Ablehnung kommt immer erst nach dem "RCTP TO", damit Office 365 so den Tenant ermitteln kann.

Welcher Tenant ist maßgeblich?

Aber halt mal! Woher kennt der Office 365 Mailserver denn den Zieltenant, wenn die Verbindung gerade erst aufgebaut wird? Er kann es ja wohl nicht an der Ziel-IP festmachen, wie ich im vorherigen Abschnitt beschrieben habe. Aber auch die Quell-IP oder den Zertifikatname des Absenders können mehrere Administratoren unterschiedlicher Tenants konfigurieren. Exchange Online muss daher auf jeden Fall warten, bis der "RCPT TO" mit einem Empfänger erhalten hat, um die passende Konfiguration zu machen. Ich habe das einfach auch getestet:

telnet uclabor-de.mail.protection.outlook.com 25

220 BY2NAM05FT028.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Tue, 11 Dec 2018 14:30:52 +0000
HELO extern.com
250 BY2NAM05FT028.mail.protection.outlook.com Hello [46.85.243.227]
MAIl FROM:user1@carius.de
250 2.1.0 Sender OK
RCPT TO:fcarius.admin@fcarius.onmicrosoft.com
550 5.7.1 Service unavailable, Client host [46.85.243.227] blocked using Spamhaus. 
   To request removal from this list see https://www.spamhaus.org/query/ip/[46.85.243.227] (AS16012612) 
   [BY2NAM05FT028.eop-nam05.prod.protection.outlook.com]
QUIT
221 2.0.0 Service closing transmission channel

Ich habe dann natürlich schnell mal die IP-Adresse eingetragen. Allerdings kann es schon einige Minuten dauern, bis Office 365 diese Änderung annimmt. Danach konnte ich an meinen Tenant eine Mail senden aber natürlich weiterhin nicht an andere Tenants.

Ich habe extra von einer Domain gesendet, die SPF mit "-all" nutzt. Dennoch sind die Mail angenommen worden. Das White-Listing umgeht also nicht nur einfache RBL-Checks sondern auch SPF-Checks.

Weil die Regel ja nur auf meinen Tenant gelten darf, habe ich natürlich auch schnell mal geprüft, was bei einer gemischten Mails passiert d.h. ich habe in einer Transaktion eine Mail an mehrere Personen in unterschiedlichen Tenants senden wollen.

telnet uclabor-de.mail.protection.outlook.com 25

220 DM3NAM05FT061.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Tue, 11 Dec 2018 16:36:03 +0000
HELO extern.com
250 DM3NAM05FT061.mail.protection.outlook.com Hello [46.85.243.227]
MAIL FROM:user1@carius.de
250 2.1.0 Sender OK
RCPT TO:user1@fcarius.onmicrosoft.com
250 2.1.5 Recipient OK
RCPT TO:user1@msxfaq.onmicrosoft.com
452 4.5.3 Recipients belong to multiple tenants [DM3NAM05FT061.eop-nam05.prod.protection.outlook.com]
QUIT
221 2.0.0 Service closing transmission channel

Normal ist das aber auch kein Problem, da ein SMTP-Server eine Mail an mehrere Empfänger bei unterschiedlichen SMTP-Domains aufsplittet und in eigenen Sessions überträgt. Dabei ist es auch nicht relevant, ob der MX-Record auf unterschiedliche Hostnamen verweist und die vielleicht sogar noch die gleiche IP-Adresse hätten.

Ich habe es natürlich auch getestet, einen Office 365 Mailserver anzusprechen, der nicht für eine Domain zuständig ist. Das würde natürlich nie ein Mailserver tun, da es keinen MX-Record gibt. Für den Fall, dass er es dennoch tut, gibt es folgenden Fehler:

451 4.4.62 Mail sent to the wrong Office 365 region. ATTR35. 
  For more information please go to https://go.microsoft.com/fwlink/?linkid=865268 
  [DM3NAM05FT045.eop-nam05.prod.protection.outlook.com]

Sie sollten also nie Richtung Office 365 irgendwelche statische IP-Adressen nutzen, sondern nur über DNS die MX-Records auflösen.

• "451 4.4.62 Mail sent to the wrong Office 365 region. ATTR35" when mail sent to EOP/EXO
  https://support.microsoft.com/en-us/help/4057301/attr35-response-code-when-mail-is-sent-to-eop-exo
  https://go.microsoft.com/fwlink/?linkid=865268
• How to prevent real email from being marked as spam in Office 365
  https://docs.microsoft.com/de-de/office365/securitycompliance/prevent-email-from-being-marked-as-spam

Connector mit Source-IP/Zertifikat/Domain

Das "Allowlisten" reicht für eingehende Mails aus dem Internet oder fremden Domänen an den eigenen Tenant. Aber damit stellt sich die Frage, wozu es dann noch den "Inbound Connector" gibt: Hierbei gibt es nur zwei konfigurierbare Optionen, wenn es um den Mailfluss zum Office 365 Tenant geht:

Wenn Sie die beiden Optionen genauer anschauen, dann können beide Connectoren über eine Source-IP-Adressen selektiert werden, um einen Vertrauensvorsprung zu erhalten. Das geht aber auch schon mit dem Connection Filtering. Die Vorteile bei einem Connector sind hingegen:

• TLS-Zwang
  Wenn Sie wissen, dass die Gegenseite TLS unterstützt oder sie sicherstellen wollen, dass eingehende Mails über das unsichere Internet "verschlüsselt" übertragen werden, dann ist ein Connector der richtige Ort um diese Anforderung zu erzwingen:
  
• TLS-Identifizierung statt IP-Adressen
  Eine IP-Adresse ist nur dann ein gutes Kriterium, wenn sie statisch und dem Absender dauerhaft zugeordnet ist. Das funktioniert nicht mit dynamischen Adressen oder wenn der Absender z.B. den Provider wechselt. Hier sind Zertifikate mit einem Namen zur Identifizierung deutlich leistungsfähiger. Sie funktionieren sogar, wenn mehrere Absender sich hinter einer IP-Adresse, Stichwort Enterprise NAT oder IPv6 auf IPv4 Umsetzung, verbergen. Die Verschlüsselung gibt es dann noch dazu.
• Absender-Domain beschränken
  Weiterhin können Sie erzwingen, dass z.B. Mails von einer bestimmten Domain auch nur über diesen Connector kommt. Das erschwert die Fälschung von Absendern.

Ein Connector erlaubt also eine weitergehende Konfiguration für eingehende Mails. dennoch muss auch hier die Eignung für den Einsatzzweck hinterfragt werden.

Microsoft Routing

Diese Seite ist lange entstanden, ehe Microsoft im Jahr 2019 erstmals etwas die Entscheidungslogik für eingehende Mails gelüftet hat. Wenn Microsoft nichts ändert, dann ist folgende Seite die Referenz:

• Office 365 Message Attribution
  https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143

Der Artikel beantwortet gleich mehrere Fragen, ehe er zum Entscheidungsbaum kommt.

1. Bestimmen der Richtung
   Office 365 nutzt dazu folgende drei Kriterien:
   • IP-Adresse/Zertifikatname des einliefernden Systems
   • EnvelopeFrom
   • EnvelopeTo
2. Finde einen "Inbound Connector" vom Typ "On-Premises" in allen Tenants mit dem Zertifikat/SAN-Name
   Das Verfahren ist relativ sicher, da eine Firma ja nur ein Zertifikat für ihre Domains bekommen kann und damit kein anderer Tenant einen vergleichbaren Connector anlegen sollte. Aber es könnte schon sein, dass es mehrere "passende" Connectoren gibt. Dann kommt der nächste Schritt
3. TLS-Zertifikat und Accepted Domain
   Finde heraus, zu welchen Tenant es passende "Accepted Domains" zum TLS-Name gibt. Idealerweise gibt es einen Tenant und die Mail wird als "eingehend" klassifiziert"
4. Suche anhand der IP-Adresse
   Ansonsten nutzt Exchange Online die IP-Adresse des Absenders und sucht in allen Tenants einen Connector vom Typ "On-Premises". Wenn es dann mehrere Connectoren gibt, wird die Domain aus dem "Envelope From" genutzt, um den Tenant zu bestimmen. Das ist übrigens ein Grund, warum z.B. vorgelagerte Spamfilter wie NoSpamProxy (Siehe EXO mit NoSpamProxy) niemals als "Inbound On-Premises" sondern immer nur als "Partner-Connector" konfiguriert werden dürfen.
5. Behandlung als Eingehend anhand Envelope-To
   Wenn die vorherige Analyse keinen Treffer geliefert hat, dann wird die Mail als "eingehend" an einen Tenant definiert und anhand der Envelope-To-Adresse der Tenant bestimmt. Mit dem Wissen um den Tenant kann dann noch einmal geschaut werden, ob es einen "besseren" Partner-Connector gibt oder der immer vorhandene "Default Inbound Connector" genutzt wird.
6. Ablehnen als Relay
   Wenn auch im letzten Schritt kein Match möglich ist, wird die Mail abgelehnt.

Was lernen wir daraus?

• Inbound Connectoren sollten mit Zertifikaten arbeiten.
  IP-Adressen sind eher ein Fallback. Beim Zertifikat sollten der Domainname auch eine Accepted Domain sein.
• Wildcard-Zertifikate sind nicht gut
  Speziell wenn der On-Premises-Server mit mehreren Tenants kommunizieren soll. Dann sind eindeutige Namen und ggfls. mehrere Zertifikate wünschenswert aber nicht erzwungen, da zusätzlich auch die MAILFROM bzw. RCPT TO-Domain zum Einsatz kommt. Siehe auch AcceptCloudServicesMail und CloudServicesMailEnabled
• Partner-Connectoren sind für vorgelagerte "Hosted Spamfilter" erforderlich.
  On-Premises-Connectoren passen nicht, wenn der Filter mehrere Tenants mit dem gleichen Zertifikat bespielt.

Konflikte provozieren

Um zu verstehen, was genau passiert, habe ich einige Konflikte absichtlich eingerichtet, sofern diese vom Assistent nicht unterbunden werden.

• Zwei Connectoren mit gleicher Absender-Domain und unterschiedlichen TLS-Anforderungen
  Connector1 hatte also TLS erzwungen und Connector 2 hatte zusätzlich noch den CN des Client-Zertifikats hinterlegt. Exchange Online hat beim Zustellversuch den Konflikt erkannt und die Annahme verweigert, weil es einen Connector gibt, der die Beschränkung auf ein Client-Zertifikat hat.

550 5.7.51 TenantInboundAttribution; There is a partner connector configured that matched the 
   message's recipient domain. The connector had either the RestrictDomainsToIPAddresses 
   or RestrictDomainsToCertificate set [CO1NAM05FT038.eop-nam05.prod.protection.outlook.com]

• Ein Connector für Absenderdomain mit TLS Zwang und unverschlüsselter Zustellversuch
  Dann habe ich einen Connector für eine Absenderdomain mit TLS konfiguriert und versucht eine Mail ohne TLS zuzustellen. Ich wollte also z.B.: sicherstellen, dass kein Fallback auf "kein TLS" erfolgt. Auch hier kommt die gleiche Fehlermeldung, dass es einen Zertifikatzwang gibt.

550 5.7.51 TenantInboundAttribution; There is a partner connector configured that matched the
   message's recipient domain. The connector had either the RestrictDomainsToIPAddresses 
   or RestrictDomainsToCertificate set [CO1NAM05FT034.eop-nam05.prod.protection.outlook.com]

Wenn Sie also einen eigenen Inbound Connector für eine Absender-Domain einrichten, dann muss die Absenderdomain auch alle Anforderungen erfüllen. Ansonsten wird die Mail nicht angenommen. Es gibt also keinen Fallback auf einen Empfang ohne Connector.

Konflikt: Mein Tenant und dein Tenant

Ein weiterer Konflikt ist denkbar, wenn ich in meinem Tenant einen Connector einrichte, der Mails von meinen Domains an fremde Domains annimmt und in das Internet oder einen anderen Tenant weiter leitet. Das kann mit einem Organization Connector erfolgen aber auch mit einem Partner Connector. Also richte ich folgendes z.B. mit meinem Spamfilter in der Cloud ein:

Wenn Sie diese Konfiguration nun anschauen, dann scheint soweit alles richtig zu sein. Mails aus dem Internet kommen über NoSpamProxy nach dem Spamfilter in meinem Tenant an. Doch ist alles richtig ?

Durchdenken wir mal einen anderen Fall: Ich sende natürlich von meinem Office 365 Tenant auch Mails in das Internet. Diese Mails gehen natürlich ausgehend an meinen NoSpamProxy, der die Mails dann ins Internet sendet. Interessant wird es, wenn das Ziel ebenfalls auf Office 365 gehostet wird. NoSpamProxy baut eine Verbindung über den MX-Record zum Office 365 Service auf, um die Mail mit meiner Absenderadresse an eine Adresse in einem "anderen" Office 365 Tenant zu senden.

Exchange Online Protection erkennt nun aber erst einmal eine eingehende Verbindung von einer IP-Adresse und kenn den dazu gehörigen MAIL FROM und RCPT TO. Sofern die Verbindung per TLS gesichert wurde, weiß er auch das und ggfls. das vom Absender vorgelegte Client-Zertifikat. Anhand dieser Daten muss Exchange Online nun entscheiden, ob dies eine Verbindung von diesem externen System zu einem anderen Tenant zur Übermittlung ausgehender Mails ist oder die eingehende Verbindung vom gleichen System an Empfänger im eigenen Tenant oder sogar im nachgelagerten Exchange On-Premises System.

Natürlich könnte ich nun sagen, dass der Schüssel dazu die Domäne in der RCPT TO-Adresse ist., da diese immer genau nur bei einem Tenant hinterlegt sein kann und damit das Ziel eindeutig ist. Aber denken Sie daran, dass auch eine ausgehende Mail vom On-Premises Exchange über Office 365 in das Internet gehen kann und damit bei Office 365 eine SMTP-Verbindung mit einer fremden Domäne als Ziel und einer Adresse aus ihren "Accepted Domains" ankommt. Diese Verbindung muss von Office 365 also zuverlässig als "eingehend in in einen anderen Tenant erkannt werden.

• EXO mit NoSpamProxy

Konflikt mit Zertifikat?

Theoretisch könnte es in zwei Tenant den gleichen "Inbound Connector" geben, der über das gleiche Zertifikat spezifiziert wird. Das ist aber mit Exchange Online kein Problem, denn Microsoft findet im ersten Durchlauf sehr wohl die beiden Connectoren in den verschiedenen Tenants. Wenn es aber mehr als einen Tenant gibt, dann wird zusätzlich geprüft, welches Tenant die Domain des Zertifikats als "Accepted Domain" hat. Und da kann es immer nur einen geben.

Der richtige Connector

Um sicher zu stellen, dass Mails an ihren einen Office 365 Tenant wie gewünscht zugestellt werden, gilt es eine Auswahl zu treffen. Hier eine Übersicht der Möglichkeiten und des passenden Connectors.

• STARTTLS
  Der Absender kann die Verbindung per TLS verschlüsseln.
• MTLS
  Der Absender muss sich seinerseits mit einem vertrauenswürdigen Zertifikat ausweisen, dessen CN überprüft wird.

Die Tabelle sieht vielleicht etwas chaotisch aus, aber überlegen Sie einfach, welche Anforderungen sie haben und finden Sie dann die Connectoren, die am ehesten passen.

Beachten Sie zudem den "Sonderfall Hybrid Centralized Mail Transport und Exchange Online mit Wildcard-Zertifikat

Empfehlung für Partner: Option 6 oder 7

Wenn Sie mit einer anderen Firma einen "sicheren" Informationsaustausch wollen, der verschlüsselt und gesichert erfolgt und eine Fälschung der Absenderadresse ausschließen wollen, dann ist die Option 5 oder in abgeschwächter Form auch Option 6 mein Favorit.

• Verbindung ist per MTLS verschlüsselt
  Kein anderer Server kann sich als diese Firma ausgeben, wenn wir mal die Falschausstellung von Zertifikaten außen vor lassen
• Absender-Domain geschützt
  Office 365 nimmt nur über diesen Connector Mails von den angegebenen Domains an.

Allerdings ist für die Funktion auch eine Mitarbeit der Partners erforderlich

• MTLS und Zertifikat
  Sein Mailserver muss ein öffentliches Zertifikat haben, dessen Namen er ihnen mitteilt und er muss MTLS unterstützen.
• Liste der Domains
  Zudem sollten Sie eine Liste der Domains von ihrem Partner erhalten, die sie so schützen wollen.

Wenn Sie die Absender-Domäne hinterlegen, dann wird jeder Versuch verhindert, mit dieser Domäne etwas "seitlich" einzuliefern". Schon beim RCPT TO kommt die Fehlermeldung:

220 DM3NAM05FT051.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Tue, 11 Dec 2018 19:43:34 +0000
helo uclabor.de
250 DM3NAM05FT051.mail.protection.outlook.com Hello [80.66.20.27]
mail from:user1@carius.de
250 2.1.0 Sender OK
rcpt to:user2@fcarius.onmicrosoft.com
550 5.7.51 TenantInboundAttribution; There is a partner connector configured that matched the message's recipient domain.
   The connector had either the RestrictDomainsToIPAddresses or RestrictDomainsToCertificate set 
   [DM3NAM05FT051.eop-nam05.prod.protection.outlook.com]

Vorgelagerter Spamfilter: Option 4 oder 5

Auf der Seite EXO mit NoSpamProxy habe ich beschrieben, wie ein vorgelagerter Spamfilter mit Office 365 "verschaltet" werden kann, damit eingehende Mails zuverlässig im eigenen Tenant landen während ausgehende Mails auf jeden Fall bei anderen Tenant der dortigen Konfiguration unterworfen werden.

Sie wissen aber nun auch, dass ein "Organization Connector" der falsche Weg ist, wenn Sie z.B. NoSpamProxy einsetzen, da die Empfänger ja alle in ihrem Tenant sind. Die Anwendung des Organization Connectors findet eh nur statt, wenn der Absender in ihren "Accepted Domains" liegt und ein offenes Relay wollen wir ja auch nicht.

Aber selbst beim Partner Connector gibt es ja noch eine mächtige Auswahl. Wenn ihr Spamfilter aber TLS und MTLS unterstützt, würde ich ein Zertifikat kaufen und dieses auch zur Qualifizierung für den eigenen Tenant nutzen. Ohne Zertifikat bleibt dann nur noch die Source-IP. Eine Steuerung über die "From-Domain" ist falsch, da ja jede Domäne aus dem Internet ein "Absender" sein kann.

Also bleiben nur die Optionen 4 und 5, wobei ich mich eher auf die Option 5 beziehe. Damit lasse ich dem Partner oder dem vorgelagerten Spamfilter mehr Optionen bei der Platzierung im Internet. Nur in Umgebungen, wo allein die Prüfung auf den Namen in einem vertrauenswürdigen Zertifikat nicht ausreicht, kann ich die IP-Adressen der Quellen als zusätzliches Kriterium heranziehen.

Entscheidungsbaum

Die Anfangs gestellte Frage, wie Office 365 bei all den Connectoren und Tenants denn unterscheiden kann, welche Konfiguration nun tatsächlich angewendet ist, lässt sich mittlerweile beantworten.

• Warten auf RCPT TO
  Exchange Online bzw. Exchange Online Protection lehnt eine Verbindung nie schon beim TCP-Connect, SMTP-HELO oder MAIL FROM ab, sondern wartet auf das erste RCPT TO

Sobald dieses Informationen zusammen sind, kann Exchange Online folgende Kriterien zur Suche nach der passenden Konfiguration heranziehen:

• Source-IP
  Von welcher Adresse die Verbindung eingehend aufgebaut wurde.
• Domain aus dem Mail-From
  Welche angebliche Domäne der Absender vorgibt.
• TLS aktiv/Zertifikatname
  d.h. hat der Absender eine angebotene TLS-Verbindung aufgebaut.
• Zertifikatname bei MTLS
  Wenn der Client auch sein Client-Zertifikat mit gesendet hat dann, dann kennt Office den CN aus dem Zertifikat.
• Empfängeradresse
  Aus dem RCPT-TO kann der SMTP-Service den Zieltenant ermitteln, in dessen Konfiguration er nun nach einen passenden Connector sucht.

Wenn Sie nun mehrere Connectoren haben, dann muss es eine Gewichtung der Kriterien geben. Ansonsten könnten mehrere Connectoren für die gleiche Mail zutreffend sein. Auch hier sind erst mal nur die Partner-Connectoren interessant. Die Organisations-Connectoren greifen ja nur, wenn der Absender aus meiner "Accepted Domain" List ist. Ich habe einfach versucht einige Konflikte anzulegen:

• IP-Adresse
  Es ist schon mal nicht möglich zwei Connectoren mit der gleichen Source-IP-Adresse anzulegen
  
  Das bedeutet aber auch, dass alle versuche abhängig von der From-Domain oder TLS-Parametern unterschiedliche Dinge zu tun, nicht möglich sind. Die Fehlermeldung kommst sogar, wenn die IP-Adressen sich einschließen, also z.B. ein Connector genau eine IP-Adresse hat und der andere Connector ein Subnetz, in dem auch diese Adresse enthalten ist. IP-Adressen müssen also eindeutig sein.
• Absender-Domain
  Ich konnte aber problemlos zwei Connectoren für die gleiche "From-Domain" anlegen und z.B. unterschiedliche TLS-Vorgaben machen. Hier hätte ich auch eine Fehlermeldung erwartet. Denn es ist nicht definiert, welcher Connector dann gewinnt.

Allen Dialogen ist aber gemeinsam, dass es Seiten zur "Identifikation" des Partner-Connectors anhand der IP-Adresse oder Domänen gibt und dann die Sicherheitseinschränkungen angewendet werden. Ich nehme daher an, dass die Sicherheitsbeschränkungen nicht zur Auswahl eines Connectors genutzt werden, sondern ob die Mail angenommen wird, wenn die vorherigen Bedingungen passen.

Für mich ergibt sich folgender Ablauf bei der Auswahl des passenden Connectors.

1. Nutze den RCPT TO um den Tenant zu ermitteln
   Das ist aber kein absolutes Kriterium, denn Sie könnten ja von On-Prem auch durch EXO in die Cloud senden. Also muss auch MAIL FROM genutzt werden.
2. Prüfe die IP-Adresse gegen RBL, Allowlist, Backlist
3. Passt die IP-Adresse auf einen Partner Connector
4. Passt die From-Domain auf einen Partner Connector
5. Stimmen die Security Einschränkungen
6. Wende den passenden Connector an.

Ich habe mal versucht das in einem kleinen Flussdiagramm abzubilden:

Das Dokument ist noch nicht komplett. Es fehlt noch der Fall, bei dem Sie von einem On-Prem Postfach über EOP in die Welt senden.

Ob diese Logik aber 100% korrekt ist, konnte ich noch nicht in allen Fällen durchtesten.

Was ich bislang noch nicht abschließend beantworten konnte, ist die Reihenfolge, in der die verschiedenen Werte bewertet werden.

So gibt es durchaus noch Tests, die aus meiner Sicht einen Konflikt darstellen können, das Sie bei der Konfiguration noch nicht verhindert werden, z.B.

• New-InboundConnector
  https://docs.microsoft.com/en-us/powershell/module/exchange/mail-flow/new-inboundconnector?view=exchange-ps
• Office 365 Message Attribution
  https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143
• Set up connectors to route mail between Office 365 and your own email servers
  https://docs.microsoft.com/de-de/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/set-up-connectors-to-route-mail#what-happens-when-i-have-multiple-connectors-for-the-same-scenario

Sonderfall: Routing über EOP

Einem besonderen Routingfall widme ich einen eigenen Abschnitt. Es gibt nämlich die Situation, dass ein Benutzer von einem On-Prem Postfach seine Mails über Exchange Online Protection versendet.

In diesem einen Fall muss sich Exchange Online und Exchange Online Protection anders verhalten. Von dem On-Premises Exchange Server kommen Nachrichten an Exchange Online, deren Absender von der eigenen Domäne kommen und die Empfänger nicht nur im eigenen Tenant sondern auch auf anderen Servern und anderen Tenants liegen können. Die Microsoft Cloud ist also ein "Relay" zum Internet. Natürlich sichert man diese Konfiguration entsprechend mit TLS und/oder der Source-IP ab, damit darauf kein öffentliches Relay wird.

Einlieferung von M 365 Diensten per MX-Record

Es gibt noch weitere Absender, die Nachrichten an ihre Empfänger bzw. ihren Tenant senden und irgendwie ihrem Tenant zugeordnet sind. Folgende Absender von eigenen Diensten an eigene Benutzer habe ich gefunden:

• Ausgehende Teams Notification/Mentioning: noreply@email.teams.microsoft.com
• Eingehend an Channel: xxxxxxxx.<tenantdomain>@amer.teams.ms
• Ausgehende Microsoft Planner <noreply@planner.office365.com>
• Ausgehend: Microsoft Azure PIM <azure-noreply@microsoft.com>
• Ausgehend: Microsoft 365 Message center <o365mc@microsoft.com>
• Ausgehend: Yammer Nachrichten Net at Work GmbH in Yammer <noreply@yammer.com>

Alle einliefernden Systeme kommen aber nicht von "innen" sondern senden von extern über den MX-Record ihre Mails an ihren Mailserver zu. Das kann natürlich Office 365 sein aber ebenso einen gehosteten Spamfilter oder ihr On-Premises-System. Microsoft gewährt diesen Systemen also keinen "Vertrauensvorschuss", nur weil diese durch einen Benutzer oder Prozess ihres eigenen Tenants initiiert wurde.

Weitere Links

• Office 365 Mail Connector
• Exchange Online Connector Routing
• Exchange Online als Nebeneingang für Mailempfang
• Hybrid Centralized Mail Transport
• Hybrid Mail Routing
• EXO mit NoSpamProxy
• Exchange Online mit Wildcard-Zertifikat
• Office 365 Message Attribution
  https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143
• How to prevent real email from being marked as spam in Office 365
  https://docs.microsoft.com/de-de/office365/securitycompliance/prevent-email-from-being-marked-as-spam
• Exchange Online Service Description - Mail Flow
  https://docs.microsoft.com/en-us/office365/servicedescriptions/exchange-online-service-description/mail-flow
• Inbound connector: FAQ
  https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/inbound-connector-faq
• Transport routing in Exchange hybrid deployments - Outbound messages to the Internet
  https://docs.microsoft.com/de-de/exchange/transport-routing#outbound-messages-to-the-internet
• Set up connectors for secure mail flow with a partner organization
  https://docs.microsoft.com/de-de/exchange/mail-flow-best-practices/use-connectors-to-configure-mail-flow/set-up-connectors-for-secure-mail-flow-with-a-partner
• Configure Exchange Online inbound mail flow to accept SMTP connection only from a specific mail security gateway IP address
  https://o365info.com/configure-exchange-online-inbound-mail-flow-to-accept-smtp-connection-only-from-a-specific-mail-security-gateway-ip-address/
• Configure Inbound Delivery Routing for Office 365
  https://community.mimecast.com/docs/DOC-1608-configure-inbound-delivery-routing-for-office-365
  IP-Adresse des Absenders aus dem Spamfilter ausnehmen. Eventuell irrelevant wenn TLS Zertifikatname ?
• Adding Network Ranges to Office 365
  https://community.mimecast.com/docs/DOC-2154
  Office 36 erlaubt keine Netze größer als /24
• THE CURIOUS LOGIC BEHIND SOME EOP ROUTING DECISIONS
  http://www.enowsoftware.com/solutions-engine/the-curious-logic-behind-some-eop-routing-decisions
• Locking Down Your Office 365 Inbound Email Flow
  https://community.mimecast.com/docs/DOC-2115
  Partner Conector mit Reject if not this IP und Domain auf "*"