Kategoriarkiv: Teknik

SPF er ikke SenderID

You are using it wrongI Januar måned oprettede jeg status.dmarc.dk, hvor man kan se email sikkerheds status for en række udvalgte domæner.
At firmaer over en bred kam ikke bekymrer sig om email sikkerhed er ikke den store nyhed.
Men det er en smule skræmmende at se hvor store problemer der er med at implementere SPF korrekt, vi taler om en over 10 år gammel standard som i nogle tilfælde end ikke store velrenomerede IT firmaer magter at implementere korrekt.

Hvordan kan så mange mislykkes med at implementere noget så forholdsvis simpelt som SPF?

Lad os starte med at se på hvad SPF egentlig er. SPF standarden er defineret i RFC7208.
Indrømmet det er bestemt ikke læselet læsning, men når man bare igennem introduktionen vil man forstå at SPF beskytter MAIL FROM domænet mod uautoriseret brug.

Næste ting vi skal have slået fast: MAIL FROM domænet er ikke det domæne du kan se som en del af afsender emailadressen i din email klient. 1
MAIL FROM adressen/domænet kan du se hvis du kigger i de rå headers der hører til en email.
Her er et eksempel på en MAIL FROM emailadresse i en email fra Proshop. 2

3fc.c.507834095.j3786771-20809254@proshop.anpdm.com

MAIL FROM domænet er i dette tilfælde

proshop.anpdm.com

Det vil sige SPF recorden som var gældende da jeg modtog denne email skal man kigge efter på ovenstående domæne,  og ganske rigtigt, der finder man en SPF record som whitelister APSIS email infrastrukturen.
Hvorfor i alverden inkluderer Proshop så APSIS SPF recorden i roden af proshop.dk domænet?
Ja det er et godt spørgsmål. men det har ihvertfald ikke noget med SPF at gøre.
Der er flere mulige forklaringer.

  • Email service provideren aner ikke hvordan SPF virker, det tror jeg nu ikke er tilfældet når vi taler om APSIS, men jeg har talt med mange hvor det var forklaringen.
  • Man forsøger at understøtte den forældede SenderID standard, på en særdeles uelegant og kluntet måde.

Lad os kigge lidt nærmere på SenderID. M3AAWG som er en sammenslutning af firmaer der modtager tæt på alle de emails du sender, skriver meget diplomatisk:

SenderID deprecation
SenderID is a deprecated standard that was intended as an alternative to SPF. SenderID was
officially deprecated with the publication of RFC7208 in 2015, and is no longer considered when
authenticating email. SenderID records can be identified by their v=spf2.0 prefix.
A record that starts with this prefix should not be used and any such record should be deleted.

Kender man lidt til SenderID syntax og fallback til SPF syntax når en SenderID record ikke eksisterer kunne man lave denne lidt mindre diplomatiske oversættelse:

SenderID er død, stendød, hold op med at understøtte det. Skal du død og pine understøtte SenderID, så hav i det mindste anstændighed nok i livet til at anvende den korrekte SenderID syntax, så du ikke samtidig gør skade på eksisterende SPF records. 🙂

Lad os komme igang med at få ryddet op efter SenderID, uhyggeligt mange SPF records indeholder include statements som ikke burde være der. Overflødige include statements er den altoverskyggende største årsag til defekte SPF records.

 

1 SPF er dermed i praksis virkningsløs som beskyttelse mod phishing.
2 Jeg har intet imod hverken Proshop eller APSIS, jeg brugte ganske enkelt det seneste nyhedsbrev jeg har modtaget som eksempel.

Kilder:
M3AAWG Best Practices for Managing SPF Records.
SPF vs. SenderID

Dinero – Det sikre valg

Dinero logo

Regnskabsprogrammet Dinero har taget DMARC i brug, vel at mærke en fuld implementering med en reject policy.
I praksis betyder det at Dinero nu beskytter både sig selv, kunderne og kundernes kunder mod falske emails.

Står du og mangler et godt regnskabsprogram?
Vil du gerne beskytte dine kunder mod falske emails?
Så er det helt klart Dinero du skal vælge.

Det er ikke lykkedes at finde andre udbydere af regnskabsprogrammer med en tilsvarende god email sikkerhed.

Hvor lang tid tager det at implementere DMARC ?

Det er meget forskelligt fra firma til firma, implementeringstiden afhænger af en del faktorer.
Det hurtigste jeg selv har implementeret for et firma tog 2 timer, den længste implementeringstid jeg har hørt om er omkring 4 år.

 

 

Et par ting der kan forlænge projektet:

  • Jo mere kompleks den eksisterende email løsning er, jo længere tid tager det at blive DMARC compliant.
  • Eksterne email leverandører som enten ikke kan eller vil sende DMARC compliant email kan forlænge projektet, f.eks hvis bliver nødt til at skifte til en anden leverandør.
  • Usamarbejdsvillige DNS og email ansvarlige personer, ja det lyder helt forkert, men der findes en del personale rundt omkring, som synes email og DNS skal fungere som det gjorde i slutningen af sidste årtusinde.

Et konkret eksempel:
Google Apps email + MailChimp nyhedsbrev + WordPress blog, i alt 2 timer.

 

Er Microsoft Sender ID dødt ?

Er Microsoft Sender ID dødt, halvlevende eller lever det i bedste velgående ? Det er faktisk ikke et helt nemt spørgsmål.

Lad os starte med lidt historie.

Sender ID og SPF er egentlig nogle eksperimenter som startede tilbage i April 2006, de er beskrevet i RFC 4406, RFC 4407 og RFC 4408.

Sender ID viste sig at være skruet lidt forkert sammen, så følger man standarden slavisk, og samtidig anvender 3. parts afsendere,  kan det resultere i en del problemer, læs eventuelt mere om  Sender ID problemer

Seks år efter Sender ID og SPF eksperimenterne startede, forsøgte man at komme frem til nogle konklusioner i RFC 6686, baseret på en masse indsamlede data.
Det er lidt svært  at se nogle egentlig konklusioner, udover at mange anvender SPF og ikke så mange anvender Sender ID.
En egentlig konklusion skal man nok finde i RFC 4408bis, her kan man se at SPF er tæt på at blive en officiel Internet standard, et lignende dokument kan man ikke finde for Sender ID.

Så for at vende tilbage til det oprindelige spørgsmål om hvorvidt Sender ID er dødt, så må svaret blive: Måske ikke helt, men det for længst blevet overhalet  af DMARC som kan alt Sender ID kan plus meget mere.