Partner Connector Wildcard

Auf den Seiten Partner Connector und Partner Inbound Connector habe ich schon viele Fälle beschrieben. Diese Seite behandelt den Sonderfall eines Partner-Connectors mit einem "*" als Domainname als Schutz gegen einen Nebeneingang ohne MX-Record.

Einsatzzweck

Ohne Inbound-Connectoren nimmt Exchange Mails von jedem Host aus dem Internet an, sofern die Zieldomain eine der in Office 365 registrierten Domains ist und Exchange Online damit den Ziel-Tenant erkennen zuordnen kann. Natürlich filtert Exchange Online auch Spam und Werbung in der Basisfunktion aber für einen verbesserten Spamschutz gibt es kostenpflichtige Zusatzlizenzen (Defender for Office 365 Plan1 und Plan2. Hier ein paar Links:

Diese Empfangsmöglichkeit aber aber natürlich nicht erwünscht, wenn ihre Mails nicht direkt von Exchange Online empfangen werden sollen. Denn es gibt zwei andere Optionen:

  • Empfang über Exchange Hybrid
    Ihr MX-Record verweist dazu in der Regel zu einem lokalen Exchange Umgebung, von der die Mails dann über den Hybrid-Connector sicher zum Exchange Online zugestellt werden. In dem Fall sollten Sie mit einem Partner Connector für die Domain "*" eine Fremd-Zustellung verhindern
  • Empfang über einen 3rd Party Spamfilter wie NoSpamProxy
    In diesem Fall sollten Sie Exchange Online darauf beschränken, dass er nur von dieser vertrauenswürdigen Instanz Mails annimmt und nicht Exchange Online als Nebeneingang erlaubt.

Insofern brauchen Sie also immer einen Partner-Connector mit dem Adressraum "*" wenn ihr MX-Record nicht auf Exchange Online verweist.

Einzelner Connector

Der klassische Fall ist ja, dass ein Dienstleister oder ein Service alle Mails an ihren Tenant weiterleiten soll und niemand sonst dran vorbei ihren Tenant erreichen darf. Dann ist das Setup sehr einfach:

  • SMTP-Domain "*"
    Damit gilt der Connector für alle Mails, wenn es keinen besseren Connector gibt. Exchange Online prüft vorher schon, ob es vielleicht einen Organization Connector (Hybrid) gibt oder ein Partner-Connector mit der Domain des Absenders passt.
  • Beschränkungen
    Allein mit der Domain reicht es nicht. Sie müssen zur Sicherheit schon die Verbindung auf IP-Adressen oder/und auf ein TLS-Zertifikat beschränken.

    Sie können auch beide Optionen aktivieren, wenn Sie nicht nur die IP-Adresse der einliefernden Server beschränken sondern auch TLS erzwingen wollen. Denkbar ist aber auch der Verzicht auf die IP-Adresse. Dann sollten Sie aber die TLS-Beschränkung mit dem Namen des Zertifikats vorgeben.

Soweit ist die Story noch einfach.

2x "*" mit Source-IP

Interessant wird es nun, wenn sie zwei Anbieter haben, die beide Mails an ihren Tenant als "Partner" senden wollen. Das kann ein Regelbetrieb sein oder sie wechseln z.B. den Spamdienstleister und wollen für eine Übergangszeit beiden Anbietern die Zustellung erlauben.

Ich habe dazu einfach zwei eingehende Partner Connectoren mit der Domain "*" angelegt die zwei einliefernde Mailserver darstellen sollen. Beide können auch TLS nutzen und haben statische IP-Adressen, die sich auch einfach per SPF-Record auflösen lassen. Ich habe dann einmal mit einer Adresse aus "carius.de" und einmal mit meinem "Netatwork.de"-Konto eine Nachricht an die username@msxfaqdev.onmicrosoft.com gesendet und den Status angezeigt.

Connectorname Restriction:Source-IP Restriction:TLS Restriction:TLSName Ergebnis

IONOS

IP-Adressen von carius.de

nicht gefordert

nicht möglich

Angekommen

NAW

IP-Adressen von netatwork.de

nicht gefordert

nicht möglich

Angekommen

Beide Mails sind im Zielpostfach angekommen:

Für diesen Betrieb bräuchten Sie natürlich keine zwei Connectoren. Sie könnten die Source-IP-Adressen einfach in einem Connector hinterlegen.

Achtung: Microsoft bietet per MX-Record auch ÍPv6-Adressen an. Wenn der Absender ebenfalls IPv6 unterstützt, dann reichen die IPv4-Adressen in der Source-IP-Beschränkung nicht aus.

2x "*" mit Source-IP + 1x TLS

Natürlich möchte ich gerne sicherstellen, dass die Übertragung verschlüsselt erfolgt. Daher habe ich mein Server auch TLS unterstützen und zumindest die Übertragung verschlüssel ist. Zuerst habe ich nur einen Connector auf TLS gestellt und einige Minuten gewartet.

Connectorname Restriction:Source-IP Restriction:TLS Restriction:TLSName Ergebnis

IONOS

IP-Adressen von carius.de

Aktiviert

nicht vorgegeben

Angekommen

NAW

IP-Adressen von netatwork.de

nicht Aktiviert

nicht vorgegeben

Angekommen

Beide Mails sind angekommen und über das Messagetracking konnte ich auch gut sehen, dass die beiden Connectoren passend genutzt wurden.

PS C:\>Get-MessageTrace -RecipientAddress adminfc@msxfaqdev.onmicrosoft.com | get-MessageTraceDetail -Event receive | fl *

....'S:InboundConnectorData=Name=NaW;ConnectorType=Partner....
....'S:InboundConnectorData=Name=IONOS;ConnectorType=Partner;TenantId=......';S:TenantServiceProvider=1n1

Hier ist mir gerade mal aufgefallen, dass es auch ein Feld "TenantServiceProvider" mit dem Wert "1n1" gibt, den mein Firmen-Connector nicht bekommt. Anscheinend hat Microsoft eine Logik, um anderen Provider zu erkennen und vielleicht beim Blacklisting oder Throttling abweichend zu behandeln.

2x "*" mit Source-IP + 1x TLS+Name

Nun drehe ich die Sicherheit bei dem Connector mit TLS noch etwas höher, indem ich den Namen des Zertifikats hinterlege.

Wir haben nun einen Connector, der die Domain "*" bedient und TLS mit einem bestimmten Namen erfordert, während ein anderer Connector nur die IP-Adresse vorschreibt.

Connectorname Restriction:Source-IP Restriction:TLS Restriction:TLSName Ergebnis

IONOS

IP-Adressen von carius.de

Aktiviert

mout.kundenserver.de

Angekommen

NAW

IP-Adressen von netatwork.de

nicht aktiviert

nicht vorgegeben

Angekommen

Auch bei diesem Fall sind beide Mails angekommen und über das Messagetracking konnte ich auch hier sehen, dass die beiden Connectoren passend zugeordnet wurden.

2x "*" mit Source-IP + 1x TLS+Name +1x TLS

Einfach zur Sicherheit habe ich zuletzt noch beide Connectoren mit TLS-Zwang versehen aber nur beim IONOS auch den Namen festgelegt

Connectorname Restriction:Source-IP Restriction:TLS Restriction:TLSName Ergebnis

IONOS

IP-Adressen von carius.de

Aktiviert

mout.kundenserver.de

Angekommen

NAW

IP-Adressen von netatwork.de

Aktiviert

nicht vorgegeben

Angekommen

2x "*" mit Source-IP + 2x TLS+Name

Einfach zur Sicherheit habe ich zuletzt noch beide Connectoren mit TLS-Zwang versehen aber nur beim IONOS auch den Namen festgelegt

Connectorname Restriction:Source-IP Restriction:TLS Restriction:TLSName Ergebnis

IONOS

IP-Adressen von carius.de

Aktiviert

mout.kundenserver.de

Angekommen

NAW

IP-Adressen von netatwork.de

Aktiviert

 ‎*.cloud.nospamproxy.com‎

Angekommen

Auch mit komplett abgesicherter Kommunikation durch SourceIP + TLS mit Zertifikatsnamen kommen die Mails über den passenden Connector an.

Gegenprobe: falscher TLSName

Natürlich habe ich auch noch die Gegenproben gemacht und bei einem Connector den TLS-Namen absichtlich falsch eingegeben.

Connectorname Restriction:Source-IP Restriction:TLS Restriction:TLSName Ergebnis

IONOS

IP-Adressen von carius.de

Aktiviert

mout.kundenserver.de

Angekommen

NAW

IP-Adressen von netatwork.de

Aktiviert

 ‎*.cloud.nospamproxy2.com‎

Abgelehnt

Die Mail über den Net at Work Server, welcher dann natürlich keine Übereinstimmung mehr hatte, kam nicht an. Die Mail von meinem carius.de-Konto über IONOS allerdings schon

Remote server returned '
554 5.7.0 < #5.7.51 smtp;
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 
           [FR2DEU01FT016.eop-deu01.prod.protection.outlook.com 2023-06-06T06:22:40.472Z 08DB6591E8589FA7]>'

Gegenprobe: Fremde IP

Die zweite Gegenprobe ist der Versand von einer IP-Adresse, die nicht aufgeführt ist.

Connectorname Restriction:Source-IP Restriction:TLS Restriction:TLSName Ergebnis

IONOS

IP-Adressen von carius.de

Aktiviert

mout.kundenserver.de

Abgelehnt

NAW

IP-Adressen von netatwork.de

Aktiviert

 ‎*.cloud.nospamproxy.com‎

Abgelehnt

Die Mail wurde natürlich nicht angekommen, da keine der Inbound Partner Connectoren "gepasst" hat.

550 5.7.51 TenantInboundAttribution; There is a partner connector configured that matched the message's recipient domain. The connec
tor had either the RestrictDomainsToIPAddresses or RestrictDomainsToCertificate set [BE1DEU01FT31.eop-deu01.prod.protection.outlook
.com 2023-06-01T23:13:23.730Z 0abbfeD62238CC31]

Zusammenfassung

Wir können festhalten, dass ein Connector mit einer Domain "*" und entsprechenden Beschränkungen auf jeden Fall dafür sorgt, dass alle Mails an diesen Tenant zwingend über ein System kommen müssen, die alle Beschränkungen erfüllen. Es ist relativ problemlos, mehrere Connectoren anzulegen, denn Exchange Online geht alle Connectoren durch, bis er eine Übereinstimmung findet.

Insofern sind auch parallele Einlieferungen und Migrationen problemlos möglich. Sie sollten aber auf jeden Fall darauf achten, dass die "Restrictions" korrekt ausgefüllt sind, d.h. eine Liste von IP-Adressen muss vollständig sein und/oder sie nutzen ein Zertifikatsnamen. Allein "TLS" als Restriction anzulegen, ist allerdings nicht ausreichend sicher, denn das kann jeder Absender. Sie müssen dann schon eine IP-Adresse und/oder den Namen eines Zertifikats konfigurieren.

Weitere Links