Partner Connector

Ein "Partner" ist für Exchange Online eine Firma oder ein Service, welcher eine gewisse "Vertrauensstellung" genießt oder besondere Einstellungen erzwingen soll. Er kann aber auch eine besondere Funktion bekommen, wenn Sie einen vorgelagerten Spamfilter wie NoSpamProxy o.ä. einsetzen und ihren Tenant gegen Nebeneingänge schützen wollen. Diese Seite beschreibt, insbesondere die Entscheidung, welcher Connector genutzt wird.

Ein- und Ausgehend

Einen Connector mit einem Partner können Sie sowohl eingehend als auch ausgehend im Exchange Admin Center oder per PowerShell konfigurieren. De GUI erzwingt dabei schon die beiden einzig möglichen Kombinationen.

Connection From

Connection To

Mögliche Einstellungen

Office 365

Partner

Der "Outbound Connector" für Partner dient dazu, Mails an bestimmte Domänen oder durch feinere Einstellungen einer Transportregel zu eine bestimmten System unter zusätzlicher Berücksichtigung erhöhter Sicherheitsanforderungen zu senden. Exchange Online macht von sich aus schon "opportunistisches TLS", d.h. verschlüsselt, wenn die Gegenseite ein STARTTLS anbietet aber erzwingt keine Prüfung. Wen sie vertrauliche Mails zu einem Partner senden wollen, dann können Sie über den Connector TLS mit einem Zertifikat erzwingen.

  • Connectorname
    Name, Beschreibung, Aktiv An/Aus
  • Verwendung
    Über Transportregel oder SMTP-Domains
  • Routing
    MX oder Smarthost
  • Sicherheit
    TLS an/aus und Optional weitere Einschränkung auf das Zertifikat der Gegenseite

Ein Sonderfall der Partner Connectoren ist der Einsatz der "*" Domain für alle Mails. Früher konnten Sie nicht "*" als Domain verwenden und mussten über eine Transportregel dann alle Mails über einen Connector senden. Mittlerweile ist das auch ohne Transportregel möglich. Beachten Sie dabei aber die Sonderfunktion Hybrid Centralized Mail Transport.

Partner

Office 365

Auch der empfangende Partner hat vielleicht in Interesse, dass Mails nur ankommen, wenn diese verschlüsselt sind und vor allem die Absenderdomain verifiziert ist. Mit SPF, DKIM und DMARC können Sie nur Mails ablehnen, wenn die Gegenstelle eine entsprechende Richtlinie veröffentlicht hat. Über einen "Inbound Connector" können Sie erzwingen, dass Mails mit einer bestimmten Absenderdomain z.B. nur von vorgegebenen Systeme (IP-Adresse und/oder Zertifikat) ankommen.

  • Connectorname
    Name, Beschreibung, Aktiv An/Aus
  • Authentifizierung der Gegenseite
    Über Absenderdomain oder IP-Adressen
  • Sicherheitsanforderungen
    TLS Zwang an/aus mit optionaler Prüfung des Namens
    Wurde mit der Absenderdomain gearbeitet, dann kann zusätzlich noch die IP-Adresse beschränkt werden

Ein Partner-Connector ist daher in beide Richtungen relevant, wenn Sie Verbindungen zwischen Firmen entsprechend absichern wollen. In der Regel konfiguriere ich dann aber immer zwei Connectoren pro Seite. Ein "Outbound Connector" von meinem Tenant zur anderen Seite, in der der ich z.B. TLS mit einen bestimmten Zertifikat erzwinge und zudem einen Inbound Connector, mit dem ich auch den Absender zwinge, seine Mails sicher zuzustellen.

Diese Einstellungen hat aber nichts mit Free/Busy-Zeiten oder den "Remote Domains" für die Format, OOF-Meldungen und Weiterleitungen zu tun.

Eingehend Attribution

Der "Outbound Connector" ist dabei noch einfach zu verstehen, da er ja in meinem Tenant hinterlegt ist und damit nur für meine Absender gilt. Für den Empfänger wird es kniffliger, da natürlich alle Tenants von den gleichen IP-Adressen und mit dem gleichen "mail-protection.outlook.com"-Zertifikat ankommen. Ein Empfänger sollte sich daher die Absender-Domain anschauen.

Aber auch bei Exchange Online wird das eingehende Routing interessant, da Exchange Online anhand verschiedener Kriterien entscheiden muss, welcher Connector letztlich gewinnt. Denn es ist durchaus möglich, dass zwei Administratoren in unterschiedlichen Tenants je einen Inbound Connector mit den gleichen Kriterien anlegen, da Sie beide mit dem gleichen Partner eine Verbindung aufbauen. Hier kann ich dann nur auf den Artikel aus dem Exchange Team Blog verweisen:

Nach den ganzen FAQs und kurz vor den Kommentaren ist der relevante Abschnitt "How does message attribution work?" mit der Entscheidungsfindung.  Eine über einen Partner Connector ankommende Mail wird normalerweise nie den Status "Originating" bekommen. Im Regelfall ist der für "On-Premises"-Connectoren vorbehalten. Es gibt natürlich per PowerShell die Option, z.B. das Flag "CloudServicesMailEnabled" oder "TreatMessagesAsInternal" zu setzen. Aber darauf gehe ich nicht weiter ein. Bei Incoming steht:

If the message has NOT been attributed as Originating, at this point the service assumes the message is coming to us either as MX routed or via relay smart host (we have no way of telling).
We then lookup if the RcptTo matches an accepted domain in a tenant and attribute the message as Incoming to that tenant.
We then look to see if the message matches any inbound partner connectors in that tenant, and if a match is made, the message is attributed to that connector.
If no match is made, then the message arrives at that tenant through the default inbound connector.
If no tenant is found which has the recipient domain has a validated domain, the message will be rejected by the service.
Quelle: Office 365 Message Attribution https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143

Exchange Online nutzt also den "RCPT TO" einer Mail, um anhand der Domain und den "Accepted Domains" aus allen Tenants den Zieltenant zu bestimmen. Erst dann schaut Exchange Online nach einem "Inbound Partner Connector" in diesem Tenant. Leider schreibt Microsoft hier nicht weiter auf, wie Exchange den "Match" macht. Ich kann ja mehrere Partner Connectoren einrichten, die sich in Zertifikat, Source-IP und Source-Domain unterscheiden. Theoretisch könnten ja sogar mehrere Konfiguration "matchen".

Hinweis: Änderungen per Powershell werden anscheinend relativ schnell aktiv. Änderungen im Exchange Admin Panel brauchen ein paar Minuten. Um repräsentative Ergebnisse zu haben, sollten Sie bei Konfigurationsänderungen einige Minuten verstreichen lassen. Das Setzen von Beschränkungen geht wohl schneller als das Entfernen.

Alle Tests wurden von einem Client in "Netatwork.de" gestartet und der Empfänger war in der msxfaqdev.onmicrosoft.com-Domain. Die Properties "RestrictDomainsToIPAddresses" und "RestrictDomainsToCertificate" habe ich immer dann auf "True" gesetzt, wenn Sie dazugehörigen Felder gefüllt sind und die Connectoren sind natürlich "Enabled:$true" und "RequireTLS:$true" gewesen.

Testfall Ergebnis Beschreibung

Nur Domain

Delivered

Ich habe zwei Partner-Connectoren angelegt, die beide die gleiche Source-Domain bedienen. Exchange hat diese Einrichtung nicht unterbunden.

Dann habe ich eine Mail an ein Postfach in dem Tenant gesendet. Die Mail kam an aber weder im SMTP-Header noch im Messagetracking gab es einen Hinweis darauf, welcher Connector denn nun "gewonnen" hatte.

Offen und DenyIP

NDR

Was passiert aber, wenn es zwei Connectoren gibt, auf die beides zutrifft? Ich habe zwei identische Connectoren eingerichtet und die Mails ist angekommen. Ob Exchange Online nun den ersten gefundenen Connector nutzt, kann ich nicht sagen. Also habe ich einen der beiden Connectoren "unbrauchbar" gemacht.

Set-InboundConnector partner2 -SenderIPAddresses 1.2.3.4 -RestrictDomainsToIPAddresses $true

Die Mail wurde mit folgender Meldung von Exchange Online abgelehnt:

< #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 

Ich habe bei den Connectoren noch nie eine Reihenfolge oder Priorität gesehen. Beim Rückstellen der Einträge prüft Exchange, ob die Parameter "sinnvoll" sind.

PS C:\> Set-InboundConnector partner2 -SenderIPAddresses $null -RestrictDomainsToIPAddresses $true
Set-InboundConnector: |Microsoft.Exchange.Data.DataValidationException|RestrictDomainsToIps: 
"RestrictDomainsToIPAddresses" kann nur auf " true" festgelegt werden, wenn ein Wert für "SenderIPAddresses" festgelegt ist.

Ich hab das alles wieder zurück gestellt und gewartet, bis die Mails wieder kommen.

Domain + TLS

NDR

Ich habe dann die Connectoren "angepasst, indem ein Connector eine Beschränkung auf einen Zertifikatnamen hatte.

Set-InboundConnector Partner2 -TlsSenderCertificateName "invalid.netatwork.de" -RestrictDomainsToCertificate $true

Auch diese Mail wurde abgelehnt.

'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

Domain + TLS/IP

NDR

Damit war ein NDR dann auch keine Überraschung, wenn ein Connector mit einer eine Beschränkung auf eine IP-Adresse und der anderen Connector auf einen Zertifikatnamen die Zustellung verhindert.

Beide Anforderungen konnte mein SMTP-Sender nicht erfüllen können. Daher wurde die Mail auch abgelehnt.

'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

Domain+ValidIP

NDR

Als weiteren Test habe ich die Inbound Connectoren noch so konfiguriert, dass einer davon "matched" aber der andere nicht:

Auch diese Mail wurde abgelehnt, obwohl der erste Connector ja gepasst hätte aber wohl der zweite Eintrag die Zustellung unterbunden hat.

2x OK + IP Überlappung

NDR

Welche Bedeutung das Zertifikat gegenüber der IP-Adresse hat, zeigt der folgende Test:

Ich habe zwei Connectoren mit der gleichen SenderIPAddresses-Beschränkung angelegt um zu sehen, ob nun der strengere Eintrag gewinnt oder ob ein System aus dem Subnetz auch ohne passendes Zertifikat Mails einliefern kann. Das Ergebnis ist eindeutig: Ohne Verwendung des Absenderzertifikats werden die Mails abgelehnt. Es scheint wohl der "strengste Connector" zu zählen.

Diese Konfiguration können Sie so nicht einstellen. Es muss immer ein TLSSenderCertificateName gefüllt sein aber sie können die "RestrictDomainsToCertificate:$False" setzen.

2x IP

Delivered

Diverse 3rd Party Spamfilter möchten gerne, dass Sie einen eingehende Partner-Connector einrichten, der die IP-Adressen des Hosted Spamfilter hat und "*" als Domain. Also wollte ich wissen, was passiert, wenn zwei Partner Connectoren mit unterschiedlichen IP-Adressen als Beschränkung aktiv sind.

Wenn ich von einer anderen IP-Adresse komme, dann ist die Fehlermeldung eindeutig:

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

Wenn ich aber in einer der IP-Adressen drin bin dann wird die Mail angenommen.

2x OK

Delivered

Zuletzt habe ich zwei Connectoren angelegt, bei denen jeder für sich die Zustellung erlaubt hätte.

Tatsächlich wurde die Mail auch zugestellt. Der "Reject" auf Basis der IP-Adresse konnte ja nicht wirken, da Sie ja ebenfalls erlaubt war.

Auf der Suche nach dem angewendeten Connector hat das Messagetracking im Exchange Admin Center nicht genug Informationen geliefert. Aber in der Exchange Online PowerShell kann ich hier mehr sehen:

$trace=Get-MessageTrace -MessageId <messageid> | Get-MessageTraceDetail
$trace[0].data
<root>
   <MEP Name="ConnectorId" String="BEZP281MB3142\Default BEZP281MB3142"/>
   <MEP Name="ClientIP" String="2603:10a6:b10:14::15"/>
   <MEP Name="ServerHostName" String="BEZP281MB3142.DEUP281.PROD.OUTLOOK.COM"/>
   <MEP Name="FirstForestHop" String="BEZP281MB3142.DEUP281.PROD.OUTLOOK.COM"/>
   <MEP Name="DeliveryPriority" String="Normal"/>
   <MEP Name="ReturnPath" String="testuserfc@netatwork.de"/>
   <MEP Name="CustomData" Blob="S:ProxyHop1=BE0DEU01FT017.mail.protection.outlook.com(20.128.125.156);
                                S:ProxyHop2=BE0P281CA0028.outlook.office365.com(2603:10a6:b10:14::15);
                               'S:InboundConnectorData=Name=Partner2;
                                  ConnectorType=Partner;
                                  TenantId=604d9047-44e5-443a-ad8f-98abe5748b0a';
                                S:tlsversion=SP_PROT_TLS1_2_SERVER;S:tlscipher=CALG_AES_256"/>
   <MEP Name="SequenceNumber" Long="0"/>
   <MEP Name="RecipientReference" String=""/>
</root>

Das Feld "data" enthält insbesondere den Connectorname "Partner2". Anscheinend hat der Name im Zertifikat eine höhere Wertung. Leider wird das vom Sender übermittelte Zertifikat nicht mit ausgegeben.

2x Cert + 1 x richtige IP

Delivered

Das hat natürlich meine Neugier geweckt, wie es sich mit zwei Connectoren verhält, die unterschiedliche Zertifikatnamen für die gleiche Domain fordern:

Interessanterweise wurde auch diese Mail durch Connector 2 angenommen. Die Vorgabe durch "Partner3" wurde ignoriert.

2x Cert + 1 x falsche IP

Delivered

Nun wollte ich natürlich wissen, ob dies auch ohne IP-Adresse gilt.

Diese Mail wurde unter Nutzung des "Partner2"-Connectors zugestellt.

IP-Deny mit Cert Allow

Delivered

Ein Fall hatte ich noch nicht beschrieben. Es gibt einen Connector mit passendem Zertifikat aber ein anderer Connector, der eine IP-Adresse erzwingt:

Aber auch diese Mail wurde zugestellt, was auf eine Dominanz des TlsSenderCertificatName hindeutet.

Doppeltes Zertifikat

Delivered

Exchange Online erlaubt tatsächlich eine Konfiguration zweiter identischer Connectoren:

Auch diese Mail wurde zugestellt.

Leider haben sich die ganzen fehlgeschlagenen Versuche nicht im Messagetracking hinterlassen, so dass ich nur für erfolgreiche Verbindungen den angewendeten Connector bewerten kann.

Erst einige Monate habe ich gesehen, dass ich in Exchange online ein "Extended Trace" anfordern kann, der dann auch Informationen zur Connector-Auswahl enthält. Ich habe die Tests hier aber nicht wiederholt.

IP-Konflikte

Bei meinen Tests bin ich das ein oder andere Mal auch auf eine Fehlermeldung gestoßen, die ebenfalls Rückschlüsse auf das Routing erlaubt. Der Versuch zwei Connectoren mit gleicher "SenderDomain" und "SenderIPAddresses" zu setzen, wird mit folgender Warnung verstehen:

PS C:\> Set-InboundConnector partner1 -TlsSenderCertificateName $null
WARNING: Konfigurationskonflikt. Mindestens eine SenderIPAddress "193.37.132.0/24" überschneidet s
ich mit Absender-IP-Adressen des bzw. der vorhandenen eingehenden Connectors "Partner2". Dieser Co
nnector bzw. diese Connectors können für E-Mail, die von den betreffenden Adressen stammt, nicht v
erwendet werden.

Die Warnung ist aufgetreten, als ich zwei fast gleiche Connectoren hatte und die namentliche Prüfung eines Zertifikats abschalten wollte:

Interessanterweise ist es aber schon möglich, mehrere Partner Connector mit der gleichen IP-Range anzulegen und selbst bei dem Beispiel kann ich bei einem Connector problemlos die Einstellung "RestrictDomainsToCertificate" auf $False und damit außer Kraft setzen, was letztlich die gleiche Wirkung hat aber nicht gewarnt wird.

Das passiert natürlich auch bei der Anlage von zwei Connectoren mit identischen Parametern aber sie werden angelegt.

New-InboundConnector -name conn1 -SenderDomains msxfaq.de -SenderIPAddresses "80.60.0.0/24" -RestrictDomainsToIPAddresses $true
New-InboundConnector -name conn2 -SenderDomains msxfaq.de -SenderIPAddresses "80.60.0.0/24" -RestrictDomainsToIPAddresses $true

WARNING: Konfigurationskonflikt. Mindestens eine SenderIPAddress "80.60.0.0/24" überschneidet sich
mit Absender-IP-Adressen des bzw. der vorhandenen eingehenden Connectors "Conn1". Dieser Connecto
r bzw. diese Connectors können für E-Mail, die von den betreffenden Adressen stammt, nicht verwend
et werden.

Eine Eingabe einer solche IP-Adresse per Admin Portal wird hingegen mit einem Fehler verhindert:

Auch andere Netzmarken für Supernetting und Subnetting, wie sie ein On-Premises Receive Connector versteht, sind nicht möglich.

Ich finde das schon suspekt, wenn in der AdminGUI die Konfiguration verhindert wird aber per PowerShell nur eine Warnung kommt.

Zwei Connectoren mit dem gleichen Clientzertifikat-Namen liefern keine Meldung.

Die Warnung kommt aber auch, wenn ich einen eigenen Partner-Connector für eine weiter Domain mit der gleichen IP-Adresse anlegen möchte.

New-InboundConnector -name conn3 -SenderDomains msxfaq2.de -SenderIPAddresses "80.60.0.0/24" -RestrictDomainsToIPAddresses $true

WARNING: Konfigurationskonflikt. Mindestens eine SenderIPAddress "80.60.0.0/24" überschneidet sich
mit Absender-IP-Adressen des bzw. der vorhandenen eingehenden Connectors "Conn1, conn2". Dieser C
onnector bzw. diese Connectors können für E-Mail, die von den betreffenden Adressen stammt, nicht 
verwendet werden.

Wer so etwas vorhat, sollte also besser einen bestehenden Connector um die zusätzlichen Domänen erweitern.

Es bringt dabei aber auch nichts, eine weitere Domain mit einer zusätzlichen Beschränkung auf einen TLS-Zertifikatnamen anzulegen.

New-InboundConnector -name conn7 -SenderDomains msxfaq7.de -SenderIPAddresses "80.60.2.0/24" -RestrictDomainsToIPAddresses $true `
   -TlsSenderCertificateName msxfaw7.de -RestrictDomainsToCertificate $true -RequireTls $true

WARNING: Konfigurationskonflikt. Mindestens eine SenderIPAddress "80.60.2.0/24" überschneidet sich
mit Absender-IP-Adressen des bzw. der vorhandenen eingehenden Connectors "conn5, conn6". Dieser C
onnector bzw. diese Connectors können für E-Mail, die von den betreffenden Adressen stammt, nicht 
verwendet werden.

Wenn Sie sie Source-IP-Adresse als Kriterium nutzen, dann sind sie gut beraten dass der Bereich über alle Connectoren eindeutig ist.
Ich habe auch schon gesehen, dass am Ende kein Connector gegriffen hat und die Mail angenommen wurde.

So richtig klar sind die Entscheidungen bei der Auswahl des "Inbound Partner Connector" noch nicht. Sie sollten daher genau testen.

Partner Attribution

Durch diese Testserie habe ich viele Informationen zum Thema "Anwendung eingehender Regeln" bei Partner Connectoren. Die Entscheidung gilt natürlich nur, wenn die Verbindung nicht schon als "On-Premises"-Connector klassifiziert wurde. Damit eine Verbindung einem Partner Connector zugeordnet wird, muss die Einschränkung hinsichtlich IP-Adresse und Sender-Zertifikat übereinstimmen. Ich versuch mich mal an einer Zusammenfassung.

  • Es gibt keine Reihenfolge bei Connectoren
    Anders als z.B. bei Transportregeln gibt es bei Connectoren eingehend wie ausgehend in Exchange Online keine Reihenfolge. Die Logik bezieht alle Partner-Connectoren in die Bewertung mit ein.
  • Bestimme den Tenant anhand der RCPT TO-Adresse
    Zuerst durchläuft der Prozess die "Office Tenant Attribution" Logik, wie ich sie auf Office 365 Inbound Mailrouting und Microsoft auf "Office 365 Message Attribution " https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143 beschrieben hat. Über die RCPT-TO Adresse wird der Tenant bestimmt.
  • Suche alle Inbound Connectoren vom Typ "Partner" mit der SenderDomains des "MAIL FROM"
    Wenn es keine Übereinstimmung gibt, dann kommt der normale SMTP-Empfang zur Anwendung, quasi ein "Default Inbound Connector", wenn kein Partner-Connector mit einem "*" als Domain dies verhindert.
  • Prüfe die Mail gegen alle Partner Connectoren dieser Domain
    Alle Connectoren müssen matchen!
  • Wenn es keinen passenden Connector für die SenderDomain gibt, dann lehne ab
    Sobald also auch nur ein Partner-Connector vorhanden ist, der für eine Domain die Beschränkungen vorgibt, erfolgt kein Fallback auf den Default Inbound Connector.

Übrigens: Bei Exchange On-Premises gibt es keinen vergleichbaren "Inbound Connector" sondern nur die Receive-Connectoren. Ich kann beim Receive Connector über die Remote-IP den Connector auswählen und TLS-Zwang vorgeben, aber eine weitere Filterung nach Source-IP und Absender-Domain geht dann erst nach dem Empfang über Transport-Regeln.

Doppelt Senderdomain *

Eigentlich habe ich diese Testserie gemacht, um eine Migration zu überprüfen. Ausgangssituation war ein Exchange Online Tenant, bei dem ein 3rd Party Spamfilter vor den Tenant geschaltet war. Klassische gibt es dazu dann immer zwei Partner-Connectoren, die ausgehende Mails über eine Transportregel oder den Adressraum "SMTP:*" zum Spamfilter senden und einen eingehenden Partner-Connector, der über die Senderdomain "*" nur Mails von dem 3rd Party Spamfilter annimmt.

Wenn Sie nun in der Umgebung den Spamfilter wechseln möchten, dann möchten Sie dies vielleicht nicht zu einen Stichtag sondern langsam parallel aufbauen und testen. Der Versand vom Tenant zum Spamfilter ist noch relativ einfach abzudecken. Sie legen einfach einen zweiten Outbound Connector zum neuen System an und routen die ersten Mails an Testdomänen über eine Transportregel oder Adressräume über die neue Umgebung.

Eingehend stellte sich da dann schon die Frage, ob und wie ich zwei Inbound Connector-Konfigurationen für die Remote-Domain "*" parallel anlegen kann. So sah dann das Setup aus:

Beide Spamfilter weisen sich mit einem Client-Zertifikate aus. Sie können gerne auch noch zusätzlich die IP-Adresse beschränken.

In der Konstellation scheint der Name des Zertifikate zur Auswahl des Connectors genutzt werden, denn allein von der IP-Adresse würden beide passen. Welcher Connector zur Anwendung kam, finden Sie nur per Powershell im Message Tracking:

<root>
  ...
  <MEP Name="CustomData" Blob="S:ProxyHop1=FR2DEU01FT006.mail.protection.outlook.com(20.128.124.83);
                               S:ProxyHop2=FR0P281CA0104.outlook.office365.com(2603:10a6:d10:a9::15);
                  'S:InboundConnectorData=Name=Inbound NoSpamProxy;ConnectorType=Partner;TenantId=<guid>';
                   S:tlsversion=SP_PROT_TLS1_2_SERVER;
                   S:tlscipher=CALG_AES_256"/>
   ...
</root>

Achtung: Diese Konfiguration blockt die Zustellung von Mails an den Tenant, wenn der Absender kein Client-Zertifikat mit den Namen hinterlegt. D.h. auch Drucker, Batch-Skripte u.a. können keine Mail mehr einliefern, da die Domain "*" auf alle Absender matched. Für automatische Prozesse sollten Sie z.B. einen Inbound Partner-Connector mit der Source-IP der zugelassenen Systeme hinterlegen.

Test Status
Mail von einem fremden Absender vorbei am Spamfilter sollten abgelehnt werden, damit niemand den MX-Record ignorieren und direkt an Exchange Online zustellen kann. Solche Fälle gab es schon in der Vergangenheit. Siehe auch Exchange Online als Nebeneingang für Mailempfang oder Hybrid Hintereingang

Ablehnung

Eine Mail von neuen und vom alten Spamfilter sollten beide noch zugestellt werden. So kann man z.B. den neuen Spamfilter schon komplett konfigurieren und erste Testmails unter Umgehung des MX-Records an den neuen Spamfilter zur Prüfung und Weitergabe an den Tenant einrichten.

Zustellung

Mit der Vorarbeit der Tests und der Verifikation in einem Test-Tenant steht nun einer Migration nichts mehr im Wege.

Ich finde gut, dass diese Konfiguration funktioniert. Wenn ich aber mehrere Einrichtungen per IP-Adresse beschränke, dann kommt nichts an. Daher immer testen!

Fehlersuche

Quasi kostenlos als Beifang habe ich einige Zeit lang das Problem gehabt, dass ich per Exchange Admin Center die Konfiguration nicht speichern konnte, wenn ein "*" im Zertifikatsnamen enthalten war. Ich nutze diesen Fehler ihnen einen Blick hinter die Kulissen zu erlauben. Wenn Sie in dem Fall nämlich mit F12 in die Debugger-Tools der Webbrowsers gehen, dann finden Sie den REST-Post auf https://admin.exchange.microsoft.com/beta/InboundConnector, der bei mir auf einen Fehler gelaufen ist.

Hier ist erst mal nur der 412-Fehler zu sehen. Wenn wir dann aber die "Nutzlast" anschauen, sehen wir quasi jeden einzelnen Parameter, wie wir ihn sonst auch in der PowerShell verwenden würden.

In der Antwort konnte ich dann noch die Fehlermeldung sehen, dass er den String "*.cloud.nospamproxy.com" nicht in den passenden Typ konvertieren konnte. Hier muss es noch eine Middleware zwischen der WebUI und letztlich der Exchange Online PowerShell im Hintergrund geben, die die Parameter entsprechend umsetzt.

Hinweis: Solche Fehler landen nicht im Exchange AdminAuditLog, da er früher erkannt wird und gar nicht die PowerShell aufruft.

Mit den Parametern konnte ich dann natürlich problemlos per Powershell den Connector anlegen:

New-InboundConnector `
   -CloudServicesMailEnabled $false `
   -Comment "" `
   -ConnectorSource "AdminUI" `
   -ConnectorType "Partner" `
   -Enabled $true `
   -Name "Inbound2" `
   -RequireTls $true `
   -RestrictDomainsToCertificate $true `
   -RestrictDomainsToIPAddresses $false `
   -SenderDomains @("*") `
   -TlsSenderCertificateName "*.cloud.nospamproxy.com"

Name     SenderDomains SenderIPAddresses Enabled
----     ------------- ----------------- -------
Inbonud2 {smtp:*;1}    {}                True

Interessant finde ich dabei, dass das Exchange Admin Center wohl immer alle Parameter setzt, auch wenn diese eigentlich nicht erforderlich wären, da es auch die Default-Werte sind. Das spricht aber eigentlich für ein gutes Design, da damit die Ergebnisse immer nachvollziehbar sind, auch wenn ein anderes Teams im Backend vielleicht die Default-Werte später einmal ändert.

Weitere Links