Identitet og autentificering i email

Historietime

Siden David H. Crocker i 1982 udgav RFC822 som blev fundamentet til den email vi kender i dag er der sket meget. Dengang blev email brugt hovedsageligt til at udveksle forskningsmaterialer mellem forskellige amerikanske universiteter. Email var i sin spæde ungdom. World Wide Web var der ingen der havde tænkt på endnu.

Alle stolede på hinanden idet beskeder kun blev udvekslet mellem en lille, lukket gruppe af universiteter. Det var ikke nødvendigt at autentificere gyldigheden af afsenderen eller indholdet af beskederne.

I løbet af de næste 30 år indså man at det oprindelige design hvor man tog alt hvad der stod i beskederne for pålydende ikke fungerede på et moderne internet. Her vrimler der nemlig med brodne kar der prøver at udnytte godtroenheden hos normale brugere ved at misbruge navnene på kendte brands til at lokke dem til at klikke i eller spamfiltre til at fejlklassificere deres emails.

Afsenderen af en email

Når man arbejder med emails skal man holde tungen lige i munden. Der er mange niche-specifikke floskler. Det gør sig især gældende når man omtaler afsenderen af en email. Der er nemlig flere.

Hvis man forestiller sig emailen som et gammeldags brev. Et brev bliver sendt i en kuvert og har typisk:

• Afsender angivet på kuverten
• Modtager angivet på kuverten
• Afsender angivet i brevet
• Modtager angivet i brevet

I forhold til postvæsenets arbejde med brevet, er det kun de to adresser angivet på kuverten der er interessante. Skulle modtageren ikke længere bo på adressen, er det også til afsender-adressen på kuverten brevet sendes tilbage til.

Når du har modtaget brevet, fjernes konvolutten af din sekretær og lægges i din indbakke. Herefter ser du kun adresserne specificeret i selve brevet. Konvolutten er ikke længere interessant.

Det samme gør sig gældende for email. Her arbejder man med:

• Afsender angivet på kuverten: RFC5321.From.
  Også kaldet envelope-sender, return-path eller bounce-adresse.
• Modtager angivet på kuverten: RFC5321.To.
  Også kaldet envelope-recipient.
• Afsender angivet i brevet: RFC5322.From
• Modtager angivet i brevet: RFC5322.To

For at være helt klare i mælet, omtaler man dem efter den RFC hvori de er defineret. Det drejer sig om:

• RFC5321 – Simple Mail Transfer Protocol
• RFC5322 – Internet Message Format

De to RFC5321-adresser er dem der benyttes i SMTP-sessionen i MAIL FROM– hhv. RCPT TO-skridtet. Hvorimod RFC5322-adresserne er dem du ser i dit mailprogram.

Hvis mailen bouncer, er det således også RFC5321.From-adressen der bounces til og ikke RFC5322.From. Det er det der gør at, en ESP som Ubivox kan give mulighed for at du sender fra din egen email-adresse samtidig med at vi har mulighed for at samle bounces op. Det er muligt idet RFC5321.From-adressen peger på en af ESP’en kontrolleret adresse og RFC5322.From er din egen personlige afsenderadresse.

Typisk er de to modtageradresser (RFC5321.To og RFC5322.To) næsten altid ens.

For en email fra christian@ubivox.dk til peter@eksempel.dk der passerer gennem Ubivox, vil de forskellige adresser se nogenlunde sådan her ud:

• RFC5321.From: bounce-oj1efnpdxlkj-2aos169t4jqx8nmudkvdlbl8ibi6dw3@kunde.uxmail.io
• RFC5321.To: peter@eksempel.dk
• RFC5322.From: christian@ubivox.dk
• RFC5322.To: peter@eksempel.dk

Den lidt kryptiske RFC5321.From tillader således Ubivox at spore bounces til præcis hvilken modtager og hvilken email det drejer sig om og sørge for at håndtere dem.

SPF – Sender Policy Framework

Omkring 2004 begyndte man at standardisere SPF. SPF er en mulighed for indehaveren af et domæne at udgive en politik for hvilke IP-netværk domænet må optræde i RFC5321.From-adresser for. Poltikken udgives som en specielt formatteret TXT-record på domænet.

Og således blev det nu muligt at sørge for at ingen kunne udgive sig for at sende fra dit domæne i RFC5321.From-adressen. I daglig tale kaldet spoofing. Effekten var dog ikke så stor, for i praksis er der ingen brugere der undersøger RFC5321.From-adressen. Den eneste adresse de ser i deres mailprogram er RFC5322.From-adressen.

Oftest vil RFC5321.From-adressen være på et domæne kontrolleret af din ESP, og du vil altså ikke skulle sætte noget op for at SPF vil være gyldig. Det gør sig også gældende i Ubivox.

SPF er specificeret i RFC7208 – Sender Policy Framework (SPF).

Sender ID

For at råde bod på det, prøvede man nogle år senere at introducere Sender ID. Udover politikken for RFC5321.From i SPF, fik man under Sender ID også mulighed for at fastlægge en politik for RFC5322.From.

Desværre giver standarden mulighed for at man, i mangel af en Sender ID-poltik, kan tolke en SPF-politik som en erstatning for den manglende Sender ID-poltik. Det endte med at give den uheldige sideeffekt at man lige pludselig risikerede at ens SPF-poltik blev fortolket i en uventet kontekst. Navnlig at en politik tiltænkt RFC5321.From-adressen endte med at blive brugt på RFC5322.From-adressen.

Det har gennem tiden givet en masse falske positiver.

Heldigvis blev Sender ID aldrig rigtig udbredt, men Microsoft valgte dog at implementere Sender ID i deres produktsortiment. Man risikerer stadig i dag at få Sender ID-afvisninger, selvom man kun havde i sinde at udgive en SPF-politik.

Sender ID er i dag næsten uddødt. Faktisk fik Sender ID status af forældet med udgivelsen af RFC7208. Dog spøger der stadig noget installationer rundt omkring. Derfor er det stadig nødvendigt at at sørge for at kunne gå igennem en Sender ID-kontrol uden anmærkninger. Det kan gøres på en af to metoder:

1. Hvis man publicerer en SPF-politik på sit RFC5322.From-domæne, kan du sørge for at den også inkluderer din ESP. For Ubivox’ vedkommende løses det ved at inkludere følgende: include:spf.ubivox.com.
2. Alternativt kan man publicere en separat Sender ID-politik. Det gøres med samme syntaks som en SPF-poltik, men hvor man i SPF indleder med v=spf indleder man i Sender ID med: v=spf2.0/pra. Det kræver samtidig en kortlægning af alle de systemer der sender e-mail hvor domænet indgår i RFC5322.From-adressen.

Benytter du Ubivox vil du, hvis der viser sig at være problemer, få en advarsel når du forsøger at sende ud.

Sender ID er specificeret i RFC4406 – Sender ID: Authenticating E-Mail.

DKIM – DomainKeys Identified Mail

Nogenlunde samtidig begyndte man at indse at det også var nødvendigt med en metode til dels at sikre at mailens indhold ikke var blevet ændret mens mailen var i transit. Men især også at kunne fastslå en ansvarlig rolle eller organisation for en given email.

Det blev løst ved introduktionen af DKIM. DKIM er en kryptografisk signatur der både bekræfter indholdet af mailen men også etablerer en identitet. I DKIM’s tilfælde er identiteten et domænenavn.

Som afsender genereres et RSA-nøglepar (en privat og en offentlig nøgle). Den offentlige nøgle lægges i DNS på domænet tilhørende den identitet man gerne vil tillægge mailen og bruges efterfølgende af tredjeparter til at verificere underskriften lavet med den private nøgle.

Hvis indholdet er ændret undervejs, vil signaturen ikke længere være gyldig, og dit mailsystem vil kunne f.eks. kunne lægge mailen i karantæne. Således blev det ikke længere muligt for spammere eller virusser at ændre på indholdet eller links i dine e-mails uden at bryde den kryptografiske signatur på mailen.

DKIM er specificeret i RFC6376 – DomainKeys Identified Mail (DKIM) Signatures.

DMARC – Domain Message Authentication Reporting & Conformance

Men man kunne jo bare pille DKIM-signaturen ud af mailen og så var der ingen problemer. Så man manglede en ordning til at udgive en politik på sit domæne om hvilke autentificeringsmekanismer der var i brug.

Små 10 år senere er løsningen her nu. Det er faktisk ved at være tæt på hvad man kan betragte som en silver bullet for at undgå spoofing. Man fik nemlig den ide at koble både SPF og DKIM-validering sammen i en ny politik hvor grundlaget for de forskellige anordninger skal ensrettes.

Hvad vil det så sige at de skal ensrettes? Det vil sige det organisatoriske domænenavn i SPF-valideringen (RFC5321.From) skal være det samme som det organisatoriske domænenavn i DKIM-valideringen som skal være det samme som det organisatoriske domænenavn i RFC5322.From.

Det organisatoriske domænenavn er i denne kontekst det domænenavn du har købt hos regitratoren. Så for f.eks. email.ubivox.dk vil det organisatoriske domænenavn være ubivox.dk.

Hvis alt er ensrettet og enten SPF eller DKIM kan validere (eller begge, afhængig af din politik), kan mailen gå igennem. Ellers vil den (afhængig af din politik) blive afvist eller lagt i karantæne (spam).

Det var Conformance-delen af DMARC. En anden vigtig ting i DMARC er Reporting.

Du har mulighed for, i din DMARC-politik, at få tilsendt rapporter i forskellige formater med beskeder om fejlede DMARC-valideringer. På den måde har du en effektiv mulighed for at undersøge om nogen spoofer dig.

DMARC er specificeret i RFC7489 – Domain-based Message Authentication, Reporting, and Conformance (DMARC)

Effekten på spam-filtre

Alle disse anordninger her er til at etablere en identitet for en e-mail. Det er ikke en genvej gennem spamfiltrene. Tværtimod bliver det nemmere for udbyderne at kategorisere dine emails og vedligeholde en samlet reputation. Alt afhængig af dit leveringsregime og opførsel kan det både være en god ting eller en dårlig ting.

Det er dog vores erfaring at flere større udbydere er begyndt at skærpe kravene til emails der ikke er underlagt en DMARC-poltik, således at det kan være sværere at komme igennem til inboxen.

Når man publicerer en poltik

Før man lægger en hvilken som helst politik i drift for et domæne, er det vigtigt at man sørger for den er fyldestgørende. Der kan være mange systemer i en organisation der sender e-mail. Og det er ens job som forfatter til en politik at få kortlagt dem alle.

Vi har oplevet mange eksempler på kunder der af andre leverandører mere eller mindre ubevidst har fået tvunget en politik ned over hovedet der med et lægger alt email gennem Ubivox i karantæne med omfattende, fremtidige leveringsproblemer til følge.

Checkliste for at opnå fuld SPF, DKIM og DMARC compliance i Ubivox

• Benyt subdomæne for dit organisatoriske domæne i RFC5322.From på din Ubivox-konto.
• Gyldig SPF-record på det organisatoriske domæne i RFC5322.From-adressen der inkluderer Ubivox
• DKIM-nøgle på din Ubivox-konto på det organisatoriske domæne i RFC5322.From-adressen.
• Gyldig DMARC-record på det organisatoriske domæne i RFC5322.From-adressen.

Noter til DMARC-politikker:

• Vi understøtter ikke aspf=s. Da vi skal kunne opsamle bounces, er vi nødt til at have et FQDN der peger på vores system. Så er aspf=r eneste mulighed (hvilket også er standarden).
• Det er normalt at SPF-validering går i stykker når mails bliver videresendt. Så sørg altid for at DKIM i det mindste altid kan validere.
• Før man udgiver en DMARC-politik, bør du have kørt med SPF og DKIM i en test-periode uden nogle problemer.
• Start altid med p=none som test for at få tilsendt fejlrapporter uden at udbyderne tager nogen handling for dine beskeder.

Eksempel

For at gøre det hele lidt mindre abstrakt, kommer her et fuldt eksempel. Vi ønsker at kunne sende DMARC-compliant e-mail fra afsender@eksempel.dk i Ubivox:

1. Opsæt subdomæne til Ubivox, f.eks.: email.eksempel.dk.
2. Sørg for at SPF-record’en på eksempel.dk indeholder include:spf.ubivox.com.
3. Konfigurer en offentlig DKIM-nøgle på domænet, f.eks.: ubivox._domainkey.eksempel.dk.
4. Konfigurer den private DKIM-nøgle i Ubivox.
5. Kør med denne opsætning i to-tre uger eller indtil du er overbevist om at der ikke er nogle problemer.
6. Undersøg om der er andre systemer i organisationen der sender e-mails fra @eksempel.dk. I så fald skal disse også leve op til en ensrettet SPF og DKIM.
7. Når du er klar, så implementer en DMARC-poltik i en TXT-record på _dmarc.eksempel.dk, f.eks.: v=DMARC1; p=none;.
8. Efterfølgende kan p=none rettes til enten p=reject eller p=quarantine.

Hvis du vil aktivere rapporteringsdelen af DMARC-specifikationen, kan du bruge parametrene herunder (og udskifte email-adresserne med nogle passende adresser for din organisation):

• rua=mailto:dmarc-aggregates@eksempel.dk; (For aggregate reports)
• ruf=mailto:dmarc-forensics@eksempel.dk; (For forensic reports)

Det kan være besværligt at hitte hoved og hale i de tilsendte rapporter. De vil nemlig være i specielle, maskinlæsbare formater. Vi anbefaler at investere i et godt software-system der kan indlæse og behandle rapporterne. I flæng kan nævnes:

• DMARC Analyzer
• dmarcian

Relevante guides

• Opsætning af DKIM i Ubivox
• Eget domæne i Ubivox
• SPF/Sender ID i Ubivox

Tak til

• Henrik Schack – for gennemlæsning og konstruktive kommentarer på artiklen.