EXO Enhanced Filtering

Wenn Sie den MX-Record ihrer Maildomain nicht direkt zu Exchange Online verweisen, sondern im Hybrid-Mode arbeiten oder einen eigenen 3rd Party Spamfilter davor betreiben, dann ist diese Seite interessant.

Die Funktion gibt es nur in Exchange Online und daher nur wirksam, wenn Mails bei Exchange Online eingeliefert werden.

Auslöser: SPF und SRS, DMARC

Exchange Online hat einen mehr oder weniger leistungsfähigen Spamfilter und Malwarefilter. Eine wesentliche Funktion zum Abwehren von Fälschungen besteht dabei in der Überprüfung des Absenders anhand der von der Absenderdomain hoffentlich veröffentlichten SPF-Einträgen. Der Absender gibt damit seine legitimen Absender vor und kann über DMARC dies noch strenger beschränken.

Solange ihr MX-Record für die Empfängerdomain direkt zu Exchange Online verweist, funktioniert diese Erkennung und Bewertung sehr gut:

Interessant wird dies aber, wenn Sie nicht Exchange Online Protection sondern einen eigenen Spamfilter einsetzen der vor Exchange sitzt. Der MX-Record verweist auf den Spamfilter, der dann die Mails per Smarthost an Exchange Online weiterleitet. In Exchange Online haben Sie einen Partner-Connector mit dem Adressraum "SMTP:*", welcher die Zustellung aus dem Internet auf ihren Spamfilter beschränkt

Sie können nun aber gut sehen, dass Exchange Online nur eingehende Verbindung von der IP-Adresse ihres vorgelagerten Spamfilters sieht. Diese ist aber garantiert nicht im SPF-Record der Absenderdomain enthalten. Ohne entsprechende Vorkehrungen würde Exchange Online diese Verbindungen als "Phishing" klassifizieren und entweder direkt ablehnen oder die Mails zumindest in die Quarantäne des Tenants oder den Junk-E-Mail-Ordners des Anwenders einsortieren. Sie haben nun zwei Optionen zur Auswahl:

  • EOP abschalten (geht nicht komplett)
    Sie können natürlich komplett auf den davor geschalteten Spamfilter setzen und versuchen den eingebauten Spamfilter von Exchange Online zu deaktivieren. Das ist über verschiedene Richtlinien einstellbar aber leider nicht komplett zu deaktivieren. Insbesondere "Malware"-Regeln sind immer aktiv. Das ist aber auch sinnvoll, um z.B. interne Spam oder Malware zu blockieren. Allzu oft werden ja auch Konten per Phishing gekapert und dann hilft ein interner Schutz.
  • Enhanded Filtering konfigurieren
    Viel wichtiger ist die Konfiguration von "Enhanced Filtering" auf dem entsprechenden "Inbound Partner Connector". Damit teile ich Exchange Online Protection mit, dass er die einliefernde IP-Adresse und optional weitere Adressen aus dem Header ignorieren soll, bis er die tatsächliche IP-Adresse des Servers findet, die mittels MX-Record die Mail zugestellt hat. Oder sie schalten die Erkennung direkt ab.

Das wird umso wichtiger, da Microsoft im Herbst 2023 auch die DMARC-Konfiguration verschärft hat. Wenn die SMTP-Domain des Absender einen DMARC-Eintrag hat, dann wird dieser nun beachtet:

Sie können natürlich auch die DMARC-Auswertung deaktivieren oder abschwächen, um eine "p=reject"-Richtlinie zu überstimmen. Dies geht im Security Center unter https://security.microsoft.com/antiphishing

Damit können Sie verhindern, dass ein Absender mit falschem DMARC-Eintrag oder ihr Connector ohne "Enhanced Filtering" eine Mail aufgrund eines SPF-Fehlers ablehnen oder in eine Quarantäne stecken.

Ein Blick in den Header einer empfangenen Mail zeigt, was Exchange geprüft hat. Wenn zwischen dem Internet und dem Server B ein 3rd Party Spamfilter "S" eingeschaltet ist. Exchange Online sieht ist als Source-IP nun die IP2 und nicht mehr die IP1, welcher per SPF publiziert ist. Selbst wenn ich in Exchange Online einen eingehenden Partner-Connector konfiguriere und damit fast ein Allowlisting einrichten kann, so macht Exchange Online dennoch einen SPF-Check, um davon abhängige Logik anzuwenden. Sie können dazu im Header einer eingehenden Mail dies direkt sehen:

Authentication-Results: spf=softfail (sender IP is 193.37.132.2)
 smtp.mailfrom=msxfaq.de; dkim=pass (signature was verified)
 header.d=msxfaq.de;dmarc=pass action=none
 header.from=msxfaq.de;compauth=pass reason=100

Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
 msxfaq.de discourages use of 193.37.132.2 as permitted sender)

Received: from netatwork.cloud.nospamproxy.com (193.37.132.2) by
 DB5EUR03FT063.mail.protection.outlook.com (10.152.20.209) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5017.22 via Frontend Transport; Mon, 7 Mar 2022 07:29:57 +0000
Received: from 178.135.28.34 by netatwork.cloud.nospamproxy.com via connector NSP
 Cloud-Connector (Tls12, Aes256, Sha384, DiffieHellmanEllipticKey384); Mon,
 07 Mar 2022 07:29:52 GMT
X-MS-Exchange-Organization-MessageDirectionality: Incoming
X-MS-Exchange-Organization-AuthSource: DB5EUR03FT063.eop-EUR03.prod.protection.outlook.com
X-MS-Exchange-Organization-AuthAs: Anonymous

Die IP-Adresse "193.37.132.2" ist natürlich nicht autoritativ für meine Domain "msxfaq.de" und damit verhindert dies eine SRS-Umschreibung, wenn ich eine Mail an eine Gruppe beim Server B sende und dieser dann weiter externe Teilnehmer hat.

Dieses Problem hat Microsoft aber auch schon gefunden und eine Lösung erarbeitet. Elegant wäre es ja, wenn ich Exchange Online sagen könnte, dass er nicht die direkt sichtbare IP-Adresse von Server S nutzt sondern z.B. die IP-Adresse aus dem "Received:"-Header davor. Hier der gleiche Header mit der zusätzlichen "Received:"-Zeile:

Received: from netatwork.cloud.nospamproxy.com (193.37.132.2) by
 DB5EUR03FT063.mail.protection.outlook.com (10.152.20.209) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5017.22 via Frontend Transport; Mon, 7 Mar 2022 07:29:57 +0000
Received: from 80.237.137.3 by netatwork.cloud.nospamproxy.com via connector NSP
 Cloud-Connector (Tls12, Aes256, Sha384, DiffieHellmanEllipticKey384); Mon,
 07 Mar 2022 07:29:52 GMT

Wenn Sie genau hinschauen. dann finden Sie hier die IP-Adresse 80.237.137.0/24 als Quelle bei der "Einlieferung an NoSpamProxy". Diese Adresse kann ich per SPF-Check gegen "msxfaq.de" problemlos auflösen. Da ich als Betreiber von Server B auch einen Vertrag mit dem vorgelagerten Spamfilter "S" habe, kann ich Exchange Online anweisen, dem Header zu vertrauen, der durch den Server "S" addiert wurde. Genau das bringt die Funktion "Enhanced Filtering" mit sich.

Inbound Connector

Ehe Sie "Enhanced Filtering" konfigurieren können, müssen Sie in Exchange Online einen "Inbound Connector" anlegen. Sie können die Funktion nicht global für einen Tenant aktivieren. Das macht auch Sinn, denn Sie sollten das vorgelagerte System ja genau kennen und gegenüber Exchange Online auch über eine IP-Adresse oder ein Zertifikat identifizierbar machen. Zudem wird so sichergestellt, dass direkte Zustellungen an den Exchange Online Tenant nicht den Spamfilter der Cloud umgehen.

Sie können Enhanced Filtering nicht mit Hybrid Centralized Mail Transport kombinieren.

Für den Empfang in Exchange Online können Sie einen Partner-Connector anlegen. Meist ist der OnPrem-Connector schon durch einen HCW angelegt und damit brauchen Sie diese Funktion nicht mehr. Ich hoffe, dass Sie vor ihrem Exchange ein adäquater Spamfilter sitzt. Der Partner Connector kann wie folgt in der Exchange Online PowerShell angelegt werden:

New-InboundConnector `
   -Name "Inbound Internet via NSP to O365" `
   -Senderdomains “*“ `
   -RequireTLS $true `
   -TlsSenderCertificateName cloud.nospamproxy.net `
   -connectortype Partner `
   -enabled:$true `
   -EFSkipLastIP:$true

Damit ignoriert Exchange Online die einliefernde letzte IP-Adresse, solange sich der Absender mit dem passenden Zertifikat ausweist.

EFSkipLastIP

Ich kann dann Exchange Online entweder automatisch versuchen lassen die maßgebliche IP-Adresse zu ermitteln oder die Adressen übergebe, die Exchange Online ignorieren soll. Als Administrator können Sie das ganz elegant im Security Center einstellen. Unter "Policy&Rules - Thread Policies - enhanced Filtering Connectors" oder der direkten URL https://security.microsoft.com/skiplisting können Sie pro Connector die Filterfunktion aktivieren.

Bei der Aktivierung können die neben der Automatismus auch die IP-Adressen ihres  vorgelagerten Systems pflegen.

Hier sollten Sie dann alle IP-Adressen pflegen und ggfls. sind Korrekturen erforderlich, wenn der Provider neue Systeme online nimmt.

Die Einstellung "Automatic" überspringt einfach den letzten Eintrag und nimmt den vorherigen "Received:"-Header. Das funktioniert natürlich nur, wenn der vorgelagerte Filter nicht aus einer Gruppe von Systemen besteht, die mehrere Header addiert:

PowerShell

Die gleichen Einstellungen können Sie natürlich per PowerShell setzen.

Set-InboundConnector `
   -Identity "Inbound Internet via NSP to O365" `
   -EFSkipLastIP $true `
   -EFUsers "test1@uclabor.de","test2@uslabor.de

Zum Testen bietet es sich an, diese Einstellung erst einmal nur für eine Teilmenge der Empfänger zu verwenden.

Testen

Der Header der nächsten eingehenden Mail sieht dann minimal verändert aus:

Authentication-Results: spf=pass (sender IP is 212.227.126.130)
 smtp.mailfrom=carius.de; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=carius.de;compauth=pass
 reason=100
Received-SPF: Pass (protection.outlook.com: domain of msxfaq.de designates
 212.227.126.130 as permitted sender) receiver=protection.outlook.com;
 client-ip=80.237.137.4; helo=212.227.126.130;
Received: from netatwork.cloud.nospamproxy.com (193.37.132.2) by
 AM5EUR03FT063.mail.protection.outlook.com (10.152.16.226) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 15.20.5017.26 via Frontend Transport; Mon, 7 Mar 2022 16:32:30 +0000
Received: from 80.237.137.4 by netatwork.cloud.nospamproxy.com via
 connector NSP Cloud-Connector (Tls12, Aes256, Sha384,
 DiffieHellmanEllipticKey384); Mon, 07 Mar 2022 16:32:27 GMT

Sie sehen, dass diese Mail nun von der IP-Adresse 80.237.137.4 bei NoSpamProxy eingeliefert und dann durch NoSpamProxy Adresse 193.37.132.2 an Exchange Online gesendet wurde. Exchange Online hat die Mail auch angenommen aber ignoriert nun diese Zeile, sondern wertet die Zeile davor aus. Exchange Online nutzt die Adresse 80.237.137.4, macht seinen SPF-Check und bekommt einen "PASS". Damit sollten weitere Prozesse, die z.B. das SPF-Ergebnis auswerten auch mit der Vorschaltung eines 3rd Party Relays besser funktionieren.

Defender schläft nicht

Bei der Einrichtung eines Inbound-Connectors im Kundenumfeld haben wir bei Testmails dennoch festgestellt, dass die Funktion anscheinend nicht gegriffen hat. Natürlich haben wir einen entsprechende Connector angelegt und "EFSkipLastIP" aktiviert. Dennoch sind Mails im Junk-E-Mail-Ordner gelandet. Der einzige Unterschied war ein leere Body bei der Junk-E-Mail. Im Header konnte man auch gut sehen, dass die Mail nicht die erwarteten Header hatte. Er sollte die 217.139.205.22 ignorieren und stattdessen die 212.227.126.130 (IONOS) als Source-IP auswerten.

Mail ohne Body nach Junk-E-mail Mail mit Body im Posteingang 
From: frank@carius.de
To: 'Test 01' test01@uclabor.de.de
Subject: Test 15:51 Cars->EXO
Date: Mon, 29 Aug 2022 15:51:41 +0200
Body: <null>
Authentication-Results: spf=fail (sender IP is 217.139.205.22)
 smtp.mailfrom=carius.de; dkim=none (message not signed)
 header.d=none;dmarc=fail action=oreject header.from=carius.de;
Received-SPF: Fail (protection.outlook.com: domain of carius.de does not
 designate 93.159.105.2 as permitted sender) receiver=protection.outlook.com;
 client-ip=93.159.105.2; helo=nsp.uclabor.de.net;
Received: from nsp.uclabor.de.net (217.139.205.22) by
 BE0DEU01FT008.mail.protection.outlook.com (20.128.125.134) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id
 15.20.5588.3 via Frontend Transport; Mon, 29 Aug 2022 13:51:44 +0000
X-EOPAttributedMessage: 0
X-MS-Exchange-Organization-MessageDirectionality: Originating
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-SCL: 5
 
From: frank@carius.de
To: 'Test 01' test01@uclabor.de.de
Subject: Test 15:52 Carius-> EXo
Date: Mon, 29 Aug 2022 15:52:11 +0200
Body: Das ist eine längere Testmail, um den Spamfilter zu befrieden
Authentication-Results: spf=pass (sender IP is 212.227.126.130)
 smtp.mailfrom=carius.de; dkim=none (message not signed)
 header.d=none;dmarc=pass action=none header.from=carius.de;compauth=pass
 reason=100
Received-SPF: Pass (protection.outlook.com: domain of carius.de designates
 212.227.126.130 as permitted sender) receiver=protection.outlook.com;
 client-ip=212.227.126.130; helo=212.227.126.130; pr=C
Received: from nsp.uclabor.de.net (217.139.205.22) by
 FR2DEU01FT022.mail.protection.outlook.com (20.128.124.107) with Microsoft
 SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id
 15.20.5588.3 via Frontend Transport; Mon, 29 Aug 2022 13:52:17 +0000
X-EOPAttributedMessage: 0
X-MS-Exchange-Organization-MessageDirectionality: Originating
X-MS-Exchange-SkipListedInternetSender: ip=[212.227.126.130];domain=212.227.126.130
X-MS-Exchange-ExternalOriginalInternetSender: ip=[212.227.126.130];domain=212.227.126.130
X-MS-Exchange-Organization-AuthAs: Anonymous
X-MS-Exchange-Organization-SCL: 1

Die Mails wurden sehr kurz aufeinander gesendet und die Konfiguration in der Zeit nicht verändert. Insofern kann die unterschiedliche Behandlung nur daran liegen, dass EOP/Defender die Mail schon vorher als "SPAM" ausgefiltert und daher gar nicht mehr einen SPF-Check durchgeführt hat. Die Richtlinie zu Defender (https://security.microsoft.com/antispam) für leere Meldungen war nicht aktiv.

Insofern ist das Verhalten nicht ganz nachzuvollziehen.

EFSkip und Zertifikate

Aus einem Microsoft Forum habe ich noch einen zweiten Fall, in dem "Enhanced Filtering" nicht zuverlässig funktioniert hat. Dies mal waren es Zertifikate:


Quelle: https://techcommunity.microsoft.com/t5/microsoft-defender-for-office/enhanced-filtering-for-connectors-not-working/m-p/2808783 

Ergebnis

Wenn Sie nicht auf den Spamfilter von Exchange Online vertrauen, sondern eine eigene 3rd Party Lösung wie NoSpamProxy z.B. für SMIME/PGP-Handling einsetzen, sollten sie "Enhanced Filtering" auf dem eingehenden Partner-Connector aktivieren. Sie helfen damit Exchange Online, die eingehenden Mails besser zu taggen, denn es ist leider nicht generell möglich, die eingehenden Verbindungen als unbeschränkt vertrauenswürdig zu konfigurieren. Mit aktiviertem "Enhanced Filtering" funktioniert aber zumindest die SPF-Prüfung auf Basis der IP-Adresse des vorherigen Hops. Der Automatismus funktioniert natürlich nur, wenn der vorgelagerte Filter nur genau eine "Received:"-Zeile addiert oder die Zwischenstationen mit "Privaten IP-Adressen" arbeiten und daher ignoriert werden. Ansonsten müssen Sie manuell alle IP-Adressen ihres Filters pflegen.

Weitere Links