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 Whitelisting 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.

EFSkipLastIP

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. Ich kann 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.

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