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.

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 Stickprobe habe ich verifiziert, dass diese Adressen nicht exklusiv für mich reserviert sind. Es gibt weitere Domänen, die auf die gleichen IP-Adressen verweisen. 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 ebenfalls wichtig, 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 unterschiedliche 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
  • 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.

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

Connector MAIL FROM RCPT TO Status Ergebnis

Organization

Accepted Domain

Accepted Domain

Kommt eigentlich nur vor, wenn es sich um eine Mail innerhalb einer Hybrid-Bereitstellung handelt. Allerdings akzeptiert Office 365 dies nur, wenn es über einen "Organization Connector" kommt, der z.B.: per Source-IP oder TLS-Zertifikat abgesichert ist

Organization

Accepted Domain

Fremde Domain

Relay in das Internet, wenn Sie von On-Premises über Exchange Online Protection in die Cloud senden

Organization

Fremde Domain

Accepted Domain

Ist möglich, wenn der MX-Record auf ihren lokalen Spamfilter läuft und Sie dann die Mails von ihrem lokalen Exchange im Rahmen einer Hybrid-Bereitstellung an Office 365 weiterlieten

Organization

Fremde Domain

Fremde Domain

Wird abgelehnt. Allerdings könnte die "Fremde-Domain" ja einem anderen Tenant gehören. Dieser Fall kommt in ihrem Tenant also nicht vor.

Partner

Accepted Domain

Accepted Domain

Ein Partner sollte nicht mit ihrer Domäne senden.

Partner

Accepted Domain

Fremde Domain

Erst recht sollte er nicht über ihren Tenant mit ihren Adressen noch ins Internet senden.

Partner

Fremde Partner Domain

Accepted Domain

Wenn die Fremde-Domain dem partner gehört, dann ist dieser Weg erlaubt.

Partner

Fremde Partner Domain

Fremde Domain

Ein Partner sollte nicht über ihren Tenant ins Internet senden. Allerdings kann die aus ihrer Sicht "fremde Domain" ja in einem anderen Tenant  eine Accepted Domain sein.

Any

Accepted Domain

Accepted Domain

Wenn alles richtig konfiguriert ist, sollte diese Mail nicht ankommen, da Sie z.B. per SPF das Spoofing verhindern können.

Any

Accepted Domain

Fremde Domain

An ihren Tenant kann die Mail so nicht zugestellt werden. Es könnte aber in einem anderen Tenant einen passenden Connector geben, d.h. wenn Sie eine Mail zu einem anderen Tenant senden. Das ist dann aber der Fall in der nächsten Zeile

Any

Fremde Domain

Accepted Domain

Eingehende Mail von anderen Domänen. Spamfilter etc. werden angewendet

Any

Fremde Domain

Fremde Domain

Ich bin sicher, dass Microsoft diesen Weg sicher verhindert.

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. Primär ist hier die Source-IP-Adresse zu betrachten, die ich in einem "Inbound Connector" spezifizieren kann.

Connection Filter: WhiteList/Blacklist

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 Whitelisting 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 WhiteList überhaupt mitspielen durfte. Die Ablehnung kommt immer erst nach dem "RCTP TO", damit Office 365 so den Tenant ermitteln kann.

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. Also muss er auf jeden Fall warten, bis er ein "RCPT TO" mit einem Empfänger erhalten hat, um die passende Konfiguration fest 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 RPB-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.

Connector mit Source-IP/Zertifikat/Domain

Das "While-Listen" 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

Quelle Beschreibung Qualifizierung

Mein Server

Dieser Connector verbindet eine On-Premises Umgebung mit einem Office 365 Tenant. Aber er kann ihrem On-Premises Server auch erlauben,, über Office 365 in das Internet zu senden. Office 365 nimmt also nicht nur Mails für Empfänger in ihrem Tenant an, sondern auch für externe Empfänger.

  • Zertifikat
  • Source-IP

Partner Server

Diese Connector verbindet ihren Tenant mit einem Partner, der sie aber natürlich nicht als "Relay" verwenden darf

  • From Domain
  • Source-IP
  • Optional TLS-Zertifkat

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.

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:

Parameter Wert Beschreibung

Name

NSP2Tenant

Ich benenne den Connector, damit ich den Verwendungszweck erkenne und in PowerShell einfach als Identity adressieren kann

Connector-Typ

Partner

Ich habe ja nur die Wahl zwischen Partner und Organization und der vorgelagerte Spamfilter ist ja kein Exchange Hybrid und muss über den Tenant auch nicht in das Internet senden

Kriterium

Domain:*

Ich erlaube ja alle Domains von "draußen" zu meinem Tenant

Restrictions

TLS + Source-IP

Damit die Verbindung auf jeden Fall verschlüsselt ist, aktiviere ich TLS. Zusätzlich kann ich noch die Source-IP von NoSpamProxy als Kriterium heranziehen, was aber hier erst mal nichts weiter ausmacht..

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.

Konflikt mit Zertifikat?

Aktuell sind meine Analysen noch nicht ganz abgeschlossen. Es fehlt insbesondere die Situation, dass ein Kunde von On Premises Mails zu Office 356 senden, um so diese ins Internet zu versenden. In dem Fall kommt bei Office 365 ja eine Mail mit einer Zieladresse außerhalb des Tenants an. Besonders wenn die Zieldomäne einem anderen Tenant gehört, könnte hier ein Konflikt auftreten. Ich hoffe diese Information in Kürze nachliefern zu können.

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.
Option Source IP From-Domain STARTTLS MTLS Relay Einstellung

1

IP-Connection Filter

Das White-Listen und Backlisten einer IP-Adresse über die EOP Protection-Regeln reicht aus, um diese Absender zuzulassen ohne weitere Vorgaben zu machen

2

Partner Connector über SourceIP

Wenn Sie nur über die Source-IP gehen, können Sie externen Absendern eine gesicherte Zustellung erlauben.

Achtung: Bei meinen Tests im Dez 2018 hat die Eintragung des Connectors mit einer Source-IP nicht gereicht, einen RBL-Check zu überstehen. Sie müssen also die IP-Adresse auch noch beim Connection Filtering eintragen.

3

Partner Connector über Source-IP und TLS-Zwang

Wenn Sie nur über die Source-IP gehen, können Sie externen Absendern eine gesicherte Zustellung erlauben. Sobald sie aber TLS aktivieren, muss der einliefernde Server zwingend STARTTLS unterstützen. Er kann ansonsten keine Mails unverschlüsselt einliefern. Der Sender braucht dazu aber kein eigenes Zertifikat.

4

Partner Connector über SourceIP mit Client TLS-Zwang

Ergänzend zur vorherigen Einstellung können Sie auch erzwingen, dass der einliefernde Server sich mit einem öffentlichen Client-Zertifikat ausweist. Es ist also eine MTLS (Mutual-TLS) Verbindung

5

Partner Connector mit Client TLS-Zwang ohne Source-IP

Diese Option entspricht Option4 aber verzichtet auf die zusätzliche Filterung nach der Source-IP. Der Partner kann also ohne Änderung auf ihrer Seite auch seine IP-Adressen ändern. Das Zertifikat ist maßgeblich.

6

Partner Connector mit Client TLS-Zwang und From-Domain

Ergänzend zur vorherigen Einstellung können Sie auch erzwingen, dass der einliefernde Server sich mit einem öffentlichen Client-Zertifikat ausweist. Es ist also eine MTLS (Mutual-TLS) Verbindung und natürlich mit bestimmten Absender-Domains kommt

7

Partner Connector mit Client TLS-Zwang und From-Domain ohne Source-IP

Ergänzend zur vorherigen Einstellung können Sie auch erzwingen, dass der einliefernde Server sich mit einem öffentlichen Client-Zertifikat ausweist. Es ist also eine MTLS (Mutual-TLS) Verbindung und natürlich mit bestimmten Absender-Domains kommt

8

Partner Connector anhand der From-Domain

Es ist möglich, einen Partner-Connector einzurichten, mit dem sie einfach eine Absender-Domain zulassen. Solange niemand weiß, dass diese Domain bei ihnen "erlaubt" ist, ist das durchaus denkbar für z.B. Scanner, die mit einer "geheimen" Domain senden aber weder SMTP-AUTH noch STARTTLS unterstützen und mit dynamischen IP-Adressen arbeiten.

9

Partner Connector anhand der From-Domain

Es ist möglich, einen Partner-Connector einzurichten, mit dem sie einfach eine Absender-Domain zulassen. Solange niemand weiß, dass diese Domain bei ihnen "erlaubt" ist, ist das durchaus denkbar für z.B. Scanner, die mit einer "geheimen" Domain senden aber weder SMTP-AUTH noch STARTTLS unterstützen und mit dynamischen IP-Adressen arbeiten.

10

Partner Connector anhand der From-Domain mit IP-Adresse

Sie können den Connector zusätzlich mit IP-Beschränkungen versehen. Wenn der Absender eine statische IP-Adresse hat, haben Sie so eine etwas sicherere Konfiguration. Es fehlt aber die TLS-Verschlüsselung

11-14


...

...


...


...

...

Partner Connector mit TLS

Diese Zeile fasst die weiteren sechs Kombinationen zusammen, die es noch für einen Partner-Connector anhand der "From-Domain" gibt. Je nach Einstellungen wird zusätzliche TLS oder sogar MTLS erzwungen

15

Organization Connector mit TLS

Die Verbindung von einem eigenen On-Premises Server schaltet in Office 365 den Weg frei, auch über Office 365 in das Internet zu senden. Dieses Recht sollten Sie nur ganz selektiv an Absender vergeben.

Achtung: Hier muss der Absender eine Domäne aus ihren "Accepted Domains" nutzen.

16

Organization Connector mit Source-IP

Wenn ihr eigener MailServer wirklich kein MTLS unterstützt und sich nicht mit einem Zertifikat ausweisen kann, dann können Sie natürlich auch allein die Source-IP als Kriterium hernehmen. Office 365 bietet natürlich weiterhin STARTTLS an, aber der Absender muss es nicht nutzen. Eine Verschlüsselung ist damit nicht erzwungen. Aus meiner Sicht ist diese Einstellung maximal für Tests aber nie für einen Echtbetrieb geeignet.

Achtung: Hier muss der Absender eine Domäne aus ihren "Accepted Domains" nutzen.

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.

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
    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-Addresse
    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 bewerten
  2. Prüfe die IP-Adresse gegen RBL, WhiteList, Backlist
  3. Pass 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.

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

 

 

 

 

Weitere Links