gmx.de und web.de haben Mail-Rejects durch SPF
Unter Mailserver-Experten ist die Technik "Sender Policy Framework" (SPF) seit Jahren umstritten. Ich selbst bezeichne SPF seit über 10 Jahren als "Bullshit und Broken by Design" und es gibt eigentlich keinen Provider, der SPF tatsächlich "hart" einsetzt. Lediglich GMX und mittlerweile auch web.de finden SPF eine tolle Sache -- und überraschten die Mailserver-Community vor einigen Tagen damit, dass E-Mails, die SPF verletzen, neuerdings hart von den GMX und web.de-Mailservern abgelehnt werden. In der Folge laufen seitdem User bei den Hotlines und Support-Teams anderer (!) Provider sturm und beschuldigen diese -- völlig zu unrecht! --, ihre Mailserver nicht im Griff zu haben -- bis hin zu wütenden Kündigungen. Dabei können die anderen Provider gar nichts dafür -- aber das müßte man erstmal (aufwändig) den GMX und web.de-Kunden erklären. Ein extrem unschöner und unkollegialer Zug der Kollegen von GMX und web.de, der in den verschiedenen Postmaster-Mailinglisten heiß und verärgert diskutiert wird.
Warum ist SPF "Bullshit und Broken by Design"?
Angesichts der Tatsache, dass immer wieder Spam mit gefälschten Absendern versendet wird und/oder Nutzer eines Providers mit Phishing-Attacken angegriffen werden, scheint das auf den ersten Blick eine gute Sache zu sein. Über SPF-Records im DNS kann der Besitzer einer Domain festlegen, welche Mailserver E-Mails mit seiner Domain ausgehend versenden können sollen. Also: Von welchen Mailservern diese Domain als Absender genutzt werden darf. So lautet der SPF-Record von Heinlein Support beispielsweise:
heinlein-support.de. IN TXT "v=spf1 ip4:213.203.238.0/25
ip4:195.10.208.0/24 mx include:jpberlin.de ?all"
Ein typischer SPF-Record listet also die zugelassenen Netzbereiche auf -- und endet mit der Festlegung, wie mit E-Mails zu verfahren ist, die von anderen Mailservern stammen. Hier gibt es vier Möglichkeiten in SPF:
- +all Alle anderen Mailserver dürfen auch für diese Domain versenden.
- -all Alle anderen Mailserver dürfen nicht mit dieser Domain versenden.
- ~all Alle anderen Mailserver sollten nicht für diese Domain versenden. Sprich: Die Mails sollten nicht geblockt werden, aber mit entsprechenden negativen Scorings in die Spam-Filterung eingehen.
- ?all Über alle anderen Mailserver wurde keine Aussage getroffen; weder positiv noch negativ.
Von Problemen betroffen sind nun die E-Mails der Absender, deren Administrator über ein "-all" den Versand von anderen Mailservern aktiv und gezielt verboten hat. Das sind die E-Mails, die nun von GMX und web.de abgelehnt werden: Weil der Absender das so will und das explizit im SPF so eingetragen hat! Insofern muß man klipp und klar sagen: Der Wille des Absenders wird umgesetzt und darüber kann sich folglich eigentlich keiner beschweren. Nur versteht das kaum jemand -- in der Regel noch nicht mal der besagte Absender, der sich zuerst beim Drittprovider beschwert, weil seine eigenen E-Mails nicht mehr an GMX & web.de versandt werden können. Nun liegt es in der Natur der Sache, dass ausgerechnet GMX und web.de ihrerseits die zwei größten Anbieter sind, die "-all" für die eigenen Domains gelistet haben -- und so trifft es ausgerechnet Kunden von GMX und web.de, deren eigene Mails als unzustellbar zurückkommen -- beispielsweise weil diese nach einer Weiterleitung zufällig zurück an ein GMX/web.de-Postfach gesendet werden sollen.
Wer "-all" einträgt muss mit Mailverlust leben wollen
Heinlein Support warnt seit jeher davor ein "-all" einzutragen -- aus den hier genannten Gründen. Allenfalls "?all" oder -- wenn man als sehr lukratives Phishing-Opfer besonderen Schutz bedarf -- ein "~all". Denn: Von welchem Mailserver eine Domain ausgehend kommen darf, kann nicht zuverlässig festgelegt werden. Ein "-all" kann nicht zuverlässig funktionieren. Wer ein "-all" verwendet, wird immer damit leben müssen (und wollen) daß Mails verloren gehen. Schon die Grundidee "ein Absender kommt zuverlässig von bestimmten Servern" ist falsch -- und damit "broken by design". Die Urväter des SMTP haben diesen Umstand erkannt und darum vor gut 30 Jahren absichtlich keine Absender-Verifikation festgeschrieben.
Absender können immer auch von anderen Mailservern kommen
So können Mails
- ...von einem User von Provider A an sein Postfach bei Provider B weitergeleitet werden Diese Weiterleitungen lassen den Absender ("Envelope-From") aus guten Gründen unangetastet.
- ...von einer Mailingliste an eine Vielzahl von Empfängern verteilt werden Hier wird der Envelope-Absender i.d.R. auf die Mailingliste zeigen, das Header-From jedoch unangetastet bleiben.
- ...Absender aus anderen technischen Gründen oder durch Webformulare von anderen Mailservern kommen.
In allen diesen Fällen erhält der Mailserver des Providers B plötzlich E-Mails des Ursprungsabsenders von den Mailrelays des Providers A. Ein harter SPF-Check muss hier zur Ablehnung führen -- und genau das passiert derzeit reihenweise. Mit dem Erfolg, dass der unschuldige Provider A den ganzen Erklärungs- und Supportaufwand zu leisten hat. "Schuld" ist hier wahlweise der Absender der Domain X, der die harten SPF-Kriterien schließlich extra gesetzt hat, oder der Empfänger B (alias GMX/web.de) der die SPF-Kriterien hart anwendet, obwohl die Probleme bekannt sind.
Üblicherweise fließt SPF allenfalls "weich" ein
Verschiedene Anti-Spam-Systeme werten SPF-Records aus und bewerten einen Verstoß gegen die SPF-Records entsprechend. Üblicherweise fließt ein solcher SPF-Bruch jedoch nur "weich" in das Gesamtergebnis ein und führt nicht gleich zur Ablehnung der gesamten E-Mail. Die bekannte Anti-Spam-Engine "SpamAssassin", die defacto als Grundlage in vielen Anti-Spam-Systemen enthalten ist, bewertet SPF-Fehler logischerweise auffallend milde:
score SPF_HELO_PASS -0.001 score SPF_FAIL 0 0.919 0 0.001 # n=0 n=2 score SPF_NEUTRAL 0 0.652 0 0.779 # n=0 n=2 score SPF_SOFTFAIL 0 0.972 0 0.665 # n=0 n=2
Spam-Assassin-Scores sind darauf ausgelegt ab einem Wert von 5 bis 6.31 Punkten einen Spam-Alarm auszulösen. SPF-Verletzungen hier hier mit deutlich unter 1 Punkt (oder sogar Null Punkten) bewertet werden sind nie im Leben dazu geeignet, alleine deswegen schon eine Mail zu blocken, dazu bedarf es immer auch erhebliche Mengen weiterer Faktoren (=Spam-Score-Punkte). GMX und web.de haben stattdessen an dieser Stelle den "harten reject" eingeführt. Man kann getrost sagen, daß das entgegen jeder "Best Practice" des Internets ist.
Warum SRS das Problem nicht löst
Um das Problem von Weiterleitungen & Co. zu lösen wurde das System "Sender Rewritung Scheme" (SRS) erfunden, das im Übrigen noch nicht mal RFC-Standard ist. Danach soll im Falle einer Weiterleitung bei Provider A der ursprüngliche Envelope-Absender X auf eine bestimmte kodierte Mailadresse von Provider A umgeschrieben werden: Sehr vereinfacht ausgedrückt: "domainx=user@domainA", also eine Art "Mailadressen-NAT". In der Folge würden nun die SPF-Records der Domain A gelten und Server A könnte die Mails auch wieder versenden.
Doch SRS hat ebenfalls zahlreiche Probleme
- Es gibt keine funktionierenden direkten SRS-Implementierungen in SMTP-Standardsoftware wie Postfix. Obwohl seit 10 Jahren immer wieder nachgefragt, hat Postfix-Erfinder Wietse Venema diesbezügliche Ansinnen stets abgelehnt. Kurz gefaßte Begründung: Weil's Bullshit by Design ist und er kein Bullshit by Design implementiert. -Dem kann man nur zustimmen.
- Unklar ist, wie bei mehrfachen Weiterleitungen zu Verfahren ist. Was passiert, wenn der Empfänger bei B seinerseits auf Domain C weiterleitet? Zugegeben: Grundsätzlich kann diese SRS-Umschreibung immer wieder erfolgen. Aber praktisch bricht hier bei Kettenweiterleitungen über kurz oder lang das Chaos aus.
- Wie und auf welchen Weg sollen Bounces und andere Unzustellbarkeitsmeldungen "rückabgewickelt" werden? Soll die Kette rückwärts wieder aufgedröselt werden?
Wer schon länger im Netz dabei ist, kann sich noch sehr gut an die zahlreichen "Gateway-Konvertierungen" aus den 1990er Jahren erinnern: Maus-Netz, Fido, Z-Netz und andere Systeme hatten SRS-ähnliche Systeme an ihren gegenseitigen Netzwerkübergängen installiert, um die zueinander inkompatiblen Absender "zu NATen". Das hat schon damals nicht funktioniert und zu entsprechendem Ärger geführt, dass wirklich jeder Ende der 1990er froh war, als dieses kranke System endlich in der Bedeutungslosigkeit versank. Wenn heute alte Netzprofis SRS hören, kommen furchtbar schlimme Alpträume von früher wieder hoch. Die mangelhafte Implementierungsverbreitung von SRS könnte man durch Aktivitäten heilen; den technischen Ärger, den man sich dadurch ins Haus holt, will man nicht haben. Wäre SRS (und SPF) sinnvoll, hätte es in den letzten 10 Jahren wesentlich umfangreichere Verbreitung gefunden.
Warum SPF übrigens gar nicht gegen Phishing schützt...
Leider wurde bei SPF noch nicht mal genau festgelegt, auf welchen Absender sich SPF eigentlich beziehen soll: So besitzen E-Mails u.a. einen "Envelope-From" auf Transport-Ebene und ein "Header-From" der eigentlich nur dem Nutzer angezeigt wird und der sonst nicht weiter von belang ist -- und der durch SRS übrigens auch nicht umgeschrieben wird. Wenn SPF jedoch nur den für den Nutzer unsichtbaren Envelope prüft und den für den Nutzer sichtbaren Header ungeprüft läßt und SRS diesen auch nicht umschreibt -- wie soll SPF dann vor Absenderfälschungen und Phishing schützen?!
Was wirklich hilft: DKIM
Die ganze leidige SPF-Diskussion ist vor allem deshalb so frustrierend, weil mit der Technik "Domain Keys Identified Mail" (DKIM) eine Lösung zur Verfügung steht, die ebenfalls den Mißbrauch von Absendern wirkungsvoll einschränken kann (und nebenbei sogar noch die Unverfälschtheit der Mail sicherstellt). DKIM führt dazu eine Crypto-Signatur im Mailheader ein, also eine digitale Unterschrift des Mailservers. Dieser DKIM-Header ist nicht an die IP-Adresse gebunden und bleibt auch bei Weiterleitungen problemlos erhalten, solange die Mail unverändert ist (und das ist ja sehr positiv). Ähnlich wie beim SPF-Record kann der Domainbesitzer auch hier über DMARC festlegen, dass seine Mails wirksam DKIM-signiert sein müssen und wie mit Mails zu verfahren ist, denen diese Signatur fehlt. Mehr dazu im unten genannten Vortrag von uns.
Warum machen GMX und web.de das?
Tja, die Frage ist schwierig zu beantworten. Irgendwie hat SPF bei GMX und (weil es der gleiche Konzern ist) bei web.de einen guten Stand. Schon vor knapp 10 Jahren gab es am Rande des Anti-Spam-Summits des IT-Branchenverbands ECO im Schloß Biebrich Wiesbaden beim Social Event mit Rotwein und Fingerfood in der hessischen Staatskanzlei eine hitzige Diskussion zu SPF zwischen acht Postmastern der großen Provider, der ich beiwohnen durfte (naja: ich habe sie angezettelt). In Sachen SPF gab es nur einen einzigen Führsprecher: der Kollege von GMX. Und der beendete die durchaus sehr kompetent geführte Fachdiskussion nach einer guten Dreiviertelstunde mit den für mich unvergesslichen Worten: "Ja, SPF geht nicht, wir machen es aber trotzdem!" Wirklich so gesagt und geschehen. Und da kann man dann nicht mehr diskutieren oder irgendwas verstehen wollen. Seitens GMX und web.de wird vermutlich auf SRS verwiesen und die Schuld (fast allen) anderen Providern zugeschoben, die halt bitteschön SRS hätten implementieren sollen. Nun, das ist ein Standpunkt und deren gutes Recht. Jedoch nicht viele Kollegen und Mailserver-Experten teilen diese Auffassung. Ergänzungshinweis: Unser Vortrag "SPF, DKIM & Co" geht der Sache ebenfalls auf den Grund und erklärt auch, warum DKIM im Unterschied zu SPF funktioniert...
UPDATE 3. Juni 2016: "-all" wurde zu "~all" abgemildert
Die Sache hat am Donnerstag Abend eine lustige Wendung genommen. Denn nun haben GMX und web.de plötzlich für ihre eigenen Domains die strikte SPF-Policy "-all" (must not) auf "~all" (=should not) abgemildert. Das ist insofern bemerkenswert, als das GMX und etwas später auch web.de das "-all" bereits seit vielen Jahren in ihrem SPF-Setup führen. Warum hier diese Aufweichung der eigenen SPF-Policy erfolgt ist mir darum gerade unklar, denn zumindest GMX hat Mails mit eigenen Absendern, die von außen kamen, schon "immer" abgelehnt, daran sollte die vor einigen Tagen stattgefundene Änderung eigentlich gar nichts verändert haben. Um das klarzustellen: Mails von Domains, die "-all" gesetzt haben, werden weiterhin abgelehnt. Nur setzen selbst GMX und web.de plötzlich kein "-all" mehr ein... Alles in allem ergibt sich nun also die ironische Situation, dass GMX und web.de entgegen der "Best Practice" in einer Nacht- und Nebelaktion ihre SPF-Checks scharf schalten und den Rest des Netzes ins Chaos laufen lassen -- gleichzeitig in eigener Sache die vorhandene SPF-Policy plötzlich abmildern um anscheinend selbst dem grundsätzlichen Ärger aus dem Weg zu gehen. Oder anders herum formuliert: Auch wenn das initiale "-all" natürlich Sache des Admins der Absenderdomain ist, schrotten GMX und web.de durch die ungewöhnlich harte SPF-Auswertung weiterhin sehenden Auges Mails anderer Domains und ihrer Nutzer und haben nun aber klammheimlich dafür gesorgt, dass sie selbst diese Konsequenzen nicht mehr tragen müssen.
Weitere Beiträge zum Thema
Enterprise Mail-Security mit Open-Source?
Enterprise Mail Security with Open Source?
Kommentare
53 Antworten zu gmx.de und web.de haben Mail-Rejects durch SPF
@Andreas G.
Was ist gegen "v=spf1 mx a ?all" einzuwenden?
"mx a" ist absolut korrekt für Server, wo Hosting und Mail auf dem selben Server, also der selben IP liegen. Oder meinst du "?all"? Nicht konsequent, klar, aber wirklich tragisch ist das jetzt auch nicht.
Jupp, ich hätte einen Einwand. Per se gefällt mir "v=spf1 mx a ?all" sehr gut, und ich wäre auch dafür, dass fehlende SPF-Records implizit als "v=spf1 mx a ?all" (vllt. sogar auch mit ~all oder -all am Ende) interpretiert werden sollten.
Das Problem hierbei besteht darin, wie sich der a-Mechanismus im Zusammenspiel mit gemischten Infrastrukturen verhält, wo IPv4 und IPv6 im Spiel sind, aber ein Teil der Border-MTAs Monostack ist.
In diesem Fall wird zunächst geschaut, ob die Emails, um die es gerade geht, per IPv4 oder per IPv6 reinkommen. Dann wird für die im a-Mechanismus referenzierte Domain ein A- oder AAAA-Record abgerufen, jeweils passend zu der verwendeten Protokollversion. Wenn in diesem Record eine IP drin steht, dann wird diese für die SPF-Prüfung herangezogen und das SPF gibt dann ein Ergebnis aus.
Wenn die DNS-Abfrage hingegen als Ergebnis „No such Record“ zurückgibt, dann hat man im SPF-Record einen nicht existierenden anderen Record referenziert. Genau das ist aber verboten - mit der Folge, dass die Auswertung des SPF-Records abgebrochen wird und die Mailannahme mit einem Softbounce und einer Fehlermeldung „Malformed SPF Record“ o. ä. abgebrochen wird.
Will heißen: Ob ein SPF-Record korrekt formatiert ist, hängt davon ab, ob die Mail per IPv4 oder per IPv6 reinkommt.
Ich wäre dafür, dass dieser Unsinn abgeschafft wird und ein „No such Record“ beim a-Mechanismus schlichtweg dahingehend interpretiert wird, dass es für die betreffende IP keinen Match gibt.
Bis sich diese Erkenntnis bei der IETF durchgesetzt hat, arbeite ich mit folgendem Workaround:
spf 86400 IN TXT "v=spf1 include:_spf6.example.net include:_spfdual.example.net -all exp=_explanation.explanation.net"
_spf6 86400 IN TXT "v=spf1 -ip4:0.0.0.0/0 a:vi.example.net -all"
_spfdual 86400 IN TXT "v=spf1 a:zweibruecken.example.net -all"
_explanation 86400 IN TXT "Thou shalt not impersonate thy neighbour."
Durch diese Konfiguration wird dem Monostack-Server vi.example.net ausdrücklich verboten, Mails per IPv4 zu verschicken, obwohl er im übrigen Mails zustellen darf. Dies hat zur Folge, dass IPv4-Adressen nicht mehr darauf geprüft werden, ob sie zur Adresse von vi.example.net passen.
Nach meinem Dafürhalten schadet diese enge Interpretation der SPF-Spezifikation sowohl der VErbreitung von IPv6 als auch der VErbreitung von SPF und sollte korrigiert werden.
Auch wenn dieser Artikel alt ist, hat er immer noch Relevanz. Ich bin erstaunt das GMX SPF als so wichtig sieht, aber dann bei den Maildomains die man ja dort kaufen kann und dann über ihre Platform laufen, KEINEN SPF Record haben. DNS bei GMX, Mail bei GMX, aber nix SPF ?!?! Wäre doch ein leichtest ein include:gmx.net als Wert für die Vorlage in deren System zu definieren. So ist der der die Domain die man vielleicht schon seit Jahren hat, zu GMX moved und dann erstaunt feststellt das man kein SPF mehr hat und der Support es auch nicht adden kann (weil die nicht mal wissen was es ist).