SPF, DKIM och DMARC – Del 1 av 4

Det har funnits olika varianter av system för att skicka elektroniska meddelande sedan 1960-talet, på den tiden rörde det sig dock om meddelande mellan användare i slutna system och det första steget för att skicka epost mellan olika system får anses vara vad som beskrivs i RFC 524. Denna beskriver hur man med hjälp av två kommandon i File Transfer Protocol, FTP, ska kunna utväxla meddelande med varann. Detta blev dock aldrig någon succé. Det var för komplicerat så den egentliga starten på epost som vi känner det idag fick vänta.

Året var 1982 då Jonathan B. Postel (enligt undertecknad är just namnet Postel roande med tanke på ämnet) publiserade RFC 821. Den beskriver protokollet Simple Mail Transfer Protocol. Det kan i detta sammanhang vara värt att notera att om man söker i RFC 821 efter ord som security eller secure så får man exakt noll träffar. Som sagt året var 1982 och världen bestod enligt ett stort gäng långhåriga hippies på Berkeley ungefär av ett stort snällt gäng andra långhåriga hippies. Säkerhet och var någon kom ifrån var helt enkelt inte prioriterat.

I april 2001 ersattes RFC 821 med RFC 2821. Säkerhet hade blivit ett begrepp och nu finns det faktiskt ett avsnitt som handlar om just säkerhet beskrivet.

För att avsluta historielektionen så ersattes även RFC 2821, denna gången med RFC 5321. Även om denna fått några tillägg så är det här moderna epostsystem har sina rötter, året för denna är 2008. Och i avsnitt 7.1 står det att läsa följande:

Det vill säga, vi har med ett ganska osäkert protokoll att göra när det kommer till att veta vem som verkligen är avsändaren till det vi läser.

För att råda bot på detta och flera andra problem (SPAM tex) så har andra tekniker introducerats. Nedan följer de olika teknikerna och en förklaring.

Sender policy Framework, eller SPF, är första initiativet att råda bot på så kallade spoofade mail. Det nämns första gången år 2000 men det är 2002 det tar fart och ett år senare bidrog bland andra Meng Wong (se fun facts för mer info om denna driftige man) till att det blev kommersiellt gångbart. I april 2004 blev det en standard.

Låt oss börja med vad SPF inte är. SPF är inte en antispam lösning. SPF kommer inte stoppa varken inkommande eller utgående spam. Så vad är det då? SPF är en lösning på så kallad spoofing, dvs att någon utger sig för att vara någon annan än den de är. Så när någon, kan vara någon som skickar spam men nuförtiden mycket oftare någon som ägnar sig åt mer avancerade saker, skickar epost så kommer SPF kolla om dessa brev kommer ifrån den domän som de säger att de kommer ifrån.

Man kan enkelt se det som att när någon ringer dig så tar du telefonkatalogen (ja det fanns en gång en bok som hette så) och kollar personens namn och ser om det matchar det telefonnummer som just nu ringer. I epostvärlden så kommer den mottagande servern att se att det kommer ett mail ifrån en viss domän (ifrån avsändaradressen som presenteras i SMTP-konversationen), därefter kolla i denna domäns DNS efter ett SPF-record för att se om det matchar den IP-adress som brevet just kom ifrån. I fallet att det matchar så går epost direkt till användarens inkorg och i fallet att det inte matchar så läggs det i skräppost eller tas bort.

SPF har en del begränsningar och risker som kan komma väldigt ovälkommet om det slås på utan att man vet vad man gör. Om vi går tillbaka till exemplet med att någon ringer till dig och du slår upp telefonkatalogen men inte hittar något nummer så kan man säga att man faktiskt inte vet mer än innan man kollade och därmed inte kan fatta ett mycket klokare beslut i frågan om personen som ringer verkligen är den som den utger sig för att vara. Men kanske säger det ändå något… Man undrar ju lite om varför den inte finns i telefonkatalogen. Det är på samma sätt med SPF. Att inte ha ett SPF är inte bra. Okej, då tänker vän av ordning att det ska vi ha. Vi tar och matar in IP-adressen för vår mailserver i vår DNS och så kör vi. Detta är potentiellt väldigt dåligt!

I fallet att vi har fler servrar eller tjänster (nyhetsbrev mm) som nu inte är med i listan så blir dessa sannolikt skickade till skräppost eller borttagna. Det är därför väldigt viktigt att få med samtliga utgående servrar när man lägger upp ett SPF-record.

En begränsning som finns i SPF är att antalet namnuppslag som kan läggas in i ett record. Man kan inte lägga in fler än tio namnuppslag. Värt att notera är att om man lägger in en URL till servrar, tex, spf.protection.outlook.com, som är SPF för Office 365, så slås detta upp till flera servrar.

Ett annat scenario som inte fungerar så bra är vidarebefordring.

Det vill säga att vår server skickar till en annan mailserver, här finns en vidarebefordring till ytterligare en server. Den första transporten går bra men när det vidarebefordras så uppstår problemet om den andra servern inte finns med i vårt SPF-record. Eftersom vidarebefordring är något alla användare kan göra är det i princip omöjligt att lösa detta.

För att skapa ett bra SPF-record vill vi uppnå följande:

·       Alla utgående mailservrar för vår domän är definierade

·       Vi vill för alla andra ha en så hård policy som möjligt (mer om detta nedan)

·       Informera berörda om att vi som organisation använder SPF och varför

Det första punkten är ganska given, att ha alla servrar definierade är en förutsättning för att epost ska komma fram till mottagaren.

Att ha en så ”hård policy” som möjligt syftar på vad mottagande epostservrar ska göra med epost som påstår sig komma från oss men som inte är med bland våra definierade servrar i vårt SPF-record.

Punkten kring information är den absolut svåraste, speciellt i en större organisation. Men vi bör ska en intern policy för hela vår organisation för att förhindra att någon avdelning på egen hand upphandlar något system som vi inte kan hantera. Just gällande SPF brukar detta inte vara ett oöverkomligt problem men vi kommer senare i denna serien se vikten av detta och hur detta kan spara oss stora pengar.

Vi på Altitude 365 har naturligtvis ett SPF-record, nedan tittar vi på hur det ser ut och analyserar de ingående delarna. För att göra det en smula mer förklarande så har jag modifierat det något från verkligheten.

”v=spf1 include:spf.protection.outlook.com include: 90.224.80.216 include:servers.mcsv.net include:spf.fouredge.se -all”

För att skapa ditt eget SPF-record använd gärna denna guide (men iaktta försiktighet enligt tidigare beskrivna risker):

https://www.spfwizard.net/

För att sammanfatta detta kan vi säga att SPF är ett enkelt sätt att införa en viss kontroll på vem som får skicka som vår domän, vi styr detta via våra egna DNS-record. SPF på egen hand kommer sannolikt inte lösa några stora problem men idag tillhör detta en av självklarheterna för varje seriös e-postdomän. Till hör du dem som ännu ej har ett SPF-record eller ett svagt SPF-record så finns det hjälp att få. Utöver de länkar du ser nedan så erbjuder Altitude 365 en workshop som är inriktad på just detta. I denna får du dessutom kontroll och kunskap om DKIM och DMARC också.

Nästa del i denna bloggserie kommer handla om just DKIM- Stay tuned!