Sender Policy Framework

Sender Policy Framework (SPF) wurde entwickelt, um Spam-Mails zu vermeiden. Im Kern geht es darum, das Fälschen von Mailadressen zu verhindern und so zu unterbinden, dass Adressen unberechtigterweise benutzt werden können. Nach wie vor fallen unbedarfte Nutzer auf Werbemails oder solchen mit Schadsoftware herein, SPF soll gerade solche User vor Angriffen schützen.

Allgemeine Informationen zum Thema

Technische Grundlage für SPF ist der Eintrag des Mailinhabers in das Domain Name System (DNS). Damit wird er berechtigt, Mails überhaupt zu versenden. Das Ziel ist die Unterbindung der missbräuchlichen Nutzung durch Dritte. Innerhalb der DNS-Zone hinterlegt der Domaininhaber einen Resource Record als .txt-Datei und legt so fest, von welchen Rechnern aus Mails verschickt werden können. Wenn eine Mail beim Empfänger eingeht, wird geprüft, welche Domain im Feld „Mail from“ bzw. HELO angegeben wurde. Dies geschieht über „Mail Transfer Agents“ (MTA).

Nachdem die SPF-Daten aus dem DNS abgerufen wurden, werden sie mit der eingetragenen IP-Adresse und der gestatteten MTA verglichen. Die Mail wird als authentisch eingestuft, wenn diese übereinstimmen, ist das nicht der Fall, wird die Mail verworfen.

Bei näherer Betrachtung kann SPF Spam nicht verhindern, verbessert jedoch die Nachverfolgbarkeit von Mailadressen erheblich.

SPF und Probleme bei Weiterleitungen

Eine der Grenzen von SPF zeigt sich, wenn Mails weitergeleitet werden. Denn der Server, der die Weiterleitung verantwortet, ist in der Liste von SPF nicht aufgeführt, sodass die Mail normalerweise verworfen wird, obwohl sie gar nicht als Spam eingeordnet werden kann bzw. soll. Um dieses Problem zu umgehen, kann der Mailempfänger mit Whitelisting arbeiten, allerdings stellt diese Methode bei starkem Mailaufkommen einen administrativ recht hohen Aufwand dar.

Man kann dieses Problem auch mit „Sender Rewriting Scheme“ (SRS) behandeln. Bei diesem Verfahren wird der Envelope im Header der Email angepasst. Als unerwünschter Nebeneffekt können unter Umständen Fehlermeldungen nicht mehr zugestellt werden. Um zu verhindern, dass die Änderung bei Envelope zu weiteren gefälschten Mails führen, erhält die SRS-Adresse einen Hash. So ein SRS Record kann wie folgt aussehen (wobei das „xxxx“ für den Hash wert steht und das „yy“ für den Zeitstempel:

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

Somit kann die Echtheit des Absender geprüft werden.

Alternative von Microsoft

Um Phishing und anderen Phänomenen zu begegnen, reicht SPF nicht aus. Daher entwickelte Microsoft im Jahr 2004 eine Erweiterung namens „SenderID“, die sich zum Ziel machte, zusätzlich die in der Regel angezeigten Kopfzeilenadressen zu authentifizieren. SenderID definiert eine neue Absenderadresse unter der Bezeichnung „Purported Responsible Address“ (PRA), das sich aus vier unterschiedlichen echten Kopfzeilen ableitet:

1. Resent-Sender
2. Resent-From
3. Sender
4. From

Der Mehrwert von Sender-ID ist allerdings übersichtlich, denn auf Fälschung geprüft wird lediglich die Resent-Sender-Adresse. Weil aber die wenigsten Mail-Clients diese (oder auch die Umschlagadressen) anzeigen, können Fälscher die Adressen ungefälscht belassen oder eine Domain verwenden, die ungeschützt ist, um so die für den Benutzer sichtbaren Kopfzeilenadressen zu unterlaufen.

Bis SPF entwickelt wurde, bestand die Spambekämpfung vorwiegend aus DNS-Blacklists, die mit Hilfe unterschiedlicher Kriterien IP-Adressen überprüft und gegebenenfalls als Spam eingestuft haben. Dem Erfolg dieser Methode waren jedoch Grenzen gesetzt, da Botnetze, die aus kompromittierten Endbenutzerrechnern bestanden, die Methodik der IP-Adressen-basierten Reputationssysteme einschränkten. Denn neue und unverbrauchte IP-Adressen können Versender von Spam einfach und kostengünstig bekommen. In diesem Punkt war die Entwicklung von SPF ein Fortschritt, da es authentifizierbare Absenderdomains beinhaltete und somit ein Sprungbrett zu domainbasierten Reputationssystemen war. Die einfachste Variante hier sind die sogenannten „Right-Hand-Side Blacklists“ (RHSBLs, „rechte Hand des @“). Dabei handelte es sich um das Äquivalent zur klassifizierten Blacklist. RHSBLs klassifizieren bösartige oder gutartige Absender, bezogen auf Domains. Der Vorteil dieser Methode liegt in der Tatsache, dass Domains für Spammer schwerer zu beschaffen und teurer sind.

SPF und Weiterleitungen

Das Problem der weitergeleiteten Mails, das oben genannt wurde, besteht auch weiterhin, kann jedoch auf zweierlei Wegen umgangen werden. Erstens, indem die weitergeleitete Mail mittels Whitelisting von der SPF-Prüfung ausgenommen wird (was einen recht hohen Aufwand bedeuten kann). Ratsam ist hier die Prüfung durch die weiterleitenden Systeme. Zweitens kann das umleitende System die Mail, die weitergeleitet werden soll, auf seine eigene Domain umschreiben und so den Absender verändern.

Bedeutung für das Development

Zwar lässt sich durch SPF recht einfach prüfen, ob eine Mail von einem echten Absender kommt, die Herkunft einer Mail lässt sich also nachverfolgen. Spam vermeiden lässt sich durch SPF aber nur bedingt, die Empfänger von Mails bleiben also weiter in der Verantwortung, genau darauf zu achten, was für Mails sie bekommen und wie sie diese behandeln.

Funktionieren kann SPF zudem nur, wenn auch die betroffenen Endbenutzer Kenntnis davon haben. Das trifft in besonderem Maße auf umgeleitete Mails zu, wenn Nutzer plötzlich keine Mails mehr erhalten, weil sie nicht über die Notwendigkeit des Whitelistings Bescheid wissen.

Der wohl eindeutigste Vorteil des SPF ist die Verhinderung des Missbrauchs der eigenen Domain. Das setzt jedoch erneut voraus, dass auch der Empfänger das Verfahren SPF unterstützt.

Weblinks

• Der Sinn von einem Sender Policy Framework (SPF) Record
• Sender Policy Framework (SPF): Wie es funktioniert und wann man es nicht nutzen sollte
• Sender Policy Framework (SPF)