Office365: Spoofing eigener Mail-Adressen erlauben

Wenn man einen anderen Mail-Server E-Mails, die von Adressen aus der eigenen Domäne stammen, an die in Office365-verwalteten Konten bzw. dieselbe Domäne schicken lässt, dann wird man ein Problem mit dem standardmäßig vorgegebenem Spoofing-Filter bekommen. Worum es sich dabei handelt und was man tun kann, zeige ich in diesem Artikel.

Was bedeutet Spoofing?

Spoofing bedeutet im Prinzip, dass ein anderer als der autorisierte Server versucht E-Mails von Adressen aus zu versenden, die eigtl. vom eigenen Mail-Server verwaltet werden. Dies könnte z. B. kritisch sein, wenn jemand über einen gehackten oder im Ausland befindlichen Mail-Server einfach E-Mails mit der Original-Mail-Adresse des Geschäftsführers mit kritischen Anweisungen an Mitarbeiter schickt und dabei für diese alles so aussieht, als hätte wirklich der Geschäftsführer die betroffenen Mails geschickt. Deshalb macht es Sinn, wenn eine solche Prüfung durchgeführt wird und solche täuschenden Mails als Junk eingestuft oder gemüllt werden. Im Normalfall sollen die E-Mail-Adressen ja auch nicht von anderen als dem eigenen Server bzw. Office365 genutzt werden.

 

Sonderfall

Allerdings kann es nötig sein, wenn z. B. ein Teil der Mail-Konten (noch) nicht bei Office365 verwaltet wird oder aus irgendeinem Grund von irgendwelchen anderen Servern Mails mit diesen an interne Mail-Konten verschickt werden sollen, dass ein Spoofing dieser Adressen erlaubt ist, damit von diesen Adressen ausgehend E-Mails an in Office365 befindliche Mail-Konten geschickt werden können. Denn ansonsten würde bei diesen der Spoofing-Filter greifen und die Mails zurecht als Junk klassifizieren.

 

Spoofing-Konfiguration

Wenn man dafür keinen Connector nutzen möchte oder kann, durch welchen Office365 als „Relay“ genutzt werden würde um die Mails selber zuzustellen, dann hat man (bisher) eigentlich nur folgende Einstellungsmöglichkeit in Office365 unter dem Punkt „Office 365 Security & Compliance“ > „Bedrohungsmangement“ > „Richtlinie“ und dann unter dem Punkt „Antispam“:

Dort kann man, wenn man den letzten Punkt „Spoofingintelligenzrichtlinie“ ausklappt, die „bereits überprüften“ oder „neue Absender“ anzeigen lassen und fürs Spoofing freigeben oder sperren. Die jeweilige Übersicht sieht dann wie folgt aus:

Den gelb markierten Text kann man übrigens vergessen. Dieser suggeriert zwar, dass man irgendwo detaillierte Einstellungen für die Spoofing-Quellen vornehmen könnte, was vllt. die Möglichkeit einen Server grundlegend als Spoofing-Quelle zu erlauben einschließt. Diese Option existiert aber einfach nirgends! Zumindest bisher, oder ich bin blind.

Man kann zwar Spoofing generell erlauben, was aber definitiv keine gute Idee ist. Denn dadurch dürfte JEDER die Adressen der Domain spoofen und es würde kein Verdacht auf eine illegale Nutzung aufkommen, wenn von irgendeinem anderen unbekannten Server E-Mails von der eigenen Domain ankommen. Dies ist also definitiv keine Option!

Wenn man eine ganze Reihe an Mail-Adressen hat, die von einem anderen Server aus gespooft werden sollen, dann bleibt einem als Vereinfachung nur diese mit einem Skript alle mehrfach nacheinander zu nutzen, damit diese alle möglichst bald in der Spoofing-Übersicht in Office365 auftauchen und dort (leider) alle manuell bestätigt werden müssen, wie zuvor gezeigt.

 

Dies habe ich z. B. für einen lokalen Exchange-Server bzw. einen Postfix-Server, von dem aus gespooft werden darf, mit folgendem Powershell-Skript bewerkstelligt:

Kurze Erläuterung: Man gibt in der Variable „mail_from_senders“ als Array alle Mail-Adressen an, die der lokale Mail-Server in Office365 spoofen können soll, in „mail_rcpt“ eine beliebige in Office365 befindliche Mail-Adresse als Empfänger und in „PSEmailServer“ den lokalen SMTP-Server. Danach durchläuft das Skript alle angegeben Sender-Adressen und verschickt über den definierten Mail-Server mittels des Powershell-Befehls „Send-MailMessage“ Test-E-Mails. Nicht wundern, die Veriable für den zu nutzenden Mail-Server muss im Kontext des „Send-MailMessage“-Befehls nicht noch explizit angegeben werden.

Damit dies funktioniert muss natürlich der Computer, auf dem das Skript ausgeführt wird, berechtigt sein über den lokalen Mail-Server per SMTP zu senden. Dies kann man beispielsweise bei einem Exchange-Server bei den Empfangsconnectoren einstellen oder man führt das Skript direkt auf dem Server aus.

 

Fazit

Entgegen dem Beschreibungstext in Office365 gibt es leider nicht die Möglichkeit einfach einen Quellserver komplett für das Spoofing der Domäne freizugeben.

Falls man es hinbekommt, kann man wohl auch per Azure-Powershell Einstellungen in Office 365 vornehmen und hat dabei eventuell auch die Möglichkeit das Spoofing durch einen Quellserver grundlegend zu erlauben. Mir ist dies leider nicht gelungen und ich habe einfach keinen Login hinbekommen und diesen Ansatz somit wieder verworfen, weshalb ich mir den zuvor aufgezeigten Lösungsweg überlegt habe 🙁

Dieser hat aber zumindest für meine Zwecke funktioniert.

 

Schreibe einen Kommentar