Diskussion:Sender Policy Framework

Generalüberholung

Was geht hier eigentlich gerade vor sich? Eine "Generalüberholung" eines Artikels, bei der gleichmal bzw. vor Allem ungewünschte Kritik entfernt wird. Erinnert stark an die Siemens/Kleinfeld Geschichte!

Eine Liste von unterstützenden / ablehnenden Unternehmen wäre gut. was ist zb mit web.de?

Auch wäre ein Hinweis nützlich, daß es de facto auch genug Spam mit SPF PASS gibt, sprich ein volles Whitelisting von SPF PASS eher kontraproduktiv ist. Und daß ein völliges Ablehnen von SPF FAIL immer noch de facto oft zu falsch positiven Ausfilterungen führt.

Siehe beispielsweise http://david.woodhou.se/why-not-spf.html oder http://www.mxlogic.com/news_events/press_releases/07_11_05_SPF.html

Legales relaying

Das Problem, daß gezieltes, Legales relaying nicht mehr möglich sein soll, kann ich nicht sehen. Wenn ich von der Uni aus eine eMail über meinen GMX-Account verschicken will, dann konnektiere ich mich halt auf den GMX smtp-server. Eine kleine Rekonfiguration der Firewall wiegt den Vorteil der effektiven Vereitelung von Spam ja wohl auf. Die eMail-Clients müssten nur insoweit angepasst werden, das sie smtp-Server Kontenabhängig nutzen ( was z.B. Thunderbird schon kann). -- mwmahlberg 12:21, 27. Apr 2006 (CEST)

Das Konnektieren zum GMX-Server verlangt erstmal, dass die Uni dir erlaubt, den Server auch zu Erreichen. Du hast eine falsche Auffassung davon, was "eine kleine Rekonfiguration der Firewall" in groesseren Netzen bedeutet. -- 83.171.149.119 12:06, 28. Mai 2006 (CEST)

Wohl kaum. Ich bin Systemadministrator und verwalte ca. 200 Server. -- mwmahlberg 09:30, 17. Okt. 2006 (CEST)

Erst einmal müssten sich alle Provider dazu verpflichten die selben Ports für die sechs Mail-Protokolle (POP3, SMTP, IMAP sowie jeweils die verschlüsselte Variante) zu nutzen, danach sollten sich alle Firewall-Administratoren dazu verpflichten eben diese Ports freizuschalten sofern der Arbeitgeber die Nutzung der firmeneigenen Infrastruktur für private Zwecke erlaubt. Ich kann beide Seiten verstehen. Natürlich ist es sehr einfach "mal eben" die nötigen Ports freizuschalten, bedenkt man aber die Anzahl der Mitarbeiter bei größeren Firmen und auch die Anzahl der unterschiedlichen Ports bei Mail-Providern kann es den Administrator auf Dauer ganz schön stressen immer wieder hier und da an der Firewall rumdoktorn zu müssen. Bezüglich der kontenabhängigen Nutzung von SMTP-Servern: Sowas kann auch Outlook sowie Outlook Express mindestens seit Office 97! -- An3k 13:33, 28. Mär. 2009 (CET)

Nicht-kommerzielle Anbieter

Vielleicht sollten für die Beispiele nicht kommerzielle Anbieter gewählt werden.

Warum nicht? — Julian Mehnle 23:35, 27. Mai 2006 (CEST)

Konnektieren

"Konnektieren", lustiges Wort, suchst du vielleicht VERBINDEN? --84.112.135.157 00:01, 19. Sep. 2007 (CEST)

Die Kritik kann ich zum Teil nicht nachvollziehen

Also was hier als Kritikpunkte aufgeführt wird, ist für mich zum Teil nicht nachzuvollziehen:

„Die Nutzung eines sauber konfigurierten zentralen Mail-Relays für Endnutzer mit heterogener E-Mail-Adressstruktur innerhalb eines Netzwerkes wird massiv erschwert.“

Warum das denn? Man braucht doch nur für jede genutzte Domain passende SPF-Einträge machen und fertig.

Eventuell hat man keine Zugriffe auf die DNS-Records? Haufenweise Leute benutzen Mailprovider wie gmx.de, web.de, oder werweisswiesiealleheissen. 83.171.149.119 12:03, 28. Mai 2006 (CEST)

„Für private Endnutzer innerhalb eines LANs muss in der Regel der SMTP-Port 25 nach außen hin geöffnet werden (damit Kontaktaufnahme mit dem jeweiligen autorisierten SPF-SMTP-Server möglich ist). Dadurch treten eine Reihe weiterer Sicherheitsprobleme auf (z.B. Viren und Würmer mit eigener SMTP-Engine)“

Das ist schlicht falsch. Es reicht, einen zentralen internen SMTP-Server aufzusetzen und entweder diesen mit dyndns oder statischer IP anzubinden und im SPF-Record einzutragen oder von dort über einen Smarthost im Netz zu verschicken und den Smarthost im SPF-Record einzutragen. Die Endbenutzer versenden dann wie gehabt über das interne Mailrelay. Machen wir hier ständig so, funktioniert bestens.

Alternativ kann man auch das interne Netz maskieren (wird man bei solchen Strukturen ohnehin tun) und die öffentliche IP des Routers im SPF-Record eintragen. Notfalls auf dem Umweg übner dyndns. Auch das ist kein nennenswertes Problem.

dass ist nur dann kein Problem, wenn die Benutzer alle Mails mit Absenderdomains verfassen, die mir gehoeren. Meine Endnutzer moechten aber ihre GMX-Adressen benutzen. Und jetzt? 83.171.149.119 12:03, 28. Mai 2006 (CEST)

Na das geht nicht und ist eine unmittelbare Auswirkung von SPF. Natuerlich ein Kritikpunkt, auch wenn manche Leute das nicht so sehen (wollen). -- 131.188.24.10 23:42, 28. Mai 2006 (CEST)

Vielmehr sollte man nach außen hin Port 587 — SMTP Submission — öffenen. Auf diesem Port nehmen andere Mailserver nur authentifizierte Verbindungen an, somit stellt sich das Viren-/Wurm-Problem nicht. — Julian Mehnle 23:35, 27. Mai 2006 (CEST)

„Mailinglisten und E-Mailweiterleitungen sind nicht ohne Workarounds wie z.B. das Sender-Rewriting-Scheme weiterhin benutzbar. Das Integrieren dieser Workarounds in eine bestehende Infrastruktur kann erhebliche Probleme bereiten oder schlicht unmöglich sein.“

Das ist korrekt.

Nicht ohne Weiteres. Ein Großteil der verwendeten Mailinglistensoftware schreibt nämlich bereits von sich aus den Envelope Sender um, z.B. per VERP. — Julian Mehnle 23:35, 27. Mai 2006 (CEST)

„Erschwerung von gezieltem legalen Relaying, es wird z.B. in aller Regel nicht mehr möglich sein, über den Mailausgangsserver des Arbeitgebers, Providers, Universität,... eine E-Mail mit seiner eigenen privaten GMX-E-Mailadresse als Absender zu schreiben.“

Das ist falsch. Man trägt den Server, den man dort benutzen will, einfach im SPF-Record ein und gut ist. Beispielsweise so: v=spf1 include:t-online.de include:arbeitgeber.com include:uni.edu -all

wie mache ich das denn dann konkret, sagen wir mal, fuer die Domain im Beispiel, naemlich gmx.de? Ich gehe zu GMX und sage denen, sie moechten doch bitte meine Uni in ihren SPF-Record aufnehmen? Wie hoch ist die Wahrscheinlichkeit, dass die das tun? 83.171.149.119 12:03, 28. Mai 2006 (CEST)

Derartige Anbieter würden das in toto wohl eher über smtpauth regeln. mwmahlberg 09:34, 17. Okt. 2006 (CEST)

„Single-Point-of-Failure bei den autorisierten SMTP-Servern: Sind die Postausgangsserver z.B. von GMX überlastet (was nicht selten vorkommt), so kann keine Mail mit GMX-Absendern abgeschickt werden. Während im bisherigen Verständnis von SMTP der Benutzer den ihm nächsten Mailserver benutzt (z.B. den seines Providers), und sich dieser Mailserver um die Zustellung kümmert, muss nun der Benutzer selbst in regelmässigen Abständen die Verfügbarkeit des GMX-Servers testen, um seine Mail zustellen zu können.“

Wenn ein Mailhoster nicht in der Lage ist, ein seinen Erfordernissen entsprechendes Maß an Redundanz und Bandbreite in den Mailausgangsservern zur Verfügung zu stellen, sollte man schlicht zur Konkurrenz wechseln.

SPF erlaubt davon abgesehen sehr wohl die Nutzung verschiedener Postausgangsserver, man muß diese halt einfach nur eintragen. Das Problem trifft also wenn überhaupt nur solche Anwender, die ihre DNS-Records nicht selbst verwalten können.

genau um diese Anwender geht es. Ich behaupte einfach mal pauschal, dass ein Grossteil der Email-Nutzer keine eigenen Absenderdomains verwenden oder besitzen. 83.171.149.119 12:06, 28. Mai 2006 (CEST)

„Ein User mit mehreren privaten E-Mailadressen (ohne administrativen Zugang auf die Domain) wird immer auch mehrere zugehörige Postausgangsserver zu jeder E-Mailadresse verwalten müssen, was einen geeigneten E-Mail-Client voraussetzt.“

Ist korrekt, aber wo ist das Problem? Geeignete Mailclients gibts zuhauf. Alternativ kann man das auch über einen lokalen Mailserver lösen, der Absenderbezogene Transport Tables kann.

„SPF benutzt momentan keine eigenen DNS-Resource-Records, sondern die bereits existierenden TXT-Records. Legitime, bereits existierende andere DNS-Anwendungen, die TXT-Records benutzen, sind zusammen mit SPF nicht verwendbar.“

Das ist so pauschal auch schlicht falsch. Diese anderen DNS-Anwendungen sind nur dann nicht zusammen mit SPF verwendbar, wenn die Namensräume der TXT-Records miteinander inkompatibel kollidieren. Da jeder SPF-Record mit "v=spf1" anfängt, kann die Anzahl dieser DNS-Anwendungen nicht besonders groß sein. Mir fällt derzeit keine einzige ein.

Trotzdem wäre es natürlich eleganter, für SPF einen eigenen RR-Type zu definieren. Nur wird man damit Akzeptanzprobleme kriegen, weil das nicht jede DNS-Software (Client wie Server) einfach so können wird. — 195.140.35.35 10:42, 26. Mai 2006 (CEST)

Unzureichende Eignung als Schutz vor Adressfälschungen?

Letzter Punkt auf der Seite:

"Unklare Positionierung von SPF: Die Entwickler von SPF weisen gerne darauf hin, dass SPF kein Spamschutz per se, sondern lediglich ein Schutz vor Adressfälschungen darstellt. Dafür allein ist SPF jedoch nur sehr unzureichend geeignet, da die Granularität der Adressprüfung prinzipbedingt nur ganze Domains umfasst (und keine Individuen) und auch keinerlei kryptographische Sicherheitsmechanismen die Authentizität des sendenden Rechners (oder gar des Senders) an sich sicherstellen. Damit stellt SPF keinen Adressschutz, sondern lediglich eine Art von Relay-Schutz dar."

Da komme ich ja vorne und hinten nicht mit: Was hat die Granularität mit der Verlässlichkeit der Adressprüfung zu tun? Die ärgert doch höchstens die Nutzer - wie in den hier angeführten Beispielen des privaten Versands aus einem abgeriegelten Netz (Arbeitegber). Folge: Die Benutzer wechseln den Provider pder der Provider nutzt SPF nicht. Aber wenn es genutzt wird, ist es doch zuverlässig; jedenfalls nicht wegen dieses Aspekts unzuverlässig.

Und nun die Qualifizierung: "nur sehr unzureichend geeignet". Der einzige sachliche Aufhänger sind die fehlenden Zertifikate/Signaturen. Welch ein Witz. Das lässt sich nur mit IP-Spoofing gegen den empfangenden MTA machen, oder übersehe ich etwas? Das aber wird nie passieren. Folglich ein rein theoretischer Einwand. Ich würden den Kritikpunkt komplett rausnehmen. --Hauke Laging 20:28, 31. Mär. 2007 (CEST)

Kritik

"Das Integrieren dieser Verfahren in eine bestehende Infrastruktur kostet Zeit und Geld, es geschehen Fehler; diese kosten wieder Zeit und Geld."

Dieser Satz ist imho überflüssig. Implementieren von egal welchem Spamschutz kostet immer Zeit und Geld und es können immer Fehler passieren die Zeit und Geld kosten.

Das möchte ich aber mal unterschreiben. - Das löschen von Spam kostet auch Zeit und Geld, mitunter sogar mehr wie dieser Einmalaufwand. Bubezleb (Diskussion) 21:22, 25. Aug. 2012 (CEST)

erledigt, Satz ist raus. --Matthäus Wander (Diskussion) 12:53, 6. Jul. 2013 (CEST)

" Das Problem wird sich mit zunehmendem Übergang auf den dedizierten SPF-Record gelöst haben."

Dieser Satz steht im Widerspruch zum Eintrag https://de.wikipedia.org/wiki/SPF_Resource_Record, in dem erklärt wird, "Dieser Resource-Record-Typ wurde jedoch im April 2014 widerrufen". (nicht signierter Beitrag von 87.149.15.230 (Diskussion) 08:04, 20. Aug. 2015 (CEST))

Webformular

Ich denke, korrekter wäre es, nicht den Reply-to header zu verwenden, sondern den eigentlich dafür vorgesehenen "Sender" header. Also email des Servers steht im "Sender", die vom Ausfüllenden steht im "From". --Th. Rieschl 14:58, 22. Aug. 2009 (CEST)

Exakt so gehört es. Dann gibt es auch keine Probleme. --Bachsau (Diskussion) 00:27, 19. Mär. 2016 (CET)

Mails, SPF, United Internet

Was ich ja eigentlich am besten an SPF finde, ist, dass Weiterleitungsadressen nicht mehr funktionieren. D.h. myname@example.com kann nicht mehr an eine GMX-Adresse (gilt auch für andere streng prüfende Provider, z.B. ISH/Unitymedia) weitergeleitet werden, sofern auch GMX-Nutzer (in Deutschland ja nicht unwahrscheinlich) an diese Adresse Mails schicken. Der GMX-Server (bzw. ISH/Unitymedia nach einer SPF-Prüfung bei GMX) lehnt dann alle diese Mails ab.

Interessanterweise funktioniert dies natürlich wunderbar, wenn man die Domain bei 1&1 (auch United Internet) gehostet hat. Die Mailserver von 1&1 sind nämlich berechtigt (bzw. im SPF-Record-IP-Bereich von GMX aufgenommen) Mails von GMX zu versenden. D.h. ist example.com bei 1&1 gehostet, so kann myname@example.com ohne Probleme an eine andere Adresse weitergeleitet werden, da GMX-Nutzer die Mail auch nach einer Prüfung von einer berechtigten Adresse (eben dem 1&1-Mailserver) geschickt haben. Auch eine Art Standortvorteil... 178.6.8.230 20:22, 3. Sep. 2012 (CEST)

"Probleme mit Webformularen"

Es gibt kein Problem mit Webformularen. Wenn aus Webfomularen unbedingt wirklich eine E-Mail generiert werden muss, verwendet man dafür ein eigens dafür eingerichtetes E-Mail-Konto. Wenn der Empfänger tatsächlich E-Mails vom Nutzer bekommen will, wird kein Webformular verwendet, sondern die E-Mail-Adresse veröffentlicht. --80.153.250.36 13:09, 20. Aug. 2015 (CEST)

Oder man benutzt ein Formular, trägt den Absender aber nur als "From" ein, nicht in den Envelope-From. --Bachsau (Diskussion) 00:27, 19. Mär. 2016 (CET)

Das ist aktuell im Arktikel nicht klar formuliert. Ich habe erst durch diesen Kommentar gelernt dass es zwei unterschiedliche FROM Felder gibt.

Alternativ könnte man, analog zum DMAC Arktikel, vorschlagen das Reply-To Feld zu verwenden und das FROM Feld auf dem original Sender zu belassen zu können. --SallmannE (Diskussion) 17:45, 5. Dez. 2023 (CET)

Kritik an der Kritik

Bitte den roten Warnhinweis streichen. »Belege« sind bei technischen Themen nachgerade unproduktiv, und führen eher zu populistischem Nachgeplappere. Entweder ein technisches Argument ist nachvollziehbar und nicht total an den Haaren herbeigezogen, oder es gehört – trotz vielleicht häufiger Nennung – weg oder nur zur Diskussion. – – Fritz Jörn (Diskussion) 21:23, 13. Feb. 2019 (CET)

Zustimmung, etwas eingedampft, Redundanzen eingedampft, Versuch einer grober Überarbeitung.--wdwd (Diskussion) 21:46, 16. Feb. 2019 (CET)

Beispiel: aussagekräftiger

Hi allerseits,

das Beispiel stimmt erstes mal nicht mehr, denn gmx.de redirect auf gmx.net

host -t TXT gmx.de
gmx.de descriptive text "v=spf1 redirect=gmx.net"

Aber auch gmx.net find ich mit nur ip4s ein wenig langweilig,

host -t TXT gmx.net
gmx.net 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 ip4:82.165.229.31 ip4:82.165.230.21 -all"

Schöner fände ich den von wikimedia.org, der hat ip4, ip46 und ein include.

host -t txt wikimedia.org
wikimedia.org descriptive text "v=spf1 ip4:91.198.174.0/24 ip4:208.80.152.0/22 ip6:2620:0:860::/46 include:_spf.google.com ip4:74.121.51.111 ~all"

Kann ich das ändern? greetz vanGore 14:39, 5. Dez. 2021 (CET)

Spamassassin Scores

„Der standardmäßige SPAM-Wert ist aber zu vernachlässigen, da diese viel zu niedrig ist (min. 0.1 Punkte bis max. 0.9 Punkte).

Die Entwickler Begründen Ihre aussage mit folgendem Statement:“

# SPF
# Note that the benefit for a valid SPF record is deliberately minimal; it's
# likely that more spammers would quickly move to setting valid SPF records
# otherwise.  The penalties for an *incorrect* record, however, are large.  ;)

Die zitierte Begründung erklärt nicht die 0.001 Punkte bei SPF_FAIL (letzte Spalte). SPF_NEUTRAL und SPF_SOFTFAIL werden mit 0.7 und 0.6 höher bepunktet. Laut diesem Diskussionsbeitrag ist SPF_FAIL zu anfällig für falsch positive Ergebnisse, SPF_SOFTFAIL jedoch nicht. --Matthäus Wander 17:45, 17. Mai 2023 (CEST)