Mittlerweile kennt sie wohl jeder: Spam und Phishing Mails, die offensichtlich von Kollegen stammen. Untersuchungen zeigen, dass Mails von vermeintlich vorgesetzten Personen deutlich unkritischer behandelt werden als von Fremden. Und oftmals bleibt alles, was die Nutzer über Phishing Mails gelernt haben, auf der Strecke, wenn ein Buchhalter eine Mail bekommt, in der der Chef spät abends in kurzen Worten schreibt, dass dringend eine Forderung für einen Zulieferer beglichen werden muss. Ansonsten droht der Firma am nächsten Morgen schon eine Klage und schlimmstenfalls Insolvenz. Es wird noch kurz die Absender Adresse geprüft und ja, die Mail kommt vom Chef, also wird pflichtbewusst die Firma gerettet und man macht brav Überstunden, um die Zahlung fristgerecht anzuweisen…
Möglicherweise werden Sie jetzt sagen: Das passiert uns nicht, die Mitarbeiter sind auch für solche Fälle geschult und mehrfach instruiert worden, immer wachsam zu sein. Aber für speziell dieses Dilemma gibt es auch technische Lösungen, die leider nur selten umgesetzt werden. Kurz:
Ein Mailserver sollte von „extern“ keine Mails annehmen, die als Absender eine eigene (=akzeptierte) Domäne vorgeben.
Doch wie erreicht man das? Und wie schafft man Ausnahmen, so dass etwa das Kontaktformular auf der eigenen Webseite auch noch funktioniert?
Auf die harte Tour
Nutz die Firma einen Exchange Server, so kann der zum öffentlichen Internet zeigende Konnektor unter Umständen so konfiguriert werden, dass eigene Domains als Absender abgelehnt werden. Dies geht sinngemäß wie folgt:
Get-ReceiveConnector "Internet" | Get-ADPermission -user “NT-AUTORITÄT\ANONYMOUS-ANMELDUNG” |
where {$_.ExtendedRights -like “ms-exch-smtp-accept-authoritative-domain-sender”} | Remove-ADPermission
Ausnahmen gibt es in diesem Szenario keine, bzw. man benötigt weitere Konnektoren.
Auf die smarte Tour
Durch das Auswerten eines SPF Eintrags für die eigenen Domains, zusammen mit der Löschung von Mails, die nicht SPF konform eingehen, lässt sich elegant der gleiche Effekt nutzen. Leider setzen viele Mailserver SPF nur sehr zaghaft um und nutzen „Fail“ und „Soft-Fail Direktiven“, um die Mails als Spam zu taggen, bzw. beziehen das in den allgemeinen SPAM Score ein. Prüft Ihr eigener Mailserver „hart“ und verwirft Mails bei einer „Fail-Condition“, dann haben Sie, falls Sie einen entsprechenden SPF Record der eigenen Domäne gesetzt haben, bereits Ihr Ziel erreicht. Die Mail eines Fremden, der Ihre Domain missbraucht, um im Namen des CEO an den Buchhalter zu schreiben, wird nicht zugestellt – Die Gefahr ist gebannt!
Aber auch, wenn Sie Mails bei SPF Fehlern generell nicht löschen wollen oder können, so können Sie über eine Transportregel zumindest Mails mit der eigenen Domain als Absender trotzdem löschen! Über diesen zusätzlichen Schritt können Sie in jedem Fall das korrekte Auswerten der SPF Einträge für ihre eigene Domain erzwingen, unabhängig von den allgemeinen SPF Einstellungen.
Ausnahmen sind in diesem Szenario durch Erweitern des SPF Records leicht möglich. Ein ordentlicher SPF Record sollte ja per se den Webserver, der ein Kontaktformular bereitstellt, oder andere Onlinedienste, die Mails versenden müssen, enthalten.
