bloghoved sidsel jensen

Fremtidens mailstandarder - opdateret

Er man en af dem som gerne vil have et soundtrack til dette blog-indlæg vil jeg foreslå OneRepublic - Future Looks Good

Kramse skrev fornyeligt et blog-oplæg om STARTTLS og så kom jeg jo til at love i kommentarsporet at genbesøge mit gamle blog-indlæg om fremtidens mailstandarder, som faktisk snart er to år gammelt. Jeg har også fornyeligt fået et pip på LinkedIn om at mit gamle blog-indlæg var et af de eneste der var til at finde på dansk om disse standarder og så er der jo ikke andet for end at komme til tasterne igen og give jer en update - for der er faktisk sket rigtig meget de sidste to år (heldigvis).

Først lige en kommentar til Kramse’s blog-indlæg - hvis ikke man er kommet igang med STARTTLS endnu - så er man altså officielt en sløv padde - det store ryk til STARTTLS skete i løbet af 2014. Det kan bla. ses af dette gamle facebook opslag hvor det store skift skete. Måske var det også derfor at EFF’s kampagne “STARTTLS everywhere” fra 2018 virkede en anelse malplaceret. De forsøgte selvfølgelig at gentage successen fra Let’s Encrypt projektet. Jeg har ikke set nogen opdatering fra dem på projektet og jeg tror ærligt talt at det blev lidt af en fuser. De skriver endda selv, at hvis man er en anelse teknisk, så kan både DANE og MTA-STS være med til at løse de her problemer fremadrettet. Det er mig en GÅDE hvorfor de så ikke er gået mere ind i at hjælpe med at få adoption raten på disse to standarder op istedet for?! EFF’s veje er nogle gange uransagelige.

Make DANE great again

Anyways - først en graf:

Illustration: Viktor Dukhovni

Lige i starten af December 2018 skrev jeg en mail til Viktor Dukhovni fortalte ham, at hans største juleønske var gået i opfyldelse og at vi hos one.com havde tilføjet TLSA records for alle vores MX hosts og så gik vores DNS mand ellers igang med at DNSSEC signe TLD for TLD. Til dem der ikke ved det, så er Viktor en af forfatterne bag DANE RFC’en. Den store lodrette streg i December 2018 er “vores” - med et hug fordoblede vi antallet af DANE domæner world wide. Tænk at man kan blive så glad for en enkelt streg på en graf…men det kan man altså godt når man ved hvor meget arbejde der ligger bag den ene streg! For sådan et projekt kan jo ikke “bare” lige gennemføres på 14 dage. Først havde vi enabled DANE outbound og havde håndteret hvad der var af fejlkonfigurede DNSSEC domæner ved at bruge DANE fail listen. Dernæst havde vi en semi-lang periode, inden både mail folk og DNS folk kunne allokeres samtidig pga. andre projekter. Det springende punkt kom da svenske Internetstiftelsen til deres Nordic Domain Days annoncerede en bonus og det gav projektet det sidste skub det skulle have i projekt prioriterings rækkefølgen.

I februar i år nåede vi så en ny milepæl - der rundede vi nemlig over 1 mio DANE domæner. Der er deployet DANE TLSA records på omkring ~12.42% af alle domæner med DNSSEC.
Og her i slutningen af august måned kom Protonmail også med i klubben af mail-providers med DANE support!

Så når Hanno i sidste uge på Twitter spørger om DANE folkene har opgivet ævret, så må jeg altså råbe et stort rungende NEJ! Vi er pt. igang med det lange seje træk der hedder forandring af mailstandarderne og det tager tid.

DNSSEC er det en barriere?

Men selvfølgelig er alt ikke lyserødt - og DNSSEC kan være en teknisk barriere for nogle. DNS skal bare virke og tanken om at man kan fubare sin DNS kan få enhver teknikker til at spontan koldsvede. Vi ved godt at når DNS er nede, er der tæt på ingenting der virker. Problemet er bare, at nogle ikke har fået læst tilstrækkeligt op på hvad DNSSEC er og kan - og det betyder selvfølgelig at DNS arbejde ikke får synderligt prioritet ude i IT-afdelingerne - “if it works don’t fix it” - right?

DNSSEC er “DNS Security Extension” og den blev skabt for at løse bl.a. DNS poisoning attacks som f.eks. Kaminsky angrebet, men altså ud over at bruge internettet til at flytte kattebilleder, så bruger vi det jo idag til en hel masse andre vigtige ting, som kræver at vi sikrer “telefonbogen” bare lidt bedre! Her er hvad ICANN skriver om DNSSEC og hvorfor det er vigtigt.

DNSSEC beskytter bla. effektivt imod DNS hijackings/DNS redirections. Hvad der sker under sådan et angreb kan du læse mere om her.

Illustration: DK-Hostmaster

Hvordan ser det så ud i Danmark på den front, vi er jo som bekendt “IT-foregangsland”? “Vi trykker Enter og så kører det”......well....Sverige og Norge holder fanen højt på vegne af de skandinaviske lande - i Norge er 58% af alle domæner DNSSEC signede og i Sverige er det 54% Lige pt. er der whooping ~2% domænenavne som er DNSSEC signet hos DK-Hostmaster og world wide står det næsten lige så sløjt til. Kun Finland ligger pt. lavere end os, med ~1% og det har bla. fået finske Traficom til at lancere en DNSSEC Launch Day d. 5/9. Vi har signet vores finske domæner i den anledning.

Her kunne jeg rigtig godt tænke mig at høre fra dig hvad DU ser som blockerne - hvad skal der til før du/I implementerer DNSSEC ude i jeres virksomhed?

Skal du have hjælp til DANE/DNSSEC så sidder der en flok meget vidende og dygtige teknikkere og gerne vil hjælpe på DANE-Users mailinglisten. Vi fik f.eks. et par gode hints om best practice da vi skulle have rullet de svenske nøgler fra algoritme 8 til algoritme 13. En af de ting som pt. mangler er mere automatisering og standard værktøjer omkring DNSSEC arbejdet. Rigtig meget er strikket sammen af hjemmebryggede scripts. Niftige værktøjer, der ligesom Certbot gjorde det nemt at hente og administrere Let’s Encrypt Certifikater er i høj kurs i en travl arbejdsdag hvor manuelle arbejdsgange nemt bliver en flaskehals eller resulterer i en “fejl 40”.

MTA-STS i beta-drift hos Google

Hvis man nu hverken kan eller vil rode med DNSSEC - så er MTA-STS et muligt alternativ. i April måned rullede Google MTA-STS og TLS Reporting ud i beta-drift til kunderne, som den første store mail-udbyder - de har nu også hele tiden været en stor støtte af standarden. Det virker nu ikke som om ret mange andre er begyndt at sende TLS Reports endnu, mit gæt er at det først begynder sådan rigtigt i 2020.

OpenARC på vej til at blive en IETF standard

I slutningen af Juli skrev Kurt Andersen fra LinkedIn: Efter 5 år og 9 inter-operability tests er jeg glad for at kunne annoncere RFC8617 - Authenticated Received Chain (ARC) protokol specifikationen. Kurt har sammen med Seth Blank fra Valimail været bannerfører for at få OpenARC så hurtigt igennem standardiserings processen som muligt og nu er den sat på det rette spor. Jeg kan kun sige, at det virker - denne blog forklarer det rigtig godt. Så hvis du kommer i nærheden af en mailingliste server så slå det til! Her er vejledningen til Mailman.

TLS 1.3 - en lavt hængende frugt

Nu I alligevel er igang med at kigge på jeres mail-installationer kan vi så ikke blive enige om at I lige opdaterer til TLS 1.3? Du får bl.a. hurtigere connection etablering og bedre sikkerhed - det er et totalt kinder-æg med "Faster, Safer, Better, Everything"!

That's all for now folks

Kommentarer (24)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lasse Mølgaard

Jeg aktiverede vistnok MTA-STS og TLS reporting på mit eget domæne for lang tid siden.

Jeg tror det var det gamle blog indlæg der var skyld i det.

Men hvis jeg skal være helt ærlig, så ved jeg ikke helt rigtigt om det kan svare sig - endnu.

Det eneste jeg har fået ud af det er en daglig mail fra e-mail adressen noreply-smtp-tls-reporting@google.com.

I mailen er der vedhæftet en gzipped report, men jeg har endnu ikke set nogen værktøjer som kan analysere disse mails og give besked, hvis der er et problem.

Så er det noget andet med DMARC:

Her gør hjemmesider som dmarcian.com og easydmarc.com det nemt at overvåge om man har opsat DMARC korrekt.

Så: Kender i til nogle værktøjer som man kan bruge til TLS reporting? :-)

  • 1
  • 0
Sidsel Jensen Blogger

Fedt at du har prøvet det af :-)

Personligt har jeg forsøgt at lobby'e for at Dmarcian også kunne håndtere TLS Reporting - ville give mening når man alligevel logger ind der....

  • 0
  • 0
Christian Schmidt

Den store lodrette streg i December 2018 er “vores” - med et hug fordoblede vi antallet af DANE domæner world wide.

Godt gået! Forhåbentlig kan omtalen her motivere andre til at følge trop.

Her er et par andre interessante e-mailstandarder, som også savner bred understøttelse:
* RFC 6531-6532: Internationale e-mailadresser, fx rødgrød@fløde.dk.
* RFC 7505: Markering af domæner, der ikke modtager mail.

Og en standard på vej:
* REQUIRETLS: Obligatorisk brug af STARTTLS for alle hops.

  • 1
  • 0
Jesper Wolf Jespersen

Hej Sidsel.

Ville det ikke være relevant om der kom lidt heuristisk spammail filtrering hos one.com ?
Jeg er ved at drukne i tilbud på lån og frække aftaler.
Fint at man skal bruge TLS for at komme i kontakt med mail serveren, men den har åbenbart ikke nogen kritisk sans overfor afsender eller indhold :-)

Jeg har haft mit domæne hos one i et årti og jeg er træt af alle de mailregler jeg sidder og vedligeholder og som jeg alligevel ikke kan holde opdateret.
Lidt GrayListing, BlackListing og WhiteListing ville slet ikke komme utilpas.
Og så er det ikke engang ny teknologi.

med venlig hilsen
Jesper

  • 0
  • 0
Sidsel Jensen Blogger

Hej Jesper

Vi laver masser af mailfiltrering, både white-, grey- og blacklisting. Vi bruger faktisk rigtig meget tid på det og nogle kunder siger vi filtrerer for meget og andre for lidt. Det er megasvært at ramme den korrekte balance og vi prøver hele tiden at gøre det bedre og mønstrene skifter hele tiden. Det er selvfølgeligt ærgeligt hvis du oplever at der hele tiden kommer for meget igennem.

Under alle omstændigheder synes jeg at du skal kontakte vores support og sende eksempler af mailsne med - for vi kan altså sagtens markere mails både som Falske Positiver (FP) og Falske Negativer (FN), så alle får glæde af den korrekte klassificering af mailsne.

Hvis du laver lokale regler baseret på f.eks. en spoofet from adresse - så fanger de ikke nødvendigvis mailen næste gang.

Mvh. Sidsel

  • 0
  • 0
Lasse Mølgaard

Vi laver masser af mailfiltrering, både white-, grey- og blacklisting.

Uh... Jeg kan skrive under på at det er svært at forhindre spam.

Det opdagede jeg da jeg begyndte at hoste mails for min kammerat os hans families domæner. :-)

De er trods alt lidt mere naive omkring hvor de efterlader deres e-mail adresser i forhold til mig, så det tog vel kun en dag eller to, før min mail server blev bombarderet af spam mails.

Både min kammerat og jeg har en meget fjendtlig indstilling over for spam, så jeg fik lært diverse værktøjer og indstillinger i mail serveren at kende. Efter en uge var mængden af spam i indbakken meget minimal.

  • 0
  • 0
Jesper Wolf Jespersen

Hej Igen Sidsel et all.
Undskyld den lidt sure tone i sidste kommentar.
Det er bare fortvivlende at se at man åbenbart ikke kan komme spam til livs.
Jeg ville foretrække at der sker en fleretrins validering før en mailserver accepterer udgående mail på en af dens mailkonti.

For man kan jo via SPF records filtrere om man vil modtage mail fra en fremmed server på et domæne afhængig om den fremmede server er berettiget til at sende for dette domæne.

Men hvis den fremmede server ikke har valideret sine brugere godt nok kan den stadig bruges som spam server.

Spam Mail sendes typisk fra adresser der ikke er gyldige mere, når man begynder at undersøde dem, hvilket gør det morderligt svært for mailmodtageren at filtrere skidtet fra.

Man kunne godt håbe på at nye mailstandarder indeholdt noget med slutbrugervalidering så man måske kan komme problemet til livs.

En ekstre Header linie med information om at slutbrugeren er valideret kunne måske være en ide. Måske skal alle slutbrugerne til at have certificater eller lignende.

Jeg er i hvertfald godt træt af spam.

Endnu engang undskyld jeg overfaldt dig Sidsel, det er ikke din skyld.

mvh Jesper.

  • 0
  • 0
Lasse Mølgaard

Tjah jeg bruger selv scriptet 'chaingen' til at lave mine DNS records til DANE.

Koden findes her: https://go6lab.si/DANE/chaingen

Mine certifikater er genereret af Let's Encrypt, så jeg bruger scriptet på denne måde:

chaingen /etc/live/letsencrypt/vps3.molgaard.eu/fullchain.pem mydomain.com

Scriptet giver så en masse linjer tilbage, hvoraf jeg er kun interreseret i 2 af dem:

_25._tcp.molgaard.eu IN TLSA 3 1 1 f11389e....
_25._tcp.molgaard.eu IN TLSA 2 1 1 60b8757...

Men i min opsætning i DNS har jeg omdøbt de overstående linjer en lille smule, fordi de bliver til følgende linjer i min DNS:

_dane.molgaard.eu IN TLSA 3 1 1 f11389e....
_dane.molgaard.eu IN TLSA 2 1 1 60b8757...

Og derudover har jeg et CNAME med følgende indhold:

_25._tcp.molgaard.eu IN CNAME _dane.molgaard.eu

Jeg lader det være op til jer at finde ud af hvordan i bruger DANE sammen med 143/tcp, 443/tcp, 587/tcp og 993/tcp.

Hint: CNAME :-)

... og som i kan se hos dane.sys4.de, så burde min DNS have de rigtige instillinger. :-)

Ulempen ved Let's Encrypt er at certifikatet har kun en levetid på 3 måneder, så jeg skal skifte linjen med IN TLSA 3 1 1 ud senest hver tredje måned.

Til gengæld fejler DANE ikke på linjen med TLSA 2 1 1, fordi den er baseret på Let's Encrypt intermidiate certificate.

  • 0
  • 0
Henrik Høyer

Løser DMARC ikke kun spørgsmålet om der senders e-mails fra et domæne? Det kunne fx være et system til indrapporting af fejl (report-uri), som kun modtager, men ikke sender. Og så er der domæner, som hverken sender eller modtager e-mails, som RFC 7505 så vil hjælpe.

Sorry min fejl, læste forkert: Jo DMARC bruges til markering af at der ikke afsendes mail.

Jeg bruger normalt bare en .invalid til MX recorden. RCF pedanter vil mene at der er forkert, men i praksis løser det problemet

  • 1
  • 0
Martin Storgaard Dieu

Eller skal MX-recorden være tom i hostname ?

Jeg prøvede at sætte det op for et domæne jeg har med følgende:
Type: MX
Mail server: .
Priority: 0

og sendte en e-mail til webmaster@domain.example og fik blandt andet følgende svar:

The response was:
DNS Error: 3807704 DNS type 'mx' lookup of domain.example responded with code NOERROR The domain domain.example doesn't receive email according to the administrator: returned Null MX https://www.rfc-editor.org/info/rfc7505

(der var også noget, som var pænt og brugervenlig formateret)

I cloudflare ser indsillingen sådan ud:
CloudFlare DNS Setting

  • 0
  • 0
Morten Sørensen

Jeg har netop skiftet til One fra G Suite. Jeg er dog meget overrasket over, at jeres support meddeler at mit .dk-domæne ikke kan DNSSEC-aktiveres, da I ikke understøtter dette?

Hvor er i øvrigt 2-faktor authentication? (På BÅDE kontrolpanel og webmail).

  • 0
  • 0
Henrik Høyer
  • 0
  • 0
Morten Sørensen

Hej Sidsel,

Havde ikke set dit svar, men så lige et opslag fra DK-Hostmaster om at I havde DNSSEC signet alle .dk-domæner. Super godt :-)

Men ja, det er skidt med 2FA - jeg håber I kommer efter det. Ellers har jeg ikke meget at udsætte på oplevelsen indtil videre efter skiftet fra G Suite.

  • 0
  • 0
Log ind eller Opret konto for at kommentere