ARC (Authenticated Received Chain) is een recent e-mailbeveiligingsprotocol (2019). Het probeert een tekortkoming van DMARC te ondervangen bij het forwarden van e-mailberichten.
Om te begrijpen wat ARC doet, is het goed om te weten hoe SPF, DKIM en DMARC werken. Weet je dat nog niet? Lees dan eerst ‘Waarom heb je nog DMARC nodig als je al SPF en DKIM hebt?’.
DMARC combineert de checks die SPF en DKIM uitvoeren op de authenticiteit van een e-mailverzender. De DMARC-check slaagt alleen als minimaal één van de andere twee checks ook slaagt.
Als de uitkomsten van zowel de SPF- als de DKIM-check negatief zijn, is ook de uitkomst van de DMARC-check dus negatief. Maar in sommige gevallen is dat te streng en leidt het ertoe dat sommige e-mails ten onrechte worden afgewezen, namelijk bij forwards en mailinglists.
Een SPF-check slaagt bijna nooit bij doorgestuurde e-mailberichten. SPF controleert het IP-adres van de verzendende e-mailserver in het e-mailbericht. Daarmee kan een ontvangende server verifiëren of de verzendende e-mailserver inderdaad e-mail mag versturen namens (de eigenaar van) het domein en dus authentiek is.
Maar deze informatie van het e-mailbericht wordt aangepast als een ontvanger het bericht doorstuurt. De SPF-controle verwijst nog steeds naar de oorspronkelijke verzender, maar de IP-adresinformatie van de doorsturende e-mailserver is niet door de eigenaar van het oorspronkelijke e-maildomein gerechtigd. Een SPF-check van de opvolgende ontvanger zal daarom niet slagen.
Bij DKIM voegt de verzendende authentieke e-mailserver een digitale handtekening toe aan elk verstuurd e-mailbericht. DKIM ‘overleeft’ het doorsturen van het bericht wél, want DKIM-informatie wordt altijd onveranderd meegestuurd. De opvolgende ontvanger kan daarom de oorspronkelijke DKIM-informatie checken.
Maar daar zit een belangrijke beperking aan: het werkt soms alleen als er bij het doorsturen helemaal niets aan de inhoud van het oorspronkelijke bericht is veranderd. En dat gebeurt in de praktijk natuurlijk wél regelmatig: iemand voegt bij het forwarden nog een kort stukje tekst toe, bijvoorbeeld. (‘Kun jij naar onderstaande bericht kijken?’)
Het gevolg: de SPF-check, DKIM-check én de DMARC-check hebben een negatief resultaat, waardoor het bericht mogelijk niet wordt afgeleverd bij de beoogde ontvanger. Ook als het bericht authentiek is. ARC is ontworpen om deze situatie te voorkomen.
ARC geeft doorgestuurde e-mails die niet door de DMARC-check heen komen een tweede kans. Het voert een aanvullende check uit op zulke berichten, waarbij de keten van tussenliggende servers een belangrijke rol speelt. Slaagt deze check wel, dan wordt de e-mail toch als authentiek aangemerkt.
Het werkt als volgt. Een authentieke e-mail komt binnen bij de ontvangende e-mailserver van de oorspronkelijke ontvanger. De e-mailserver voert een DMARC-check uit. Het resultaat van deze eerste DMARC-check is positief. Het bericht is immers nog niet gewijzigd en/of doorgestuurd. De ontvangende server levert de e-mail keurig af in de inbox van de oorspronkelijke ontvanger A.
Vervolgens stuurt de oorspronkelijke ontvanger A het bericht, eventueel met wat eigen aanvullingen, door naar iemand anders, persoon B. De e-mailserver van persoon A voegt de uitkomst van de eerder uitgevoerde DMARC-check toe aan de envelop van het e-mailbericht. Ook ondertekent deze e-mailserver het bericht en de uitkomst met een digitale handtekening (vergelijkbaar met de DKIM-handtekening). En hij voegt deze handtekening ook toe aan de envelop.
De digitale handtekening zorgt ervoor dat een hacker het bericht (en daarmee ook de meegestuurde uitkomst van de oorspronkelijke DMARC-check) onderweg niet ongemerkt kan aanpassen. In dat geval klopt de digitale handtekening namelijk niet meer.
De e-mail komt vervolgens bij de e-mailserver van de nieuwe ontvanger B aan. Deze e-mailserver voert een eigen DMARC-check uit. Als deze DMARC-check dan faalt, komt ARC in het spel voor een tweede kans. De server voert de ARC-check uit: hij kijkt wat de meegestuurde uitkomst is van de DMARC-check die zijn voorganger heeft gedaan. En of de handtekening van die voorganger klopt, waarmee de uitkomst wordt bevestigd.
Omdat de uitkomst van de oorspronkelijke DMARC-check wel positief is en de handtekening van de vorige e-mailserver klopt, slaagt de ARC-check. De e-mailserver levert het bericht daarom alsnog af bij ontvanger B.
En als ontvanger B de e-mail zelf ook weer doorstuurt, herhaalt het hele proces zich: zijn e-mailserver checkt de uitkomst van de oorspronkelijke DMARC-check en de digitale handtekeningen van zijn voorgangers. En bij het doorsturen voegt deze e-mailserver zijn eigen digitale handtekening weer toe aan het bericht. Zo bouw je een keten van handtekeningen op die de authenticiteit van het bericht aantonen.
De benodigde informatie voor de ARC-check wordt in headers aan de envelop van een doorgestuurd e-mailbericht toegevoegd. Elke tussenliggende server in de keten van verzender naar ontvanger voegt de volgende drie ARC-headers toe:
Ook checkt iedere ontvangende e-mailserver het volgende aan de ARC-headers:
ARC is nog een experimentele technologie. Het is nog niet als standaard aangemerkt. Nog lang niet alle e-mailproviders en -systemen ondersteunen het. Daardoor is ARC nu nog niet goed bruikbaar. Zodra je een e-mail doorstuurt naar een mailsysteem dat nog geen ARC-ondersteuning heeft, breek je daarmee de keten van vertrouwen die tot dan toe is opgebouwd.
Een bijkomend probleem is dat een aanvaller een ARC-keten van vertrouwen eenvoudig kan vervalsen. Hij neemt een e-mail met een geldige ARC-keten, vervangt de berichtinhoud en de From– en Subject-velden en voegt zijn eigen handtekening aan de keten toe. De ARC-keten van de e-mail blijft geldig, maar de aanvaller kan het nu gebruiken om zijn spamboodschap de wereld in te sturen.
Tot slot geeft ARC geen garanties dat de aflevering van doorgestuurde e-mails verbetert. Het is nog steeds aan de e-mailserver zelf om te bepalen wat er met een e-mail gebeurt als de ARC-check slaagt.
Wacht met het gebruik van ARC tot het uit de experimentele fase is.