OrganizationConnector und Spamfilter

Auf dieser Seite möchte ich eine leider oft falsch konfigurierte Verbindung von Exchange Online mit einem 3rd Party Spamfilter mithilfe eines OrganizationConnector beschreiben und warum diese Konfiguration falsch ist.

Beachten Sie dazu auch die Seiten OrganizationConnector, OrganizationConnector Attribution und EXO mit NoSpamProxy

Umgebung

Wer nicht Exchange Online Protection nutzt, braucht natürlich einen eigenen Spamfilter, sei es im Eigenbetrieb oder eine gehostete Lösung. Als Exchange Online Admin wollen Sie natürlich die von ihrem vorgelagerten Spamfilter bereinigten Mails möglichst problemlos zu Exchange Online durchlassen und nicht erneut über EOP oder Defender prüfen lassen. Zumal hier ein SPF-Check z.B. immer ein FAIL liefert.

Der richtige Weg ist die Konfiguration eines "Inbound Partner Connector" für die Domain "*" und die Anpassung durch EXO Enhanced Filtering

Wenn Sie aber gegen meinen Rat einen Inbound Organisation Connector anlegen, denn spielen Sie mal folgendes Experiment durch:

Ihre aktuelle Umgebung sieht dann wie folgt aus:

  • Eingehende Mails aus dem Internet über MX-Record zum Spamfilter und dann per Smarthost weiter zu Exchange Online
  • Ausgehende Mails von Exchange Online über Smarthost zum Spamfilter und per MX-Record an die Ziele
  • Der Spamfilter nutzt ein Zertifikat, um TLS anzubieten und eingehend sich beim Exchange Online auszuweisen

Nun betrachten wir ein paar Fälle:

Internet -> Spamfilter -> Ihr Tenant

Die Stationen sind schnell beschrieben.

  • Mail kommt per MX Record bei beim Spamfilter an
  • Spamfilter behandelt Spam, Empfängerfilter etc.
  • Spamfilter sendet weiter zu Exchange Online per MTLS
  • Exchange Online nutzt das Zertifikat des Spamfilters und erkennt den OrganizationConnector
  • Mail wird zu Exchange Online zugestellt.

Soweit alles in Ordnung

Ihr Tenant -> Spamfilter -> Internet

Auch der Versand über ihren Spamfilter könnten sie mal so eben schnell einrichten

  • Exchange Online sendet die Mails an den vorgelagerten Spamfilter
    Das können Sie über eine Transportegel machen oder Centralized Mail Transport
  • Der Spamfilter nimmt die Mails an und sendet sie über den MX-Record ins Internet

Soweit scheint auch hier alles noch in Ordnung zu sein. Dazu brauchen wir auch keinen OrganizationConnector, es sei denn die versuchen das Routing über Centralized Mail Transport zu realisieren, was eine dumme Idee ist.

FremdTenant -> Spamfilter -> IhrTenant

Ihr MX-Record verweist ja auf ihren Spamfilter, wenn ein fremder Tenant eine Mail zu ihnen sendet, dann durchläuft er folgenden Weg:

  • Fremdtenant sendet per MX-Record an ihren Spamfilter
  • Spamfilter routet Mail wieder zu  ihrem Exchange Online Tenant zurück.

In dem Zuge frage ich sie einfach mal, wie denn ihre Spamfilter zwischen den beiden Tenants unterscheiden kann. Denn ob eine ausgehende Mail von ihrem Tenant ins Internet geht oder von einem anderen Tenant kommt, kann er ja nicht allein an der Source-IP oder dem Zertifikatnamen „protection.mail.outlook.com“ festmachen.

SpamTenant -> Spamfilter -> Internet

"Security by Obscurity" funktioniert aber auch nicht, denn mir reicht eine Mail von ihrem Tenant an mich, um im Header die verschiedenen Stationen zu ermitteln. So finde ich sehr einfach heraus, über welches ausgehende System sie ihre Mails versenden. Als Spammer würde ich nun einfach in meinem Tenant einen Smarthost über ihr Spamrelay einrichten, ihre IP-Adresse noch in den SPF-Record meiner Domains addieren und dann ihr System als Relay missbrauchen. Das nennt man dann ein offenes Relay.

Ihr Spamfilter muss ausgehend sowohl die IP-Adresse und/oder den Zertifikatnamen des einliefernden Systems auf "Exchange Online" prüfen und dann auch noch die Domain des Absenders einbeziehen. Wenn Sie aus ihren "Accepted Domains" kommt, dann kann der Spamfilter die Mail entsprechend als legitim von "Intern nach Extern" klassifizieren.

Sie können das einfach prüfen: Nutzen Sie einen anderen Tenant, z.B. einen Developer Tenant, mit einer anderen Domain, konfigurieren Sie einen Partnerconnector für eine Testdomain oder "*" zu ihrem Spamfilter und senden eine Mail. Ihr Spamfilter sollte die Mail ablehnen.

Ihr Tenant -> Spamfilter -> FremdTenant

Kommen wir nun zu dem Fall, der mich immer wieder erreicht und von vielen Administratoren nicht gesehen wird. Sie senden eine Mail von ihrem Tenant an eine externe Firma und die Mail kommt nicht an oder landet wieder bei ihrem Tenant, während der Administrator im Ziel nichts bei sich sieht.

Der Fehler passiert dann, wenn das Ziel selbst auch Exchange Online nutzt UND der MX-Record des Empfängers auf Exchange Online verweist. Was passiert dann?

  • Ihr Anwender sendet eine Mail an den Empfänger
  • Exchange Online routet die Mail über den Smarthost zu ihrem Spamfilter
  • Der Spamfilter akzeptiert die Mail
  • Der Spamfilter routet die Mail über den MX-Record zu Exchange Online
    Hier passiert dann das Problem, wenn der Spamfilter mit dem Zertifikat oder Source-IP-Adresse bei Exchange Online ankommt zu dem es einen OrganizationConnector gibt. Dann wird die Mails nämlich falsch an ihren Tenant zugeordnet und nicht an den Empfängertenant.

Diese Fall ist nicht einfach zu analysieren, denn sie suchen natürlich immer erst im Ziel, warum die Mails dort nicht ankommen, wo doch ihr lokale Spamfilter die erfolgreiche Zustellung zu Exchange Online anzeigt.

Das Problem betrifft speziell "Hosted Spamfilter", die auch noch viele Kunden über die gleiche Instanz betrieben und Kunden vielleicht fälschlicherweise den gleichen OrganizationConnector mit dem Zertifikatnamen des Hosters anlegen und sich wundern, dass der Connector nie zum Einsatz kommt, denn die Domain des Zertifikat ja keine AcceptedDomain in den jeweiligen Tenants.

Daher sollten Sie bei einem OrganizationConnector für den einliefernden Server immer nur ein Zertifikat aus einer Domain nutzen, die auch in ihrem Tenant definiert ist.

IP statt Zertifikat

Gerade das letze Fehlerbild ist knifflig und wenn das mit das Zertifikaten nicht funktionieren kann, dann könnte Sie ja auf den Gedanken kommen, auf Source-IP-Adressen statt Zertifikate umzuschwenken. Das ist möglich, wenn Sie ihren "persönlichen" Spamfilter mit einer dedizierten IP-Adresse haben. Betrachten Sie das Thema "Tenant Attribution" von Microsoft auf:

Wenn kein Connector mit dem Zertifikat gefunden wird, dann nutzt Exchange Online folgende Regel:

we next look at the Connecting IP and find all tenants with Inbound OnPremises connectors which match the IP.
For all matched connectors we next look at what tenant has the MailFrom domain configured as an accepted domain. 
If one is found the message is attributed as Originating from that tenant.

Das funktioniert super, wenn der Absender eine lokale Exchange Umgebung ist und die Mail von "Intern zu Intern" übertragen wird. Wenn der Absender aber aus dem Internet mit einer Domain sendet, die sicher nicht zu ihren "Accepted Domains" gehört, dann kommt auch diese Regel nicht zum Tragen.

Das Ergebnis ist, dass kein "OrganizationConnector" gefunden wird und die Mails als "Eingehend aus dem Internet" angesehen wird. Dabei ist es dann egal, ob in einem oder mehreren Tenants es einen OrganizationConnector mit der IP-Adresse des Hosted Spamfilter gibt.

Exchange Online versucht zuallererst zu ermitteln, ob eine Mail als "Originating" oder "Incoming" gewertet wird. "Originating" bedeutet, dass die Mail von einem Absender in ihrer Firma, d.h. entweder ein Exchange OnPremises oder ein Exchange Online-Postfach, ist. Ein Organization Connector ist definitiv die falsche Konfiguration für eingehende Mails über einen vorgelagerten Spamfilter!

Weitere Links