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

Lange Zeit habe ich die spezielle Funktion "Enhanced Filtering" nicht benutzt, weil ich über einen eigenen "Inbound Connector" z.B. die Zustellung meines davor betriebenen "NoSpamProxy"-Servers gesteuert habe. Über einen Partner Connector habe ich die meisten Spam/Phishing-Filter von EOP deaktiviert. Vor einigen Jahren hat Microsoft aber auch noch die Funktion SRS (Sender Rewriting Scheme) addiert, so dass Mails von extern, die über meine Exchange Umgebung an eine andere externe Adresse gehen, entsprechend umgeschrieben werden. Die FROM-Adresse wird so angepasst, dass meine Domain erscheint und damit der finale Empfänger einen SPF-Check machen kann.

Nun kann es aber passieren, dass die eingehende Mail von A vielleicht gefälscht ist. Würde Exchange auf "B" nun die SRS-Logik-aktivieren, dann würde System C die Mail mit einem "SPF:Pass" annehmen. Aus dem Grund aktiviert Exchange z.B. die SRS-Umschreibung nur, wenn das  einliefernde System per SPF (aber nicht DKIM) bewertet wurde. Das kann aber auch auch dazu führen, dass die Mail beim Empfänger "C" abgelehnt wird, da der Server B natürlich nicht in der SPF-Allow-Liste für die Domains von Server A steht.

Vieleicht sehen Sie nun, dass SPF alleine nicht ausreichend ist, sondern Absender A auf jeden Fall die Nachrichten mit DKIM kennzeichnen sollte, damit Empfänger C die trotz SPF-Fail annimmt.
SRS wird von Exchange nur aktiviert, wenn die Mail von A zu B per SPF validiert werden konnte.

The main change is for messages that fail SPF checks when they are sent to Office 365. SRS will no longer fix these failures
Quelle: Sender Rewriting Scheme (SRS) in Office 365 https://docs.microsoft.com/en-us/office365/troubleshoot/antispam/sender-rewriting-scheme

Unschön wird dies aber nun , 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, 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 217.139.205.22 (IONOS) als Source-IP auswerten.

Mail ohne Body nach Jun-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