Sender Policy Framework

Sender Policy Framework (früher Sender Permitted From), kurz SPF, ist eine Technik, die das Fälschen des Absenders einer E-Mail auf SMTP-Ebene erschweren soll. Dazu wird in der DNS-Zone einer Domäne ein sog. Resource Record vom Typ TXT oder SPF mit Informationen darüber hinterlegt, welche Computer E-Mails für diese Domäne versenden dürfen. Anhand dieser Informationen soll nach RFC 4408 der Empfangs-Server dann sowohl die "MAIL FROM"-Identität als auch die "HELO"-Identität des Senders nachprüfen. Absenderangaben im E-Mail-Header werden nicht überprüft.

Im DNS-Eintrag einer Domäne sind bislang schon normale MX-Einträge vorhanden, die SMTP-Servern sagen, an welchen Host sie E-Mails für diese Domäne senden sollen. Wenn also ein SMTP-Server eine E-Mail an test@example.org schicken soll, sieht er im MX-Record von example.org nach, an welchen Server er die Mail schicken soll. Mit SPF wird nun ein Record im Stil eines Reverse-MX den DNS-Einträgen einer Domäne hinzugefügt. Empfängt ein Mailserver eine E-Mail mit einem Absender von example.org, sieht er im SPF-Record von example.org nach, ob der zustellende Mailserver laut SPF-Record dazu berechtigt ist, Mails für diese Domain zu versenden. Mit dieser Technik lässt sich die Fälschung von Absenderadressen effektiv verhindern. SPF kann so durch die leichtere Nachverfolgbarkeit von E-Mails auch zur Bekämpfung von Spam und zur Erschwerung von Phishing beitragen. SPF erhebt jedoch lediglich den Anspruch, Absenderadressfälschungen zu verhindern, nicht aber, direkt Spam zu bekämpfen.

SPF muss nur vom Empfängersystem unterstützt werden – am SMTP-Protokoll der Mailübertragung ändert sich nichts. Die Veröffentlichung von SPF-Records ist für eine Domäne freiwillig, Mails von Domains ohne SPF-Records sollen laut SPF-Spezifikation (RFC 4408) von Empfängern nicht negativ eingestuft werden; allerdings bleiben solche Domänen naturgemäß wie bisher gegen Umschlag-Adressfälschungen ungeschützt.

Aufbau eines SPF-Records

Jeder SPF-Records beginnt mit einer Versionsnummer — für die aktuelle SPF-Version "v=spf1". Es folgen beliebig viele Ausdrücke, die in der Reihenfolge von vorne nach hinten ausgewertet werden. Die meisten Ausdrücke sind dabei sog. Direktiven, welche die Autorisierung des Versenders definieren, und bestehen aus einem optionalen Qualifikator und einem sog. Mechanismus, der für eine gegebene Situation (IP-Adresse) entweder einen Treffer oder keinen Treffer ergibt. Der erste Mechanismus, der einen Treffer darstellt, bestimmt das Ergebnis der gesamten Auswertung des SPF-Records.

Es gibt folgende Qualifikatoren:

Q.	Ergebnis-Code	Beschreibung
`+`	`Pass`	die Direktive definiert autorisierte Sender; dies ist der Standard, d.h. ist kein Qualifikator angegeben, so wird `+` angenommen
`-`	`Fail`	die Direktive definiert nicht autorisierte Sender
`~`	`SoftFail`	die Direktive definiert nicht autorisierte Sender, der Empfänger soll diesen Fehlschlag aber großzügig behandeln; dieser Qualifikator ist für Testzwecke gedacht
`?`	`Neutral`	die Direktive definiert Sender, über deren Legitimität nichts ausgesagt werden soll; dieses Ergebnis muss vom Empfänger wie das gänzliche Fehlen eines SPF-Records behandelt werden

Folgende Tabelle zeigt einige gängige Mechanismen:

Mech.	Direktive trifft zu, wenn...
`all`	immer
`a`	...ein `A`-(oder `AAAA`-)Record der befragten (oder explizit angegebenen) Domäne die IP-Adresse des Senders enthält
`mx`	...ein `MX`-Record der befragten (oder explizit angegebenen) Domäne die IP-Adresse des Senders enthält
`ip4`	...die angegebene IPv4-Adresse die IP-Adresse des Senders ist bzw. das angegebene IPv4-Subnetz diese enthält

Einen Überblick über alle erlaubten Ausdrücke gibt die Unterseite SPF Mechanisms der SPF-Website.

Beispiel

$ host -t TXT gmx.de gmx.de text "v=spf1 ip4:213.165.64.0/23 -all"

Die Firma GMX legt also fest, dass alle Server im Netzbereich von 213.165.64.1 bis 213.165.65.254 E-Mails von der Domäne gmx.de verschicken dürfen. Alle anderen Server sind laut diesem SPF-Record nicht für die Benutzung dieser Domäne in der Umschlag-Absenderadresse autorisiert.

Status

SPF besteht in der Version 1 schon seit Ende 2003 größtenteils unverändert als informelle Spezifikation. Am 28. April 2006 wurde SPFv1 von der IETF als RFC 4408 veröffentlicht und ist damit endgültig in seiner Form festgelegt. Das RFC hat den Status "Experimental", da die im Vorlauf eingestellte MARID-Arbeitsgruppe der IETF mehrere zur Debatte stehende Verfahren bearbeitete, sich jedoch nicht auf eines der Verfahren einigen konnte.

Zu den bekanntesten Unterstützern von SPF gehören neben GMX auch Microsoft (Hotmail), AOL sowie GMail. GMX setzt SPF bereits seit April 2004 produktiv ein. Die anderen Provider haben im Laufe des Jahres 2004 nachgezogen. So gut wie alle Spamfilter nutzen SPF-Verifizierung zum Scoring eingehender E-Mail.

Viele Mailprovider bilden die SPF-Verifikation auch im Mailheader ab, zum Beispiel durch das Einfügen einer Zeile Received-SPF: pass (gmail.com: domain of foo@example.org designates 127.0.0.1 as permitted sender) oder X-Warning: SPF records of example.org exclude 127.0.0.2

Probleme bei Weiterleitung

Der Einsatz von SPF kann Probleme verursachen, wenn der Empfänger seine E-Mails an ein anderes Postfach weiterleiten lässt:

Wird eine E-Mail weitergeleitet, die von einer durch einen SPF-Record geschützten Domain stammt, so erkennt das Zielsystem, dass diese E-Mail von einem nicht vom Sender autorisierten System übermittelt wurde, und es wird die E-Mail als Nachricht mit gefälschter Absenderadresse betrachten.

Das Problem wird unterschiedlich gelöst, je nachdem, von wem die Weiterleitung ausgeht:

Geschieht die Weiterleitung im Auftrag des Empfängers, der etwa Mails verschiedener Konten auf einem sammelt, so kann dieser einfach auf die SPF-Prüfung von Mails der weiterleitenden Domains verzichten. Wenn er einen Provider hat, sollte dieser einen entsprechenden Auftrag zum Whitelisting durchführen. Sinnvollerweise sollten die weiterleitenden Systeme dann die SPF-Prüfung übernehmen.
Geschieht die Weiterleitung im Auftrag des Absenders und hat dieser die Möglichkeit und Fähigkeit, den DNS-Eintrag seiner Domäne zu bearbeiten, kann er im SPF-Record die weiterleitende Domäne als legitimen Versender für seine Domäne autorisieren. Dies ist jedoch oft nicht praktikabel, da der einzelne Absender etwa bei Domains mit vielen E-Mail-Konten keinen Zugriff auf den DNS-Eintrag besitzt und dieser auch mit dem Hinzufügen sehr vieler erlaubter Weiterleitungsdomains überlastet wäre. Für diese Fälle kann das Weiterleitungssystem die Umschlag-Absenderadressen der weitergeleiteten Mails auf seine eigene Domäne umschreiben und so die Verantwortung für die Gültigkeit der ursprünglichen Absenderadresse und für die Zustellung eventueller Bounces übernehmen. Ein solches Verfahren ist z.B. das Sender Rewriting Scheme. Auch hier muss sichergestellt sein, dass das weiterleitende System eine wirksame SPF-Prüfung vornimmt.

Kritik

SPF zählt zu den am kontroversesten diskutierten Verfahren im Bereich der Adressfälschungs-Abwehrmechanismen. In der Tat wirft der großflächige Einsatz von SPF für Administratoren wie Endbenutzer gleichermaßen einige Probleme auf:

Bevor die oben beschriebenen Verfahren zur Ermöglichung der E-Mail-Weiterleitung installiert sind, wird es Probleme damit geben.
Das Integrieren dieser Verfahren in eine bestehende Infrastruktur kann erhebliche Probleme bereiten. Allerdings schreibt ein Großteil der verwendeten Mailinglistensoftware bereits von sich aus die Umschlag-Absenderadresse um, z.B. per Variable Envelope Return Path (VERP). Dies zeigt, dass die Probleme keineswegs unlösbar sind.
Viele Menschen wollen ihre privaten E-Mail-Adressen aus dem Netz ihres Arbeitgebers, ihrer Universität etc. nutzen. Dazu müssen sie entweder einen SMTP-Server des externen Providers oder des Netzes benutzen. Ersteres wird oft durch die Firewall/den Proxy des Netzes unterbunden. Das Zweite wird mit der Einführung von SPF praktisch unmöglich gemacht. Die Benutzer müssten nämlich die Netz-Mailserver im SPF-Record ihrer privaten E-Mail-Domain (z.B. gmx.de) als erlaubte Absender autorisieren. Dazu sind sie im Allgemeinen weder fähig noch (durch den Provider) befugt. Dies betrifft auch z.B. Netze in Wohnheimen, Bürgernetzen u. dergl. SPF-Befürworter wenden dagegen ein, dass genau dies die eigentliche Zielsetzung von SPF ist: Der Besitzer einer Domäne (also im Beispiel GMX) soll kontrollieren können, über welche Systeme Mails im Namen seiner Domäne versendet werden können.
Die leichtere Identifizierung von Absendern ist der Grund, dass SPF von polizeilichen Ermittlungsbehörden im Rahmen der TKÜV forciert wird. Kritiker sprechen in diesem Zusammenhang auch von einem "Zwangsrelay" über den jeweiligen Provider und befürchten einen Machtzuwachs des Staates, der die Gefahr eines Überwachungsregimes erhöht.
Ein Benutzer mit mehreren E-Mail-Adressen (ohne administrativen Zugang auf die entsprechenden Domänen) wird immer auch mehrere zugehörige Postausgangsserver verwalten müssen, was Arbeit macht, Wissen erfordert und einen geeigneten E-Mail-Client voraussetzt. Diesen kann man allerdings heutzutage voraussetzen.
Obwohl SPF ein eigener DNS-Record-Typ zugewiesen wurde und die SPFv1-Spezifikation die Unterstützung dieses SPF-Record-Typs vorsieht, benutzt SPFv1 aus historischen Gründen hauptsächlich DNS-Records vom Typ TXT. So konkurriert SPF mit anderen TXT-Records um den begrenzten Platz in DNS-UDP-Antwortpaketen, was bei insgesamt zu großen TXT-Records eines DNS-Namens dazu führen kann, dass die UDP-Antwort auf eine TXT-Anfrage die vorhandenen TXT-Records nicht vollständig enthält.
Eine häufige Kritik ist auch, dass das System gegen Spam sowie Malware nur schlecht greift, da Spammer vermehrt "Einwegdomains" und die Email-Systeme gekaperter "Zombie-Computer" mit deren korrekten SPF-Records verwenden. So zeigen Studien, dass ein großer Teil der existierenden Domains mit SPF-Record Spammern gehören. Diese Kritik geht jedoch fehl, da SPF nicht als Spam- bzw. Malware-Bekämpfungsmaßnahme, sondern lediglich als Maßnahme gegen Adressfälschung entwickelt wurde.

Weblinks

Die SPF-Website mit technischen Erläuterungen und Hinweisen für DNS-Administratoren (engl.)
Onlinecheck von DNS-Einträgen, der auch das Vorhandensein von SPF-Records prüft (engl.)
RFC 4408: Sender Policy Framework, Version 1 (engl.)

Kritik:

Siehe auch

E-Mail