Exchange Intern/Extern

Beim Einsatz von Exchange Transport-Regeln können sie "Inside Organization" und "Outside-Organization" als Kriterium verwenden. Dazu muss man aber wissen wie Exchange dies unterscheidet.

Auslöser

Ausgangspunkt für diese Seite war ein Exchange Online Tenant, der alle externen Mails über einen Smarthost senden sollte. Dies ist eine durchaus übliche Konfiguration, wenn Sie nicht auf Exchange Online Protection setzen, sondern einen 3rd Party Spamfilter wie z.B. NoSpamProxy o.a. vor ihren Tenant schalten um auch die ausgehenden Mails zu "lernen", mit Disclaimer zu versehen oder mittels SMIME signieren und verschlüsseln wollen.

Lange Zeit konnten Sie in Exchange Online keinen Outbound Connector mit dem Adressraum "*" anlegen, so dass ein Rerouting nur durch eine Transportregen möglich war. In Exchange On-Prem konnten sie schon immer einen Sendconnector mit dem Adressraum "SMTP:*" aber können kein Rerouting über Transportregeln konfigurieren. Das Rerouting als Aktion ist nur eine mögliche Aktion.

Exchange Online sendet normalerweise alle ausgehenden Mails direkt über den MX-Record ins Internet. Ein Weg dies zu ändern ist eine Transportregel mit einem Connector

  • Outbound Connector
    Zuerst legen Sie in Exchange Online einen Outbound Connector von "Office 365" zu "Partner" an

    Den Namen können Sie frei wählen und die Verwendung wird auf "Transportregel" gestellt.

    Unter Routing können Sie dann den Smarthost und TLS-Einstellungen etc. vorgeben.
  • Transport-Regel
    Im zweiten Schritt legen wir nun eine Transportregel an, die jede Mail an externe Empfänger an den Connector weitergibt:

Nach einigen Minuten ist die Regel auch aktiv und es funktioniert alles fast wie erwartet. Die meisten Mails nach Extern folgten dieser Regel und wurden über den Smarthost weiter geleitet, der dann die Mail ins Internet verteilt hat. Allerdings sind die Mails an eine befreundete Domain nicht behandelt worden, sondern direkt per MX-Record-Auflösung von Exchange Online versendet worden. Wobei sie gar nicht angekommen sind, denn die Gegenseite hat die Annahme von Exchange Online verweigert. Der SPF-Record (Siehe Spam und UCE - Filter: SPF, SenderID) war so gesetzt, dass nur der Spamfilter auch im Namen der Firma versenden durfte. Wir mussten also herausfinden, warum die Mails nicht von der Transportregel umklassifiziert wurden.

Kriterium

Natürlich sollten Sie sich schon mal fragt, woran Exchange denn festmacht, ob ein Empfänger nun "innerhalb der Organisation" oder doch "außerhalb der Organisation" ist. Ein Blick in die Dokumentation beschreibt bei den Transport-Regeln die entsprechenden Eigenschaften:


Quelle: https://learn.microsoft.com/en-us/exchange/security-and-compliance/mail-flow-rules/conditions-and-exceptions
Stand 1. Feb 2023 - Mittlerweile hat Microsoft die Anleitung aktualisiert.

Exchange prüft entsprechend das globale Adressbuch hinsichtlich realer Empfänger (Postfach, Gruppe, PublicFolder). Hier steht zwar auch "MailUser" aber das kann ich so nicht bestätigen. Mailcontacts erscheinen auch nicht in der Liste. Also habe ich mal die fehlenden Objekte angelegt und getestet.

Absender und Regel Empfängertyp Klassifizierung

Exchange Online Postfach

EXO: Postfach

Intern

Exchange Online Postfach

EXO: MailUser nach OnPrem

Intern

Exchange Online Postfach

EXO: Mailuser nach extern

Extern

Exchange Online Postfach

EXO: MailContact

Extern

Exchange Online Postfach

EXO: MailenabledGroup

Intern

Exchange Online Postfach

EXO: Frei eingegeben externe Adresse

Extern

Exchange On-Premises Postfach

OnPrem MailboxUser

Inern

Exchange On-Premises Postfach

OnPrem Remote Mailbox

Intern

Exchange On-Premises Postfach

OnPrem MailUser Externe Domain

Extern

Exchange On-Premises Postfach

OnPrem MailContact Externe Domain

Extern

Exchange On-Premises Postfach

OnPrem MailenabledGroup

Intern

Hinweis: Bei einer Gruppe triggert die Regel zweimal. Einmal beim Versand an die Gruppe und noch einmal nach der Expansion der Gruppe an jeden einzelnen Emüfänger

Diese Aussagen haben aber nicht erklären können, warum die Mails an die befreundete Domain falsch geroutet wurde. Sie wiederspricht auch etwas der Aussage, dass eine Mail an einen "MailUser" als "Intern" bewertet wird. Das ist bei mir auch nicht der Fall, außer die MailUser verweist auf eine meiner Domains oder an die befreundete Domain

Remote Domains

Remote-Domains können Sie bei Exchange On-Premises nur per PowerShell verwalten.

Damit ist aber eine weitere Einstellung in den Fokus geraten. Bei der Kundenkonfiguration wurde eine Partnerschaft zur anderen Domain und als erste Aktion wurde diese als Remote-Domain angelegt, damit die andere Seite die "internen OOF-Meldungen" und automatische Weiterleitungen genutzt werden können. Ich habe in meinem Test-Tenant einfach diesen Eintrag für meine "carius.de"-Domain angelegt und weiter getestet.

Meine Erwartungshaltung war, dass sich dies auf die Verarbeitung von eingehenden Mails der Postfächer auswirkt. Allerdings hat diese Einstellung unter Umständen auch Auswirkungen auf die Entscheidung von Transport-Regeln. Wenn Sie sich die Properties dieser Domain anschauen, dann finden wir deutlich mehr Einstellungen als im Admin-Center.

Das Feld "AllowedOOFType" entspricht der Auswahl im Exchange Admin Center aber das Feld "IsInternal" können Sie nicht über das Exchange Admin Portal sehen oder verwalten. Die Bedeutung ist in der Hilfe zu Set-RemoteDomain aufgeführt.


https://learn.microsoft.com/en-us/powershell/module/exchange/set-remotedomain

Laut Dokumentation ist der Default-Wert ein "$false", aber das stimmt nur, wenn Sie den "AllowedOOFType" nicht auf "InternalLegacy" setzen.

Damit war es mal Zeit für eine Testserie, auf welchen Wert "IsInternal" abhängig von "AllowedOOFType" gesetzt wird:

AllowedOOFType IsInternal

 

 

Set-Remotedomain <domainname> -AllowedOOFType InternalLegacy

wechselt auf True

 

 

Set-Remotedomain <domainname> -AllowedOOFType ExternalLegacy

wechselt auf False

 

 

Set-Remotedomain <domainname> -AllowedOOFType External

wechselt auf False

 

 

Set-Remotedomain <domainname> -AllowedOOFType None

wechselt auf False

 

 

Danach habe ich natürlich noch die Gegenprobe gemacht, indem ich "IsInternal" geändert habe. Wie Sie sehen, ändert sich damit auch der Wert von "AllowOOFType":

Start AllowedOOFType/IsInternal Set-Remotedomain <domainname> -IsInternal Ergebnis AllowedOOFType

InternalLegacy/True

False

ExternalLegacy

ExternalLegacy/False

True

InternalLegacy

External/False

True

External/True

External/True

False

External/False

None/False

True

External

Die Abhängigkeit und Wechselwirkung der beiden Felder voneinander wird leider nicht weiter dokumentiert.

Letztlich ist es aber das Feld "IsInternal", welche dafür sorgt, dass Mails an diese Domain ab sofort bei der Transportregel ebenfalls als "Intern" angesehen wird und daher die Transportregel nicht mehr greift.

Achtung: Setzen Sie daher nie die Default-Domain "*" direkt auf "IsInternal=$true" oder indirekt über "AllowOOFType=Internal"

Ergebnis

Mit dem Wissen kann ich nun sagen, dass der Exchange Transport nicht nur die Domains aus "Accepted Domains" als intern ansieht, sondern auch alle "Remote-Domain", bei denen die Einstellung "IsInternal" ebenfalls auf "$True" steht. Die Entscheidung wirkt sich dann auf die SMTP-Adresse des Empfänger bzw. Absender aus. Wenn Sie also einen "MailUser" oder "MailContact" anlegen, dann wird die Domain der TargetAddress/ExternalRoutingAddress ausgewertet. Die Dokumentation in der Hilfe zu den Transportregeln ist wohl ungenau generell von "MailUser" zu sprechen. Dass eine "Remote Domain" auch Einfluss auf die Entscheidung nach "Intern/Extern" hat, geht aus der Dokumentation zum Feld "UserScopeTo" nicht hervor.

Lösungen

Aber mit dem Wissen können Sie nun die Konfiguration entsprechend erweitern. Ausgehend von der Startsituation, dass ich in meinem Tenant jede externe Mail aus meinen Exchange Online System immer einen Smarthost ausliefern möchte, kann ich mehrere Optionen einsetzen:

  • Verzicht auf Remote-Domain mit InternaIOOF
    Ich kann leider keine Remote-Domain anlegen, bei der ich interne OOF-Meldungen erlaube und gleichzeitig "IsInternal" auf "$False" setze. Ich kann eine RemoteDomain aber für die Steuerung von Automatischen Weiterleitungen einsetzen.
  • Transportregel auf Empfänger Domain
    Ich kann bei der Transportregel auf "Internal/External" verzichten und stattdessen z.B. "alle Mails" umleiten "außer" eine Liste der internen Domains"

    Damit umgehe ich die Exchange eigene Bewertung
  • Zusätzlicher Connector für Remote Domains mit "AllowedOOFType=InternalLegacy"
    Eine dritte Option ist die Anlage eines weiteren Outbound Connectors, der die Remote Domains ebenfalls zum Smarthost sendet.

Nun muss man natürlich noch mal überlegen, warum man eine RemoteDomain zu einer Partnerumgebung einrichtet. Automatische Weiterleitungen und interne OOF-Meldungen sind ja schon ein deutliches Zeichen auf eine engere Bindung und dann würde sich doch eh ein eigener Connector anbieten, der z.B. auch TLS erzwingt und nicht nur "Opportunistisches TLS" nutzt. Bei noch engerer Bindung wäre auch eine OrganizationRelationship zu überlegen, damit Frei/Belegt-Zeiten zwischen den Organisationen erreichbar werden.

Zusammenfassung

Es soll niemand sagen, dass man auch als Senior Consultant mehr 27+ Jahren Exchange Erfahrung schon alles gesehen hat. Jeden Tag gibt es neue Fragestellungen und wenn Sie die Herausforderung annehmen, dann haben sie keine Arbeit sondern eine Berufung gefunden. Das ganze funktioniert aber nicht als Solokämpfer sondern nur im Team mit anderen Consultants und MVPs. Anfangs sah es eine lange Zeit so aus, als ob ich hier einen Fehler im Exchange Routing gefunden habe.

Nun weiß ich, dass auch eine Einstellung an der RemoteDomain einen Einfluss auf das Routing hat und dieser Sachverhalt eher wenigen Menschen bekannt sein dürfte. Irritierend ist für mich dabei aber die Kopplung dieser Einstellung mit dem AllowOOFType, die aus meiner Sicht keinen Sinn macht.

Weitere Links