När vi talar om "Email Authentication" syftar vi på en teknik som ger mottagaren av ett meddelande en viss grad av säkerhet om att meddelandet faktiskt kommer från den påstådda källan till meddelandet. Tanken bakom sådana tekniker är att uppnå en viss nivå av försvar mot bedräglig e-post, såsom phishing och spoofing, e-post som kan urholka en mottagares förtroende för att ta emot e-post. Att skicka autentiserad e-post innebär dock inte att e-postmeddelandet är bra eller önskat. Det innebär bara att e-postmeddelandet är sådant att ett rykte för den autentiserade parten kan fastställas på ett tillförlitligt sätt och användas i beslut om godkännande och placering av e-post.

Det finns två former av e-postautentisering som används idag:

• Sender Policy Framework (SPF)

• Domännycklar för identifierad e-post (DKIM)

I dagens inlägg går jag igenom vad DKIM är och hur det fungerar.

Översikt över DKIM

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.

Mina mål med det här inlägget är att du ska lära dig och förstå följande begrepp om DKIM:

• DKIM är en "innehållsbaserad" autentisering, till skillnad från den "vägbaserade" SPF.

• Den ansvariga enheten bekräftar sitt ansvar genom att "signera" meddelandet med ett par kryptografiska hashvärden som infogas i meddelandets rubrik.

• DKIM-validering görs genom att den mottagande domänen försöker generera samma två hashvärden.

• DKIM-valideringen kan i många fall inte slutföras förrän hela meddelandet har överförts av den sändande servern.

• Valideringsfel kan vara svåra att felsöka.

• 
  

"Innehållsbaserad" autentisering

DKIM kallas för "innehållsbaserad" autentisering, snarare än "sökvägsbaserad", eftersom huruvida ett meddelande klarar DKIM-valideringen enbart baseras på huruvida innehållet har ändrats mellan den tidpunkt då det signerades och den tidpunkt då valideringsförsöket gjordes.

DKIM-signering och validering

Organisationer som vill DKIM-signera e-post måste först generera två kryptografiska nycklar. En av nycklarna hålls privat och är tillgänglig för den sändande servern för signering av e-post, och den andra ska offentliggöras i DNS för att användas av mottagande domäner i försök att validera signaturen. Metoderna för att generera dessa nycklar och installera dem är plattformsberoende och ligger utanför ramen för detta inlägg, även om jag senare kommer att beskriva publiceringen i DNS av den offentliga DKIM-nyckeln.

DKIM-signaturens rubrik

För att börja förstå DKIM, låt oss först titta på en DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=meddelanden; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=Från:Svar-Till:Ämne:Datum:Meddelande-ID:Till:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQQ9a3mnhF2TQss=;

DKIM-Signature-headern består av en serie nyckel-värdepar, varav vissa är mer intressanta för läsaren än andra, men jag kommer att beskriva dem alla här.

Först tittar vi på de som mestadels är av förbigående intresse för läsaren:

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

• a=rsa-sha256; – Den 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; – Den timestamp of when the signature was created.

Dessa tre rubrikdelar innehåller den faktiska signaturinformationen:

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

• h=Från:Svar-Till:Ämne:Datum:Meddelande-ID:Till:MIME-Version:Innehåll-Typ; - - - - - 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

Dessa tre delar är av störst intresse för den mottagande servern som skall validera signaturen:

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

• s=meddelanden; - 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.

Anledningen till att dessa delar är av intresse för den mottagande servern är att de tillhandahåller den information som krävs för att mottagaren skall kunna validera signaturerna.

DKIM Validation

In addition till 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 vid location selector._domainkey.domain. So, in our example here, with s=notices and d=welcome.foo.com, the public DKIM key would be found in DNS at notices._domainkey.welcome.foo.com, and it might look something like this:

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

Valideraren använder den nyckeln (p=-bitarna) för att skapa sin egen uppsättning hashningar av meddelandet. Om dessa hashningar stämmer överens har meddelandet inte ändrats under överföringen, och meddelandet kan därför bidra till, och kanske dra nytta av, det rykte som finns för undertecknaren av meddelandet.

Valideringsfel och felsökning

Jag nämnde ovan att DKIM-fel kan vara svåra att felsöka, och jag ska förklara varför det är så här.

Vissa DKIM-valideringsfel har uppenbara orsaker, t.ex. att meddelandet inte har signerats, att signeringsdomänens offentliga nyckel inte finns i DNS eller inte är syntaktiskt korrekt, eller att meddelandet uppenbarligen har ändrats under överföringen. När den typen av misslyckanden inträffar är det lätt att ta reda på problemet och rekommendera en lösning. De svåraste fallen, och de som leder till de mest frustrerande supportupplevelserna, är de där meddelandet har signerats, den offentliga nyckeln finns i DNS och meddelandet inte uppenbart har ändrats, men validatorn rapporterar att signaturen inte kunde valideras.

Anledningen till att dessa är svåra att felsöka är att det inte finns något riktigt sätt för någon av sidorna att återskapa de förhållanden under vilka meddelandet signerades och validerades. Meddelandet har i sin DKIM-Signature-header de hashvärden som genererades av undertecknaren vid tidpunkten för undertecknandet, men valideraren har sannolikt ingen tillgång till undertecknarens infrastruktur och kan därför inte försöka återskapa signaturen under undertecknarens villkor. På samma sätt har undertecknaren sannolikt ingen tillgång till validerarens infrastruktur och har därför inget sätt att försöka validera meddelandet på samma sätt som valideraren gjorde.

Fel som jag beskriver här är sällsynta, och DKIM-valideringsfel i sig har vanligtvis ingen inverkan på leveransplaceringen. Det är min erfarenhet att sådana fel leder till fler supportärenden än någon annan typ av DKIM-problem.