mta Archive - IT KnowHow für jedermann/frau

Wer einen eigenen Mailserver ohne SPF betreibt, kennt das Problem zur Genüge: Spammer versenden Mails mit der eigenen Domain darüber bzw. Empfänger erhalten Mails, die wir nie losgeschickt haben. Spamschutz auf dem Mailserver ist ein sehr sensibles Thema, denn bei allem Schutz willst du unbedingt vermeiden, dass versehentlich eine gute Mail abgefangen wird. Aus diesem Grund sind heutige Spamschutzmechanismen ziemlich konservativ. In dieser Artikelreihe soll es daher darum gehen, was du dagegen tun kannst und wie das funktioniert. Der erste Artikel beschäftigt sich mit dem Sender Policy Framework. Um zu verstehen, wie SPF wirkt, beschreibe ich erst einmal den grundsätzlichen Ablauf beim Transfer einer Email anhand einer kleinen Zeichnung: Mailversand schematisch Um die Adresse des für die Maildomain des Empfängers zuständigen Mailservers herauszufinden, macht Mailserver A eine Anfrage beim DNS-Server (Domain Name Server) und erhält dort die Adresse von Mailserver B. Darin ist keinerlei Schutz gegen Spam enthalten. SPF ist ein Eintrag im DNS, der darüber informiert, welche(r) Mailserver für eine Maildomain zustellen dürfen. Dieser Mechanismus muss daher auf Empfängerseite geprüft werden: SPF mit erfolgreichem Mailversand Hier sendet A wieder an B. A erhält vom DNS-Server die Adresse von Mailserver B. B prüft im DNS vor dem Akzeptieren der Mail, ob Mailserver A für Maildomain A überhaupt Mails senden darf. Erst dann nimmt Mailserver B die Mail an. SPF mit gescheitertem Mailversand Im oberen Beispiel versucht Mailserver X eine Mail zuzustellen. Im DNS steht aber, dass für Maildomain A nur Mailserver A zustellen darf. Mailserver B wertet den SPF-Record aus und verwirft den Zustellungsversuch von Mailserver X daher. Das Sender Policy Framework ist also genau genommen nichts Anderes als ein kleiner DNS-Eintrag des Typs TXT, in dem steht, welche Mailserver Mails für eine Domain ausliefern dürfen. Sender Policy Framework ist ein sehr wirksamer Schutz gegen Spam. Leider hat er keine allzu hohe Verbreitung und ist daher auch nicht zwingend erforderlich. Ein empfangender Server, der Mails auf SPF überprüft, wird daher Maildomains ohne diesen Eintrag klaglos annehmen. Der einfachste Weg, um für eine DNS-Domain SPF zu implementieren, ist das Anlegen eines TXT-Records in der forward-Zone in Form des folgenden Eintrags vspf1 mx -all Der Eintrag besagt, dass für die domain NUR die MX-Server (also die mail exchanger!) zustellen dürfen und sonst keiner (-all). Auf http://www.openspf.org/SPF_Record_Syntax finden sich weitere Beispiele für die Syntax des SPF-Records, die weit über unser Beispiel hinausgehen. Als kurze Erklärung zum MX-Record: Dies ist ein spezieller Eintrag im DNS, der darüber informiert, an wen Mails für die entsprechende Domain zu senden ist. Im Fall von SPF wird der MX-Record dazu verwendet auszuwerten, von wem eine Mail kommen darf :-) Dieser Artikel deckt nicht ab, wie sich der empfangende Mailserver durch SPF-Auswertung schützt. Dies ist auf den unterschiedlichen Mailservern absolut abhängig vom Produkt. Für weitere Infos zum Sender Policy Framework empfehle ich auch den Eintrag bei Wikipedia: https://de.wikipedia.org/wiki/Sender_Policy_Framework.

Schlagwort: mta

Mailserver-Spamschutz mit SPF