Einführungsstrategie in zwei-Phasen

"Die Kunst des Fortschrittes besteht darin, Ordnung inmitten der Veränderung zu bewahren und Veränderung inmitten der Ordnung."
-- Alfred North Whitehead

Am Anfang können Domaininhaber ?all setzen, was so viel wie "standardmässig unbekannt" bedeutet. Dann werden deren Benutzer auf authentifizierte SMTP Möglichkeiten (SASL, usw) vorbereitet und geschult. Eventuell wird ein Zeitpunkt festgelegt, wo alle Benutzer dieses Verfahren verwenden müssen.

Wenn die Mehrzahl der Benutzer das Richtige machen (Mails nur noch über vom Administrator festgelegten Mailserver verschicken) kann man die Standardantwort in -all abändern, was soviel bedeutet wie "standardmässig ablehnen". Dieses sagt einen SPF-fähigen Empfängermailserver, dass es sicher ist, SPF-Verletzung abzulehnen, anstatt diese nachträglich anzunehmen und eventuell später als Spam zu klassifizieren.

Was wird wahrscheinlich passieren

Eine Anzahl von Bedenken kamen schon auf. Ja, einige werden sicherlich schmerzlich sein, aber als ein Ganzes, sehe ich ein grossen Vorteil. Ich habe SPF mit Mitglieder technischer Gemeinden besprochen, deren Meinung ich respektiere. Keiner hat grössere Mängel erkannt. Die Meisten glauben der Einführung stehe nichts im Weg.

Freiwillige Einführung. Einige Domains werden langsam ihre SPF Informationen über das DNS bekanntgeben; Hotmail, AOL und weitere grosser Provider wären erfreut sich nicht mehr mit falschen Missbrauchsberichte, die von technisch unversierten Spamopfer stammen, auseinandersetzen zu müssen.

Ablehnung der Einführung. Einige Domains werden keine SPF-Einträge bekanntgeben. Spammers werden Mails verfälschen, so dass diese Domains als Absenderadressen verwendet werden. Dieses passiert auch schon: Spammers verfälschen ständig den Absender, so dass diese anscheinend von @aol.com oder @hotmail.com kommen. Die meisten angesehenen Betriebe verfolgen die Markenmissbrauch. Es sollte ungewöhnlich erscheinen, wenn eine Domain keine SPF-Einträge hat: Es bedeutet, dieser Betrieb stört es nicht, wenn Emails mit deren Domain als Absenderadresse gefälschten durch Spammer verschickt werden. Wenn SPF weitgehend eingeführt ist und es wird entschieden, dass das nicht vorhandenseins von SPF-Einträgen stark mit Spammer in Verbindung gesetzt werden kann, werden Leute anfangen Mails aus diesen Domains zu verweigern (Blacklisten), so dass diese dann gezwungen werden, SPF-Listen bekanntzugeben.

Guerilla Einführung. Gütige Dritte können erscheinen, die SPF-Listen für langsame Domaininhaber bekanntgeben, während diese es nicht tun. Letztendlich wird es der Domaininhaber satt haben, dass diese Listen nicht aktuell genug sind und eigene Listen bekanntgeben. Es werden eventuell auch Dienstleister erscheinen, die die diese Aufgabe bei Domaininhaber, die sich damit nicht auskennen, übernehmen.

"Schöne-Namen" Domains ("Vanity domains"). Was bedeutet das für denjenigen, die eine Domain einfach aus kosmetischen Gründen verwenden (kurze URL, schöne Email Adresse...)? Wenn diese nicht willig oder unfähig sind, die entsprechenden DNS-Einträge zu erstellen, haben diese Domaininhaber die Wahl bei SPF einfach nicht mitzumachen. Email funktioniert trotzdem wie seither.

Unterstützung in MTAs (Mailübertragungs Server). Wir haben die Möglichkeit bei den vier gängigsten Opensource MTAs die Unterstützung der SPF-Abfragen zu integrieren.

Unterstützung im DNS. Alle bereits existierenden DNS-Server haben schon die Möglichkeit TXT-Einträge zu verwalten. Hier sind also keine Änderungen notwendig.