SMTP hat ein Sicherheitsloch: Jeder kann eine beliebige Absenderadresse bei einem Mailversand angeben. Diese Lücke wird von Spammern ausgenutzt, um Absenderadressen zu fälschen. Schliesse diese Lücke, und wir können die Spammer sinnvollerweise über deren Absenderdomain ablehnen.
Ich bin ein System-Administrator (und kann englisch). How do I implement SPF? (der Verweis leitet dich weiter zu den Ursprungsseiten auf englisch).
Ich bin ein Manager/Entscheider. Gib mir bitte eine kurze Zusammenfassung, worum es geht.
Neuigkeiten
26. Februar 2004: Die neuste Version von Mail::SPF::Query kann nun auch Caller-ID Einträge parsen! SPF-Anwendungen können somit auch Hotmail's oder Microsoft.com's Einträge lesen und diese in SPF Einträge umwandeln. Bemerkung: SPF wurde entwickelt um den Envelope-Sender zu schützen so dass du keine Rückmeldungen der Art 'Du hast uns ein Virus geschickt' bekommst. Caller-ID wurde entwickelt, um die Kopfzeilen der Emails zu schützen, damit eBay und PayPal den Schaden, der durch Phishing Spam (betrügerisches verfälschen der Absendeadresse) entsteht, die z.B. den Empfänger täuschen mit Anforderungen wie "Deine Kreditkarte ist abgelaufen, bitte geben Sie diese hier erneut ein". Wenn du über Viren verärgert bist, die an dich zurückkommen, solltest du SPF-Einträge veröffentlichen. Wenn du ein grösseres Unternehmen oder Bank vertrittst und wegen Phishing besorgt bist, solltest du Caller-ID Einträge veröffentlichen. Davor solltest du aber bei Microsoft vorbeischauen, da du eventuell eine technologische Lizenz benötigt: Microsoft kontrolliert den Patent von Caller-ID.
24. Februar 2004: Microsoft hat seine Caller-ID für E-mail, ein naher Verwandte von SPF, angekündigt. Einige Leute haben Probleme mit Microsoft Word Dateien, deswegen werden Sie hier als PDF versions zur Verfügung gestellt. Andere Nachricht: Wir haben bereits über 7500 registrierte Domains.
12. Februar 2004: Ein Artikel im eWeek [englisch] diskutiert SPF's Zusammenspiel mit dem IETF Standardisierungsprozess. Während es schön wäre, wenn der SPF Entwurf in den nächsten Wochen schon als ein Experimenteller oder Entwurfsstandard akzeptiert würde, erfordert jedoch der konservative IETF Prozess, dass eine langwierige Prozedur verfolg wird, indem ein technisches Meeting (BOF) abgehalten wird, eine Arbeitsgruppe gebildet wird und man sich in den nächsten Jahren ein paar Mal zusammensetzt. Die konservative Haltung hat der IETF bisher gut getan, und man will sicher keine voreilige Entscheidungen treffen. Jedoch sind die Probleme dringend und es gibt schon Leute die Email komplett aufgeben. Wir müssen so schnell wie es uns erlaubt ist handeln.
11. Februar 2004: Die Spezifikation wurde als ein Internet-Draft mit der Versionsnummer 00 eingereicht. Dies stellt den ersten Schritt in Richtung eines RFC Standards dar. Ausserdem wurde der Name von "Sender Permitted From" zu "Sender Policy Framework" geändert.
5. Februar 2004: Jetzt ist auch die "FAQ" Seite (Häufig gestellte Fragen) übersetzt.
4. Februar 2004: Die SPF-Registrierung überschreitet die 6000 Marke. Unter anderen haben schon folgende wichtige Domains SPF-Einträge: AOL.com, Altavista.com, DynDNS.org, E!Online.com, GNU.org, LiveJournal.com, MotleyFool.com, OReilly.com, Oxford.ac.uk, PairNIC.com, Perl.org, PhilZimmermann.com, SAP.com, Symantec.com, Tiscali.de, Ticketmaster.com, w3.org und natürlich foo.com.
2. Februar 2004: Die SPF-Registrierung überschreitet die 5500 Marke.
Zu dieser Übersetzung
Diese Seiten wurden von den Ursprungsseiten ab dem 28. Januar 2004 so gut wie möglich ins Deutsche übersetzt. Ziel ist es zunächst einmal Entscheidern eine grobe Übersicht der SPF-Technik zu geben.
Maßgebende Quelle jeglicher SPF-Informationen bleibt weiterhin die Ursprungsseiten unter http://spf.pobox.com/. Dort findet man auch sehr viel mehr Informationen (vor allen die technischen Aspekte). Leider habe ich momentan keine Zeit, diese auch zu übersetzen, das kann sich aber auch ändern.