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.
Kommentare
51 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.