Partner Inbound Connector

In der Standardeinstellung nimmt Exchange Online erst einmal von jeder IP-Adresse per SMTP eingehende E-Mails an. Natürlich gibt es dabei einen Spamfilter etc.

Es gibt eine noch ausführlichere Seite zu dem Thema auf Partner Connector und eine gesonderte Seite zu Partner Connector Wildcard. Dies ist eher eine Kurzfassung.

Warum Partner Connector?

Das primäre Ziel eines Partner Connectors ist aber die Zustellung von eben diesen anderen Server abzusichern. Sie können z.B. vorgeben, dass Mails einer Absender-Domain nur von bestimmten IP-Adressen kommen dürfen. Sie können ebenfalls TLS erzwingen und zusätzlich das Zertifikat hinsichtlich des Ausstellers (Public PKI erforderlich) und dann zusätzlich sogar den Zertifikatsnamen prüfen. So sollte es fast unmöglich sein, dass sich jemand als eine andere Firma ausgibt. Wobei die Domainprüfung nur anhand der Domain im RFC8321-"MAIL FROM" im Envelope erfolgt. Ganz sicher ist es also nicht.

Zusätzlich kann ich natürlich über eine Domain "*" jegliche Zustellung von anderen Servern unterbinden, die sich nicht mit einer IP-Adressen und/oder Zertifikat ausgewiesen haben. So können Sie sie den Exchange Online als Nebeneingang für Mailempfang oder Hybrid Hintereingang blockieren.

Zum generellen Empfang von Mails mit Exchange Online müssen Sie aber überhaupt keinen Connector anlegen, denn es gibt immer einen "unsichtbaren Default Connector", welcher Mails annimmt annimmt. Allerdings gibt es natürlich Spamfilter, so dass Mails auch mal als Spam gefiltert werden oder in der Quarantäne landen. Ein Partner Connector sichert die eingehende Verbindungen von Partnern zusätzlich ab.

Anlage per GUI

Wenn Sie in Exchange Online einen Connector anlegen, dann fragt sie der Assistent erst einmal nach dem Anwendungszweck. Vielleicht brauchen Sie ja gar keinen Connector. Ich wähle hier "Partner" aus und das Ziel ist damit schon vordefiniert:

Im nächsten Dialog werde ich dann gebeten, einen Namen und optional eine Beschreibung anzugeben.

Interessant wird es nun bei der Auswahl, woran Exchange Online denn bei einer eingehenden Verbindung den passenden Connector zuweisen kann. Exchange Online bietet ihnen hier zwei Auswahlmöglichkeiten:

  • MAIL FROM-Domainname
    Exchange Online kann anhand der Absender-Domain den Connector vorselektieren.

Exchange nutzt dabei den RFC8321-MAILFROM des Envelope und nicht den "RFC8322-FROM des SMTP-Headers.

  • Source-IP-Adresse
    Alternativ können Sie die einliefernde IP-Adresse als Kriterium nutzen. Wenn Sie die Domain als Kriterium nutzen, können Sie die Quell-IP-Adressen nachträglich als weitere Bedingung fordern.

Im Detail ist noch zu prüfe wie sich mehrere Connectoren mit überlappenden Kriterien verhalten.

NaNach der Auswahl der Identifikation können Sie dann noch bestimmen, welche Vorgaben zusätzlich erfüllt ein müssen. Im Wesentlichen geht es dabei um den TLS-Zwang in unterschiedlich strenger Überprüfung.

Nur wenn Sie als Vorentscheidung die Absenderdomain nutzen, dann können Sie zusätzlich zu TLS auch noch IP-Adressen einschränken. p>

Wenn Sie bei der Vorentscheidung eine IP-Adressen als Kriterium nutzen, dann wird im Hintergrund die Domain auf "*" gesetzt. Die verhindert jegliche andere Zustellung, wenn es keinen Connector mir einer besser passenden Domain gibt.

MeMehr gibt es dann nicht mehr über das browserbasierte Adminportal einzustellen.

Default-Einstellungen

Natürlich gibt es im Hintergrund schon noch mehr Parameter und ich habe einfach die drei primären Varianten durchgespielt und mich auf die Felder beschränkt, die sich unterschieden haben:

Name

DomainNoIP

IPOnly

Domain+IP
Vorauswahl

Domain=carius.de

IP=1.2.3.4

DoDomain=Carius.de
Restriktion

TLSp>

TLS

IP=1.2.3.4 + TLS
PowerShell 
SenderIPAddresses : {}
SenderDomains : {smtp:carius.de;1}
RequireTls : True
RestrictDomainsToIPAddresses : False
 
SenderIPAddresses : {1.2.3.4}
SenderDomains : {smtp:*;1}
RequireTls : True
RestrictDomainsToIPAddresses : False
 
SenderIPAddresses : {1.2.3.4}
SenderDomains : {smtp:carius.de;1}
RequireTls : True
RestrictDomainsToIPAddresses : True

Es gibt natürlich noch weitere Felder, die zum einen die zusätzlich TLS-Sicherheit wiedergeben aber auch einige Optionen anbietet, die per Portal nicht erreichbar sind aber ich erst nachgelagert betrachte.

Beachten Sie bitte, das der "IPOnly"-Connector im Hintergrund ein "SMTP:*;1" addiert hat, obwohl RestrictDomainsToIPAddresses auf "$false" steht.

IcIch habe dann eine Mail an diesen Tenant mit meiner carius.de-Adresse gesendet und sie wurde umgehend abgelehnt:

SMTP ror from remote server for TEXT command, host: msxfaqdev.mail.protection.outlook.com (104.47.7.138) 
reason: 550 5.7.51 TenantInboundAttribution; 
There is a partner connector configured that matched the message's recipient domain. 
The connector had eith er the RestrictDomainsToIPAddresses or RestrictDomainsToCertificate set
[BE0DEU01FT013.eop-deu01.prod.protection.outlook.com 2023-06-01T16:5 4:49.917Z 08DB626A6B0436AE]

Attribution

Die drei Connectoren bilden einen Konflikt, so dass Exchange Online keine Mail annimmt. Eigentlich hätte der "DomainNoIP"-Connector die Mail annehmen könne, da es keine IP-Beschränkung gab und mein Absender natürlich TLS spricht. Dennoch haben die beiden anderen Connectoren die Zustellung verhindert. Also habe ich eine Matrix mit den beiden anderen Connectoren gebaut und nach jeder Änderung etwas gewartet, ehe ich wieder eine Testnachricht gesendet habe:

DomainNoIP
Domain=carius.de		 IPOnly
IP=1.2.3.4		 Domain+IP
Carius.de + 1.2.3.4		 Ergebnis

On

On

On

Nicht zugestellt

On

Off

On

Nicht zugestellt

On

Off

Off

Zugestellt

On

On

Off

Zugestellt

Maßgeblich für die Ablehnung ist in dem Fall die Kombination aus "Domain+IP". Der breiter gefasste Connector "IPOnly" beschränkt zwar die Domain "*" auf eine IP aber die genauere Domainangabe der beiden anderen Connectoren gewinnt hier. Natürlich habe ich nach Quellen gesucht aber ich habe nur eine wenig hilfreiche Aussage gefunden:

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.
Quelle: Office 365 Message Attribution https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143 <

Die Frage ist halt einfach, was ein "Match" ist, wenn es mehrere Connectoren mit der gleichen Domain gibt. Wirken die Parameter "RestrictDomainsToIPAddresses " und "RestrictDomainsToCertificate" verschärfend, indem sie mehr Mails blocken oder lockern sie die Regeln, weil der Connector nicht mehr passt?

Die Tabelle zeigt, dass ein "RestrictDomainsToIPAddresses" dafür sorgt, dass die Mail abgewiesen wird. Der weniger strenge Connector kommt nicht mehr zum Zug.

Achtung: Exchange Online sucht zuerst einen Connector mit einer zur "MAIL FROM" passenden Senderdomain. Exchange nutzt nicht die Domain aus dem "From"-Header. Üblicherweise sind beide Domains identisch und bei DMARC sogar gefordert (Siehe DMARC-Validation und DMARC bricht SPF bei SRS) Aber SRS kann dies stören.

Die Domain muss genau übereinstimmen oder sie arbeiten mit Wildcards.

MailFrom-Domain     ConnectorDomain            Match
====================================================
    msxfaq.de         msxfaq.de                Ja
sub.msxfaq.de         msxfaq.de                Nein
    msxfaq.de       *.msxfaq.de                Ja
sub.msxfaq.de       *.msxfaq.de                Ja

Hinweis: Ein Eintrag "*carius.de" ist nicht gültig. Im Webportal steht nur ein Fehler

Wenn sie die gleiche Konfiguration per PowerShell eintragen wollen, sehen Sie dann eine sprechende Fehlermeldung:

New-InboundConnector: Cannot process argument transformation on parameter 'SenderDomains'.
  Cannot convert value "*carius.de" to type "Microsoft.Exchange.Data.MultiValuedProperty`1[Microsoft.Exchange.Data.AddressSpace]".
  Error: "Failed to convert *carius.de from System.String to Microsoft.Exchange.Data.AddressSpace.
  Error: System.FormatException:
 Error while converting string '*carius.de' to result type Microsoft.Exchange.Data.AddressSpace: '*carius.de' isn't a valid SMTP domain.

Den meisten Problemen gehen Sie aus dem Weg, wenn es pro Senderdomain immer nur genau genau einen passenden Connector gibt.

Sonderfall "*"-Domain

Siehe dazu die gesonderte Seite Partner Connector Wildcard

Connector auslesen

Das klassische Messagetracing im Exchange AdminPortal unter https://admin.exchange.microsoft.com/#/messagetrace liefert leider keine Information, welcher Connector letztlich angewendet wurde. Über die Exchange Online PowerShell können Sie aber sehr wohl mit Get-Messagetrace zuerst die Mail finden und dann mit Get-MessageTraceDetail nach dem "Receive-Event" suchen. Im Feld "Data" steckt dann eine XML-Struktur mit dem Namen des angewendeten Connectors.

get-messagetrace `
   -SenderAddress <RFC8322-HeaderFrom-Adresse des Absenders> `
| Get-MessageTraceDetail `
   -Event receive `
| fl data

Hinweis1: Das Feld "SenderAddress" bei Get-Messagetrace bezieht sich auf die Absenderadresse im Header der Mail. Diese ist nicht zwingend mit der Adresse im Envelope identisch, anhand der Exchange den Connector bestimmt.

Hinweis2: Die Zeitstempel bei der Ausgabe von Get-MessageTraceDetails sind immer UTC und nicht lokalisiert.

Hier ein paar Beispiele:

  • Eingehende Mail, auf die kein Partner Connector passt
  • Eingehende Mail
    Wenn Exchange einen Connector zuweisen kann, dann sehen Sie diesen im Feld DATA. Beachten Sie, dass im DATA-Feld auch der Wert "ReturnPath" bzw. OriginalFromAddress" enthalten ist. Dies ist der RFC8321-EnvelopeFrom und nicht der Absender aus dem Header, welchen Sie bei der Suche mit "Get-Messagetrace" angeben müssen.
  • Subdomains
    Wenn Sie einen Connector mit "*.<domain>" verwenden können Sie sehen, dass dies auch die Basisdomain beinhaltet:

Wenn eine Mail zugestellt wurde, dann können wir so ermitteln, welcher Connector genutzt wurde. Wurde die Mail allerdings abgewiesen, dann sehen Sie hier leider nichts.

AuditLog

Alle Änderungen in der Exchange Konfiguration werden natürlich auch im Auditlog hinterlegt. Bei Exchange Online können Sie mit "Search-AdminAuditLog" danach suchen.

Search-AdminAuditLog `
   -StartDate (get-date).addminutes(-10) `
   -EndDate (get-date) `
   -Cmdlets new-inboundconnector,set-inboundconnector

Hier eine exemplarische Suche nach dem letzten "New-InboundConnector" und die Parameter

Spamfilter und Partner Connector

Die Einrichtung eines Partner-Connector steuert nur, welche Vorgaben sie z.B. hinsichtlich der TLS-Verschlüsselung machen. Sie steuern damit keine Spamfilter-Funktionen und können den Namen des Connectors leider auch nicht in Transportregeln auswerten. Wenn Sie eingehende Mails z.B. von einem 3rd Party Spamfilter in EXO ohne weitere Filterung empfangen wollen, dann sollten Sie überlegen, ob Sie die SourceIP-Adressen in der globalen Connectionliste pflegen. Das geht per Browser unter https://security.microsoft.com/antispam

Wer hier aber viele Adressen pflegen muss, macht dies besser per PowerShell:

Set-HostedConnectionFilterPolicy `
   -Identity "Default" `
   -IPAllowList 192.0.2.0/24,198.51.100.0/24 `
   -IPBlockList $null

Sie können hier mehrere IP-Adressen und Subnetze eingeben. Die maximale Subnetzmaske ist aber /24. Größere Subnetze müssen Sie daher manuell auf Class-C aufspiltten.

Enhanced Filtering

Eine zweite Möglichkeit auf den Spamfilter Einfluss zu nehmen ist das Enhanced Filterung, welches auf den Connectoren per Default abgeschaltet ist. Sie erreichen es per Browser unter https://security.microsoft.com/skiplisting

Die Einstellungen können ebenfalls per PowerShell mit "Set-InboundConnector" über folgende Parameter gesteuert werden:

-EFSkipIPs
-EFSkipLastIP 
-EFSkipMailGateway 
-EFTestMode 
-EFUsers

Weitere Links