Wenn wir von "E-Mail-Authentifizierung" sprechen, beziehen wir uns auf eine Technik, die dem Empfänger einer Nachricht ein gewisses Maß an Sicherheit gibt, dass die Nachricht tatsächlich von der behaupteten Quelle der Nachricht stammt. Die Idee hinter solchen Techniken ist es, ein gewisses Maß an Schutz vor betrügerischen E-Mails, wie Phishing und Spoofing, zu erreichen, die das Vertrauen des Empfängers in den Empfang von E-Mails untergraben könnten. Das Versenden einer authentifizierten E-Mail bedeutet jedoch nicht, dass es sich um eine gute oder erwünschte E-Mail handelt; es bedeutet lediglich, dass die E-Mail so beschaffen ist, dass eine Reputation für die authentifizierte Partei zuverlässig festgestellt und bei Entscheidungen über die Annahme und Platzierung von E-Mails verwendet werden kann.

Es gibt zwei Formen der E-Mail-Authentifizierung, die heute verwendet werden:

• Sender Policy Framework (SPF)

• Domain Keys Identifed Mail (DKIM)

Im heutigen Beitrag gehe ich darauf ein, was DKIM ist und wie es funktioniert.

DKIM-Übersicht

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.

Mit diesem Beitrag möchte ich erreichen, dass Sie die folgenden Konzepte über DKIM lernen und verstehen:

• DKIM ist eine "inhaltsbasierte" Authentifizierung, anders als das "pfadbasierte" SPF.

• Die verantwortliche Stelle bestätigt ihre Verantwortung, indem sie die Nachricht mit einem Paar kryptographischer Hashes "signiert", die in einen Nachrichtenkopf eingefügt werden.

• Die DKIM-Validierung erfolgt, indem die empfangende Domäne versucht, dieselben beiden Hashes zu erzeugen.

• Die DKIM-Validierung kann in vielen Fällen erst abgeschlossen werden, wenn die vollständige Nachricht vom sendenden Server übermittelt wurde.

• Fehler bei der Validierung können schwer zu beheben sein.

• 
  

"Inhaltsbasierte" Authentifizierung

DKIM wird als "inhaltsbasierte" Authentifizierung und nicht als "pfadbasierte" Authentifizierung bezeichnet, denn ob eine Nachricht die DKIM-Validierung besteht oder nicht, hängt ausschließlich davon ab, ob sich der Inhalt zwischen dem Zeitpunkt der Signierung und dem Zeitpunkt der Validierung geändert hat oder nicht.

DKIM-Signierung und -Validierung

Organisationen, die E-Mails mit DKIM signieren wollen, erzeugen zunächst zwei kryptografische Schlüssel. Einer der Schlüssel wird privat gehalten und steht dem sendenden Server für die Signierung der E-Mail zur Verfügung, der andere wird im DNS veröffentlicht, damit die empfangenden Domänen ihn für die Validierung der Signatur verwenden können. Die Methoden zur Erzeugung dieser Schlüssel und ihre Installation sind plattformabhängig und würden den Rahmen dieses Beitrags sprengen, obwohl ich später die Veröffentlichung des öffentlichen DKIM-Schlüssels im DNS beschreiben werde.

Der DKIM-Signatur-Header

Um DKIM zu verstehen, schauen wir uns zunächst einen DKIM-Signatur-Header an:

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

Der DKIM-Signatur-Header besteht aus einer Reihe von Schlüssel-Wert-Paaren, von denen einige für den Leser interessanter sind als andere, aber ich werde sie hier alle beschreiben.

Zunächst werden wir uns mit denjenigen befassen, die für den Leser hauptsächlich von vorübergehendem Interesse sind:

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

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

Diese drei Headerteile enthalten die eigentlichen Signaturinformationen:

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

• h=From: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

Diese drei Teile sind für den empfangenden Server, der die Signatur validiert, von größtem Interesse:

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

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

Der Grund, warum diese Teile für den empfangenden Server von Interesse sind, ist, dass sie die notwendigen Informationen liefern, um dem Empfänger bei der Validierung der Signaturen zu helfen.

DKIM Validation

In addition zum 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 am 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.willkommen.foo.com, and it might look something like this:

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

Der Validator verwendet diesen Schlüssel (die p= Bits), um seinen eigenen Satz von Hashes der Nachricht zu erstellen; wenn diese Hashes übereinstimmen, dann wurde die Nachricht während der Übertragung nicht verändert und kann somit zur Reputation des Unterzeichners der Nachricht beitragen und vielleicht davon profitieren.

Validierungsfehler und Fehlerbehebung

Ich habe bereits erwähnt, dass DKIM-Fehler schwierig zu beheben sein können, und ich werde hier erklären, warum das so ist.

Einige DKIM-Validierungsfehler haben offensichtliche Ursachen, z. B. dass die Nachricht nicht signiert wurde oder dass der öffentliche Schlüssel der signierenden Domäne im DNS nicht gefunden wurde oder syntaktisch nicht korrekt ist oder dass die Nachricht während der Übertragung offensichtlich verändert wurde. Wenn diese Art von Fehlern auftritt, ist es einfach, das Problem zu erkennen und eine Lösung zu empfehlen. Die schwierigsten Fälle und diejenigen, die zu den frustrierendsten Erfahrungen mit dem Unterstützung führen, sind die Fälle, in denen die Nachricht signiert wurde, der öffentliche Schlüssel im DNS vorhanden ist und die Nachricht nicht offensichtlich verändert wurde, aber der Validator meldet, dass die Signatur nicht validiert werden konnte.

Der Grund dafür, dass diese Probleme schwer zu beheben sind, liegt darin, dass es für beide Seiten keine Möglichkeit gibt, die Bedingungen zu reproduzieren, unter denen die Nachricht signiert und validiert wurde. Die Nachricht enthält in ihrem DKIM-Signatur-Header die Hashes, die vom Unterzeichner zum Zeitpunkt der Unterzeichnung generiert wurden, aber der Validierer hat wahrscheinlich keinen Zugriff auf die Infrastruktur des Unterzeichners und kann daher nicht versuchen, die Signatur unter den Bedingungen des Unterzeichners zu reproduzieren. Ebenso hat der Unterzeichner wahrscheinlich keinen Zugriff auf die Infrastruktur des Validierers und kann daher nicht versuchen, die Nachricht auf die gleiche Weise zu validieren wie der Validierer.

Fehler, wie ich sie hier beschreibe, kommen selten vor, und DKIM-Validierungsfehler haben in der Regel keine Auswirkungen auf die Zustellungsplatzierung. Meiner Erfahrung nach führen solche Fehler zu mehr Unterstützunganfragen als alle anderen Arten von DKIM-Problemen.