PHP Blogger

Startseite Schreib mir ne Mail! RSS Abo Webnews

Newsletterversand mit SPF legitimieren

Das faszinierende an meinem Job ist, das man immer wieder etwas dazulernt. Schön ist natürlich, wenn das so nebenbei passiert.

Nur so zum Hintergrund: Ich konfiguriere die DNS-Einträge aller meiner (Kunden)-Domains manuell über Bind, das seit etwa 3 Jahren. Ist vielleicht etwas mehr Arbeit, als eine Klickibunti-Oberfläche, aber man hat eben alle Möglichkeiten. Letzte Woche meinte ein Freund, dass man fremde Mailserver zum Versand über einen MX-Eintrag autorisieren kann. (Ich hab das mal wehement abgestritten ;) Und natürlich direkt gegoogelt, an jeder Behauptung ist ja meist was dran…

Das Zauberwort heisst SPF (”Sender Policy Framework“, früher mal “Sender Permitted From”). Und ist übrigens kein MX-Eintrag, sondern genaugenommen ein TXT-Vermerk. Kurzgefasst kann man mit diesem Eintrag bestimmte (fremde) Mailserver definieren, die im Namen der Domain Mails verschicken können, und andere Mailserver (u.A. per Wildcard) ausschließen.

Schon seit 2006 gibts das RFC 4408, das alle Features genau beschreibt. Wie bereits erwähnt, ist das ganz praktisch, wenn man Mails von einem Webserver aus verschickt, dessen MTA nicht der zur Domain passende MX ist. Fallbeispiele: Von Notification-Mails über Formular-Mails bis hin zu Newslettern alles denkbar.

Prinzipiell ist es möglich, von jedem SMTP Server eine Mail von jeder beliebigen E-Mail-Adresse zu schicken. Was ja auch viele Spammer machen. Viele Hoster haben ihre Mailserver in Kombination mit Spam-Scannern so scharf eingestellt, das die versendeten Mails nur von autorisierten SMTP Servern kommen dürfen. Die T-Com greift hier zum Beispiel rigoros durch. Wer solche Kontrollen durchführt berücksichtigt meist (d.h. muss nicht unbedingt sein) den SPF Kommentar in einem DNS-Datensatz.

Und so schaut so ein Teil für Bind aus:

@		IN	TXT	"v=spf1 mx -all"

Dieser Eintrag erlaubt z.B. nur das Senden von den eingestellten MX-Servern. Wer den Webserver noch zusätzlich autorisieren möchte, baut das wie folgt um:

@		IN	TXT	"v=spf1 a mx -all"

Zu dem Thema gibt es viel Literatur, deshalb gehe ich hier nur in Kürze auf die Syntax ein und schildere viel lieber noch weitere Möglichkeiten. Die Links zu Howtos und Generatoren findet Ihr am Ende de Artikels…

Man kann z.B. weitere Hosts auf IP- oder Namens-Basis freischalten, Subdomains (hilfreich bei verteiltem Hosting), ganze oder Teil-Netzwerke (hilfreich bei Loadbalancern und Serverfarmen) und MX-Server anderer Domains.

Am Ende ist Euch sicherlich “-all” am Ende aufgefallen: Das bedeutet, das Mails, die von einer anderen Domain kommen, als Spam markiert werden sollen. Es gibt noch eine Abschwächung (”~all”), die eher als eine Empfehlung interpretiert werden kann, allerdings meist den Spam-Score trotzdem ordentlich hochdreht.

Probleme beim Formularversand

Häufig ist es vom Kunden gewünscht, das Formulare die auf einer Website ausgefüllt werden, per Email an eine zuständige Person oder ein bestimmtes Postfach weitergeleitet werden. Meist implementiert man dann eine Funktion, die checkt, ob derjenige, der das Formular ausgefüllt hat, auch eine E-Mail-Adresse hinterlegt hat. Wenn das der Fall ist, setzt man die E-Mail-Adresse als Absender der Formular-Mail ein.

Das widerspricht natürlich allen SPF Regeln und wird (meiner Meinung nach zu Recht) als Spam gewertet. Trotzdem sollte man beim Einführen von SPF für eine Domain an die Konsequenzen denken: Eventuell verschimmeln auf diese Art versandte Kontakt- oder Bestellformulare in Spam-Ordnern.

Weiterführende Links

SPF-Generator (engl.)
Offizielle SPF-Website (engl.)
Bruno Sousa zum Thema SPF
Hetzner Wiki zum Thema SPF

Ähnliche Artikel:

  1. Newsletter Queue mit PHP
  2. Per Windows Batch Mails versenden
  3. Die Mailq neu anschubsen
  4. Mailversand simulieren
  5. PHP Mailer Update: miniMail V1.3

Schreib Deine Meinung