Exchange Online Connector Routing

Normal sendet und empfängt Exchange Online Mails über Exchange Online Protection. Diese Seite beschreibt, wie ein Drittprodukt wie z.B. NoSpamProxy in den Übertragungsweg einbinden.

Beachten Sie dazu auch die Seite Partner Connector

Warum?

Exchange Online ist nicht nur ein leistungsfähiger Mailserver. Microsoft stellt mit Exchange Online Protection auch einen durchaus akzeptablen Spamfilter bereit, der speziell für viele kleinere Tenants sogar erst Wahl ist. Aber Es gibt Dinge, die Exchange Online von Hause aus entweder nicht oder nicht gut genug kann. Dann schlägt die Stunde der Dritthersteller, die ihre eigenen Produkte in die Umgebung integrieren wollen. Nun können Sie natürlich keine Transportagenten für Exchange Online installieren, da die Server ja von Microsoft betrieben werden. Über eine geschickte Konfiguration von Connectoren lassen sich aber Dritt Produkte wie z.B. NoSpamProxy durchaus integrieren. Interessant ist dies immer wenn Sie z.B. ein oder mehrere der folgenden Funktionen nutzen wollen, bei denen Exchange Online alleine nicht stark genug ist.

  • Verschlüsselung mit SMIME/PGP
    Aktuell kann Exchange Online diese Funktion nicht bereitstellen. Microsoft setzt hier eher auf "Rights Management", vormals RMS und nun Azure Information Protection (AIP).
  • Leistungsfähige Disclaimer
    Über Exchange Online Transport Regeln können Sie in einfache Disclaimer-Funktionen umsetzen. Sie sind aber wirklich "einfach" und erfordern die Einstellung als "Exchange Admin". Delegierung ist nicht einfach und selbst dann brechen diese Transportregeln z.B. eine Verschlüsselung/Signierung durch SMIME/PGP auf dem Client. Zudem ist nicht jeder Administrator geübt im Eingeben von HTML-Code
  • Flexible Spamfilter die über EOP hinaus gehen
    EOP filtert Spam aber fokussiert sich auf das Prinzip "One Sizes fits all". Feintuning und Anpassungen sind eigentlich nicht möglich. Das ist je nach Branche durchaus kritisch zu sehen. Spezialisten wie NoSpamProxy leisten hier deutlich mehr.
  • Eigene Transport-Aktionen
    Wenn jede Mail durch ihre Lösung geht, können Sie viel mehr Funktionen umsetzen, als Exchange Online alleine bietet oder per EWS erreichbar wären.

Es gibt noch weitere Gründe, warum sie ein Drittprodukt oder vielleicht auch eine eigene Lösung in den Mailfluss ihrer Office 365 Postfächer einbinden wollen. Daher stelle ich zwei Varianten vor.

Davor oder Dazwischen?

Sie können eine 3rd Party Lösung über zwei Wege in den Mailfluss von Exchange Online einbinden, wovon jede ihre individuellen Vorteile und Einschränkungen hat. Es bietet sich natürlich an die eigenen Lösungen direkt in Azure zu betreiben, damit der Weg kurz und die Bandbreite hoch ist.

Position Beschreibung

Davor

Eine Variante ist die eigene Lösung zwischen das Internet und die Exchange Online Umgebung zu stellen. Dann ist ihr Service direkt für die Mailannahme zuständig und sendet auch selbst. Exchange Online ist quasi dahinter versteckt. In Exchange Online werden alle ausgehende Mails zum Service gesendet und Mails vom Service anhand der Source-IP oder Namen im Zertifikat als "vertrauenswürdig" angenommen um den Spamfilter Exchange Online Protection zu umgehen.

Beachten Sie dabei aber, dass der Versand in das Internet durch ihren Service erfolgen muss und nicht alle Hoster (z.B. Azure) per Default einen Versand erlauben. Auch SPF-Einträge und RBL-Listen beim Ziel können eine Herausforderung sein oder Sie nutzen weitere Versender wie z.B. Sendgrid u.a.

Daneben Variante 1

Ich kann den Service hinter Exchange Online verbergen, indem ich ausgehende Mails immer erst zu meinem Service leite, der dann die Mails aber wieder zu Exchange Online einliefert. Entsprechende Transportregeln leiten die Mails zu einem Connector um, wen Sie noch nicht durch den Service gekennzeichnet wurden und ein Inbound-Connector nimmt die Mail an um sie dann wieder über Exchange Online zu versenden. Dieser Werg ist interessant, wenn der Service für ausgehende Mails und optional für eigenende Mails genutzt wird aber der Spamfilter von Exchange Online Protection genutzt wird.

Einstellungen bezüglich TLS-Sicherheit sind weiterhin in Exchange Online über Connectoren zu steuern.

Daneben Variante 2

Wenn der eigene Service aber auch z.B.: bessere Spamfilter-Funktionen anbietet, dann können sie den MX-Record natürlich auch auf ihren Service verweisen lassen und damit eingehend auch weitergehende Funktionen bezüglich TLS, RBL etc. kontrollieren. Das ist durchaus interessant, wenn ihnen die allgemeinen Schutzfunktionen von Exchange Online nicht genügen oder für ihre Anwendung nicht passend sind. Sie können weiterhin über Exchange Online versenden und damit die Microsoft Server dazu verwenden.

Wenn Sie dann aber auch den Versand selbst abwickeln, dann entspricht das Bild schon fast wieder dem ersten Szenario "Davor"

Bei den beiden "Daneben"-Varianten wird der Versand über Exchange Online geführt und daher ist es erforderlich, dass Exchange erkennen kann, ob die Mail schon durch den eigenen "Service" verarbeitet wurde. Dazu sollte der eigene Service z.B. einen SMTP-Header addieren, der dann bei den Transport-Regeln in Exchange Online referenziert werden. Es gibt sicher noch die ein oder andere kleine abweichende Variante. Ich beschränke mich hier aber erst einmal auf diese drei Hauptvarianten.

Gegenüberstellung

Hier eine kurze Gegenüberstellung der Varianten:

Funktion Davor Dazwischen 1 Dazwischen 2

Skizze

Header durch App zu setzen

nicht erforderlich

Erforderlich

Erforderlich

Scope
  • Mails an externen Empfänger
  • Mails von externen Sendern
  • KEINE internen Mails
  • Mails an externen Empfänger
  • Mails von externen Sendern
  • interne Mails
  • Mails an externen Empfänger
  • Mails von externen Sendern
  • interne Mails

Versand

Eigene IP-Adressen. Einschränkungen von Azure

Mails werden weiterhin durch EOP versendet

Mails werden weiterhin durch EOP versendet

MX-Record/Spamschutz

Über den eigenen Service

Über Exchange Online

Über den eigenen Service

SPF-Eintrag

Eigener Service

Office 365

Office 365

SMIME/PGP

Ja, mit externen

Ja, mit externen und internen

Achtung: ECP kann eingehend verschlüsselte Mails nicht prüfen

Ja, mit externen und internen

Disclaimer

Ja, mit externen

Ja, mit externen und internen

Ja, mit externen und internen

SMTP-TLS
  • Ausgehend: Eigener Services bestimmt
  • Eingehend: EXO Konfiguration maßgeblich
  • Ausgehend: EXO Konfiguration maßgeblich
  • Eingehend: EXO Konfiguration maßgeblich
  • Ausgehend: EXO Konfiguration maßgeblich
  • Eingehend: eigener Service

Es gibt also für jede Variante die individuellen Vorteile und Einschränkungen. Wer nach extern gar nichts veröffentlichen will, nutzt die "Dazwischen 1"-Variante, verzichtet dabei aber auf eigene Einstellungen bezüglich TLS-Vorgaben und Spamfilterung. Bei der "Davor"-Lösung müssen Sie sich natürlich noch selbst um den Versand der Mails ins Internet kümmern, was bei den anderen Varianten durch Exchange Online abgewickelt wird.

Transport-Regeln und Connectoren

Die komplette Konfiguration besteht aus der geschickten Kombination von Inbound-Connector und Outbound-Connectoren und den selektiven Einsatz von Transportregeln.

  • Outbound Connector
    Diese Einstellung im Office 365 Tenant bestimmt, wohin bestimmte Mails geroutet werden. Er wird beim Szenario "davor" genutzt, um generell alle Mails an das Service-System zu routen, egal ob es nun "daneben" oder "davor" steht.
  • Inbound Connector
    Über diese Einrichtung können sie bestimmten Quell-IP-Adressen einen Vertrauenslevel geben. So erreichen Sie, dass Verbindungen und darüber übertragene Nachrichten von Exchange Online angenommen werden können und zumindest nicht durch RBL-Regeln oder SPF-Verifizierungen geblockt werden.
  • Transport Regeln
    In Exchange Online ist es möglich, über Transportregeln bestimmte Mails zu einem Connector umzuleiten. Dies geht On-Premises aktuell nicht. Diese Funktion ist aber wichtig um ausgehende Mails zu eben einem Connector zum eigenen Service zu lenken und auch die Mails anders zu behandeln, die schon vom Service wieder zurock kommen

Diese gesamte Konstellation benötigt zur Funktion noch etwas mithilfe von dem Service. Speziell wenn die gleiche Mail zweimal durch

Beispiel "Dazwischen 1"

Exemplarisch beschreibe ich die Integration von NoSpamProxy als SMIME/PGP-Gateway, welches z.B. auf Azure laufen kann aber sich nicht selbst um den Mailversand per TLS kümmert. Der Ablauf ist dann wie folgt in beide Richtungen

Sowohl in die ausgehende als auch eingehende Richtung werden die Mails durch den eigenen Service geleitet und können damit komplett verarbeitet werden. Das Setup müsste im Tenant dann wie folgt aussehen.

Richtung Beschreibung

Office 365 eingehend

Damit eingehende Mail von ihrem Service von Office 365 an angenommen werden, muss in Office 365 der Service definiert werden. Das geht mit einem Connector, der Verbindung von der eigenen Organisation zu Office 365 erlaubt. Der gleiche Connector wird auch mit dem Hybrid Configuration Wizard eingerichtet, wenn Sie Exchange Hybrid betreiben. Es ist aber kein Problem mehrere solcher Connectoren einzutragen.

  • Name: "NSP to Tenant"
  • Typ: Own Organization -> Office 365
  • Remote Host: by Cert "nsp.msxfaq.net"

Eine Überprüfung des Connectors findet nicht statt.

Service Ausgehend

Nachdem im Tenant hinterlegt wurde, wie eingehende Mails vom Service angenommen und identifiziert werden, müssen Sie ihrem Service natürlich noch konfigurieren, alle ausgehenden Mails an ihren Tenant zu senden.

Service Eingehend

Damit die Mails vom Office 365 Tenant beim Service entsprechend zugeordnet werden können, sollten Sie im Service eine Konfiguration hinterlegen, die idealerweise TLS erzwingt und dann den Namen aus dem Zertifikat von Office 365 als Authentifizierung heranzieht. Diese Konfiguration muss zuerst abgeschlossen werden, ehe Sie den letzten Schritt tun können.

Office 365: Ausgehend

Um Mails über den Service ins Internet zu senden, müssen Sie einen Connector einrichten, der von Office 365 zu eigenen Organisation geht.

Mittlerweile können Sie einen "Outbound Connector" mit dem Adressraum "*" anlegen und alle Mails zu NoSpamProxy senden.

Der Weg über eine

Hier wird aber kein Adressraum angegeben sondern die Nutzung als Ziel in einer Transport Regel eingestellt.

  • Name: "Tenant to NSP"
  • Typ: O365 -> Own Organization
  • Only when transportrule applies
  • Smarthost: "nsp.msxfaq.net", TLS-Name

Nachdem alle Werte eingetragen wurden, versucht Office 365 direkt eine Mail zu senden. Ohne diesen Test ist die Konfiguration nicht komplett. Daher ist es wichtig zu der Zeit den Service schon online und konfiguriert zu haben.
Transportregel

Zuletzt muss über eine Transportregel nun erreicht werden, dass Mails, die noch nicht verarbeitet wurden, erst zum Service gehen. Der einfachste Weg dafür ist die Kontrolle eines SMTP-Headers, der von dieser Applikation gesetzt wird. Wenn Sie als Service hier z.B. NoSpamProxy nutzen, dann bietet sich z.B. das Feld "X-NoSpamProxy-ID" an, welches entsprechend gesetzt wird. Mit einer andere Lösung müssen sie natürlich erst ein passendes Feld finden. Beachten Sie, dass Mails von internen Absendern das Feld nicht haben aber eingehende Mails durchaus das Feld schon enthalten können. Wenn der entfernte Absender das gleiche Produkt verwendet oder absichtlich den Header addiert, dann könnte dies ihre Logik stören.

Wer diese Lücke dennoch schließen will, weil ein Angreifer ja auch anhand einer Mail die ID ermitteln könnte, könnte eine weitere Transport Regel bauen, die aus allen ausgehenden Mails mit diesem Header diesen entfernt. Oder sie routen alle Mails von "externen Absendern" generell zum Service und verwenden ein anderes Feld als Kriterium, um intern das Routing weiter zu steuern.

So ist sichergestellt, dass jede Mail die noch nicht diesen Header hat, umgehend zum Service geroutet wird. Der Service kann die Mail dann entsprechend umarbeiten und muss nur den Header setzen. Sie wird dann nach der Rücklieferung an den Office 365 Tenant durch die Ausnahme nicht mehr verarbeitet.

Beispiel "Daneben"

Für die Konfiguration "neben" dem Mailfluss habe ich keine Beschreibung veröffentlicht. Speziell wenn das Gateway dann über Office 365 wieder in das Internet senden soll, sind sowohl auf dem Gateway als auch im Tenant entsprechende Einstellungen erforderlich. Eine generische Beschreibung würde eher in die Irre leiten denn hilfreich werden. Office 365 muss ja unterscheiden können, ob die Mail vom Gateway kommt und ins Internet geht (Relay) oder von Gateway kommt um nach intern zugestellt zu werden.

NoSpamProxy ist dahingehend schon vorbereitet, dass es entsprechende SMTP-Header wie "X-NoSpamProxy-ID " gibt, anhand der man in Office 365 über Transportregeln erkennen kann, woher die Mails kommen um damit den Weg nach intern und extern zu unterscheiden.

Jede Mail, die eingehend in Office 365 schon das Feld "X-NoSpamProxy-ID " mit dem richtigen Wert hat, und der Absender intern ist, kann nach extern geroutet werden während alle Mails ohne dieses Feld ausgehend zum Connector Richtung NoSpamProxy zwecks Nachbearbeitung geroutet werden.

Weitere Links