Das Thema Spam ist schon wirklich lästig. Wen wundert es da, dass es dazu viele gute aber auch weniger gute Lösungsansätze gibt. Ein Lösungsansatz ist das Sender Policy Framework (SPF). Was das genau beinhaltet, werde ich hier mal versuchen zu beschreiben.

Funktionsweise

Die grundlegende Funktion ist relativ einfach. Eine Domain, über die Mails versendet werden sollen, erhält einen DNS Ressource Record des Typs TXT, der alle Mailserver auflistet, die zum Mailversand für diese Domain berechtig sind. Der Empfänger kann(!) diesen Eintrag verwenden, um die Echtheit zu überprüfen. Wenn eine Mail empfangen wird und der Empfänger feststellt, dass der sendende Server nicht in der Liste des angesprochenen TXT Records enthalten ist, wird die Mail verworfen.

Verbreitung

Es gibt keinen wirklich vereinheitlichten Umgang mit SPF. Es gibt große Provider, die SPF verwenden. Aber auch genau so viele, die das nicht tun. GMX, 1&1 und Web.de beispielsweise verwenden SPF. T-Online und Strato tun dies nicht.

SPF Record

Wie sieht ein solcher TXT Record aus?

Hier am Beispiel von GMX:

Unter Strings befinden sich die autorisierten MTAs (Message Transfer Agent) für die Domain gmx.de. Voran gestellt ist immer die Versionsnummer für die aktuelle SPF Version „v=spf1“. Wie sie sehen, können auch ganze Netze eingetragen werden.

Bei 1&1 wir das einfacher gestaltet:

Sie könnten auch alle Server Ihrer Domain zulassen.

Langlitz-it.de     TXT        299         Answer                               {v=spf1 include:langlitz-it.de -all}

Eine genaue Definition der SPF Records finden Sie hier.

Probleme bei Weiterleitungen

Bei Weiterleitungen von Mails ergibt sich das Problem, dass der weiterleitende Mailserver natürlich nicht in der Liste der ursprünglichen enthalten ist. Damit würde beim Empfänger die Mail wieder verworfen. Um das zu umgehen, kann sicher auf der Empfängerseite mit Whitelisting gearbeitet werden. Das stellt aber meist einen ziemlichen administrativen Aufwand dar.

Eine weitere Möglichkeit dieses Problem zu umgehen, ist das Sender Rewriting Scheme (SRS). Dabei wird der sogenannte Envelope im Header der Mail angepasst. Dies wiederum kann aber dazu führen, dass Fehlermeldungen nicht mehr zugestellt werden können. Damit nicht die Envelope Änderung dazu führt, dass doch wieder „gefälschte“ Absender genutzt werden, wird der SRS Adresse ein Hash voran gestellt. Ein typischer SRS Record stellt sich dann in der Form dar:

SRS0+xxxx=yy=host=absender@domain.xx

„xxxx“ steht für den Hash Wert und „yy“ für den Zeitstempel.

Die genaue Definition finden Sie hier.

Vorteile / Nachteile / Fazit

SPF bietet auf relativ einfache Art und Weise eine Möglichkeit, die Echtheit des Absenders zu prüfen. Die Herkunft einer Spammail lässt sich dadurch zwar nachverfolgen, einen wirklichen Schutz vor Spam bietet es aber meiner Meinung nach nicht. Denn was nutzt es mir, wenn per SPF gewährleistet ist, dass der Spamversand tatsächlich von einem für die Domain autorisierten Server kommt. Wenn zum Spammen „Wegwerfdomains“ verwendet werden und diese einen gültigen SPF Record erhalten, kann der Spammer fröhlich Mails versenden. Das Spammen über Open Relays allerdings kann durch SPF unterbunden werden.

Ein Vorteil ist aber auf jeden Fall, dass der Missbrauch der eigenen Domain verhindert werden kann. Allerdings setzt dies wieder voraus, dass der Empfänger auch tatsächlich das SPF Verfahren unterstützt.

Über Sender Policy Framework finden Sie weitere Information zum diesem Thema.