Diskussion:Sender Policy Framework

message: 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)
replies: text: 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)
replies: text: Wohl kaum. Ich bin Systemadministrator und verwalte ca. 200 Server. -- mwmahlberg 09:30, 17. Okt. 2006 (CEST)
replies: text: 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)
thread_title:  Legales relaying 

message: Vielleicht sollten für die Beispiele nicht kommerzielle Anbieter gewählt werden.
: Warum nicht? — Julian Mehnle 23:35, 27. Mai 2006 (CEST)
thread_title:  Nicht-kommerzielle Anbieter 

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

message: Also was hier als Kritikpunkte aufgeführt wird, ist für mich zum Teil nicht nachzuvollziehen: 
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)
replies: text: 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)

text: 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)

text: 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)

text: 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)

text: 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)

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

text: 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)
thread_title:  Die Kritik kann ich zum Teil nicht nachvollziehen 

message: 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)
thread_title:  Unzureichende Eignung als Schutz vor Adressfälschungen? 

message: "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)
replies: text: erledigt, Satz ist raus. --Matthäus Wander (Diskussion) 12:53, 6. Jul. 2013 (CEST)
thread_title:  Kritik 

message: 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)
replies: text: Exakt so gehört es. Dann gibt es auch keine Probleme. --Bachsau (Diskussion) 00:27, 19. Mär. 2016 (CET)
thread_title:  Webformular 

message: 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)
thread_title:  Mails, SPF, United Internet 

message: 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)
replies: text: Zustimmung, etwas eingedampft, Redundanzen eingedampft, Versuch einer grober Überarbeitung.--wdwd (Diskussion) 21:46, 16. Feb. 2019 (CET)
thread_title:  Kritik an der Kritik 

message: 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)
thread_title:  Beispiel: aussagekräftiger 

message: „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)
thread_title:  Spamassassin Scores