Know How: SPF, Sender Policy Framework

SPF versucht SPAM dadurch zu bekämpfen, indem die sendenden MTAs für eine Domain autorisiert werden.

• de.wikipedia.org/wiki/Sender_Policy_Framework
  
• www.openspf.org/SPF_Record_Syntax
  
• www.openspf.org/RFC_4408
  

Probleme

• Remailer (Mailing-Listen) funktionieren nicht mit SPF, da dann der aussendende MTA nicht für die Domain des From zuständig ist. Es gibt komplizierte Rewriting-Regeln, mittels denen man Mailing-Listen so umschreiben kann, dass SPF mit ihnen funktioniert. Diese Lösung ist aber schlimmer als das eigentliche Problem.
• SPF kann somit eigentlich den Header-From nicht sinnvoll prüfen. Leider wurde versäumt, den MAIL FROM im Tranport-Header per SPF prüfbar zu machen.
• SPF muss sofort beim Empfang geprüft werden. Somit schlagen DNS-Probleme voll beim Empfänger durch. Außerdem kann man den empfangenden MTA somit stark beeinträchtigen (DoS-Attacke). Sollte z. B. ein SPF-Problem mit einer Domain von der Domain gemeldet werden, werden diese Meldungen ggf. wegen der SPF-Probleme abgelehnt.
• Aussenden von SPAM mit gültigem SPF ist trivial.
  
• SPF kann SPAM also nicht bekämpfen. Es kann aber wirksam genutzt werden, um Backscatter zu bekämpfen. (Backscatter sind eMails die eintreffen, weil der From missbraucht wurde.) Leider wurde aber genau das bis heute nirgendwo implementiert (nicht einmal Google macht es).

SPF implementieren

In der Domain fügt man eine SPF-Record hinzu. Für die Aussendung von xxx@example.com fügt man in die Zone example.com folgendes ein:

(Statt TXT kann man auch SPF verwenden, sofern der Nameserver das in der Zone verträgt.)

Hinter dem Magic "v=spf1" kann man per Leerzeichen getrennt folgende Angaben einfügen die aus zwei Teilen besteht, einem Präfix (Qualifikator) und einer Angabe (Mechanismus):

Präfixe:

• +: (Default wenn der Präfix fehlt.) "Pass", d. h. die Angabe gibt autorisierte Sender an, die eMail muss akzeptiert werden.
• -: "Fail", die Angabe gibt nicht autorisierte Sender an. Was in diesem Fall passiert darf der Empfänger entscheiden.
• ~: "Softfail", die Angabe definiert nicht autorisierte Sender, aber der Empfänger soll die eMail trotzdem großzügig akzeptieren. Ansich nur für Testzwecke.
• ?: "Neutral", die Angabe gibt Sender unbekannter Legitimität an, die eMail muss trotzdem akzeptiert werden.

Angaben (/prefix ist bei Default das Maximum, :domain ist bei Default die abgefragte Domain):

• all: Alles, d. h. gilt immer
  
• a:domain/prefix: Der Sender ist ein A- oder AAAA-Eintrag in der Zone. Siehe "dig a example.com."
• mx:domain/prefix: Der Sender ist ein MX-Eintrag in der Zone. D. h. "dig mx example.com."
• ip4:i.p.n.r/prefix: Die IP-Nummer fällt in den angegebenen Bereich.
• ip6:ip6addr/prefix:: dito. ip6addr ist eine IPv6-Adresse in der üblichen hex-Schreibweise mit : und :
• ptr:domain: Die IP wird reverse aufgelöst, mit Verifikation. Einer der überlebenden Namen muss auf die Domain enden.
• exists:domain: Die angegebene Domain muss auflösbar sein. (Siehe: Makros)
• include:domain: Füge den TXT-Record der angegebenen Domain ein. Wenn der Include fehlschlägt ist SPF undefiniert. Der Prefix gibt an, wie ein "Pass" verarbeitet werden soll.

Ausßerdem kann man folgende Angabe einmalig angeben:

• redirect=domain: Mache mit SPF-Eintrag an dieser Stelle weiter.
• exp=domain: Lies den TXT-Record an dieser Stelle. Bei Ablehnung der eMail steht der zu vermeldende Fehler dort.

Makro-Expansion: www.openspf.org/RFC_4408#macros

• %%: %
  
• %-: %20
  
• %_: Leerzeichen
  
• %{s}: Sender (xxx@example.com)
  
• %{l}: User (xxx)
  
• %{o}: Sender-Domain (example.com)
  
• %{d}: Domain (meistens o, man kann in Direktiven aber die Domain ändern, z. B. bei Include usw.)
• %{i}: Client-IP, immer in "."-Format (auch für IPv6), damit man es in Domains (reverse) verwenden kann
• %{p}: PTR der Client-IP (wenn der PTR auf den Namen zurückmappt)
• %{v}: "in-addr" wenn IPv4, ip6 bei IPv6
  
• %{h}: Angabe von HELO/EHLO
  
• %{c}: Client-IP für Menschen (nur für exp=) bei IPv4 dasselbe wie i, bei IPv6 die normale Schreibweise
• %{r}: Eigener Hostname (nur für exp=)
  
• %{t}: Timestamp (nur für exp=)
  

Man kann in die geschweiften Klammern noch folgendes hinten anfügen:

• Zahl: Gibt den Domain-Level an, 1 ist also TLD, 2 ist SLD usw.
• r: "Reverse", d. h. die Dot-Notation wird umgekehrt geschrieben (für ir).

SPF prüfen

Während man SPF recht einfach in die Domain eintragen kann, ist das Parsen von SPF-Records die Hölle.

Syntax-Fehler sind permanente(!) Fehler, die meistens zur Ablehnung von eMail führen. DNS-Resolver-Probleme können ebenso permanente(!) Fehler sein (z. B. wenn ein DNS gerade rebootet, die Domain noch nicht kennt da sie noch nicht geladen ist, und somit sagt, sie ist nicht existent).

Dieser Text ist zu lang

Das bedeutet, SPF ist vermutlich zu kompliziert.

-Tino, 2009-07-07