Sender Policy Framework

Sender Policy Framework (afgekort SPF) is een protocol dat tot doel heeft spam te verminderen. Men hoopt e-mail spoofing en spam te verminderen door vast te stellen of de verzender van een e-mailbericht gerechtigd is te verzenden namens de vermelde afzender van het bericht.^[1] De procedure is vastgelegd in RFC 7208.

Geschiedenis

Het concept werd voor het eerst publiekelijk genoemd in 2000, maar bleef destijds grotendeels onopgemerkt.^[2] Pas in 2002 verscheen op de IETF-mailinglijst "namedroppers" een eerste ontwerp van een SPF-achtige specificatie, opgesteld door Dana Valerie Reese,^[3][2] die niet op de hoogte was van de eerdere vermelding. Een dag later plaatste Paul Vixie op dezelfde lijst zijn eigen voorstel, wat veel aandacht trok en leidde tot de oprichting van de IETF Anti-Spam Research Group (ASRG).^[4][2] Op hun mailinglijst werd het idee verder uitgewerkt. Onder de ingediende voorstellen waren onder meer "Reverse MX" (RMX) van Hadmut Danisch en "Designated Mailer Protocol" (DMP) van Gordon Fecyk.^[5]

In juni 2003 voegde Meng Weng Wong de RMX- en DMP-specificaties samen^[6] en vroeg om feedback. In de volgende zes maanden werden veel wijzigingen doorgevoerd en groeide de gemeenschap achter SPF aanzienlijk.^[7]

Begin 2004 richtte de IETF de MARID-werkgroep op om SPF en het CallerID-voorstel van Microsoft te combineren tot Sender ID. Dit mislukte door technische en licentieproblemen.^[8] De SPF-gemeenschap keerde terug naar de oorspronkelijke, "klassieke" SPF-specificatie. In juli 2005 keurde de IESG deze versie goed als IETF-experiment en nodigde de gemeenschap uit om SPF gedurende twee jaar te observeren.^[9] Op 28 april 2006 werd SPF gepubliceerd als experimentele RFC 4408.^[10]

In april 2014 publiceerde de IETF SPF als voorgestelde standaard in RFC 7208.^[11]

Werking

SPF vereist het gebruik van een TXT-record in de DNS-server waarin wordt aangegeven welke servers berichten mogen sturen namens een domeinnaam:

v=spf1 mx include:mijn.example.nl ip4:1.2.3.4 ip6:FFFF::0000 -all

Het bovenstaande voorbeeld is de simpelste implementatie van SPF die beschikbaar is. Hierin staan verschillende gegevens:

v=spf1 Sender Policy Framework versie = SPF1,

mx Alle mailservers mogen sturen (deze worden in DNS opgenomen in de MX-record)

include:mijn.example.nl Accepteer alles wat het SPF-record van het domein mijn.example.nl accepteert

ip4:1.2.3.4 Email verstuurd vanaf het IPv4-adres 1.2.3.4 moet geaccepteerd worden

ip6:FFFF::0000 Email verstuurd vanaf het IPv6-adres FFFF::0000 moet geaccepteerd worden

-all Hiermee wordt aangegeven dat alle andere mail niet legitiem is.

Een ontvangende mailserver kijkt naar het domein van de MAIL FROM- of Return-Path-header en haalt daarvan het SPF-record op. Als er een SPF-record bestaat en het IP-adres van de verzendende mailserver komt niet overeen met een van de IP-adressen in het SPF-record, dan kan het e-mailbericht geweigerd worden. Merk op dat het hier om de MAIL FROM- of Return-Path-header gaat en niet om de DISPLAY FROM- of From-header die gewoonlijk in een mailclient weergegeven wordt. SPF beschermt daarmee vooral de communicatie tussen mailservers en beschermt niet tegen het vervalsen van de voor de gebruiker zichtbare afzender in een e-mailbericht.^[12] Hiervoor kan eventueel DKIM gebruikt worden.

In het verleden was er sprake van een specifiek SPF-record op DNS-servers. Deze is echter nooit ingevoerd hoewel de IANA er wel een code voor heeft toegewezen.

Beperkingen van SPF

Hoewel SPF in theorie relatief goed werkt, zijn er een aantal mankementen aan het protocol, waardoor SPF op zichzelf niet voldoende is om e-mail spoofing en spam tegen te gaan: Veel grote organisaties en diensten gebruiken namelijk nog steeds niet de volledige bescherming van SPF. Dit laat onder andere toe dat klanten, werknemers en andere onschuldige ontvangers nog steeds phishing-mails krijgen namens deze bedrijven. Het ontbreken van een dergelijk SPF record heeft zelfs de Nederlandse overheid al eens in een negatief daglicht gezet,^[13] maar nog steeds, anno 2020, is de (Nederlandse) consument en werknemer niet voldoende beschermd tegen spoofing en phishing.

Daarnaast moeten de records exact goed zijn om bescherming te bieden; bij foute of incomplete records zullen veel mailservers de e-mails automatisch weigeren. Bij een typfout, fout in de volgorde of het ontbreken van bijvoorbeeld include, mag de ontvangende mailserver het record volgens de RFC 7208 negeren. Aan de andere kant kan een record ook waardeloos zijn, doordat qualifiers niet voldoende zijn ingesteld. Wanneer het record bijvoorbeeld -all bevat, kan de ontvangende mailserver zijn ingesteld om geen andere e-mails door te laten. Wanneer het record echter ?all bevat, zal de mailserver óók alle andere e-mails doorlaten. Dat zorgt ervoor dat de ontvanger alsnog malafide e-mails kan blijven ontvangen, hoewel de mailserver deze mogelijk markeert als potentieel schadelijk.

Een andere beperking van SPF is dat het protocol enkel de zogeheten envelop beschermt en niet de inhoud van de e-mail. Hier komt bij kijken dat op de envelop een andere afzender vermeld kan worden dan bij de inhoud van de e-mail. Hiervoor is DKIM opgezet. Vervolgens is er het probleem dat niet elke ontvangende mailserver actief beleid voert op SPF en DKIM, waardoor ook e-mails zonder deze records worden doorgelaten. Om dat laatste gat te dichten, is in 2012 DMARC in het leven geroepen. Hiermee geeft de verzender aan wat er moet gebeuren met e-mails namens zijn domein, wanneer die niet voldoen aan de gestelde eisen.^[14]

Externe link

• OpenSPF-website (mirror) met verschillende implementaties voor mailservers
• Internet.nl, initiatief van de internetgemeenschap en de Nederlandse overheid waarop onder andere SPF van een domein getest kan worden.
• senderpolicyframework.com en spfwizard, tools voor het opzoeken, valideren en generatie van een SPF record