Wanneer we het hebben over "e-mailverificatie", bedoelen we een techniek die de ontvanger van een bericht enige zekerheid biedt dat het bericht werkelijk afkomstig is van de beweerde bron van het bericht. Het idee achter dergelijke technieken is een zekere mate van bescherming te bieden tegen frauduleuze e-mail, zoals phishing en spoofing, post die het vertrouwen van de ontvanger in het ontvangen van e-mail zou kunnen aantasten. De verzending van geauthenticeerde e-mail betekent echter niet dat de e-mail goed of gewenst is; het betekent alleen dat de e-mail zodanig is dat een reputatie voor de geauthenticeerde partij op betrouwbare wijze kan worden vastgesteld en gebruikt bij beslissingen over de aanvaarding en plaatsing van e-mail.

Er zijn tegenwoordig twee vormen van e-mailverificatie in gebruik:

• Sender Policy Framework (SPF)

• Domain Keys Identifed Mail (DKIM)

In het bericht van vandaag behandel ik wat DKIM is en hoe het werkt.

DKIM Overzicht

Unlike its authentication counterpart SPF, which provides a way for a domain to authorize a host to send mail on its behalf, DKIM provides a way for an entity (domain, organization, person, etc.) to take responsibility for a message, independent of the entity that actually sent the message. While in many cases the responsible entity and the sending entity will be the same, or at least closely related, with DKIM there’s no requirement that this be so.

Mijn doel met dit bericht is dat u de volgende concepten over DKIM leert en begrijpt:

• DKIM is een "op inhoud gebaseerde" authenticatie, in tegenstelling tot de "op pad gebaseerde" SPF.

• De verantwoordelijke entiteit bevestigt haar verantwoordelijkheid door het bericht te "ondertekenen" met een paar cryptografische hashes die in een berichtkop worden ingevoegd.

• DKIM-validatie vindt plaats doordat het ontvangende domein dezelfde twee hashes probeert te genereren.

• DKIM-validatie kan in veel gevallen niet worden voltooid totdat het volledige bericht door de verzendende server is verzonden.

• Validatiefouten kunnen moeilijk op te lossen zijn.

• 
  

"Authenticatie op basis van inhoud

DKIM wordt "op inhoud gebaseerde" authenticatie genoemd, in plaats van "op pad gebaseerde", omdat het al dan niet slagen van een bericht voor DKIM-validatie uitsluitend gebaseerd is op het al dan niet veranderen van de inhoud tussen het moment van ondertekening en het moment van validatie.

DKIM ondertekening en validatie

Organisaties die DKIM willen ondertekenen, genereren eerst twee cryptografische sleutels. Eén van de sleutels wordt privé gehouden en is beschikbaar voor de verzendende server voor het ondertekenen van mail, en de andere wordt openbaar gemaakt in DNS voor gebruik door ontvangende domeinen in pogingen om de handtekening te valideren. De methoden om deze sleutels te genereren en te installeren zijn platform-afhankelijk en vallen buiten het bestek van deze post, hoewel ik later de publicatie in DNS van de publieke DKIM sleutel zal beschrijven.

De DKIM-handtekeningkop

Om DKIM beter te begrijpen, kijken we eerst naar een DKIM-handtekening-header:

DKIM-handtekening: v=1; a=rsa-sha256; d=welcome.foo.com; s=berichten; c=ontspannen/ontspannen; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=Van:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;

De DKIM-handtekeningkop bestaat uit een reeks sleutelwaardeparen, waarvan sommige interessanter zijn voor de lezer dan andere, maar ik zal ze hier allemaal beschrijven.

Eerst kijken we naar die welke meestal van voorbijgaand belang zijn voor de lezer:

• v=1; – Specifies the DKIM version (1 is the only valid value)

• a=rsa-sha256; – De algorithm used to construct the cryptographic hashes

• c=relaxed/relaxed; – There are two sets of rules regarding removal of whitespace in the headers and body that can be applied when creating the hashes in a DKIM signature; these rules are called “canonicalization rules” (hence the key of c) and the rulesets are either “relaxed” or “strict”.

• t=1454417737; – De timestamp of when the signature was created.

Deze drie kopteksten bevatten de eigenlijke handtekeninginformatie:

• bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; -. This is the hash of the body of the message.

• h=Van:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; - This is a list of the headers that were used to create the signature data shown below.

• b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; -;. This is the acutal DKIM signature data

Deze drie delen zijn van het grootste belang voor de ontvangende server die de handtekening zal valideren:

• d=welcome.foo.com; - This identifies the domain that signed the message

• s=berichten; - The selector; domains can have multiple selectors that they use when signing messages.

• i=@welcome.foo.com; - This is the identity on whose behalf the message was signed. Syntactically, this will look like an email address, and might even be one; the localpart of the email address can be empty, as in this example, and the domain part must be the same as, or a subdomain of, the domain in the d= part of the signature.

De reden waarom deze delen van belang zijn voor de ontvangende server is dat zij de informatie verschaffen die nodig is om de ontvanger te helpen de handtekeningen te valideren.

DKIM Validation

In addition naar de requirement mentioned that the i= domain must be the same as or a sub-domain of the d= domain, the d= and s= bits are used by the validator to look up the signer’s public DKIM key in DNS. The key is a TXT record in DNS, and it’s always found aan de location selector._domainkey.domain. So, in our example here, with s=mededelingen and d=welcome.foo.com, the public DKIM key would be found in DNS at berichten._domainkey.welkom.foo.com, and it might look something like this:

berichten._domainkey.welcome.foo.com. beschrijvende tekst "v=DKIM1; h=sha256; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB; s=email"

De validator gebruikt die sleutel (de p= bits) om zijn eigen reeks hashes van het bericht te produceren; indien die hashes overeenstemmen, is het bericht niet gewijzigd tijdens het vervoer, en kan het bericht bijdragen tot, en misschien profiteren van, de reputatie die bestaat voor de ondertekenaar van het bericht.

Validatiefout en probleemoplossing

Ik zei hierboven al dat DKIM-fouten moeilijk op te lossen zijn, en ik zal hier uitleggen waarom dat zo is.

Sommige DKIM validatie fouten hebben duidelijke oorzaken, zoals het bericht dat niet ondertekend is, of de publieke sleutel van het ondertekenende domein die niet gevonden kan worden in DNS of niet syntactisch correct is, of misschien is het bericht duidelijk veranderd tijdens het transport. Bij dit soort fouten is het gemakkelijk om het probleem te achterhalen en een oplossing aan te bevelen. De moeilijkste gevallen echter, en degene die leiden tot de meest frustrerende ondersteuningservaring, zijn de gevallen waarin het bericht werd ondertekend, de openbare sleutel bestaat in DNS, en het bericht niet duidelijk werd gewijzigd, maar de validator meldt dat de handtekening niet kon worden gevalideerd.

De reden waarom deze problemen moeilijk op te lossen zijn, is dat geen van beide partijen de omstandigheden waaronder het bericht is ondertekend en gevalideerd, kan reproduceren. Het bericht heeft in zijn DKIM-handtekeningheader de hashes die door de ondertekenaar zijn gegenereerd op het moment van ondertekening, maar de validator heeft waarschijnlijk geen toegang tot de infrastructuur van de ondertekenaar en kan dus niet proberen de handtekening te reproduceren onder de omstandigheden van de ondertekenaar. Ook de ondertekenaar heeft waarschijnlijk geen toegang tot de infrastructuur van de validator en kan dus niet proberen het bericht te valideren zoals de validator dat heeft gedaan.

Fouten zoals ik hier beschrijf komen zelden voor, en DKIM-validatiefouten op zich hebben meestal geen invloed op de plaatsing van afleveringen. Het is mijn ervaring dat dergelijke fouten meer support tickets opleveren dan enig ander DKIM probleem.