EXO mit NoSpamProxy

Am Beispiel von NoSpamProxy beschreibe ich, wie sie einen eigenen SpamFilter bzw. Verschlüsselungsgateway o.ä. sicher und korrekt mit ihrem Exchange Online in ihrem Office 365 Tenant verbinden. Das klingt erst mal unspektakulär aber einige Fallstricke gibt es doch.

Wenn Sie bei ihrer Spamfilterlösung einen "OrganizationConnector" in Exchange Online einsetzen wollen, dann lesen Sie vorher die Seite OrganizationConnector und Spamfilter, warum das eine schlechte Idee ist.

NoSpamProxy statt EOP?

"Moment mal!" höre ich hier schon den ein oder anderen sagen. Warum sollte ich ein 3rd Party-Produkt einsetzen, wenn Office 365 doch schon einen SpamFilter (EOP = Exchange Online Protection) eingebaut hat? Solange Spamfilter und Mailserver getrennte Produkte waren, gab es auch einen getrennten Markt mit Anbietern. Microsoft hat aber schon früh entsprechende Basisfunktionen (Siehe Intelligent Message Filter) in ihre Produkte eingebaut und die Exchange Online-Variante ist schon sehr leistungsfähig. Aber es immer noch ein System für alles und individuelle Anpassungen sind nur ein engen Grenzen möglich. So unterstützt EOP immer noch keine Verschlüsselung per SMIME/PGP, kennt keine Anbindung an DOI-Netze oder De-Mail und einige andere Besonderheiten.

Bitte beachten Sie, dass Microsoft ein 3rd Party Gateway ohne SpamFilterung als nicht supported ansieht
Quelle: https://docs.microsoft.com/en-us/exchange/mail-flow-best-practices/manage-mail-flow-using-third-party-cloud#Scenario2

Es gibt immer noch Kunden, die einen eigenen Service zwischen "Internet" und Mailsystem einbinden wollen oder sogar müssen. Die Details können Sie gerne mit dem NoSpamProxy-Vertrieb klären. Wir beschäftigen uns hier mit der Technik.

Mailrouting in Exchange Online

Zum Einstieg und warm werden hier noch einmal die drei Basiskonstellationen, die mit Exchange Online oder Exchange Hybrid zum Einsatz kommen können. Diesmal noch ohne NoSpamProxy. Die Bilder behandeln nur das Mailrouting. Andere Dienste wie DirSync, Authentifizierung (ADFS), Autodiscover oder die Exchange Web Services für Frei/Belegt-Zeiten und Migrationen sind hier zur Vereinfachung nicht abgebildet.

  • Office 365 Only
    Hierbei liegen durchweg alle Postfächer in der Cloud und der MX-Eintrag für die Domäne verweist auf den Cloud-Server. Bei Office 365 laufen die eingehenden Mails durch "Forefront Online Protection" als erste Verteidigung gegen Viren und Spam.

    On-Premises ist gar nichts installiert. Das ist die Wunschvorstellung von Microsoft und bei der Einrichtung von Domänen in Office 365 meckert der Assistent auch penetrant, wenn Sie den MX-Record, SPF-Eintrag etc. nicht mit in die Cloud einrichten.
  • Exchange Hybrid mit On-Prem Routing
    Wenn die Firma auch On-Prem einen Exchange Server betreibt, dann spricht man von einem "Hybrid-Szenario", bei dem die beiden Exchange Welten miteinander verbunden sind. In der Regel gehen eingehende und ausgehende Mails über ein Relay beim Kunden On-Prem zum internen Exchange Servern. Die Verbindung in die Cloud erfolgt über einen dedizierten Connect, bei dem optional ein Edge Server zum Einsatz kommen kann
  • Exchange Hybrid mit Cloud Routing
    Es ist durchaus möglich auch in einer Hybrid-Umgebung eingehende Mails an die Cloud liefern zu lassen und ausgehende Mails direkt aus Office 365 nach extern zuzustellen. So können Sie mit entsprechenden Office 365 Lizenzen vom Spamfilter der Cloud profitieren, auch wenn die Benutzer noch On-Premises ihr Postfach haben.

    Es sind sogar möglich über die Cloud und On-Prem Mails zu routen. Allerdings ist dies nicht immer sinnvoll, da es für einen Administrator die Fehlersuche und das Nachtracken kniffliger wird und unterschiedliche Spamfilter und Virenscanner verschiedene arbeiten. Sobald Sie über ein Gateway verschlüsseln wollen, müssen alle Mails sowieso durch Gateways mit der gleichen Funktion laufen, so dass diese "Split-Konfiguration" in der Folge nicht weiter betrachtet wird.
  • Gateway as a Service
    Ein Stück weiter geht der Ansatz, die Funktion selbst einfach einzukaufen, d.h. ein Dienstleister stellt die Ressourcen (Internetverbindung und Rechenleistung, die Software und die Verwaltung bereit. Sie als Kunden kaufen nur noch die Leistung z.B. nach Tagen, nach Gigabyte o.ä. ein.

Wenn das Mailsystem und der Filter aber nicht "nebeneinander stehen, dann muss es eine sichere Möglichkeit geben, wie der Filter zwischen "intern" und "extern" unterscheiden kann. Das gilt um so mehr, wenn das Internet als Transportweg genutzt wird und die Verbindung "von intern" über die gleichen Wege das Gateway erreichen. Das ist insbesondere in Verbindung mit Office 365 ein Sonderfall, da die ausgehenden Mailserver in Office 365 ja nicht nur von dem einzelnen Kunden sondern von allen Office 365 Kunden genutzt werden. Allein die "Source-IP" von Office 365 ist daher kein ausreichendes Kriterium für die Einstufung einer Verbindung als "intern".

Neben dem SMTP-Fluss muss natürlich auch das Management geklärt sein, d.h. das Gateway soll ja ungültige Empfänger z.B. gleich ablehnen, wozu es die Liste der gültigen Empfänger braucht. Und natürlich muss aus unserer Sicht die komplette Kommunikation verschlüsselt sein. Aufgaben, die lösbar sind, aber vom Produkt entsprechend unterstützt werden müssen. Wenn Sie nun aber eh ein Gateway zwischen Internet und ihrem internen Mailserver schalten, dann sollten Sie wissen, dass Microsoft für den Hybrid-Mode nur eine direkte Verbindung der beiden Exchange Welten über die Exchange HubTransport-Rolle oder einen optionalen Exchange Edge unterstützt.

Ich habe bislang nur einmal die Anforderung gehabt, einen Edge als Vermittler zu installieren. Die meisten Firmen nutzen als "Hybrid-Verbindung" einfach eine eigene IP-Adresse, die dann nur von Office 365 für den "Interconnect" genutzt wird. Der "normale" Verkehr geht dann eh über ein eigenes Relay.

NoSpamProxy muss im wesentlichen über Port 25 mit anderen Mailservern, d.h. im Internet und dem Server mit ihren Postfächern, kommunizieren. Zudem wollen Sie natürlich NoSpamProxy konfigurieren und NoSpamProxy muss über einen Webservice z.B.: die Liste der gültigen Adressen bekommen etc. Auf die Details gehe ich hier nicht weiter ein.

Ignite 2017: BRK2090 Insights into your Office 365 Mail Flow
https://channel9.msdn.com/Events/Ignite/Microsoft-Ignite-Orlando-2017/BRK2090
https://www.youtube.com/watch?v=PGJ9poMrYhc

Office 365 Routing und Besonderheiten

Wer heute ein alternatives Mail-Relay mit Office 365 oder einem anderen Hoster koppeln will, muss sich Gedanken über die sichere Kopplung machen. Auf seitens des Produkts können wir als Hersteller z.B. entsprechende Änderungen vornehmen. Aber auf der Seite des Providers muss man nehmen, was man bekommen kann. Zum Glück ist Office 365 da sehr gut geeignet, auch wenn man ein paar Besonderheiten beachten muss. Hier mal das grundlegende Bild:

Die einzelnen Punkte im Detail

Connector Beschreibung

Auf der Seite zu Office 365 hingegen wird es interessant. Office 365 sendet per Default ja selbst direkt in der Internet

NoSpamProxy muss natürlich die Verbindungen von Office 365 annehmen und anhand bestimmter Kriterien als "von intern" ansehen ohne gleiche alle Verbindungen von dem gleichen Quellsystem als intern zu behandeln.

Auf dem Weg zum Internet geht es wieder wie gewohnt weiter.

Eingehende Mails an die Firmendomäne werden per MX-Record zu NoSpamProxy gesendet.

Ausgehend sendet NoSpamProxy per DNS-Lookup direkt zum Zielserver des Empfängers.
Dazu kann man den MX-Record für <tenantname>.mail.onmicrosoft.com nutzen.

Nun muss sichergestellt werden, dass Mails von NoSpamProxy zur Cloud zugestellt und idealerweise gar nicht mehr einem Spamfilter unterworfen werden.

Die Verbindung 1->2 und 5->6 ist dabei besonders zu beachten, damit NoSpamProxy beim Empfang von Office 365 den Tenant unterscheiden kann. Der Trick hierbei ist es die so genannten "Dienstkopfzeilen" ("Retain service headers on transmission "). Diese sind eigentlich für die Hybridbereitstellung von Exchange gedacht, aber genau genommen ist die Verbindung von Office 365 mit NoSpamProxy ja auch eine "vertraute" Verbindung". Diese zusätzlichen Kopfzeilen erlauben aber Funktionen die zwischen externen Firmen und ihrem Mailsystem natürlich nicht erlaubt werden sollten. Hier mal exemplarisch so ein Header einer Mail von Office 365 -> NoSpamProxy.

x-microsoft-antispam: uriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR01MB268;
x-forefront-antispam-report: BMV:1;SFV:NSPM;SFS:(10009020)(6009001)(36882001)(229853001)(107886001)(2900100001)(....labs.com;FPR:;SPF:None;MLV:sfv;LANG:;
x-microsoft-antispam-prvs: <xxxxx@DB3PR01MB268.eurprd01.prod.exchangelabs.com>
x-exchange-antispam-report-test: uriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(601004)(5002010)(5005006);SRVR:DB3PR01MB268;BCL:0;PCL:0;RULEID:;SRVR:DB3PR01MB268;
x-forefront-prvs: 05168A3970
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Mar 2015 23:02:43.2217 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: <guid des tenant>
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR01MB268

Interessant sind hier sicher die "X-MS-Exchange-CrossTenant"-Felder. Wenn die Verbindung z.B. per TLS als "gesichert" angesehen werden kann, könnte ein Gateway über diese Felder entscheiden, ob der Absender zum eigenen Tenant gehört oder nur eine andere Firma in Office 365 ist, die uns erreichen will.

Option 1: Kunde mit Hybrid und Routing „via On-Premises Exchange Org“

In diesem Fall steht der NoSpamProxy nahe beim On-Prem Server der Firma und bekommt seine Mails auch nur über den Server und liefert eingehende Mails auch dort ein. Die Office 365 Umgebung ist hier komplett uninteressant. Auch bezüglich Provisioning der Benutzer kann die Liste der Benutzer vom internen AD bezogen und an NoSpamProxy hochgeladen werden.

Natürlich muss die Firma natürlich die lokale Exchange Organisation mit Office 365 koppelt. Das geht direkt über die Hub/Transport-Server oder dazwischengeschalteten Edge-Server.

Achtung
Laut Microsoft ist es nicht unterstützt ein anderes Relay zwischen die beiden Exchange Organisationen zu stellen. Ich kann mit vorstellen, dass sich Microsoft so natürlich den Weg für zukünftige Erweiterungen offen hält. Technisch wäre es wohl auch für NoSpamProxy kein Problem die gesamten TLS-Handshakes etc. abzuwickeln aber sie verlassen damit den gesicherten Weg.

Insofern stellt sich das Bild dann wie folgt dar:

NoSpamProxy steht als Relay zwischen Internet und der On-es-Umgebung und übermittelt Mails zwischen den beiden Welten. Die Verbindung zur Office 365 Cloud übernimmt der Exchange Server direkt oder über einen Edge Server.

Option 2: Kunde komplett in Office 365 oder Hybrid mit Routing über Office 365

Der einfachste zu erklärende Fall ist der Weg, dass ein Kunde nur in Office 365 arbeitet aber mit dem "Forefront Online Protection" als Filter nicht zufrieden ist. Das kann an der Spamerkennungsrate oder einfach an der reduzierten Funktion (Stichwort Level of Trust, Large File Service oder die fehlenden Verschlüsselungsfunktionen (PGP, SMIME, DE-Mail) liegen. er kann in diesem Fall recht einfach NoSpamProxy einsetzen, indem er Es zwischen Office 365 und das Internet schaltet.

Zuerst muss er natürlich einen "Platz" für das Gateway finden. NoSpamProxy ist eine Windows Software, die auch virtuell betrieben werden kann. Sie können also selbst einen Server bei sich aufbauen oder einen Server in einer beliebigen Cloud mieten. Das könnte auch Azure sein. Sie müssen natürlich ein gewisses "Vertrauen" mitbringen, denn auf dem Server liegen später beim Einsatz der Verschlüsselungsfunktion natürlich die privaten Schlüssel für SMIME und PGP.

Wo aber letztlich die Instanz ausgeführt wird, ist sehr frei zu entscheiden. Ich habe das Bild daher einfach mal "in die Mitte" gesetzt. Für die Office 365 Konfiguration bedeutet dies:

  • Office 365 sendet Mails mit SEND Connector an NoSpamProxy
    Einen entsprechenden Send-Connector für den Adressraum "SMTP:*" gibt es per Default in Office 365 nicht, und kann auch nicht so einfach über das Exchange Control Panel eingerichtet werden. Aber über das "Criteria Based Routing" lassen sich alle Mails, die von Office 365 an Empfänger "Außerhalb der Organisation" gehen, zu einem bestimmten Connector senden.
  • NoSpamProxy muss “erkennen” dass die Mails quasi “von innen” kommt
    Die Kontrolle der Source-IP reicht nicht. Erforderlich ist die Auswertung eines Headers, anhand NoSpamProxy den eigenen Kunden von anderen Kunden auf Office 365 unterscheiden kann. Erst dann darf er sich als "intern" verarbeiten und weiter senden

Dieses "erkennen" ist besonders wichtig, wenn NoSpamProxy nur eine IP-Adresse hat und damit "anonyme" Mails von anderen Firmen in der Cloud und Mails vom eigenen Tenant von der gleichen Office 365 Quelle kommen. Ein weiterer Aspekte gibt es hier, wenn NoSpamProxy für mehrere Firmen quasi als "Hosting" genutzt wird und die unterschiedlichen Kunden unterschieden werden müssen, auch wenn Sie beim gleichen Hoster, z.B. Office 365, liegen.

  • Eingehend muss der MX-Record auf NoSpamProxy verweisen
    Nur so kommen eingehende Mails bei NoSpamProxy an
  • NoSpamProxy muss die Mails zum Office 365 Tenant weiter senden
    Dazu kann NoSpamProxy den Host nutzen, auf den der MX-Record von "<tenantname>.mail.onmicrosoft.com" verweist.
  • Office 365 muss den eingehenden Verbindungen trauen
    Damit nicht erneut die Spamfilter von Office 365 die bereits gereinigten Mails vielleicht in Quarantäne einsortieren, sollte die eingehende Verbindung in Office 365 ebenfalls als "vertrauenswürdig" angesehen werden.

Wenn eWenn eine Firma schon Hybrid nutzt, aber die Mails über Office 365 sendet und empfängt, dann sind die gleichen Voraussetzungen zu erfüllen, als wenn die Firma komplett in Office 365 ist.

Sonderfall Empfänger und Sender in Office 365

Wenn Sie nun direkt mit der Einrichtung anfangen würden, dann dürften Sie sehr schnell an das Problem stoßen, dass Mails an andere Firmen, die ebenfalls in Office 365 gehostet sind, nicht zuverlässig ankommen. Das liegt in einer Besonderheit der Konfiguration in Office 365. Eigentlich erwarten Sie diese Verbindungen:

Allerdings sollten Sie sich nun genau den Send-Connector 5 anschauen, mit dem NoSpamProxy die Mails zur Cloud sendet. Damit der Empfang über ein "Inbound Connector 6" zu ihrem Tenant funktioniert, muss Office 365 ihre NoSpamProxy-Installation eindeutig identifizieren. Das kann per Source-IP-Adressen aber auch per Zertifikat gehen.

Ich rate hier immer zur Nutzung eines Zertifikats, da damit dann auch SMTP über TLS quasi gesichert ist und wechselnde IP-Adressen kein Problem darstellen.

Wenn NoSpamProxy nun per MX-Records wieder auf Office 365 geleitet wird, dann müssen Sie durch eine geeignete Konfiguration sicherstellen, dass die Cloud diese eingehende Verbindung nicht irrtümlich als interne Verbindung zwischen ihrem Tenant 1 und ihrer NoSpamProxy Installation ansieht. Die Konfiguration von Receive Connectoren sind nämlich global und Microsoft schreibt dazu:

The following conditions must be met:
1. Connections must have a matching certificate name.
2. At least one of the following domains must be a verified and accepted domain in Office 365:
   a Sender domain
   b Recipient domain
   c Domain name that matches the certificate's subject name
Quelle: “Identifying email from your email server” https://technet.microsoft.com/en-US/library/ms.exch.eac.InboundConnector_TlsNameMatchYourOrgServerCert(EXCHG.150).aspx

Ich verstehe das so, dass eine IP-Adresse als Kriterium nicht ausreichend ist und neben dem Zertifikat auch eine der zusätzlichen Bedingungen zutreffen muss. Aber in der Regel ist es ja genau so, dass die interne Verbindung zwischen NoSpamProxy und dem Tenant mit einem Zertifikat ausgestattet ist und der Sender in dem Beispiel ein interner Benutzer ist. In dem Fall wird eine Mail von Tenant 1 über das Gateway zurück zu Office 365 als "eingehend zu Tenant 1" klassifiziert.

Damit Office 365 diese eingehende Verbindung anders klassifiziert, muss der Sender sich anders verhalten. Ob eine alternative IP-Adresse funktioniert, habe ich nicht getestet. Aber wird müssen für ausgehende Verbindungen nur sicherstellen, dass NoSpamProxy entweder kein oder ein anderes Zertifikat nutzt. Das ist in NoSpamProxy einfach über den Punkt "ClientID" einstellbar. Aber sie müssen hier eben aktiv werden, dass Sie für die ausgehende externe Kommunikation ein anderes oder kein Zertifikat anbieten.

"Unsicherer" ist das erst einmal nicht, denn auch ohne ein Clientzertifikat des Senders ist SMTP/TLS weiterhin möglich. Ohne Zertifikat kann aber der sendende Host sich nicht ausweisen und MTLS geht entsprechend nicht. Wer also eingehende Mails an den eigenen Office 365 Tenant einliefern will, sollte ein zusätzliches Zertifikat vorsehen.

Konfiguration

Wenn wir uns nun die Einstellungen anschauen, dann brauchen wir ein paar Connectoren, bei denen es durchaus Besonderheiten gibt:

Update: Mittlerweile können Sie "Internet" gar nicht mehr als Ziel angeben, sondern nur Partner aber dafür können Sie nun einen "Adressraum SMTP:*" konfigurieren. Sie haben nun die Wahl, ob Sie über Transportregeln oder Adressraum alle Mails an externe Domains über einen Smarthost senden.

  • Outbound Connector zum "Internet" via NoSpamProxy
    Office 365 geht davon aus, dass die Cloud selbst sendet und meldet auch, dass ein gesonderter Connector zum Internet nicht erforderlich sei.

    Ein flexibler weg ist die Konfiguration über einen "Criteria based routing"-Connector, um Mails an "alle" über einen Connector zu NoSpamProxy zu senden. Dazu wird ein Connector von Office 365 zu einem "Unternehmensserver" angelegt und statt der Domänen die Transportregel ausgewählt

    Danach wird natürlich die IP-Adresse oder Name der vorgeschalteten NoSpamProxy-Instanzen und ggfls. das Zertifikat angegeben. Nachdem auch in NoSpamProxy die Konfiguration erfolgt ist, kann in Exchange eine Transportregel angelegt werden:
  • Eingehender Connector
    Weiterhin muss in Office 365 natürlich ein Connector für die Annahme der Mails von NoSpamProxy aktiviert werden. Das ist dann ein "Inbound Connector" von einem Partner"  an Office 365. Die Auswahl "Unternehmensserver" wäre hier falsch, da nur Mails von der eigenen Domäne über den Weg angenommen würden.

    Nach der Festlegung eines Namens, z.B. "Inbound von NoSpamProxy" und der Festlegung der Domains auf "*" müssen Sie vorgeben, dass TLS genutzt werden muss. Meine Empfehlung ist hierbei die Nutzung eines Zertifikatnamens, der exklusiv für diese Verbindung genutzt wird.
  • Konfiguration in NoSpamProxy
    Der Weg von dem Internet zum eigenen Mailserver, hier also Office 365, wird in NoSpamProxy über einen "eingehenden Send-Connector" konfiguriert. Für jeden Connector können Sie eine eigene Identifizierung über Zertifikate einrichten.

    Hier müssen Sie dann das Zertifikat auswählen, welches in Office 365 beim "Inbound Connector" hinterlegt ist.

Hier noch mal die Forderung beim Connector von "Unternehmensserver zu Office 365".

"Office 365 also verifies that the sender domain is an accepted domain for your organization before accepting messages from your own email server "
Quelle: Configuring the sender domain as an accepted domain
https://technet.microsoft.com/en-US/library/ms.exch.eac.ConnectorOnPremUseAsscDomains(EXCHG.150).aspx

Beachten Sie, dass der Hybrid Konfiguration Wizard einen anderen Connector per PowerShell konfiguriert, den Sie aber nicht per Browser einrichten können.

Eingehend mit "Enhanced Filtering"

Mit der Einführung der Funktion Enhanced Filtering gibt es einen weiteren Weg, Exchange Online mit einem 3rd Party Spamfilter eingehend zu verbinden. Technisch ist es ein "Partner Connector" aber Exchange Online würde immer nur die IP-Adresse von NoSpamProxy sehen. Mit aktiviertem SFP-Check besteht das Risiko, dass Exchange Online die eingehenden Mails als Spam klassifiziert.

Mit der Funktion Enhanced Filtering kann ich Exchange Online anweisen, das die einliefernde IP-Adresse nicht genutzt wird. Stattdessen analysiert Exchange vorherigen IP-Adressen aus dem SMTP-Header um so die einliefernde IP-Adresse vor dem 3rd Party Spamschutz zu ermitteln.

Als Anbieter dieser Lösung sollte ihr Spamfilter also wirklich besser sein, als Exchange Online Protection, denn ansonsten gibt es immer noch Mails in der Quarantäne oder Junk-E-Mail-Foldern.

Irrweg: Hybrid-Simulation "RouteAllMessagesViaOn-Premises"

Exchange Online kennt eine besondere Konfiguration: Hybrid Centralized Mail Transport. Dieser Fall ist dafür, dass eine Mail immer durch die On-Premises-Umgebungen geht, damit dort z.B. Transportregeln, Disclaimer, Archiv etc. ansetzen können. Folgende beiden Fälle sind hier interessant.

  • Eine Mail aus dem Internet landet bei Exchange Online
    z.B. weil der MX-Record in die Cloud verweist um den EOP-Spamfilter zu nutzen
  • Eine Mail eines Exchange Online Absenders
    Um auch interne Mails zwischen zwei Exchange Online Absendern über On-Premises zu routen

Wie sinnvoll nun so eine Konstruktion aus Dauer ist, lasse ich mal dahin gestellt sein. Sie könne die entsprechende Konfiguration über den HCW - Hybrid Configuration Wizard aber auch manuell einstellen. Nehmen wir an, sie legen in der Cloud folgenden Connector an

New-OutboundConnector -Name "Alles zu NoSpamProxy" `
   -RecipientDomains "*" `
   -ConnectorType onprem `
   -UseMXRecord $false `
   -SmartHosts nospamproxy.msxfaq.de `
   -RouteAllMessagesViaOn-Premises:$true

Damit ist sichergestellt, dass alle Mails von Exchange Online immer zu NoSpamProxy gehen. Aber nun denken Sie an die Mails aus dem Internet, die über NoSpamProxy zu Exchange Online gehen. Für Exchange Online ist das eine eingehende anonyme Mail, die durch die "Centralized Mail Transport"-Regel erst zu On-Premises gesendet wird. In dem Fall aber wieder genau zu NoSpamProxy zurück. Wir haben eine Loop gebaut.

Damit diese Konfiguration dennoch funktioniert, muss die Mail von NoSpamProxy eingehend als "vertrauenswürdig" gelten. Ich muss als parallel noch einen "Inbound-Connector" anlegen, der dann die eingehenden Mails von NoSpamProxy so behandelt, was wären sie schon von einem Exchange On-Premises Server gekommen. Die Anforderungen dafür sind hier gut beschrieben.

Damit Exchange Online eine eingehende SMTP-Verbindung zu einem "Inbound Connector" vom Typ "OnPrem" passt, müssen verschiedene Voraussetzungen erfüllt sein.

  • Client Zertifikat
    Es muss einen InboundConnector geben bei dem das vom Absender genutzte Zertifikat passt. Wenn es mehrere solche Connectoren gibt, dann muss der Domainname zu einer Accepted Domain passen.
  • Source-IP und MailFrom
    Wenn es keinen Match mit dem Zertifikat gibt, dann sucht Exchange Online anhand der IP-Adresse einen Connector und die "MailFrom"-Adresse muss zu den Accepted Domain passen.
  • RCPT-TO und Accepted Domain
    Zuletzt nutze Exchange Online die RCPT-TO-Adresse mit der Accepted Domain um den Tenant zuzuordnen. Hierbei schaut er noch mal, ob es einen Partner Connector mit besonderen Vorgaben gibt. Die Mail wird aber immer als "eingehend von extern" angesehen und entsprechend "geprüft"  (SPF, DKIM etc)

Wenn Sie also wirklich eine Mail von NoSpamProxy über einen "Organization"-Connector einliefern wollen, dann geht das nur per Zertifikat, denn die MailFrom einer solchen externen Mail passt ganz sicher nicht zu ihrem Tenant.

Übrigens gilt diese Betrachtung und damit der Irrweg auch für die Verbindung einer Exchange On-Premises-Umgebung mit mehreren Tenants mit "OnPrem"-Connectoren.

Weitere Links