Sender Policy Framework

aus Wikipedia, der freien Enzyklopädie

Du hast neue Nachrichten (Unterschied zur vorletzten Version).

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.

[Bearbeiten] 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.

[Bearbeiten] 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.

[Bearbeiten] 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. Eine Reihe großer Provider wie T-Online, Web.de, Yahoo hat bis heute (Juli 2006) noch gar keinen SPF-Record veröffentlicht. Andere, wie Arcor, nutzen die unklaren Qualifikatoren „Softfail“ oder „Neutral“.

So gut wie alle Spamfilter nutzen SPF-Verifizierung zum Scoring eingehender E-Mail. Hierfür sind auch die Qualifikatoren „Softfail“ und „Neutral“ verwendbar.

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

[Bearbeiten] Probleme bei Mail-Umleitung

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

Das empfangende System sieht die Domain des Absenders aber die IP-Adresse des umleitenden Systems. Diese wird i.A. nicht vom Absender als erlaubt gekennzeichnet sein. Bei einer SPF-Prüfung wird eine solche Mail wegen Absenderfälschung abgelehnt.

Das Problem hat zwei Lösungen:

Der Empfänger verzichtet einfach auf die SPF-Prüfung von Mails der umleitenden Domains, die ihm ja bekannt sind. 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. Ein Nachteil dieses Verfahrens ist, dass im Falle eines Zustellungsfehlers die Fehlermeldung (Bounce) direkt an den Absender gesandt wird. Dieser könnte so von der Zieladresse der Umleitung erfahren, was u.U. vom Empfänger unerwünscht ist.
Dieses Problem wird vermieden, wenn das Weiterleitungssystem die Umschlag-Absenderadressen der umgeleiteten Mails auf seine eigene Domäne umschreibt und so die Verantwortung für die Gültigkeit der ursprünglichen Absenderadresse und für die Zustellung eventueller Bounces übernimmt. Ein solches Verfahren ist z.B. das Sender Rewriting Scheme (SRS). Es muss allerdings sichergestellt sein, dass das weiterleitende System eine wirksame SPF-Prüfung vornimmt, was z.Zt. nicht immer der Fall ist.

[Bearbeiten] 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:

Endbenutzer haben i. A. keine Ahnung von der Existenz von SPF und der Notwendigkeit, bei Umleitung Whitelisting einzuschalten. Vor der weitgehenden Verwendung von SRS werden also viele Benutzer sich irrtümlich selbst von E-Mails aus SPF-geschützten Domains abschneiden. Das kann für diese ein Wettbewerbsnachteil sein.
Das Integrieren dieser Verfahren in eine bestehende Infrastruktur kostet Zeit und Geld, es geschehen Fehler, die kosten wieder Zeit und Geld.
Viele Menschen wollen ihre privaten E-Mail-Adressen aus dem Netz ihrer Arbeitgebers, ihrer Universität etc. heraus nutzen. Dazu müssen sie entweder einen SMTP-Server des externen Providers oder des Netzes benutzen. Ersteres wird aus Sicherheitsgründen teilweise 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 authorisieren. Dazu sind sie im Allgemeinen weder fähig noch (durch den Provider) befugt. Dies betrifft auch z. B. Netze in Wohnheimen, Bürgernetzen und dergleichen. 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. Eine mögliche Lösung ist für die Firewall-Admins, Port 587 — SMTP Submission zu öffnen, der nur authentifizierte Verbindungen erlaubt und damit sicher ist.
Kritiker sprechen im Zusammenhang von SPF auch von einem „Zwangsrelay“ über den jeweiligen Provider und befürchten in diesem Zusammenhang einen Vorteil für sowohl staatliche Überwachungsstellen als auch private Datensammelstellen. Speziell SPF hat in diesem Kontext die Eigenschaft, dass keine örtliche Verteilung des Postausgangsverkehrs mehr auftritt: So laufen z. B. bei einer GMX-Adresse nun sowohl Posteingangs wie auch Postausgangsverkehr immer über die hauseigenen GMX-Server und ermöglichen somit potentiellen Überwachern und Data-Minern ein einfaches Erfassen des gesamten E-Mail-Verkehrs an einer zentralen Stelle.
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 und Wissen erfordert.
Obwohl SPF mittlerweile ein eigener DNS-Record-Typ zugewiesen wurde und die SPFv1-Spezifikation die Unterstützung dieses SPF-Record-Typs vorsieht, benutzen viele Domains noch 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. Das Problem wird sich mit zunehmendem Übergang auf den dedizierten SPF-Record gelöst haben.
Eine häufige Kritik ist auch, dass das System gegen Spam sowie Malware nur schlecht greift, da Spammer vermehrt „Einwegdomains“ und die E-Mail-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. Das kann man jedoch umgekehrt als Erfolg von SPF bezeichnen - Open Relays und Open Proxies fallen als Spamquellen aus, die Spamwege sind leichter zurückzuverfolgen. Ob dieser Nutzen den Aufwand überwiegt, ist eine Frage des Standpunktes.
Unklare Positionierung von SPF: Die Entwickler von SPF weisen gerne darauf hin, dass SPF kein Spamschutz per se, sondern lediglich ein Schutz vor Adressfälschungen darstellt. Dafür allein ist SPF jedoch nur sehr unzureichend geeignet, da die Granularität der Adressprüfung prinzipbedingt nur ganze Domains umfasst (und keine Individuen) und auch keinerlei kryptographische Sicherheitsmechanismen die Authentität des sendenden Rechners (oder gar des Senders) an sich sicherstellen. Damit stellt SPF keinen Adressschutz, sondern lediglich eine Art von Relay-Schutz dar.