Zurück zur Suchliste

01.06.2016 - Fachbeitrag

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.

spf-weiterleitungen 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

Mein Liebster SPF Eintrag ist "v=spf1 mx a ?all".
Hat jemand mal als "SPF ist mir egal Record" bezeichnet.

Hallo Peer,

wie lege ich am denn am sinnvollsten fest das meine Mails mit DKIM signiert sein müssen. Ich nutzte DMARC habe aber mittlerweile gelernt es für DMARC reicht wenn entweder SPF oder DKIM oder beide korrekt sind. Wenn ich also einen gültigen SPF Record verteile wäre DMARC auch immer gültig selbst wenn die Mail nicht DKIM signiert ist. Oder habe ich da was falsch verstanden?

Wunderbarer ausführlicher Artikel. Auch wir bei mail.de erhalten einige Beschwerden, "E-Mails gehen verloren, ich verklage euch!", uns wird mit Kündigung gedroht “wenn wir das Problem nicht auf der Stelle beheben!!” usw.

Ich habe versucht auf United Internet einzuwirken und sie vor der SPF-Check-Aktivierung auf die Probleme hingewiesen. Heutzutage macht man DKIM, oder SPF+DKIM=DMARC. SPF allein ist keine gute Idee, aus oben genannten Gründen (Mailinglisten + Weiterleitungen).

SRS machen nur wenige Provider. Das könnte, wie oben beschrieben, daran liegen dass weder Postfix noch Dovecot (Sieve-Weiterleitungen) das unterstützen. Auch aus unserer Sicht ist es korrekt, bei einer Weiterleitung die E-Mail unangetastet zu lassen. Selbst wenn wir den unsichtbaren Envelope-From ändern würden, könnte der From-Header, der dem Nutzer angezeigt wird, beliebig gesetzt werden. SPF hilft also nicht gegen Phishing oä!

Mit DMARC bekämpft man Phishing. DMARC prüft den sichtbaren From-Header, und erst wenn SPF + DKIM fehlschlagen, dann soll eine Sonderbehandlung stattfinden. Bei korrekt konfigurierten Mailinglisten und Weiterleitungen bleibt die DKIM-Signatur erhalten, ein SPF-fail darf dann vorkommen.

Ich hoffe auf ein Einsehen von United Internet, dass SPF allein keine gute Idee ist, und zusätzlich DKIM und DMARC umsetzt werden sollte, um wirksam gegen Phishing zu kämpfen. Nur SPF allein bringt keinen Vorteil, nur Probleme…

Scheinbar werden PTR Einträge bei 1&1 nicht berücksichtigt. Bei den Kunden und Domains die bei uns Probleme haben greifen die PTR Einträge im SPF Record nicht. Die Diskussionen über den Sinn von SPF, DMARC, DKIM oder DNSSEC sind eine Sache. Ich finde es viel wichtiger, dass man da was man einsetzt auch richtig konfiguriert. Meine Erfahrung ist, dass SPF,DKIM und DNSSEC oft falsch konfiguriert oder umgesetzt wird.

Danke, damit hast du mir und einigen meiner Kunden gerade den Tag gerettet.

Kunden Probleme mit Mail-Servern zu erklaeren ist wohl einer der groeszten Zeitfresser, weil die meisten denken, das waere wie bei der Post - ich schick den Brief ab und der kommt beim Empfaenger an. Das zwischendurch zig mal in den brief reingeschaut wird, der Absender und Empfaenger umgeschrieben werden kann und ich in einem kleinen standardbrief keinen Bleiblock mitsende(E-Mail als file transfer protokoll ist ja leider auch immer noch sehr beliebt...), das ist halt einfach zu hoch fuer die Endanwender..

Am Ende sollten wir wohl einfach darauf hinarbeiten, dass emails, wie wir sie heute kennen, abgeschafft werden. Das System ist alt, fragil und wir muessen staendig neue Bodges und Pflaster bauen, damit es uns nicht ganz um die Ohren fliegt...

Die Einträge in den SPF-Records sind Vorwärtslookups, also A-Records im DNS, nicht PTR (Reverse DNS). Ich nehme aber an, das meintest Du. :-) Ob 1&1 die Namen nicht auswertet kann ich nicht bestätigen, habe ich nie getestet aber so auch noch nicht gehört. Wäre mir jetzt auch nicht plausibel.

Wir haben die SPF Records unserer Kunden mit ip Einträgen versehen, was das Problem mit 1&1 umgeht. Komischerweise haben wir bisher keine großen Probleme gehabt. Wir nutzen ptr seit einigen Jahren und bei unseren Kunden konnte bisher jede dusselige Antispam Appliance mit diesen Einträgen umgehen. Der Nachteil ist ein erhöhtes DNS Aufkommen. Was aber bei allen Implementierungen entsteht. Egal ob SPF, DKIM, DMARC, DNSSEC oder was auch immer. Wir werden unsere Kundendomains überprüfen und gegebenenfalls die ptr Einträge durch ip4 und ip6 Einträge ersetzen. Das sorgt dann zwar für weniger DNS Abfragen, aber für sehr viel größere SPF Einträge mit mehreren includes.

http://www.openspf.org/SPF_Record_Syntax

The "ptr" mechanism

ptr
ptr:
The hostname or hostnames for the client IP are looked up using PTR queries. The hostnames are then validated: at least one of the A records for a PTR hostname must match the original client IP. Invalid hostnames are discarded. If a valid hostname ends in domain, this mechanism matches.

If domain is not specified, the current-domain is used.

If at all possible, you should avoid using this mechanism in your SPF record, because it will result in a larger number of expensive DNS lookups.

Examples:

"v=spf1 ptr -all"

A domain which directly controls all its machines (unlike a dialup or broadband ISP) allows all its servers to send mail. For example, hotmail.com or paypal.com might do this.
"v=spf1 ptr:otherdomain.com -all"

Any server whose hostname ends in otherdomain.com is designated.

Hallo Peer,

schöner Beitrag, über den ich gestolpert bin, weil mich Bekannte angesprochen haben, dass meine Mail-Adresse nicht mehr funktioniert.

Als ich (nachdem natürlich erst mal mein Provider behelligt wurde) mit dem GMX Premium Support telefonierte bekam ich auch den Rat, einfach auf Sammeldienst umzustellen.

Leicht gesagt und für mich als technikversierten vielleicht noch machbar. Aber GMX befördert mich mit dieser Aktion zum Familien-Mailprovider wider willen.

Da ich derjenige bin, der die Familien-Domain hostet bin ich bisher zwar schon der Admin bzgl. neuer/geänderten Adressen, was sich in Punkto Aufwand aber sehr in Grenzen hält, da ich bisher lediglich eine Weiterleitung an die Wunschadresse anlegen oder bearbeiten musste.

Wir sind aber eine sehr große Familie, so dass da schon jetzt ein Sümmchen an Adressen zusammenkommt. Sobald die jüngeren Kids größer werden rücken mittelfristig etliche neue Adressen nach.

Statt wie bisher jede einzelne Adresse "name@familiendomain.de" einfach an den ausgesuchten Mailprovider (viele sind bei GMX) weiterzureichen soll ich jetzt - wenn die Privatsphäre auch weiterhin geschützt bleiben soll - jedem einzelnen ein Postfach auf meinem Server einrichten und die Mails dort erst mal vorhalten, bis sie abgeholt werden.

Muss dabei natürlich aufpassen, dass mein Domänenprovider dann nicht auch schon Spams ausfiltert, muss aufpassen, dass mein Speicher nicht zuläuft, muss Hilfestellung geben, wenn der Sammeldienst spinnt, muss...

Ein Rattenschwanz an Verantwortlichkeiten, Verbindlichkeiten und Aufwänden, den ich bisher nicht hatte, weil alles einfach durchgereicht wurde. Aus einer wirklich einfachen Sache hat GMX so eine Verwantwortungsvolle (,unbezahlte) Aufgabe gemacht :-(

Ein Aspekt, der auch in deinem Beitrag nicht unberücksichtigt bleiben sollte.

Gruß
Markus

GMX hätte Dir auch empfehlen können alle Briefe auszudrucken und per Post rauszusenden. Wäre das nicht auch ein genauso "guter" Workaround gewesen?

Aber das Problem ist doch woanders. Warum wird denn hier schon wieder der Bock zum Gärtner gemacht.

Familienmitglieder haben Postfächer bei GMX. Sie verlieren damit wissentlich E-Mails. Das ist deren mehr oder weniger bewußte, aber eben doch deren eigene Entscheidung. Ich sehe keinerlei Grund warum Du etwas machen mußt um mit bewußten eigenen Entscheidungen anderer Leute klarzukommen. Wer das als Empfänger so haben will, der kann das haben; wer das nicht will, der sucht sich bitte einen anderen Provider.

Danke für den Artikel!

Bemerkt hab ich das Problem am Montag, als sämtliche Mails von ikea.com nicht bei GMX ankamen. Die Bounce Mail zerschellten dann am donotreply@.. :P

Ich leite jetzt die Mails von meiner Namensdomain statt direkt auf GMX über GMail um, wo sie dann wiederum zu GMX umgeleitet werden.

Unnötig nervig das Ganze. Ein Grund mehr, meine GMX Adressen endlich sterben zu lassen..

Unser hauseigener Provider <a href="https://mailbox.org" rel="nofollow">https://mailbox.org</a> erlaubt auch die native Nutzung eigener Domains.

Peer, ich schätze das was du tust sehr. Mit deinem Fachwissen hast du oft überzeugt.

Hier muss ich dir aber widersprechen: Nein, nicht in der Frage ob SPF Mist ist. Da bin ich bei dir.

Ich widerspreche dir bei dem Vorwurf, dass das Verhalten von UnitedInternet unkollegial sei.

Halten wir fest: Laut deinem Bericht ist die einzige Änderung die UnitedInternet in den vergangen Tagen durchgeführt hat die Auswertung und Umsetzung von SPF-Records (ich persönlich hatte erst vermutet der Aufschrei hätte den Hintergrund, dass GMX/Web.de für ihre eigenen Domains nun harte Policies gesetzt hätten, d.h. Leute über ihre eigenen Server nun nicht mehr mit „ihrem“ GMX/Web.de-Absender rausmailen könnten, da die neue Policies dies untersagt. D.h. bei prüfenden MXs würden diese Mails nun abgelehnt werden).

Was ist daran schlimm und in irgendeiner Form unkollegial? Wir sprechen davon, dass Domainbesitzer für ihre Domains Policies publizieren. Wenn diese Besitzer harte Anweisungen veröffentlicht haben muss man davon ausgehen, dass das auch gewollt ist. Es wäre eher eine Bevormundung wenn man diese Records bewusst ignorieren würde.

Wer glaubt SPF verwenden zu müssen und entsprechende Policies veröffentlicht der soll mit den Folgen leben. Aber jetzt UnitedInternet den schwarzen Peter zuschieben, weil diese vom Domaininhaber publizierte Records auswerten… NEIN!

Zu deiner vorgeschlagenen Lösung (DKIM): DKIM alleine, d.h. ohne DMARC, ist genauso sinnbefreit wie „soft“e SPF-Records zu pflegen. Ohne Policy was bei Verstoß mit einer Mail erfolgen soll macht kein System Sinn. SPF kann man vorwerfen Grundideen zu zerstören (Weiterleitungen…). Je nachdem über welche Felder ich eine DKIM-Signatur lege und entsprechende Signaturen mit DMARC erzwingen kann ich Weiterleitungen aber auch bei diesem Verfahren unterbinden. Klar: Du wirst vermutlich argumentieren (und da würde ich dir zustimmen), dass das ja kein vernünftiger Mensch tun würde, zur Absicherung des Absenders reichen wenige Felder welche bei einer Weiterleitung nicht verändert werden. Was du in meinen Augen ignorierst:
Solche Entscheidungen obliegen dem jeweiligen Domainbesitzer. Man kann Entscheidungen kritisieren aber am Ende des Tages sollte man sie trotzdem respektieren.

…und derjenige der diese Entscheidungen durchsetzt ist der letzte der unkollegial handelt.

[…] Einige Provider haben Sender Policy Framework (SPF) aktiviert. Damit kann der empfangende Server erreichen, dass er nur noch Mails von Servern annimmt, die im SPF-Record der absendenden Domain eingetragen sind. Das sollte theoretisch SPAM verhindern. Mehr Informationen zu dem Problem unter https://www.heinlein-support.de/blog/news/gmx-de-und-web-de-haben-mail-… . […]

Hallo Sven!

Natürlich ist Widerspruch erlaubt -- und bei unbestritten kontroversen Themen auch erwünscht. Ich hoffe, ich habe auch in meinem Beitrag klar gemacht, daß das Grundübel als solches natürlich bei dem liegt, der SPF "-all" setzt (wozu GMX & Co ja leider auch gehören, aber das schon seit Jahren).

"Unkollegial" empfinde ich es, solch eine weitreichende Änderung ohne Vorankündigung "in der Szene" zu machen und damit alle anderen erstmal ins offene Messer laufen zu lassen. Wenn Google die Policies ändert dann wird das bekannt gegeben und alle anderen können sich überlegen, ob sie sich anpassen, was sie unternehmen, wie sie reagieren. GMX und web.de SIND nunmal riesengroß und in der Sekunde wo die das einschalten knallen bei anderen Providern wie auch meinen eigenen binnen weniger Stunden Hunderte von Support-Tickets auf. Da weiß das Helpdesk so schnell gar nicht, wie es rechts und links schauen soll. Die Kunden schimpfen, machen den Drittprovider verantwortlich oder kündigen wutendbrannt.

"Kollegial" wäre es also vielleicht gewesen, diese für Dritte (!) sehr weitreichende Änderung mal vorher zu kommunizieren. Dann kann man FAQs vorbereiten, User informieren, vielleicht sogar auch IN RUHE doch SRS implementieren (statt wie jetzt von einigen ganz hektisch über's Knie gebrochen). In der Not haben einige Unis/Provider kurzerhand in deren Webinterfaces einprogrammiert, daß keine Weiterleitungen mehr an GMX und web.de-Zieladressen angelegt werden dürfen. Ist das alles ein fachlich guter sauberer Verlauf?!

Je größer man ist, umso mehr Verantwortung hat man eben auch anderen gegenüber daß das eigene Handeln im Sinne des Netzes bleibt und nicht unbeteiligte Dritte negativ beeinflußt. Jedem muß klar gewesen sein, daß in der Sekunde, wo SPF dort hart aktiviert wird, sofort hunderttausende von Mails geschrottet werden. Das hat die Verantwortlichen schlichtweg nicht interessiert, das haben sie anscheinend einfach in Kauf genommen, anstatt zu versuchen, die Auswirkungen (auch im Sinne ihrer eigenen Kunden!) zu minimieren.

Eine kleine Vorankündigung auf den üblichen Mailverteilern mit zwei Wochen Vorlauffrist hätte allen viel Ärger, Streß und Überstunden erspart. Anderen Providern -- und normalen Nutzern. Wäre das zuviel verlangt gewesen?

<blockquote>Wäre das zuviel verlangt gewesen?</blockquote>
Nein, wäre nicht zu viel verlangt. Da stimme ich dir uneingeschränkt zu.

<blockquote>Ich hoffe, ich habe auch in meinem Beitrag klar gemacht, daß das Grundübel als solches natürlich bei dem liegt, der SPF „-all“ setzt (wozu GMX & Co ja leider auch gehören, aber das schon seit Jahren)</blockquote>Leider nein. Einen Teil deiner Antwort auf meinen Kommentar hätte ich mir schon in deinem Artikel gewünscht.
Nach Lesen deines Artikels hatte ich eher den Eindruck als würdest du herumjammern und noch einmal gegen die Entscheidung keilen (was in meinen Augen einem Kampf gegen Windmühlen gleicht, da die Änderung beschlossen wurde).

Danke für deine Ausführungen. Jetzt verstehe ich was du gemeint hast.
Ich hoffe du hast noch genügend Eis... das könntest du dann deinen Jungs und Mädels spendieren wenn sie die Support-Lawine überstanden haben und eine Zwangs-Lösung wie SRS etc. umgesetzt haben.

Evtl. kommt aus Montabaur ja auch ein Paket... wer weiß.

Sie setzen nun wieder auf den SPF-Softeintrag: ~all

Da hatte jemand wohl ein Einsehen.

Hi Peer,

also entweder GMX & Web.de haben in Windeseile die DNS Records geändert oder die Aussage "...daß das Grundübel als solches natürlich bei dem liegt, der SPF „-all“ setzt (wozu GMX & Co ja leider auch gehören, aber das schon seit Jahren)." lässt sich auf den ersten Blick nicht bestätigen.

s1:/root# dig +short gmx.net TXT
"google-site-verification=J0NZ2F6kdhXzsguHSKZTm3CWujnrImftkDG3zhz14g0"
"v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:74.208.4.192/26 ip4:82.165.159.0/24 ip4:217.72.207.0/27 ~all"

# dig +short web.de TXT
"google-site-verification=No4jlUg2OIV7IsI2UF0v792Q8HgI9Brnp7qary1nMAQ"
"v=spf1 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:217.72.192.248/29 ip4:82.165.159.0/26 ip4:217.72.207.0/27 ip4:217.72.192.64/26 ~all"

VG

GMX und web.de haben in der Tat gestern Nachmittag in Eile die DNS-Records geändert.

[…] Die E-Mail-Provider GMX.de und Web.de (beide gehören zum „United Internet“ -Konzern) setzen seit ein paar Tagen offenbar auf SPF-Records mit „-all“ Einstellung. Das zeigt anderen Mailservern, dass nur die GMX-eigenen Mailserver E-Mails für GMX-Domains versenden dürfen. Klingt auf den ersten Blick tatsächlich nach einer sinnvollen Maßnahme gegen Phishing – ist auf den zweiten Blick aber „Bullshit und Broken by Design„. Warum das so ist, erklärt Peer Heinlein in einem ausführlichen Blogpost in Mailbox.org Blog. […]

Ich habe soeben (Freitag 9.10 Uhr) mit GMX telefoniert. Aussage: Sie mussten die scharfen Einstellungen wegen Spam (Spoof) machen und es werde definitiv nicht zurückgeändert. Die anderen Provider sollen den Service der Original-Umleitung nicht mehr anbieten (sondern nur mit Umschreibung) oder in ihrem GMX-Account einen Sammeldienst einrichten und betreiben.
Meine Meinung: Der dienstliche Anbieter soll nur umleiten. Ich möchte keine SRS-Umschreibung, sondern eine Umleitung des Originals. Ich möchte meine Post auch selbst sehen können. Sonst ist E-Mail in dieser Form bald tot.
Ich werde als Admin meinen Kollegen empfehlen, keine Umleitung an GMX/web.de mehr zu schicken, sondern einen anderen Provider zu nehmen.
Im Übrigen ist in dieser Angelegenheit das Verfahren von GMX sehr kundenunfreundlich: ohne Vorankündigung ein derartiges Chaos zu erzeugen.
Das Gegenargument der Sicherheit ließ ich nicht gelten: Dann eben keinen deutschen Provider, sondern googlemail...

Und was bedeutet diese Änderung jetzt? Bin nicht der SPF-Experte. Was genau hat denn nun GMX wieder entschärft? Was geht nun wieder - und was nicht?

Ärgerlich ist insbesondere, dass GMX und web.de längst "intern" DKIM verwenden, um den Mehrwertdienst <a href="http://www.united-internet-media.de/de/produkte-und-loesungen/dialog/tr…; rel="nofollow">Trusted Dialog</a> technisch umzusetzen.
Man versucht das, was die Yahoo-, Microsoft- und Google-Dienste längst als offenen Standard implementiert haben, dem Versender als Mehrwertservice zu verkaufen.

[…] Sehr guter Artikel unserer Kollegen von Heinlein-Support: Link […]

Weil durchaus manche Kollegen und Kunden die geänderten SPF-Records bei web.de und GMX falsch verstanden haben, schreibe ich doch kurz das offensichtliche.

Die geänderten Records bedeutet NICHT, dass GMX und web.de SPF beim Empfang nicht länger überprüfen. Das ist genauso scharf wie vorher und führt natürlich nach wie vor zu Problemen.

Das Muster "gmx-Absender schickt an Empfänger, der wiederum an eine andere gmx-Adresse weiterleitet" ist damit zwar gelöst und das kann bei manchen Providern tatsächlich zu einer nachhaltigen Entspannung führen. Aber dem hier als Beispiel genannten ikea.com hilft das natürlich nicht.

Man muss es hart formulieren: wer als Absender ein "-all" definiert, der verbietet den Empfängern die Weiterleitung der E-Mails. Versteht mich also nicht falsch, ich habe kein Mitleid mit IKEA.

Sehr guter Artikel.
Das ganze fällt unter DGI (Dümmer Geht Immer).
De facto heißt das, web.de / gmx.de künftig zu meiden.
Na jedenfalls wird das noch lustig.
Vielen Dank jedenfalls!

Jetzt muss ich als zugegeben ahnungsloser Mensch aus dem Marketing einfach mal blöd fragen: hat das einen Einfluss darauf, dass wir von einer scheinbar anderen Mailadresse aus Mails oder Newsletter an Kunden versenden?

Beispiel:
Ich schaue in unsere Kontakt-Postfach rein (kontakt@domain.com), antworte aber mit Lotus Notes und somit mit meiner eigenen Emailadresse. Als "from" steht aber weiterhin "kontakt@domain.com" im Header.

Return path: meine.email@mailserver.de
From: kontakt@domain.com
Sender: meine.email@mailserver.de

Würde das zu dem besagten Problem führen?

Hallo Peer,

danke für den Artikel. Auch bei uns sind ein paar Tickets aufgeschlagen, die auf die SPF-Prüfung von United Internet zurückzuführen sind.
Natürlich hätte United Internet hier großflächig informieren können und damit einen Ärger im Vorfeld vermieden. Allerdings stimme ich dir nur bedingt beim Thema DKIM zu. Wenn ich mir anschaue, welch geringer Prozentsatz der bei uns eingehenden sauberen (!) Emails überhaupt eine DKIM-Signatur besitzen , kann dies kein probates Mittel gegen SPAM-Bekämpfung sein.

Meiner Meinung nach ist eine Mischung aus SPF & DKIM Check schon ein guter Ansatz, wenn auch nicht die perfekte Lösung. Die wird es wohl auch niemals geben, denn für perfekte SPAM-Bekämpfung ist wohl SMTP an sich "Broken by Design", wie du immer zu sagen pflegst ;)

Übrigens verwenden wir ebenfalls einen "harten" SPF-Eintrag mit -all und fahren sehr gut damit. Allerdings kann man unsere Firmengröße (100.000 Mailboxen) nicht mit United Internet vergleichen. Das lässt sich dann doch noch etwas besser handhaben.

Grüße aus Erfurt

[…] heinlein-support hat einen interessanten Artikel zur Sache von gmx.de und web.de geschrieben. So versteht man die Hintergründe genauer. […]

Auch von mir ein Dankeschön für den gut verständlichen Artikel.

In der Sache verstehe ich es folglich aber nicht so ganz: was treibt denn all die anderen Provider an?

- Man findet SPF eigentlich blöd, nutzt es aber dann doch
- Vor allem setzt man den harten "-all", also den ausdrücklichen Wunsch, dass keiner Mails von nicht genannten Servern annehmen soll.

Was soll das? Gibt es dafür irgend einen plausiblen Grund?
Es knallt jetzt, weil plötzlich jemand diesen ausdrücklichen Wunsch respektiert.

Ja, ich habe verstanden, dass eine Vorwarnung nett gewesen wäre ... aber ich verstehe nicht, warum man jahrelang diesen Wunsch äussert und gleichzeitig darauf baut, dass es keiner macht.
Das klingt ja so, als ob ich jahrelang verlange, Fussgänger sollen bei rot stehen bleiben und wenn sie es dann "ohne Vorwarnung" eines Tages wirklich tun, bricht mein Verkehrsnetz zusammen und ich beschwere mich ...?

Soweit ich verstehe, setzen doch keine Ahnungslosen Endkunden diesesn SPF-Header sondern die Provider? Wenn deren Helpdesk nun glüht, kann man dann nicht sagen: "selbst Schuld"?
Oder was habe ich übersehen?

Sehr aufschlussreicher Beitrag, DANKE!

Die aktuelle Änderung der SPAM Policies durch United Internet kann man auch als eine weitere Maßnahme einordnen, den Traffic auf die eigenen Portale zu erhöhen. Der Benefit seitens United Internet daraus ist vermutlich einfach zu groß, um es in den Entscheidungen nicht zu berücksichtigen:

http://www.digitalkontext.de/wie-e-mail-provider-spam-mails-gewinnbring…

Hallo Peer,

> Familienmitglieder haben Postfächer bei GMX. Sie verlieren damit wissentlich E-Mails. Das ist deren mehr oder weniger bewußte, aber eben doch deren eigene Entscheidung.

Naja - wissentlich bisher noch nicht. Sind wie gesagt fast alle Laien, die mich bestimmt mit ganz großen -nix verstehen- Augen angucken werden, wenn ich ihnen erzähle, dass sie ab sofort damit leben müssen, dass E-Mails unbemerkt im Nirvana verschinden können, wenn sie über die Familiendomain Mails empfangen und bei GMX bleiben.

> GMX und web.de haben in der Tat gestern Nachmittag in Eile die DNS-Records geändert.

Einsehen oder Verschleierungstaktik?
Hätten sie von anfang an die softe Variante gehabt, hätte ich deutlich länger gebraucht, bis ich gemerkt hätte dass da seit Juni plötzlich Mails verloren gehen, da mein Test (logischerweise von GMX aus) erst mal ohne Probleme verlaufen wäre und die Eingrenzung auf GMX sicher deutlich langwieriger geworden wäre.

Weiterhin keine offizielle Info seitens GMX (auch nach meiner Beschwerde).
Naja - vielleicht will man ja einfach keine schlafenden Hunde wecken, weil der Standard-Nutzer nicht in die Probleme läuft?

PS: Selbst Amazon wird bei mir rejected :-(

Vielen Dank für diesen ausführlichen Post.
Auch mir wurde dadurch der Grund der Beschwerden in unserem Hause damit klar.

Vielen Dank

Danke für deinen ausführlichen Artikel. Auch wenn ich nur die Hälfte verstehe, aber sehr gut, dass ich seit Jahren keinen dieser Anbieter mehr nutze. Mit Erlaubnis würde ich deinen Artikel bei mir im Blog aufgreifen!?

Grüße

Sehr guter Artikel, sollte eigentlich bei jedem Postmaster an der Wand hängen.

Grüße aus dem Erzgebirge.

Vielen Dank für den ausführlichen kompetenten Artikel und die sachliche Diskussion.
Leider muss ich aus unserer Sicht hinzufügen, daß von unseren Kunden auch Emails an gmx und web.de abgelehnt wurden in deren Domains/DNS kein einziger SPF-Record eingetragen war und da glaube ich an eine fehlerhafte Implementierung der harten Ablehnung. Ob die inzwischen gefixt ist weiß ich allerdings nicht. Wir haben "ist mir egal" SPF-Records für die betroffenen Kunden nachgerüstet und seit der Stellungnahme von gmx bei heise gings dann ja auch wieder.

Grüße aus dem Süden

Ich konnte jetzt zwar nur bei Web.de testen, aber die ganze Sache mit den SPF-Rejects hat sich mittlerweile wohl erledigt.

<cite>United Internet bestätigte auf Nachfrage, dass die Änderung "dauerhaft" sei.</cite>
Soviel dazu.

<cite>[...] Leider muss ich aus unserer Sicht hinzufügen, daß von unseren Kunden auch Emails an gmx und web.de abgelehnt wurden in deren Domains/DNS kein einziger SPF-Record eingetragen war und da glaube ich an eine fehlerhafte Implementierung der harten Ablehnung. [...] </cite>

Die Implementierung muss nicht zwangsläufig fehlerhaft sein, sie könnte sich auch so verhalten wie sie soll. Siehe dazu Abschnitt "5.2. 'include'" im RFC7208.
Dieser Abschnitt beschreibt zwar, wie sich ausschließlich ein "recursive check_host() result" verhalten soll, doch daraus geht hervor, dass ein "none", also kein SPF Record gesetzt, sich wie ein "PermError" verhält und das Bedeutet im Klartext, dass E-Mails "rejected" werden.

Im übrigen muss ich mich an dieser Stelle entschuldigen, dass ich zum einen die Spezifikation nur halbherzig überflogen habe, sowie zum anderen im Lesen und Interpretieren ebendieser nicht besonders bewandert bin. Damit möchte ich einräumen, dass ich an dieser schlicht nicht einschätzen kann, ob ich mit meiner Interpretation richtig liege und bei irgendwem sicherlich den Bulls**t Detektor ausgelöst habe, da meine Interpretation schlicht falsch ist.

Umgekehrt wird aus meiner Sicht ein Schuh daraus: Es wird zwangsläufig notwendig sein den "SPF ist mir egal" Record zu setzen, um sicherzustellen, dass E-Mails ankommen.
Der "Sicherheitsgewinn", wenn jeder einen "SPF ist mir egal" Record setzt, ist damit anschaulich hinfällig und wir sind wieder bei "Broken by Design".

https://tools.ietf.org/html/rfc7208

http://www.openspf.org/SPF_Record_Syntax

[…] einem Blog-Artikel von heinlein-support.de, können Sie bei Interesse mehr zu den technischen Hintergründen erfahren. Aus diesem Artikel […]

Sehr guter Artikel.

Auch unsere Kunden hatten Probleme mit dem senden dahin. Dabei war der SPF-Record neutral gestellt. Trotzdem kamen die Mails zurück. Ein Kunde hat immer noch Probleme, sein SPF war auch neutral eingestellt. Angeblich sollen diese nun gegen die Richtlinien verstoßen. Problem hierbei: Entweder werden diese abgelehnt, oder sie gehen durch.

Grüße aus dem Nordosten.

GMX hat in der Tat massive Spam/Spoofing-Probleme. Das geht so weit, dass gespoofte Mails von GMX-Absendern auch direkt wieder an GMX-Nutzer gehen (also kürzlich sogar an mich). Statt auf DKIM zu setzen, versucht man offenbar das tote Pferd SPF weiter zu reiten, aber it's dead, Jim.

Wenn sich da vor 10 Jahren jemand oben in der Hierarchie von GMX weit aus dem Fenster gelehnt hat, kann das ein persönliches Machtspiel sein, das verhindert, dass GMX und web.de DKIM einsetzen...

Hallo Admins!

Ich arbeite gerade an der neuen Konfiguration des Mail-Servers und habe ein gewaltiges Problem mit den Benutzern von hotmail.com . Ich fahre seit vielen Jahren glücklich und zufrieden mit qmail auf einem debian- server. Nun habe ich SPF ("v=spf1 a mx ~all") und DKIM eingeführt. Meine E-Mails gehen sauber rauss. Bei dem Empfang habe ich jedoch ein Problem, und zwar: die Mails vom hotmail werden rejected. Die Meldung aus meiner log-Datei lautet:
qmail-smtpd: message rejected (qmail-dkim: signature error: selector p= value invalid or wrong format (#5.7.5)): ******@hotmail.com from 65.54.190.95 to user@domain.de helo BAY004-OMC2S20.hotmail.com.

Kann mir Jemand helfen? Was mache ich falsch? Kann ich bei meinem Server die Ausnahmen hinzufügen? die Einträge in /etc/spamassassin/local.cf

whitelist_from_dkim user@hotmail.com

haben Nichts gebracht. Ist auch klar. Die Mails werden rejected, noch vor SpamAssassin. Danke für Eure Hilfe!

Ah, Danke für den Hinweis!

Hatte mich schon gewundert, warum es bei dem ein oder anderen permanent knallt.

Laut Google Postmaster Tools ist aber ein funktionierender SPF *und* DKIM gewünscht, bzw. reduziert die Wahrscheinlichkeit, dass die Mails von Google als Spam markiert werden.

Sicherlich wendet Google das nicht hart an - aber für Gmail ist das sicherlich ein Indikator, ob der Post/Webmaster sauber (~seriös!) gearbeitet hat.

GMX scheint SPF wieder auf -all gesetzt zu haben:

$ host -t txt gmx.de
gmx.de descriptive text "v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:74.208.4.192/26 ip4:82.165.159.0/24 ip4:217.72.207.0/27 -all"

Ich verstehe nicht viel hier von der Technik ausser das ich plötzlich nicht mehr in mein gmx.de Account komme. Mir wurde mitgeteilt das der Server sein passwort geändert habe. Wie komme ich daran. Ich kann ja nicht mal irgendwo anfragen. Kann meinen Account nicht öffnen

Kurzer Nachtrag zur Thematik.

Ich hatte diese Woche „das Vergnügen“ mit der Mailsecurity von GMX in Kontakt zu stehen. Hintergrund waren für mich nicht nachvollziehbare rejects beim Versand von Mails. rDNS-Eintrag für den Sender-Host gesetzt, SPF als TXT-Eintrag in den Einträgen der jeweils gehosteten Domänen mit Verweis auf die Sender IP eingetrage. Ich stand wirklich vor einem Rätsel.
Im Laufe des Austauschs kam dann heraus, dass GMX Mails rejected, wenn der DNS-Name des Senders Namensanteile des Web-Hosters enthält. Da sich dieser Namensrintrag in ziemlich vielen Config-Files befindet, fand ich den Vorschlag von GMX doch einfach EINE der Domains auf meinem System zu nehmen, nicht wirklich hilfreich und auch sicher nicht zweckdienlich.
Der Standardname setzt sich in meinem Fall aus der mit Bindestrichen getrennten, fixen IP und der Hosterdomäne zusammen. Deshalb fand ich es ziemlich erheiternd, als deren Support mit Kapitel 3.3 Absatz 1.b der MAAWG als Begründung für den reject zitierte - in diesem Teil geht es darum einen sendenden Host eindeutig identifizieren zu können. Ich Noob war bisher davon ausgegangen eine fixe IP, welche auch noch im Host-Anteil der DNS-Domäne referenziert wird, würde sowas ermöglichen?

Scheinbar nicht bei GMX oder sind die einfach nicht kompetent genug, um mit solch einem trickreichen Set-Up umzugehen? Fragen über Fragen..

Eigentlich müsste man die mit ihrem Verhalten blacklisten...

Cheers,
AphxTwn

-all ist wieder/ immernoch drin bei web und gmx....

Da freu ich mich ja richtig, dass GMX und Web.de das so rigoros durchziehen. Manchmal braucht es leider den Holzhammer Marktmacht, damit die Ewiggestrigen sich in ihre Löcher verkriechen. Wenn Postfix da nicht mit macht, wird's halt geforked oder schlicht bedeutungslos. Mit "men on a mission" konnte die OSS-Community zum Glück bisher ganz gut umgehen. Derweil wäre SRS von Anfang an das einzig Richtige gewesen, ob mit oder ohne SPF. Ein Server hat für das verantwortlich zu zeichnen, für das was er tut. >Ich sende. Ich bin der Absender.< Klar und deutlich.

Bleibt der erste und scheinbar wichtigste Grund dieses armseligen Beitrags: Es nervt den Kundendienst. Ehm.... warte mal... hab ich das richtig gelesen? Die Technologie ist Mist, weil es ein Layer 8 Problem gibt? Na das ist ja mal 'ne Neuigkeit. Dann lasst uns mal das Internet abschaffen.

[…] Dank eines Kundenfeedbacks wurden wir auf diese Problem aufmerksam und haben es schnellst möglich behoben. Für den Technik interessierten Leser sei erwähnt, dass es beim Versenden des Ferienhaus Anfrage- und Buchungs-Formulars zu einem Problem rund um SPF (Sender Policy Framework) gekommen ist, in Zusammenhang mit unserem Formular und Web.de und GMX Email-Adressen. Mehr zum Thema SPF und GMX/Web.de. […]

Du hast drei Probleme genannt:

1.) Weiterleitung
Jemand wird also über max@example.com angeschrieben und dort hat Max eine Weiterleitung auf max@example.org hinterlegt. Max kann dieses Problem lösen:
a) Er fügt den Empfänger max@example.com zu seiner Whitelist hinzu
b) Er hört auf E-Mail-Adressen unterschiedlicher Domains zu verbreiten
c) Er legt das zusätzliche Konto in seinem E-Mail-Programm an, statt mit Weiterleitungen zu arbeiten
d) Er lässt die E-Mails als Anhang weiterleiten, so dass sie immer den Absender max@example.com tragen und bei Bedarf ergänzt er ein reply-to

Fazit: Weiterleitungen waren vor SPF bequem. Weniger Spam ist aber bequemer.

2.) Mailingliste
Es spricht nichts dagegen, dass die Mailingliste den Absender nicht faked, sondern mailing@example.com nutzt.

3.) Webformulare
Der Versand von Mails über Webformulare im Namen Dritter ist zu recht Spam. Korrekt ist ausschließlich der Absender formular@example.com und max@example.org als reply-to und das hätte auch schon immer so sein müssen.

Gerade 2.) und 3.) wurde damals so umgesetzt, weil es kein SPF gab. Hätte es schon immer SPF gegeben, hätte sich keiner an diese Vorgehensweise gewöhnt und würde heute SPF verteufeln.

Kommentar erstellen