SPF: Verbesserung der Spamfilterraten

Um die Postfächer unserer Kunden besser vor Spam zu schützen, planen wir eine Umstellung der Prüfung von SPF-Einträgen. Was genau das bedeutet und wie sich das Verhalten ändert, beschreiben wir in diesem Beitrag.

Doch zunächst: Was genau ist SPF?  

SPF (Sender Policy Framework) wurde entwickelt, um das Fälschen von Absenderadressen in E-Mails zu verhindern. Das funktioniert wie folgt:  

Mit einem SPF-Eintrag kann ein Domaininhaber seine Domain so konfigurieren, dass über E-Mailadressen der Domain nur aus bestimmten Bereichen, also z.B. aus seinem Heimnetzwerk, dem Büro etc. gesendet werden darf.  

Man legt also fest, dass Absender unter der Domain nur über bestimmte IP-Adressen oder Netzwerkbereiche senden dürfen.  

💡 Kurz zur Erklärung: Nameserver

An dieser Stelle möchten wir kurz erklären, was es mit Nameserver-Einträgen auf sich hat. Das ist wichtig, um die Funktion von SPF zu verstehen. Wenn Sie sich mit Nameservereinstellungen bereits auskennen, überspringen Sie diesen Part bitte einfach.

Für jede Domain sind in den Nameservern technische (keine persönlichen!) Informationen hinterlegt, die jeder abfragen kann.

Stellen Sie sich vor: Jemand gibt im Browser die Adresse Ihrer Webseite ein – und sie öffnet sich. Im Hintergrund passiert (vereinfacht gesagt) Folgendes: Der Browser Ihres Besuchers schickt eine Anfrage los, und sucht in den Nameservern nach Informationen dazu, wo im Internet er Ihre Webseite findet. Das ist ein wenig so, als würde er in den Gelben Seiten blättern. Im Eintrag zu Ihrer Domain (im sogenannten Zonefile) findet er alle Informationen. Also z.B., auf welchem Webserver Ihre Webseite liegt. Aber auch, welcher Mailserver E-Mails für Ihre Domain entgegennimmt und eben auch den SPF-Eintrag, sofern einer vorhanden ist.  

Wird nun eine E-Mail über diese Domain geschickt, prüft der Mailserver des Empfängers, ob ein SPF-Eintrag existiert und wenn ja, ob die IP-Adresse des Absenders in dem SPF-Eintrag erlaubt wurde.  

Ist alles in Ordnung, wird die E-Mail zugestellt.  

Wenn nicht, reagiert der empfangende Mailserver entsprechend. Wie genau – das kommt darauf an, wie der Mailserver konfiguriert ist. Und an dieser Stelle nehmen wir nun eine Änderung bei unseren Mailservern vor.  

Wie verhält sich die SPF-Prüfung bei DomainFactory momentan? 

Wenn unser Mailserver eine E-Mail entgegennimmt, prüft er den SPF-Eintrag der absendenden Domain und fügt je nachdem folgende Informationen zum Header hinzu: 

Es existiert ein SPF-Eintrag, der mit dem Absender übereinstimmt: 

X-Received-SPF: pass ( mx04.ispgateway.de: domain of sender-domain.tld designates Sender-Server-IP as permitted sender ) 

Es existiert ein SPF-Eintrag, der nicht mit dem Absender übereinstimmt: 

X-Received-SPF: fail ( mx02.ispgateway.de: domain of sender-domain.tld does not designate Sender-Server-IP as permitted sender ) 

Es existiert kein SPF-Eintrag:  

X-Received-SPF: none ( mx15.ispgateway.de: domain of sender-domain.tld does not provide an SPF record ) 
💡 Der komplette Header einer E-Mail wird in der Regel nicht direkt in Ihrem E-Mailprogramm angezeigt, sondern kann über die Einstellungen eingeblendet werden.

Es passiert erst einmal nichts weiter.  

Sie können nun aber selbst entscheiden, ob eine Prüfung des Headers stattfinden soll, indem Sie für das Postfach einen individuellen Mailfilter über Ihr Kundenmenü einrichten. 

Was wird geändert?  

Besteht ein SPF-Record bei einer Domain, und die Informationen des Absenders stimmen nicht damit überein, wird die E-Mail künftig nicht mehr nur im Header markiert, sondern sie wird von unseren Mailservern abgelehnt. Folgende Fehlermeldung geht an den Absender zurück:  

„mail@sender-domain.tld is not allowed to send mail from sender-domain.tld. Help at/Hilfe unter www.mfaq.info“ 

Das bedeutet, dass Sie nicht mehr selbst konfigurieren müssen, ob solche E-Mails abgelehnt werden sollen. 

Als Beispiel erklärt 

Gehen wir davon aus, ein Kunde von Ihnen schickt Ihnen eine E-Mail. Der Kunde kann seine E-Mailadresse bei einem beliebigen Provider haben. Ihr Postfach, das die E-Mail empfangen soll, ist bei DomainFactory.  

Szenario 1: Ihr Kunde hat keinen SPF-Eintrag gesetzt

Ihr Kunde schickt Ihnen die E-Mail. Unser Mailserver nimmt die E-Mail entgegen und stellt fest, dass Ihr Kunde für seine Domain keinen SPF-Eintrag gesetzt hat. Die E-Mail wird zugestellt.

Szenario 2: Ihr Kunde hat einen SPF-Eintrag gesetzt, der mit dem Absender übereinstimmt 

Ihr Kunde schickt Ihnen die E-Mail, unser Mailserver nimmt die E-Mail entgegen. Er prüft den SPF-Eintrag und stellt fest, dass die E-Mail von einer IP-Adresse geschickt wurde, die im SPF-Eintrag zugelassen wurde. Die E-Mail wird zugestellt. 

Szenario 3: Ihr Kunde hat einen SPF-Eintrag gesetzt, der mit dem Absender nicht übereinstimmt 

Jemand schickt eine E-Mail und benutzt als Absenderadresse die Ihres Kunden. (Das geht leider genau so einfach, wie auf einen Briefumschlag einen falschen Absender zu schreiben und den Brief zur Post zu bringen.) 

Unser Mailserver nimmt die E-Mail entgegen und stellt fest, dass ein SPF-Eintrag existiert, die absendende IP-Adresse darin jedoch nicht erlaubt wurde. Bislang hätte unser Mailserver einen Eintrag im Header gesetzt, den Sie vielleicht gar nicht prüfen (dafür hätten Sie manuell einen eigenen Mailfilter einrichten müssen).  

Mit der neuen Einstellung wird die E-Mail abgelehnt, die absendende E-Mailadresse erhält eine Fehlermeldung.  

Hat Ihr Kunde die E-Mail selbst geschickt und sich beim Senden einfach nicht in dem zugelassenen Bereich (den er selbst definiert hat!) befunden, weiß er durch die Fehlermeldung Bescheid, dass Sie die Mail nicht erhalten haben.  

Hat ein Spammer die E-Mailadresse Ihres Kunden missbraucht, bekommt dieser Kunde die Fehlermeldung auch, denn sie geht ja zurück an die Absenderadresse. So bekommt Ihr Kunde mit, dass seine Mailadresse zum Spamversand missbraucht wurde.  

Nur wenn der Spammer irgendeine E-Mailadresse unter der Domain benutzt, kann die Fehlermeldung natürlich nicht zugestellt werden.  

Warum führen wir die Änderung durch? 

Durch einen SPF-Record legt der Domaininhaber fest, welche IP-Adressen bzw. welche Netzwerkbereiche E-Mails über seine Domain versenden dürfen.  

Durch das aktuelle Verhalten werden die E-Mails jedoch auch dann zugestellt, wenn der Absender nicht zugelassen ist.  

Durch diese Änderung entsprechen wir also dem Sinn eines SPF-Eintrags: E-Mails aus nicht zugelassenen Bereichen werden direkt abgelehnt – ohne, dass unsere Kunden dafür eigene Mailfilter anlegen müssen.  

Kann ich diese E-Mails trotzdem empfangen?  

Wir stellen auch Mailserver für den Mailempfang bereit, die keine Spamschutz-Prüfungen durchführen.  

Wenn Sie für Ihre Domain diese Server nutzen möchten, gehen Sie bitte wie folgt vor:  

  • Loggen Sie sich in Ihr Kundemenü ein, wählen Sie ggf. den entsprechenden Auftrag aus und klicken Sie dann in der linken Navigation in der Rubrik „E-Mail“ auf „Spamschutz“.  
  • Wählen Sie nun die Registerkarte „Reverse-DNS-Prüfung“ und dort den Button „Reverse-DNS-Prüfung konfigurieren“.  
  • Nun klicken Sie rechts neben der Domain auf „Editieren“ und wählen in dem Dropdown-Menü „Alle Prüfungen inaktiv“.  

Nun werden für diese Domain unsere empfangenden Mailserver verwendet, die keine Spamschutz-Prüfungen für eingehende E-Mails durchführen. 

❗ Bitte beachten Sie, dass Sie dadurch in den Postfächern der entsprechenden Domain wahrscheinlich deutlich mehr Spam erhalten werden! 

Fragen & Support 

In unseren FAQ finden Sie eine Anleitung, wie Sie selbst für Ihre Domain einen SPF-Eintrag setzen können:  

DomainFactory FAQ: SPF-Einträge erstellen 

Unter http://www.kitterman.com/spf/validate.html können Sie prüfen, ob Ihr SPF-Eintrag richtig funktioniert.  

Wenn Sie noch Fragen zu SPF haben, steht Ihnen unser Kundenservice gern zur Verfügung – oder nutzen Sie die Kommentarfunktion unter dem Beitrag!  

End of article

Anna Philipp

Über den Autor

Anna Philipp

Anna arbeitet seit 2006 bei DomainFactory. Als Social Media und Content Manager vertritt sie DF in den sozialen Netzwerken (Facebook, Twitter, Googleplus und natürlich im DF-Blog). In ihrer Freizeit findet man Anna - sofern sie mal nicht online ist - höchstwahrscheinlich zwischen Rührschüsseln und Schneebesen am Backofen.

88 Kommentare

Die von Ihnen hier erhobenen Daten werden von der domainfactory GmbH zur Veröffentlichung Ihres Beitrags in diesem Blog verarbeitet. Weitere Informationen entnehmen Sie bitte folgendem Link: www.df.eu/datenschutz


  • Recktenwald
    Recktenwald - 7. Mai 2019 um 11:24 Uhr

    Machen alle andern auch mit ,was passiert wenn ich in einem Online Shop einkaufe der die bestätigung schickt ,das mail wird dann nicht zugestellt oder ,Viele Shops schreiben auch falls unser Mail nicht ankommt schauen Sie in ihren Spam Ordner.
    Hoffentlich geht das nicht wie das Hornbacher Schiessen aus
    gruß

    • Anna
      Anna - 7. Mai 2019 um 12:09 Uhr

      Wenn der Shopbetreiber alles richtig konfiguriert hat, kommt die Mail auch an. Sie würde nur dann abgeleht werden, wenn ein SPF gesetzt und nicht mit dem Absender übereinstimmen würde.

    • Bachsau
      Bachsau - 7. Mai 2019 um 12:43 Uhr

      Durch einen SPF-Eintrag bestimmt der Absender selbst, welche Server berechtigt sind, eine Mail unter seiner Absender-Adresse einzureichen. Diesen Eintrag muss der Shop-Betreiber für seine Domain selbst hinterlegen, wenn er das System SPF nutzen möchten. Sollten deshalb legitime Mails abgelehnt werden, hat der Shop das also selbst zu verantworten, und dann wird er nicht nur bei DF Probleme haben, seine Mails loszuwerden. Der Spam-Ordner dient ja dazu, Mails überprüfen zu können, die durch eine heuristische Analyse, man könnte auch sagen von einer KI, mit einer gewissen Wahrscheinlichkeit als Spam eingestuft werden, wobei es zu Falschentscheidungen kommen kann. SPF ist dagegen eine klare Regel, die vom rechtmäßigen Besitzer einer Domain definiert wird. Entweder entspricht die Mail dieser Regel, oder es ist was faul. Daher ist der Spam-Ordner hier überflüssig.

      Das Anti-Spam-System von DF wirklich top ist. Zuerst kommt die Prüfung auf „harte“ Kriterien über drei verschiedene Eingangs-Server, zu der in Zukunft auch SPF gehört, und bei der E-Mails garnicht erst angenommen werden, wenn sie nicht den Vorgaben entsprechen. Im Anschluss folgt dann die „weiche“ Prüfung, bei der ein Score festgelegt wird und dessen Behandlung über Filterregeln völlig frei bestimmt werden kann.

      • Charlie
        Charlie - 7. Mai 2019 um 18:18 Uhr

        Wenn ich das richtig verstehe, habe sie doch damit alle Problem dieser Kacker-Welt gelöst, oder? Keiner kann dann mehr auf meinen Rechner, es sei denn, ich habe es ihm erlaubt und landet erlandet somit im Spam-Ordner und da ist Ende?

      • Bachsau
        Bachsau - 7. Mai 2019 um 18:48 Uhr

        @Charlie Hä? Wie kommst du denn darauf? Der Durchschnitts-Spammer schickt dir seine Mails normalerweise mit Absendern von Domains, die SPF noch nicht verwenden oder über gekaperte Server, wo es keine Rolle spielt, weil der Absender ja korrekt ist. Eine Whitelist, wo alles aussortiert wird, was du nicht explizit erlaubt hast, kannt du dir auch ohne SPF basteln. Macht nur irgendwie keinen Sinn, weil dann außer den Mails von Mama und Papa fast garnichts mehr ankommt, oder?

  • aCustomer
    aCustomer - 7. Mai 2019 um 11:27 Uhr

    Interessant könnte an dieser Stelle noch sein, ob bzw. seit wann Domainfactory selbst SPF für seine eigenen bzw. die Domains seiner Kunden einsetzt.

    • Anna
      Anna - 7. Mai 2019 um 12:10 Uhr

      Sie können auch für Ihre eigenen Domains SPF-Einträge setzen. Wir haben hier eine Anleitung dazu: https://www.df.eu/de/support/df-faq/e-mail/spf-sender-policy-framework/spf-eintraege/

    • Bachsau
      Bachsau - 7. Mai 2019 um 12:55 Uhr

      Standardmäßig setzt DF keine SPF-Einträge, da sie nicht wissen können, wie ein Kunde seine Domain verwendet und er dann möglicherweise Probleme bekäme, deren Ursache im nicht klar ist. Du kannst so einen Eintrag aber jederzeit selbst im DNS setzen. Meiner sieht z.B. so aus:

      „v=spf1 a:tatooine.bachsau.net include:ispgateway.de -all“

      Das heißt, dass Mails, bei denen meine Domain hinter dem „@“ steht, entweder von meinem Server oder einem Mailserver der DF beim Empfänger eingliefert werden dürfen. Alle anderen Server sind nicht berechtigt, mails unter meiner Adresse zu versenden und werden deshalb hoffentlich vom Empfänger blockiert.

  • DF Kunde
    DF Kunde - 7. Mai 2019 um 11:30 Uhr

    Guten Tag DF, wir sind bei DF Kunde, und haben vorallem das Aergernis, dass unsere eigene Mailadresse missbraucht wird um ums selber zu bespammen. Wie ist das in Ihrem SPF Scenario, die SPF Records haben wir bei Ihnen schon seit Jahren gesetzt, auf -all, sprich ein Scammer schickt spoofmail z.B. mit validemail@df.eu von externen laut SPF record nicht zugelassenen IP adressen an validmail@df.eu, bespammt „sich“ (also mich/Sie) selbst. Die Mail wird zwar jetzt laut Ihrem Blogeintrag abgelehnt wie Sie schreiben, aber was bedeutet die Information dass der „Absender“ jetzt eine Hinweismail erhaelt dass er nicht senden darf wegen widersprechendem SPF record. Diese Hinweismail waere ja dann wiederum der gespoofte absender, sprich man selber, naemlich validmail@df.eu, was ja wiederum ein Problem waere, wenn das wirklich so umgesetzt werden wuerde.

    Man sollte einfach im SPF System von DF das so einstellen koennen, dass fuer eigene/DF-gehostete Domains da keinerlei Mails an eigene Domains oder sowas gesendet werden. Oder verstehen wir das jetzt falsch? Sind genau fuer diese Faelle dann nicht auch noch DKIM und DMARC erfunden worden, was einfach die Situationen nur noch komplexer gestaltet? Man sollte doch als Mailkunde jedweden Mailhosters festlegen koennen, dass eine Domain, naemlich die eigene, die Mails niemals ueber irgendwelche fremdgelagerten oder externen Mailserver/Strukturen gesendet werden.

    Ich finde diese Aussage:
    > Mit der neuen Einstellung wird die E-Mail abgelehnt, die absendende E-Mailadresse erhält eine Fehlermeldung.

    problematisch, und man sollte das selber als DF Kunde fuer seine eigenen gehosteten Domains komplett abschalten koennen. Keine Fehlermails an Mailadressen die ja bereits auch schon gespooft sind und mich dann wiederum durch bounce spams oder return spams zumuellen werden wenn ich das jetzt so korrekt verstanden habe.

    Bitte um Stellungnahme fuer den spoof/eigene Mailadresse durch den Spammer benutzt Fall.
    Vielen Dank. MfG.

    • Bachsau
      Bachsau - 9. Mai 2019 um 19:59 Uhr

      Ersteinmal muss ich leider sagen, dass die Informationen, die DF hier zum Zustellungsweg der Fehlermeldungen gibt, falsch sind. Mit dem neuen Verfahren wird eine Annahme der betroffenen Mails direkt bei der Einlieferung verweigert. Das bedeutet, dass der absendende Server die Fehlermeldung bereits während des Zustellversuchs erhält, vergleichbar mit einem zugenagelten Briefschlitz. Daher braucht es keine E-Mail mit einer Fehlermeldung die irgendwohin zurück geschickt wird, und der Absender bekommt die Meldung von seinem eigenen Anbieter in sein Postfach gelegt.

      Was den Missbrauch deiner eigenen Adresse als Absender betrifft, ist es wichtig zu wissen, dass SPF nur den „Sender“ schützt. Das ist die Adresse, an die auch üblicherweise Zustellungsfehler zurück gemeldet werden, und sie taucht nur in den Headern einer Mail auf. Diese darf nicht mit dem Briefkopf-Absender „From“ verwechselt werden, der üblicherweise von Mailprogrammen als Absender angezeigt und auch als Antwort-Adresse verwendet wird. Diese lässt sich auch mit SPF beliebig fälschen. Fehlermeldungen solltest du dagegen mit SPF nur noch für die Mails erhalten, die du auch wirklich selbst gesendet hast.

  • Arne
    Arne - 7. Mai 2019 um 11:48 Uhr

    Hallo,

    das heißt, es werden Hard-, sowie Softfail direkt angelehnt? Softfail sollte ja durchgehen.

    Außerdem vermisse ich den Hinweis, das dann DF Postfächern keine weitergeleiteten Mails mehr annehmen, wenn der Ursprüngliche Absender SPF gesetzt hat und der Weiterleitungsserver den Header nicht umschreibt.

    Gruß Arne

    • ToBeFree
      ToBeFree - 7. Mai 2019 um 12:17 Uhr

      Um das von Arne angesprochene Problem zu lösen, könnte Domainfactory für die Kunden, die einen solchen Weiterleitungsdienst anstelle der Domainfactory-Server nutzen, eine Kundenmenü-Option anbieten. So könnte man zum Beispiel die Mailserver einer beliebigen Domain als bekannte Weiterleitungsserver definieren. Der Kunde tippt einen Domainnamen ein, und der SMTP-Server nutzt diesen, als befände er sich als „mx“-Eintrag im SPF-Record des Absenders.

      • Bachsau
        Bachsau - 7. Mai 2019 um 14:20 Uhr

        Wenn ein weiterleitender Server diesen Header nicht anpasst, ist er schlichtweg falsch konfiguriert, und sein Administrator sollte sich darum kümmern. Der weiterleitende Server ist in diesem Fall derjenige, der die E-Mail technisch raus schickt, also sollte er sich auch als solcher zu erkennen geben. Tut er das nicht, geht also quasi mit Falschangaben hausieren, dann werden seine Mails zu Recht abgelehnt. Der ursprüngliche Absender bleibt durch den „From“-Header trotzdem erkennbar, wird als solcher auch im Mailprogramm angezeigt und er erhält auch die Antworten. Nur eben nicht die Fehlermeldungen, welche bei korrekter Angabe des Versenders an den weiterleitenden Server zugestellt werden.

    • Anna
      Anna - 7. Mai 2019 um 12:22 Uhr

      Genau, es wird nur Hardfail abgelehnt.

      Das mit den weitergeleiteten Mails ist richtig. Wenn Sie das so nicht möchten, müssten Sie der Anleitung unter dem Punkt „Kann ich diese E-Mails trotzdem empfangen?“ folgen und die Prüfungen deaktivieren.

    • DG1IUK
      DG1IUK - 7. Mai 2019 um 15:19 Uhr

      Softfails will man doch eigentlich heute gar nicht mehr haben. Die sind nur etwas für den Testbetrieb des SPF gewesen. Im produktiven Betrieb sollte man immer mit Hardfails und einem „-all“ am Ende der SPF-Definition arbeiten. Schon allein die Definition eines Softfails klingt doch komisch „jemand, der nicht die Erlaubnis hat, unter meinem Namen zu senden aber bitte trotzdem großzügig behandelt werden soll“…

      Grüße,
      Florian

  • ToBeFree
    ToBeFree - 7. Mai 2019 um 11:59 Uhr

    Dankeschön! Der Nachteil eines benutzerdefinierten Filters war für mich die fehlende Fehlermeldung beim Absender. Man konnte zwar einen Autoresponder festlegen, aber eine wirkliche Ablehnung auf Serverebene war das nicht. Bei diesem Vorgehen bestand das (in RFC 7208 2.5 explizit als „backscatter“ erwähnte) Risiko einer Endlosschleife. Die einzig technisch sinnvolle Lösung, eine SMTP-Fehlermeldung, fehlte hier bisher.

    Vielen Dank für die Verbesserung, die, anders als es der Blogbeitrag vielleicht vermuten lässt, nicht einfach nur allen Kunden Arbeit abnimmt, sondern zudem tatsächlich ein technisches Problem selbst für die Kunden löst, die manuelle Filter eingesetzt haben.

    • Anna
      Anna - 7. Mai 2019 um 12:12 Uhr

      Vielen Dank für Ihr Feedback, es freut uns, dass Ihnen die Umstellung entgegenkommt!

  • Tobi
    Tobi - 7. Mai 2019 um 12:13 Uhr

    Wie sieht das mit Mails aus, die von Scripten auf euren Servern verschickt werden? z.B. WooCommerce-Bestell-Mails etc?
    Müssen wir da nun auch irgendwas irgendwo anpassen – oder ist da SPF automatisch richtig/gar nicht gesetzt?

    • Anna
      Anna - 7. Mai 2019 um 12:23 Uhr

      Sie meinen für Ihre Domains bei uns? Sie müssten dafür explizit einen SPF-Eintrag setzen, wenn Sie das möchten: https://www.df.eu/de/support/df-faq/e-mail/spf-sender-policy-framework/spf-eintraege/

      • Tobi
        Tobi - 7. Mai 2019 um 12:46 Uhr

        Genau. Wenn man Zeug bei euch hosted, was Mails sendet, die letztlich in nem DF-Mailaccount landen.

        Danke für den Link, dann schaue ich da mal drüber.

    • Anna
      Anna - 7. Mai 2019 um 12:56 Uhr

      Wenn Sie keine SPF-Einträge gesetzt haben, betrifft das auch nicht die Mails, die Sie versenden. Es geht hier nur um das empfangen von E-Mails.

    • Bachsau
      Bachsau - 7. Mai 2019 um 14:24 Uhr

      Als Versender betrifft dich diese Änderung nicht. Doch derade als Shop-Betreiber solltest du dich einmal mit SPF auseinader setzen. Der Wikipedia-Artikel ist ein guter Einstieg. Durch einen korrekten SPF-Eintrag kannst du deine Kunden (natürlich nur bedingt) davor schützen, dass Cracker deine Mails fälschen um z.B. einen Phishing-Angriff durchzuführen.

  • N.
    N. - 7. Mai 2019 um 12:17 Uhr

    Moin!

    Kann man auch einfach wieder das bisherige Verfahren einschalten?

    SPF ist leider broken by design…

    • Anna
      Anna - 7. Mai 2019 um 12:24 Uhr

      Ja, eine Anleitung dazu finden Sie unter „Kann ich diese E-Mails trotzdem empfangen?“ in diesem Artikel.

      • N.
        N. - 7. Mai 2019 um 13:16 Uhr

        Im Artikel steht etwas von „alle Prüfungen abschalten“. Das klingt etwas schwarz-weiß.

        Mir ging es nur um die jetzt angekündigte Konfigurationsänderung bzgl. SPF.

        Von mir aus auch allgemein SPF abschalten und andere Prüfungen aktiv lassen…

    • Bachsau
      Bachsau - 7. Mai 2019 um 14:38 Uhr

      In keinster Weise. Weiterleitende Mailserver, die unter falschem Namen versenden, weil sie den „Sender“ nicht anpassen, sind „broken by design“. Warum sollte ich z.B. die Mailer-Daemons kriegen, für Mails die ich garnicht versendet habe? Nein, niemand außer mir hat das Recht, unter meiner Domain irgendwo E-Mails einzuliefern, auch nicht, wenn er sie nur weiterleitet. Wenn ein empfangender Mailserver meint, die Mail von mir mit geändertem Ziel wieder rausschicken zu müssen, dann soll er wenigstens so anständig sein, im technischen Teil zu vermerken, dass er selbst dafür verantwortlich zeichnet, und nur das prüft SPF. Die Absender-Angabe im Briefkopf („From“-Header) bleibt ja unverändert.

      Stell dir vor, ein Facharzt schickt mir einen Brief mit der Schneckenpost und ich schicke diesen nach eigener Entscheidung an meinen Hausarzt. Ich stecke ihn in einen neuen Umschlag und schreibe einen anderen Empfänger drauf. Natürlich schreibe ich dann auch mich als Absender drauf, denn ich bin ja dafür verantwortlich, dass das Schriftstück erneut im Briefkasten landet. Soetwas sollte selbstverständlich sein. Wäre ja auch komisch, wenn der Brief nicht zugestellt werden kann und der Facharzt plötzlich einen Umschlag zurück bekommt, den er nie versendet hat.

      • N.
        N. - 7. Mai 2019 um 21:43 Uhr

        SPF war schon immer „broken by design“, auch als es noch „Sender Permitted From“ hieß.

        Gerade der Vergleich mit der „Schneckenpost“ zeigt, wie kaputt das System ist. Stell Dir mal vor, ich könnte keine Postkarte mehr aus dem Urlaub schicken, weil der Sender nicht autorisiert wäre… oder Du könntest nicht mal mehr einen Brief für einen Kumpel einwerfen, weil Du nicht autorisiert bist…

        SPF ist schlicht Sabotage. Beispiele: Weiterleitungsadressen, Mailinglisten.

        Also vielleicht nicht einfach blöd herumquatschen… 🙂

  • Bachsau
    Bachsau - 7. Mai 2019 um 12:27 Uhr

    FInde ich völlig richtig, denn das ist der Sinn von SPF. Wer SPF einsetzt, der sollte wissen was er tut, daher würde ich mir keine Sorgen machen, dass etwas Wichtiges nicht ankommen könnte. Für die Unwissenden sei gesagt: Beim durch SPF-Geprüften Absender handelt es sich um den tatsächlich einsendenden Server, manchmal auch als „Envelope-From“ (Umschlag-Absender) bezeichnet. Dies ist nicht der Absender, der normalerweise vom Mailprogramm zur Anzeige verwendet wird. Hierzu dient der „From“-Header, der eher einem Briefkopf entspricht. Es kann also weiterhin jeder beliebige Absender im Mailprogramm angezeigt werden. In den Headern kann man aber sehen, wo die Mail wirklich herkommt, und SPF stellt sicher, dass diese Angabe wahr ist.

    • N.
      N. - 7. Mai 2019 um 13:20 Uhr

      Leider stellt SPF gar nichts sicher…

      Ob es sich um einen legitimen Versand einer E-Mail handelt, kann SPF nicht sicherstellen.

      Wie jede Anti-Spam-Maßnahme ist SPF auch eine Anti-Mail-Maßnahme. In diesem Fall schießt SPF allerdings über das Ziel weit hinaus und verhindert legitime E-Mail-Anwendungen. Daher gilt SPF bei Kritikern eben als „broken by design“.

      Der Ansatz, den SPF verfolgt, kann gar nicht funktionieren…

      • Baysen
        Baysen - 7. Mai 2019 um 14:18 Uhr

        Na das musst du uns jetztt aber auch erklären! Was ist denn genau daran „broken by design“? Ich kann abseits von abstrusen Weiterleitungsproblemen veralteter E-Mail-Clients keine Fehler erkennen.

      • Bachsau
        Bachsau - 7. Mai 2019 um 14:46 Uhr

        Wenn ein Absender einen SPF-Eintrag für seine Domain festlegt, dann sagt er damit explizit, dass er das, was du als „legitime Anwendung“ bezeichnest, nicht haben will. Es ist seine Domain, und er allein hat das Recht, das zu entscheiden. Lies dir meinen Beitrag weiter oben dazu durch und quatsch nicht nach, was irgendein auf den Kopf gefallener Kritiker von sich gibt. Du hast Unrecht und SPF funktioniert bereits sehr gut.

  • Daniel
    Daniel - 7. Mai 2019 um 12:58 Uhr

    Info-Mail mit Umstellungstermin zum 20.5.2019 kam heute rein.

    Was muss ich jetzt machen? Alle IP-Adressen, die wir in der Firma nutzen, im DNS eintragen?

  • Michaela
    Michaela - 7. Mai 2019 um 13:09 Uhr

    Ich habe ein neues iPad und ein Freund hat mit dort eingerichtet, dass ich von da Emails senden und empfangen kann (hostname, etc…).
    Nun habe ich versucht eine Mail zu versenden mit folgendem Ergebnis:
    Emails können nicht gesendet werden.
    Kopie wird im Ausgangsfach abgelegt.
    Adresse wurde vom Server abgelehnt.
    Was muss ich tun, dass mein Server den Zugang meines iPads erlaubt?
    Grüße

    • Anna
      Anna - 7. Mai 2019 um 13:13 Uhr

      Können Sie einen Screenshot Ihrer Einstellungen an unseren Kundenservice schicken oder kurz anrufen? Dann können wir die Einstellungen gerne gemeinsam durchgehen.

  • Thomas Schwinge
    Thomas Schwinge - 7. Mai 2019 um 13:22 Uhr

    Ich habe hier eine Nicht-Spam-Email, die sowohl „X-Received-SPF: fail“ als auch „X-Received-SPF: pass“ enthält:

    […]
    X-Received: from unknown (HELO mta4001.groups.mail.bf1.yahoo.com) (10.201.194.219)
    by mtaq1.grp.bf1.yahoo.com with SMTP; 28 Dec 2018 13:55:13 -0000
    X-Original-Return-Path:
    X-Received-SPF: fail (domain of alumni.ethz.ch does not designate 129.132.72.10 as permitted sender)
    X-YMailISG: […]
    Authentication-Results: mta4001.groups.mail.bf1.yahoo.com from=alumni.ethz.ch; dkim=neutral (no sig)
    X-Received: from 127.0.0.1 (EHLO virgo02.ee.ethz.ch) (129.132.72.10)
    by mta4001.groups.mail.bf1.yahoo.com with SMTPS; Fri, 28 Dec 2018 13:55:12 +0000
    […]
    Content-Type: multipart/alternative;
    boundary=“zYLn8bf4RiKsyXd5h8kNgqO-DHbelgCiDYVM89P“
    X-Received-SPF: pass ( mx08.ispgateway.de: domain of returns.groups.yahoo.com designates 66.163.190.94 as permitted sender )
    X-DKIM: DKIM passed: (address=sentto-479767-12373-1546005696-@returns.groups.yahoo.com domain=yahoogroups.com), signature is good.
    X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
    spamfilter04.ispgateway.de
    […]

    Wie wird diese in Zukunft behandelt?

    Und, ähnlich, eine Nicht-Spam-Email mit „X-Received-SPF: temperror (encountered temporary error during SPF processing of domain of alum.mit.edu)“ und weiter unten „X-Received-SPF: pass ( mx01.ispgateway.de: domain of returns.groups.yahoo.com designates 98.137.66.212 as permitted sender )“.

    Wie werden diese in Zukunft behandelt?

    Die anderen „X-Received-SPF: fail“-Emails der letzten Wochen, die ich gerade überprüft habe, sind in der Tat allesamt Spam.

    Ich habe hier allerdings auch noch weitere „X-Received-SPF“-Varianten:

    X-Received-SPF: (invalid) ( mx07.ispgateway.de: error: unknown SPF result 0 encountered while checking 119.253.81.250 for domain of taikanglife.com )
    X-Received-SPF: (invalid) ( mx18.ispgateway.de: error: unknown SPF result 0 encountered while checking 193.136.98.27 for domain of iscsp.ulisboa.pt )

    Spam.

    X-Received-SPF: (invalid) ( mx08.ispgateway.de: error: unknown SPF result 0 encountered while checking 193.169.181.97 for domain of newsletter.selbststaendigentipps.de )

    Kein Spam.

    X-Received-SPF: neutral ( mx09.ispgateway.de: 199.83.103.190 is neither permitted nor denied by domain of aol.co.uk )
    X-Received-SPF: neutral ( mx11.ispgateway.de: 94.247.40.156 is neither permitted nor denied by domain of etu.imt-lille-douai.fr )

    Spam.

    X-Received-SPF: neutral ( mx08.ispgateway.de: 213.165.92.155 is neither permitted nor denied by domain of nussbaum-wds.de )
    X-Received-SPF: neutral ( mx18.ispgateway.de: 209.85.128.97 is neither permitted nor denied by domain of musicbrainz.org )
    X-Received-SPF: neutral ( mx07.ispgateway.de: 94.247.40.156 is neither permitted nor denied by domain of ira.uni-karlsruhe.de )

    Kein Spam.

    X-Received-SPF: softfail ( mx01.ispgateway.de: transitioning domain of gmail.com does not designate 49.212.129.122 as permitted sender )
    X-Received-SPF: softfail ( mx01.ispgateway.de: transitioning domain of protonmail.com does not designate 94.177.232.84 as permitted sender )
    X-Received-SPF: softfail ( mx01.ispgateway.de: transitioning domain of siirius.pro does not designate 162.250.122.195 as permitted sender )
    X-Received-SPF: softfail ( mx06.ispgateway.de: transitioning domain of aol.com does not designate 94.247.40.156 as permitted sender )
    X-Received-SPF: softfail ( mx09.ispgateway.de: transitioning domain of seoulind.co.kr does not designate 162.250.122.195 as permitted sender )
    X-Received-SPF: softfail ( mx14.ispgateway.de: transitioning domain of msn.com does not designate 202.191.2.41 as permitted sender )

    Spam.

    X-Received-SPF: softfail (transitioning domain of alum.mit.edu does not designate 96.114.154.166 as permitted sender)

    Kein Spam.

    X-Received-SPF: temperror ( mx02.ispgateway.de: encountered temporary error during SPF processing of domain of gbdb-kontakt.net )
    X-Received-SPF: temperror ( mx09.ispgateway.de: encountered temporary error during SPF processing of domain of renatadonati.com.mx )
    X-Received-SPF: temperror ( mx18.ispgateway.de: encountered temporary error during SPF processing of domain of kudanganalkcs.com )

    Spam.

    X-Received-SPF: temperror ( mx01.ispgateway.de: encountered temporary error during SPF processing of domain of nongnu.org )
    X-Received-SPF: temperror ( mx01.ispgateway.de: encountered temporary error during SPF processing of domain of osb-alliance.com )
    X-Received-SPF: temperror ( mx09.ispgateway.de: encountered temporary error during SPF processing of domain of discoursemail.com )
    X-Received-SPF: temperror ( mx09.ispgateway.de: encountered temporary error during SPF processing of domain of lists.llvm.org )
    X-Received-SPF: temperror ( mx10.ispgateway.de: encountered temporary error during SPF processing of domain of vger.kernel.org )
    X-Received-SPF: temperror ( mx11.ispgateway.de: encountered temporary error during SPF processing of domain of lists.infradead.org )
    X-Received-SPF: temperror ( mx14.ispgateway.de: encountered temporary error during SPF processing of domain of sourceware.org )
    X-Received-SPF: temperror ( mx15.ispgateway.de: encountered temporary error during SPF processing of domain of gcc.gnu.org )
    X-Received-SPF: temperror ( mx16.ispgateway.de: encountered temporary error during SPF processing of domain of lists.debian.org )

    Kein Spam.

    Wie werden diese in Zukunft behandelt?

    Würden all diese zugestellt, somit keine Nicht-Spam-Emails abgewiesen?

    • Bachsau
      Bachsau - 8. Mai 2019 um 01:47 Uhr

      Deine erste Mail würde durchgehen. Die oberen Header stammen von einem vorherigen Schritt der Zustellungskette und sind nur eine Dokumentation des Geschehenen. Von oben nach unten gelesen: Die E-Mail wurde von einem Rechner im Netzwerk der ETH Zurüch ( alumni.ethz.ch) bei Yahoo eingereicht. Leut dem SPF-Eintrag von alumni.ethz.ch hätte diese E-Mail von diesem Rechner nicht bei Yahoo eingereicht werden dürfen. Das hat aber alles noch nichts mit DF zu tun und offensichtlich hat sich der Server von Yahoo entschieden, die Mail dennoch weiterzuleiten und diesen Fehler nur in einem Header-Feld zu vermerken. Anschließend hat sich also der Server von Yahoo mit dem von DF in Verbindung gesetzt um diese Mail dort abzuladen. Er hat dort als Absender seine eigene Adresse angegeben. DF hat den SPF-Eintrag von returns.groups.yahoo.com geprüft und festgestellt, dass dieser Server berechtigt ist, E-Mails im Namen von Yahoo zu versenden. DF hätte die Mail also angenommen. Solcher Header-Blöcke können sehr lang werden, wenn eine Mail durch viele Server läuft und jeder seine Hinweise und Filter-Daten hinzufügt.

      Deine anderen Beispiele sind alle jeweils standardisierte Ergebnis-Codes einer SPF-Prüfung. Was sie genau bedeuten, kannst du leicht googlen. Du kannst aber davon ausgehen, dass alles ankommt, was nicht in einem „fail“ resultiert, und das wie oben beschrieben auch nur, wenn der betreffende Header von DF erzeugt wurde. Alles was davor war ist eine nette Information, aber nichts was du beeinflussen kannst. Jede Zeile die etwas wie „… Received: from (HELO…“ oder „… Received: from (EHLO…“ enthält kannst du als Trennlinie sehen, an welcher die E-Mail auf dem Weg zu dir eine Server-Grenze überschritten hat. Ich weiß, SMTP ist kompliziert… 😉

      • Thomas Schwinge
        Thomas Schwinge - 8. Mai 2019 um 17:38 Uhr

        Vielen Dank für die Erläuterung, das deckt sich mit meinem rudimentären Verständnis von SMTP/SPF. Wichtig war mir im Wesentlichen, eine Bestätigung zu bekommen, dass wirklich nur DF-seitiges ‚fail‘ abgewiesen wird und alles andere weiterhin zugestellt wird.

  • Patrick
    Patrick - 7. Mai 2019 um 13:35 Uhr

    Interessant ist, ich habe gerade einen „Newsletter“ von DF erhalten, die darauf hinweist – im Header dieser EMail steht schon:

    X-Received-SPF: fail ( mx11.ispgateway.de: domain of bounces.sendnode.com does not designate 85.13.139.144 as permitted sender )

    Also selbst der eigene Newsletter würde nach der Änderungen nicht mehr ankommen – sehe ich das richtig ? Wenn es schon die eigenen Newsletter betrifft, dann doch bestimmt fast alle anderen auch…

    • Anna
      Anna - 7. Mai 2019 um 14:47 Uhr

      Das wird natürlich noch angepasst 😉

    • Bachsau
      Bachsau - 9. Mai 2019 um 20:10 Uhr

      Es ist aber nicht so, dass diese Mails einfach verschwinden, sondern der Absender bekommt das ja mitgeteilt. Daher würde das Team vom DF-Newsletter auch sofort merken, dass ihre Mails nicht zugestellt werden können, und hätte es spätestens dann korrigieren können. Ein legitimer Absender hat mit SPF eigentlich nie ein Problem, denn er kann die Regeln jederzeit anpassen.

  • Softeam
    Softeam - 7. Mai 2019 um 14:09 Uhr

    Solange Sie nicht die DF eigenen Weiterleitungsprobleme aus SPF geschützten Domänen zu SPF geschützten Domänen in den Griff bekommen, verschärfen sie sich u.E. noch weiter, da jetzt selbst Weiterleitungen innerhalb der DF Infrastruktur nicht mehr funktionieren werden. Leider wird, nach unseren bisherigen Informationen und nach obigem Post, noch nicht einmal versucht das lange bekannte und oft kommunizierte Problem der Weiterleitung (z.B. durch Einsatz von SRS) zu entschärfen. Deshalb müssen wir diese Änderung nach aktuellem Stand als halbherzig und kontraproduktiv ansehen.

    • Bachsau
      Bachsau - 7. Mai 2019 um 14:53 Uhr

      Wenn DF seine Header nicht im Griff hat, ist das kein Problem von SPF, sondern DF hat Mist gebaut und muss dringend nachbessern. SRS sollte standard sein: Ein Server muss die Verantwortung für das übernehmen, was er tut. Ich hoffe dass sich dieses Problem immer weiter verschärft und mail mit unpassendem SPF bald überall kategorisch abgelehnt werden. Vielleicht wird der Druck dann endlich groß genug, damit Betreiber von Weiterleitungsdiensten und Mailinglisten lernen, ihre Systeme vernünftig zu konfigurieren.

      • N.
        N. - 7. Mai 2019 um 21:49 Uhr

        Man kann Systeme mit SPF nicht „vernünftig“ konfigurieren, weil es außerhalb der eigenen Einflußsphäre liegt.

        Und SRS (Sender Rewriting Scheme) ist doch der nächste Flicken, um an den Problemen durch SPF herumzudoktern.

      • Bachsau
        Bachsau - 8. Mai 2019 um 01:57 Uhr

        @N. Außerhalb deiner Einflußsphäre liegt nur, was nicht dir gehört, und so soll es auch sein. SRS hätte von Anfang an Standard sien sollen und ist die einzige Art, es richtig zu machen. Aber wir werden da wohl nicht auf einen Nenner kommen, weshalb ich auf weitere Beiträge von dir auch nicht antworten werde. Ich bin ein großer Verfechter des SPF-Systems, wie auch anderer zukunftsweisender Technologien (IPv6, DNSSEC, DANE, DKIM, systemd), und ich bin froh, dass die Mehrheit das genau so sieht.

  • Thomas Braun
    Thomas Braun - 7. Mai 2019 um 14:10 Uhr

    Gilt das nur wenn meine Postfacher auf DF Mailserver liegen oder auch wenn emails per MX-Record auf einen eigenen Mailserver verweisen?

    • Anna
      Anna - 7. Mai 2019 um 14:43 Uhr

      Das gilt nur, wenn Sie unsere MXe verwenden.

  • Helmut
    Helmut - 7. Mai 2019 um 14:33 Uhr

    Hallo Anna,
    Wenn ich mir unter meinen Domains Mails senden will muss ich ja auch die Einträge machen da ich dann ja sowohl Absender als auch Empfänger bin. Eure Info ist sehr ausführlich. Nur in dem Punkt der zulässigen Adressbereiche komm ich ins straucheln. Wenn ich als privater Anwender klassisch dynamisch zugewiesene Adressen erhalte wie soll ich das machen ? Mit ist ja nicht ganz klar welche ich vom Provider erhalte bzw. auch welche Adressbereiche dieser hat. Vielleicht stehe ich auch nur auf dem Schlauch. Dann bitte kurze wegschubsen 🙂 Danke

    • Anna
      Anna - 7. Mai 2019 um 14:46 Uhr

      Das gilt nur für eingehende Mails, deren Domains explizit einen SPF-Eintrag gesetzt haben. Sie brauchen wegen der Umstellung nun also keine SPF-Einträge setzten.

    • Bachsau
      Bachsau - 7. Mai 2019 um 15:05 Uhr

      Du stehst gewaltig auf dem Schlauch, denn abgesehen davon, dass, wie auch @Anna schon geschrieben hat, der SPF beim Empfänger geprüft wird und das auch nur passiert, wenn der Absender einen SPF-Eintrag zur Verfügung gestellt hat, sendest du E-Mails in der Regel auch nicht direkt von Heimcomputer an den Empfänger, sondern lieferst sie bei deinem Anbieter ein, von wo aus sie dann weitergeleitet werden. Das verwendete Protokoll ist das selbe (SMTP), aber um Mails nach draußen zu schicken legitimierst du dich dabei nicht über deine IP, sondern über Benutzername und Passwort.

      Theoretisch könnte man natürlich Mails von Zuhause aus direkt beim Emfänger einliefern, aber damit kommst du von vornherein durch fast keinen Spamfilter, denn sonst würden die Postfächer von Mails überschwemmt, die von irgendwelchen infizierten Privat-PCs kommen. Bevor du da Probleme mit dem SPF bekommst, wird die Mail schon vom Dialin-IP-Filter rausgefischt. Da stehen alle Adressebereiche drauf, die von den großen Providern dynamisch an Endkunden vergeben werden, und wenn du mit so einer IP irgendwo antanzt um Mails einzuliefern, kann es sein, dass der Mailserver nichtmal antwortet, weil du hochkant gegen die Firewall fliegst.

      • Helmut
        Helmut - 7. Mai 2019 um 15:47 Uhr

        Hallo Bachsau,
        da lässt der Profilname bereits ein klares Wort erwarten. Danke für die ausführliche Erläuterung. Verstanden und damit jetzt auch vom Schlauch.

      • Bachsau
        Bachsau - 7. Mai 2019 um 16:07 Uhr

        @Helmut Ich habe keine Ahnung was du mir mit der Anspielung auf meinen Namen sagen willst, aber ich glaube, ich war dir gegenüber weder beleidigend noch unfreundlich, und habe dir einen ausführlichen Überblick über den Sachverhalt geliefert.

  • tkuehnem
    tkuehnem - 7. Mai 2019 um 16:11 Uhr

    Peer Heinlein hat das treffend zusammengefasst: „Wer „-all“ einträgt muss mit Mailverlust leben wollen“

    im Kontext: https://www.heinlein-support.de/blog/news/gmx-de-und-web-de-haben-mail-rejects-durch-spf/

    • Bachsau
      Bachsau - 7. Mai 2019 um 17:04 Uhr

      Naja, den Verlust an gefälschten Mails nimmt man doch gerne hin. Ich setze es seit Jahren ein und hatte noch keine Probleme. Ich bin als Versender natürlich selbst verantwortlich, dass meine SPF up-to-date sind, wenn ich sie einsetze. Wenn erstmal alle konsequent prüfen, merken Versender es sofort, wenn sie Mist gebaut haben.

      • N.
        N. - 7. Mai 2019 um 21:54 Uhr

        Nur daß es nicht um „gefälschte“ E-Mails geht.

        Der vom OP gelieferte Link beschreibt doch das Problem. SPF ist vom Konzept her eben schon untauglich.

      • Bachsau
        Bachsau - 8. Mai 2019 um 02:07 Uhr

        Es gibt vieles, das unbedarfte Endkunden nicht verstehen, und deshalb irgendeinen Kundendienst nerven. Eine Technik abzulehnen, weil es irgendwo ein unvermeidliches Layer 8 Problem gibt, ist ein ziemlich armseliges Argument. Aber heutzutage muss ja auch Hinz und Kunz Domains und Server haben, auch wenn er von Tuten und Blasen keine Ahnung hat. Da hilft dann wirklich nur die Holzhammer-Methode: Marktmacht, „-all“ und drauf. Danke GMX & Web.de! 😉

  • Fryd
    Fryd - 7. Mai 2019 um 17:35 Uhr

    Na, da hoffen wir mal, dass es df bis dahin schafft, den Return-Path bei Weiterleitungen korrekt zu setzen.

  • Alexander Nick
    Alexander Nick - 7. Mai 2019 um 17:54 Uhr

    Ich verwende gmail fuer das versenden meiner Emails, aber benutze meine DF email Adresse als Sender. Bedeutet dies dass meine eigenen versendeten Emails nun nicht mehr ankommen?

    • Bachsau
      Bachsau - 7. Mai 2019 um 18:55 Uhr

      Nein. Hat damit überhaupt nichts zu tun.

  • Ingolf Kretschel
    Ingolf Kretschel - 7. Mai 2019 um 18:32 Uhr

    geht die Prüfung auch über eine deutsche sprachige Seite?
    Danke.

  • H.-W. Wyes
    H.-W. Wyes - 7. Mai 2019 um 18:45 Uhr

    Ich habe keine Ahnung, was alles hinter den Kulissen bei einem Provider passiert. Trotzdem ist es mir mit Hilfe der von Ihnen gelieferten Anleitungen problemlos gelungen, meine Domains mit SPF zu sichern. Getestet: Die E-Mails, die von meinen Kontaktformularen geschickt werden, werden von SPF als gültig eingestuft. Nun kann der 20. Mai ruhig kommen. Danke ans Team!

    • Bachsau
      Bachsau - 7. Mai 2019 um 19:06 Uhr

      So gut wie alles, was da passiert, ist öffentlich dokumentiert. Die meisten Provider setzen Standardsoftware ein. Bei DF ist es Exim (mit diversen Plugins) und Dovecot. Die Protokolle sind sowieso standardisiert.

      • H.-W. Wyes
        H.-W. Wyes - 7. Mai 2019 um 19:50 Uhr

        Alle diese Dinge sind mir ein Buch mit sieben Siegeln. Ich bin nun mal kein Web-Admin, auch wenn ich eine Webseite betreibe. Dennoch auch Ihnen herzlichen Dank für Ihre engagierte Arbeit im Blog.

  • ateet
    ateet - 8. Mai 2019 um 00:39 Uhr

    manchmal bekomme ich meldungen, dass e-mails nicht zugestellt werden konnten, die von meiner adresse gesendet wurden, die aber ich selbst nicht gesendet hatte. betrifft eure neue änderung auch diese vorfälle und schützt sie mich vor diesen missbrauch?
    danke und liebe grüße

    • Bachsau
      Bachsau - 8. Mai 2019 um 03:21 Uhr

      Nein. Hier stehst du auf der „anderen Seite“, das heißt deine Mailadresse wird als Absender missbraucht. Um dich davor zu schützen, musst du selbst in deiner Domain einen SPF-Eintrag anlegen. Wenn du es tust, musst du aber sicher stellen, dass der Eintrag korrekt und immer up-to-date ist, damit deine eigenen Mails nicht auch als gefälscht durchgehen. Der Generator im Kundenzentrum hilft dir.

  • Georg Kreuzberger
    Georg Kreuzberger - 8. Mai 2019 um 08:41 Uhr

    1.Also muss ich bei jeder Spam auf die Domainfactory um dort diese Email Adresse oder nur dessen Domain zu sperren?
    2.Es sind unter „Spam“ oft auch welche dabei, die für mich keine Spams sind.
    3.Werden alle die als Spam deklariert sind gar nicht zugestellt?

    • Bachsau
      Bachsau - 9. Mai 2019 um 20:19 Uhr

      Alle deine Fragen (sofern halbwegs verständlich) haben nichts mit dem Thema zu tun und werden von der Änderung auch nicht beeinflusst.

  • Wendt-Rupert von Knobloch
    Wendt-Rupert von Knobloch - 8. Mai 2019 um 09:50 Uhr

    Super! Wieder eine Menge gelernt! Sinnvolle Sache; Dank an Domainfactory für diesen komfortablen Service!

  • Elmar Schwarzmann
    Elmar Schwarzmann - 8. Mai 2019 um 10:24 Uhr

    Hallo Anna,
    ich verstehe nicht viel von dem Geschriebenen, es hört sich aber gut an und lässt erwarten das wir weniger Spams bekommen.
    Muß ich jetzt irgendetwas neu einstellen oder geschieht dies automatisch?

    Gruß Elmar

    • Anna
      Anna - 9. Mai 2019 um 10:37 Uhr

      Sie brauchen dafür nichts zu ändern, die Umstellung erfolgt automatisch!

  • Nino
    Nino - 8. Mai 2019 um 14:56 Uhr

    SPF? Völlig unsinnig, denn die meisten Unternehmen haben noch etliche Mitarbeiter außerhalb des Unternehmens die von jedem Ort aus mailen müssen. Natürlich müssen auch sehr oft Haupt-Konten von unterwegs aus benutzbar sein. Selbst den Bereich des eignen Firmensitzes genau zu definieren ist bei dynamischen IPs fast unmöglich und nicht 100% sicher. Zudem der SPAM über gefälschte Absenderadressen extrem nachgelassen hat. Es gibt mittlerweile viel effizientere Methoden Spam abzusetzen.

    SPF ist also aus meiner Sicht nicht wirklich nützlich! Und ich bin auch der Meinung das ein Hoster/Provider nicht zu entscheiden hat welche Mails man bekommt und welche nicht. Diese Entscheidung sollte immer auf Seiten des Clients liegen. Demnacht finde ich auch automatisch aktivierte Spamfilter auf Seiten der Hoster völlig daneben, egal ob man diese Einstellung als Client ändern kann.

    • Bachsau
      Bachsau - 9. Mai 2019 um 20:23 Uhr

      Der Absender hat dank SPF das Recht zu entscheiden, wer unser seiner Domain E-Mails versenden darf. Mitarbeiter eines Unternehmens senden Mails auch von außerhalb über das Zentrale Mailsystem dieses Unternehmens, sodass es überhaupt keine Rolle spielt, wo der einzelne Mitarbeiter gerade ist. Dennoch wird niemand gezwungen SPF zu nutzen. Wenn besagtes Unternehmen diese Form der Sicherheit nicht wünscht, hinterlegt es keinen SPF-Eintrag und dann werden seine Mails auch nicht blockiert.

  • Ulrica Griffiths
    Ulrica Griffiths - 8. Mai 2019 um 16:17 Uhr

    Ich finde SPF interessant. Den Nutzen auf Empfängerseite habe ich verstanden, jetzt frage ich mich aber schon, welche Unternehmen diese SPF-Einträge machen werden. Was ist, wenn jemand aus dem Unternehmen mit dem Tablet eine dienstliche E-Mail vom Zug aus oder aus einem fremden WLAN schickt, müsste ich für alle diese Fälle die IP wissen und im SPF eintragen? Das geht doch gar nicht. Oder habe ich es falsch verstanden?

    • Bachsau
      Bachsau - 9. Mai 2019 um 20:29 Uhr

      Wenn jemand von irgendwo mit dem Tablet oder Laptop in irgendeinem WLAN eine Mail verschickt, hat das überhaupt nichts damit zu tun, denn er versendet sie ja nicht wirklich von da. Er reicht die Mail ja stattdessen, nach anmeldung mit Benutzername und Passwort, erstmal bei Mailserver seines Unternehmens ein, und erst von da werden sie dann verschickt. Es zählt also die IP-Adresse des versendenden Servers, nicht die von irgendeinem Endgerät. GMX und Web.de schützen ihre Server schon lange mit SPF. Das würde ja kaum funktionieren, wenn es davon abhinge, wo sie deren Nutzer gerade aufhält.

  • Ludwig Kumer
    Ludwig Kumer - 8. Mai 2019 um 17:06 Uhr

    Bitte sagen Sie mir nur welche Kreise und Kästchen ich in EIGENSCHFATEN von „NAME SERVER -EINTRAG ANLEGEN“ aktivieren soll, um einen optimalen SPAM Schutz unter Nutzung der SPF-Verbesserung zu erhalten, danke.

    • Anna
      Anna - 9. Mai 2019 um 08:37 Uhr

      Sie brauchen dafür gar nichts zu machen, die Umstellung erfolgt automatisch.

      • L. Kumer
        L. Kumer - 10. Mai 2019 um 20:54 Uhr

        Danke Anna, das ist für einen nur Nutzer die beste Nachricht, Ludwig

  • hanbird.net
    hanbird.net - 8. Mai 2019 um 22:14 Uhr

    Hilfe! – Seit heute erhalte ich Hinweise, dass Kunden mich nicht erreichen können.
    Ich habe sofort, wie beschrieben, die Reverse-DNS-Prüfung abgeschalten. Offenbar hilft das nicht!
    Wer kann mir helfen?

    • hangbird.net
      hangbird.net - 8. Mai 2019 um 22:31 Uhr

      … apropos: wie geht es eigentlich dem Forum? Das wäre doch jetzt praktisch, um strukturierter sich dazu austauschen zu können…
      Support-Anfrage gestellt; ich hoffe, ich bekomme schnell eine Antwort.

      • hangbird.net
        hangbird.net - 9. Mai 2019 um 07:56 Uhr

        Mir wurde geantwortet, ich soll den inhaltsbasierten Spam-Filter „MailfilterEASY“ anders konfigurieren und ggf. trainieren. (*kopfschüttel*) – Ob der Support diesen Blog-Post überhaupt gelesen hat und den Mechanismus von SPF kennen???

    • Anna
      Anna - 9. Mai 2019 um 08:37 Uhr

      Welche Fehlermeldung bekommen die Kunden denn? Die Umstellung ist noch gar nicht erfolgt, wir führen das erst wie in der E-Mail angekündigt zum 20.5.2019 durch.

    • Bachsau
      Bachsau - 9. Mai 2019 um 20:40 Uhr

      Blinder Aktionismus ohne Kenntnis der Ursache ist selten eine gute Idee. Reverse-DNS und Dial-in-IP sollte immer eingeschaltet sein, ebenso wie der Virenschutz. Spamhaus ist umstritten, da sie ihre Listen gerne missbrauchen, um unliebsame Anbieter zu erpressen. Die korrekte Einstellung für den Spamfileter EASY ist aber „Normal zustellen“, wenn man Filterregeln darauf anwenden will, oder „Im Betreff markieren“, wenn man darauf keinen Bock hat. Mit diesen Einstellungen kommt garantiert alles an, war ein echter Kunder dir schicken könnte.

  • DanielDF
    DanielDF - 9. Mai 2019 um 13:07 Uhr

    Ist es möglich die Prüfungen für alle eingehenden Mails aktiv zu lassen, AUSSER für Mails, die vom EIGENEN Server aus gesendet werden? Also auch solche mit Server-fremden E-Mail Absenderadressen?

    Grund: Wir haben ein Kontaktformular auf der Seite, das als Absender E-Mail Adresse die Adresse des Kunden, also die, die ins Formular eingetragen wird, benutzt. Das wäre ja dann eine nicht zugelassene IP Adresse, weil die E-Mail über PHP / SMTP an uns selbst verschickt wird.

    Könnte man jedoch dafür eine Ausnahme festlegen?

    Beispiel:
    Kontaktformular:

    Name: Mustermann
    E-Mail: mustermann at gmail com

    PHP / SMTP von UNSEREM Server sendet diese E-Mail mit Absender Adresse „mustermann at gmail com“ an UNSERE eigene E-Mail Adresse. Wir möchten also, dass DIESE „Fake“ E-Mails durchkommen, alle anderen jedoch nicht.

    Ist das möglich?

    Danke vorab.

    • Bachsau
      Bachsau - 9. Mai 2019 um 20:44 Uhr

      Nein, ist so nicht möglich. Da müsstest du die Prüfung tatsächlich komplett abschalten. Sinnvoller ist aber, das Kontaktformular vernünftig zu Programmieren. Sorgt einfach dafür dass es als Sender die Bounce-Adresse eures Servers nutzt und tragt die vom Kunden mitgeteilte E-Mail-Adresse nur im From-Header ein. Damit habt ihr das Problem korrekt gelöst. Bei `sendmail` wird dazu der -f Parameter genutzt.

      • DanielDF
        DanielDF - 10. Mai 2019 um 15:14 Uhr

        Danke für die Rückmeldung.
        Ich dachte das „from“ sei gerade das Problem und man solle da keine serverfremde Adresse benutzen!? Das wäre ja aber hier der Fall. Oder gilt das nur für SMTP und nicht für Sendmail?

        Nichtsdestotrotz – Könntest du mir Infos zu diesem -f Parameter geben? Konnte dazu nichts brauchbares finden.

        Vielen Dank!

      • Bachsau
        Bachsau - 11. Mai 2019 um 04:24 Uhr

        E-Mails besitzen zwei Arten von Absendern, den der quasi auf dem Umschlag steht (Sender) und der, der im Briefkopf steht (From). From wird in Mailprogrammen angezeigt, SPF prüft aber nur den Sender, an den auch Fehlermeldungen zurück geschickt werden. Wenn du dir auf php.net einmal die Dokumentation das Mail-Befehls anschaust, sieht du, dass er als 4. Parameter die angabe zusätzlicher Header ermöglicht, unter anderem den „From“-Header. Parameter 5 ermöglicht dagegen die Angabe zusätzlicher Parameter für sendmail, wie z.B. „-f deine@erlaubte.adresse„. Wenn diese Adresse eine ist, die dir gehört und laut deinem SPF von deinem Server genutzt werden darf, ist es egal was im „From“-Headers steht.

  • kerberos
    kerberos - 9. Mai 2019 um 23:38 Uhr

    Es wäre wünschenswert, wenn diese Filtermethode separat zu deaktivieren wäre, ohne gleich die gesamten Spamschutz-Prüfungen über Bord zu werfen. Ich bin beispielsweise auf eine Weiterleitungsadresse angewiesen, die historisch gewachsen ist, die es schon vor der Entwicklung von SPF gab und leider kein SRS unterstützt. Es liegt außerhalb meiner Einflussmöglichkeit, dies zu ändern. Daher werde ich in Zukunft auf die Spamschutz-Prüfungen verzichten müssen, was ich, gelinde gesagt, unschön finde.

    Prinzipiell, in einer perfekten Welt, ist SPF eine gute Idee. Denn in einer solchen unterstützen alle Server, die Emails weiterleiten, auch SRS. Andererseits, in einer perfekten Welt gäbe es auch keinen Spam…