Wenn wir von "E-Mail-Authentifizierung" sprechen, beziehen wir uns auf eine Technik, die dem Empfänger einer Nachricht ein gewisses Maß an Sicherheit bietet, dass die Nachricht tatsächlich von der angegebenen Quelle stammt. Die Idee hinter solchen Techniken besteht darin, ein gewisses Maß an Schutz gegen betrügerische E-Mails zu erreichen, wie z.B. Phishing und Spoofing, E-Mails, die das Vertrauen des Empfängers in den Erhalt von E-Mails untergraben könnten. Das bedeutet jedoch nicht, dass der Akt des Sendens authentifizierter E-Mails bestätigt, dass die E-Mails gut oder gewünscht sind; es bedeutet lediglich, dass die E-Mail so ist, dass ein Ruf für die authentifizierte Partei zuverlässig etabliert und in Entscheidungen über die Akzeptanz 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 Identified Mail (DKIM)
In dem heutigen Beitrag werde ich erläutern, was DKIM ist und wie es funktioniert.
DKIM-Übersicht
Im Gegensatz zu seinem Authentifizierungsgegenstück SPF, das eine Möglichkeit bietet, für eine Domain einen Host zu autorisieren, um im Namen der Domain E-Mails zu senden, bietet DKIM eine Möglichkeit für eine Entität (Domain, Organisation, Person usw.), die Verantwortung für eine Nachricht zu übernehmen, unabhängig von der Entität, die die Nachricht tatsächlich gesendet hat. Während in vielen Fällen die verantwortliche und die sendende Entität dieselbe oder zumindest eng miteinander verbunden sind, besteht bei DKIM keine Anforderung, dass dies so sein muss.
Meine Ziele für Sie mit diesem Beitrag sind, dass Sie die folgenden Konzepte über DKIM lernen und verstehen:
DKIM ist eine „inhaltbasierte“ Authentifizierung, im Gegensatz zu der „pfadbasierten“ SPF.
Die verantwortliche Entität erhebt ihren Anspruch auf Verantwortung, indem sie die Nachricht mit einem Paar von kryptografischen Hashes signiert, die in den Nachrichtenkopf eingefügt werden.
Die DKIM-Validierung erfolgt durch die empfangende Domain, die versucht, dieselben beiden Hashes zu generieren.
Die DKIM-Validierung kann in vielen Fällen nicht abgeschlossen werden, bis die vollständige Nachricht vom sendenden Server übertragen wurde.
Validierungsfehler können schwierig zu beheben sein.
„Inhaltbasierte“ Authentifizierung
DKIM wird als „inhaltbasierte“ Authentifizierung bezeichnet, anstatt „pfadbasiert“, weil es darauf ankommt, ob eine Nachricht die DKIM-Validierung besteht, basierend allein darauf, ob sich der Inhalt zwischen dem Zeitpunkt, zu dem er signiert wurde, und dem Zeitpunkt, zu dem die Validierung versucht wurde, geändert hat.
DKIM-Signierung und -Validierung
Organisationen, die E-Mails mit DKIM signieren möchten, müssen zunächst zwei kryptografische Schlüssel generieren. Einer der Schlüssel wird privat gehalten und steht dem sendenden Server für die Signierung von E-Mails zur Verfügung, und der andere wird in DNS öffentlich gemacht, damit die empfangenden Domains ihn verwenden können, um die Signatur zu validieren. Die Methoden zum Generieren und Installieren dieser Schlüssel sind plattformabhängig und fallen nicht in den Rahmen dieses Beitrags, obwohl ich später die Veröffentlichung des öffentlichen DKIM-Schlüssels in DNS beschreiben werde.
Der DKIM-Signaturkopf
Um unser Verständnis von DKIM zu beginnen, betrachten wir zunächst einen DKIM-Signaturkopf:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; 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-Signaturkopf besteht aus einer Reihe von Schlüssel-Wert-Paaren, von denen einige für den Leser interessanter sind als andere, aber ich werde alle hier beschreiben.
Zuerst betrachten wir die, die für den Leser hauptsächlich von geringem Interesse sind:
v=1; – Gibt die DKIM-Version an (1 ist der einzige gültige Wert)
a=rsa-sha256; – Der Algorithmus, der verwendet wird, um die kryptografischen Hashes zu erzeugen
c=relaxed/relaxed; – Es gibt zwei Regelsets, die beim Entfernen von Leerzeichen in den Headern und dem Textkörper angewendet werden können, wenn die Hashes in einer DKIM-Signatur erstellt werden; diese Regeln werden als „Kanonisierungsregeln“ bezeichnet (daher der Schlüssel c) und die Regelsets sind entweder „relaxed“ oder „strict“.
t=1454417737; – Der Zeitstempel, zu dem die Signatur erstellt wurde.
Diese drei Teile des Headers enthalten die tatsächlichen Signaturinformationen:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Dies ist der Hash des Körpers der Nachricht.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Dies ist eine Liste der Header, die zur Erstellung der Signaturdaten verwendet wurden, die unten gezeigt werden.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Dies sind die tatsächlichen DKIM-Signaturdaten
Diese drei Teile sind von größtem Interesse für den empfangenden Server, der die Signatur validieren wird:
d=welcome.foo.com; – Dies identifiziert die Domain, die die Nachricht signiert hat
s=notices; – Der Selektor; Domains können mehrere Selektoren haben, die sie beim Signieren von Nachrichten verwenden.
i=@welcome.foo.com; – Dies ist die Identität, in deren Namen die Nachricht signiert wurde. Syntaktisch wird dies wie eine E-Mail-Adresse aussehen, und könnte sogar eine sein; der lokale Teil der E-Mail-Adresse kann leer sein, wie in diesem Beispiel, und der Domainteil muss mit dem in der d=-Teil der Signatur identisch sein oder eine Subdomain davon sein.
Der Grund, warum diese Teile für den empfangenden Server von Interesse sind, liegt darin, dass sie die notwendigen Informationen bereitstellen, die dem Empfänger helfen, die Signaturen zu validieren.
DKIM-Validierung
Zusätzlich zu der genannten Anforderung, dass die i=-Domain die gleiche sein muss wie die d=-Domain oder eine Subdomain davon, werden die d=- und s=-Bits vom Validator verwendet, um den öffentlichen DKIM-Schlüssel des Signierers in DNS zu suchen. Der Schlüssel ist ein TXT-Eintrag in DNS, und er wird immer an der Stelle selector._domainkey.domain gefunden. In unserem Beispiel hier, mit s=notices und d=welcome.foo.com, wäre der öffentliche DKIM-Schlüssel in DNS unter notices._domainkey.welcome.foo.com zu finden, und könnte wie folgt aussehen:
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 seine eigenen Hashes der Nachricht zu produzieren; wenn diese Hashes übereinstimmen, dann wurde die Nachricht während der Übertragung nicht verändert, und die Nachricht kann zu dem beitragen und möglicherweise von dem Ruf profitieren, der für den Signierer der Nachricht besteht.
Validierungsfehler und Fehlersuche
Ich habe oben 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, wie z.B. dass die Nachricht nicht signiert ist, oder dass der öffentliche Schlüssel des signierenden Domains nicht in DNS gefunden werden kann oder nicht syntaktisch korrekt ist, oder vielleicht wurde die Nachricht offensichtlich während der Übertragung verändert. Wenn solche Fehler auftreten, ist es einfach, das Problem herauszufinden und eine Lösung zu empfehlen. Die schwierigen Fälle hingegen, und die, die zu den frustrierendsten Support-Erlebnissen führen, sind die Fälle, in denen die Nachricht signiert wurde, der öffentliche Schlüssel in DNS existiert und die Nachricht nicht offensichtlich verändert wurde, aber der Validator meldet, dass die Signatur nicht validiert werden konnte.
Der Grund, warum diese Schwierigkeiten bei der Fehlersuche auftreten, ist, dass es keine wirkliche Möglichkeit für eine der beiden Seiten gibt, die Bedingungen zu reproduzieren, unter denen die Nachricht signiert und validiert wurde. Die Nachricht hat in ihrem DKIM-Signaturkopf die Hashes, die zur Zeit der Signierung vom Signierer generiert wurden, aber der Validator hat wahrscheinlich keinen Zugang zur Infrastruktur des Signierers und kann daher nicht versuchen, die Signatur unter den Bedingungen des Signierers zu reproduzieren. Ebenso hat der Signierer wahrscheinlich keinen Zugang zur Infrastruktur des Validators und hat daher keine Möglichkeit, die Nachricht so zu validieren, wie es der Validator tat.
Fehler wie die, die ich hier beschreibe, sind seltene Vorkommen, und DKIM-Validierungsfehler haben in der Regel keinen Einfluss auf die Zustellplatzierung. Meiner Erfahrung nach führen solche Fehler zu mehr Support-Tickets als jede andere Art von DKIM-Problem.