CUSTOMIZE Wenn wir von „Email Authentication“ 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 behaupteten Quelle der Nachricht stammt.
Wenn wir von „Email Authentication“ 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. Der Gedanke hinter solchen Techniken ist es, ein gewisses Maß an Schutz vor betrügerischen E-Mails, wie etwa Phishing und Spoofing, zu erreichen, die das Vertrauen des Empfängers in den Empfang von E-Mails erodieren könnten. Das Senden von authentifizierten E-Mails bedeutet jedoch nicht, dass die E-Mail gut oder erwünscht ist; es bedeutet lediglich, dass die Mail einer reputationsbasierten Bewertung der authentifizierten Partei ermöglicht, die zuverlässig etabliert und in Entscheidungsprozessen zur E-Mail-Akzeptanz und -Platzierung verwendet werden kann.
Es gibt heute zwei Formen der E-Mail-Authentifizierung:
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
In dem heutigen Beitrag erkläre ich, was DKIM ist und wie es funktioniert.
DKIM Überblick
Im Gegensatz zu seinem Authentifizierungs-Gegenstück SPF, das einem Domain ermöglicht, einem Host die Berechtigung zum Versenden von E-Mails in ihrem Namen zu erteilen, bietet DKIM eine Möglichkeit für eine Einheit (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 Entität und die sendende Entität dieselbe oder zumindest eng miteinander verbunden sein werden, gibt es bei DKIM keine Anforderung, dass dies so sein muss.
Meine Ziele mit diesem Beitrag sind, dass Sie die folgenden Konzepte über DKIM lernen und verstehen:
DKIM ist eine „inhaltsbasierte“ Authentifizierung, im Gegensatz zur „pfadbasierten“ SPF.
Die verantwortliche Entität erklärt ihre Verantwortung, indem sie die Nachricht mit einem Paar kryptografischer Hashes signiert, die in einen Nachrichtenheader eingefügt werden.
DKIM-Validierung erfolgt durch die empfangende Domain, die versucht, dieselben zwei Hashes zu erzeugen.
DKIM-Validierung kann in vielen Fällen nicht abgeschlossen werden, bis die vollständige Nachricht vom sendenden Server übermittelt wurde.
Fehler bei der Validierung können schwer zu beheben sein.
“Inhaltsbasierte” Authentication
DKIM Signing und Validation
Organisationen, die Mails mit DKIM signieren möchten, werden zunächst zwei kryptografische Schlüssel erzeugen. Einer der Schlüssel wird privat gehalten und dem sendenden Server für das Signieren von Mails zur Verfügung gestellt, während der andere öffentlich im DNS gemacht wird, um von empfangenden Domains zur Validierung der Signatur verwendet zu werden. Die Methoden zur Erzeugung und Installation dieser Schlüssel sind plattformabhängig und liegen außerhalb des Umfangs dieses Beitrags, obwohl ich später die Veröffentlichung des öffentlichen DKIM-Schlüssels im DNS beschreiben werde.
Der DKIM-Signature Header
Um unser Verständnis von DKIM zu beginnen, lassen Sie uns zunächst einen DKIM-Signatur-Header betrachten:
DKIM-Signatur: 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-Signatur-Header ist eine Reihe von Schlüssel-Wert-Paaren, von denen einige für den Leser interessanter sind als andere, aber ich werde alle hier beschreiben.
Zuerst schauen wir uns diejenigen an, die für den Leser meistens nur von vorübergehendem 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 erstellen
c=relaxed/relaxed; – Es gibt zwei Sätze von Regeln bezüglich der Entfernung von Leerzeichen in den Headern und im Textkörper, die beim Erstellen der Hashes in einer DKIM-Signatur angewendet werden können; diese Regeln werden „Kanonisierungsregeln“ genannt (daher der Schlüssel c) und die Regelsätze sind entweder „entspannt“ oder „streng“.
t=1454417737; – Der Zeitstempel, wann die Signatur erstellt wurde.
Diese drei Headerteile enthalten die eigentlichen Signaturinformationen:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Dies ist der Hash des Textkörpers der Nachricht.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Dies ist eine Liste der Header, die verwendet wurden, um die unten gezeigten Signaturdaten zu erstellen.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Dies sind die eigentlichen 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 Domäne, die die Nachricht signiert hat
s=notices; – Der Selector; Domains können mehrere Selector 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 sieht dies wie eine E-Mail-Adresse aus und könnte sogar eine sein; der lokale Teil der E-Mail-Adresse kann leer sein, wie in diesem Beispiel, und der Domain-Teil muss derselbe sein wie, oder eine Subdomäne der Domain im d= Teil der Signatur.
Der Grund, warum diese Teile für den empfangenden Server interessant sind, besteht darin, dass sie die notwendigen Informationen bieten, um dem Empfänger bei der Validierung der Signaturen zu helfen.
DKIM Validation
Zusätzlich zu der erwähnten Anforderung, dass die i= Domain identisch mit oder eine Subdomain der d= Domain sein muss, werden die d= und s= Bits vom Validator verwendet, um den öffentlichen DKIM-Schlüssel des Unterzeichners im DNS nachzuschlagen. Der Schlüssel ist ein TXT-Eintrag im DNS und ist immer an der Stelle selector._domainkey.domain zu finden. In unserem Beispiel hier, mit s=notices und d=welcome.foo.com, würde der öffentliche DKIM-Schlüssel im DNS unter notices._domainkey.welcome.foo.com gefunden werden, und er könnte in etwa so 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 eigene Menge an Hashes der Nachricht zu erstellen; wenn diese Hashes übereinstimmen, dann wurde die Nachricht während der Übertragung nicht verändert, und so kann die Nachricht zu dem Ruf beitragen, der für den Unterzeichner der Nachricht besteht und möglicherweise davon profitieren.
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 zum Beispiel, dass die Nachricht nicht signiert wurde, oder der öffentliche Schlüssel der signierenden Domain nicht im DNS gefunden wurde oder syntaktisch nicht korrekt ist, oder vielleicht wurde die Nachricht offensichtlich während der Übertragung verändert. Wenn solche Fehler auftreten, ist es leicht, das Problem zu erkennen und eine Lösung zu empfehlen. Die schwierigen Fälle jedoch, und diejenigen, die zu den frustrierendsten Supporterfahrungen 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 berichtet, dass die Signatur nicht validiert werden konnte.
Der Grund, warum diese schwer zu beheben sind, liegt darin, dass es keine wirkliche Möglichkeit für beide Seiten gibt, die Bedingungen nachzustellen, unter denen die Nachricht signiert und validiert wurde. Die Nachricht enthält im DKIM-Signatur-Header die Hashes, die vom Unterzeichner zum Zeitpunkt der Signierung generiert wurden, aber der Validator hat wahrscheinlich keinen Zugang zur Infrastruktur des Unterzeichners und kann daher nicht versuchen, die Signatur unter den Bedingungen des Unterzeichners zu reproduzieren. Ebenso hat der Unterzeichner wahrscheinlich keinen Zugang zur Infrastruktur des Validators und kann daher nicht versuchen, die Nachricht auf die gleiche Weise zu validieren wie der Validator.
Fehler wie die, die ich hier beschreibe, sind seltene Vorkommen, und DKIM-Validierungsfehler allein haben normalerweise keinen Einfluss auf die Zustellungsplatzierung. Während DKIM die Nachrichtenauthentifizierung übernimmt, stellt die Implementierung umfassender E-Mail-Validierungstechniken sicher, dass Sie an legitime Adressen senden, die Ihre Nachrichten tatsächlich empfangen und authentifizieren können. Aus meiner Erfahrung treiben solche Fehler mehr Supporttickets als jede andere Art von DKIM-Problemen.
