Zusammenspiel

Wie passt nun alles zusammen? Der Unterzeichner berechnet aus der kanonikalisierten Mail und seinem privaten Schlüssel die Signatur. Die Signatur wandert zusammen mit den Parametern für die Kanonikalisierung als Header-Zeile »DKIM-Signature« in den Kopf der Mail. Die Mail wird übertragen. Beim Empfänger steuert die DKIM-Signatur die Authentifizierung: Die »d«-, »s«- und »q«-Tags geben an, wie der öffentliche Schlüssel aus dem DNS zu besorgen ist, andere Parameter bestimmen, wie bei der Kanonikalisierung zu verfahren ist.

Auf diese Weise errechnet der Empfänger wieder zuerst den Hash und daraus die Signatur und vergleicht sie mit der mitgelieferten Signatur (Abbildung 6). Sind beide identisch, dann muss die im »d«-Tag angegebene Domain tatsächlich diejenige sein, aus der die Mail stammt.

Abbildung 6: Aus dem Hash der kanonikalisierten Mail und dem öffentlichen Schlüssel wird die Signatur berechnet. Sie muss mit der mitgelieferten Signatur aus dem Header der Mail übereinstimmen, dann ist der Absender verifiziert.

Im Vergleich

Zu Beginn des 21. Jahrhunderts kam es zu einer regelrechten Flut an Vorschlägen zur E-MailAuthentifizierung und ähnlichen Verfahren. Die Ursache war das exponentielle Wachstum des Spam-Aufkommens. Eines der ersten dieser Verfahren, die auch die Aufmerksamkeit der IETF auf sich zogen, war Reverse-MX (RMX) [7].

Diese Methode und ähnliche Konzepte mündeten schließlich in den Verfahren, die heute als Sender Policy Framework (SPF) [8] beziehungsweise Sender ID [9] bekannt sind. Trotz Unterschieden in den Details arbeiten alle diese Verfahren nach demselben Muster: Eine Domain veröffentlicht, welche Server mit welchen IP-Adressen berechtigt sind, in ihrem Namen Mail zu verschicken. Erhält der Empfänger eine Mail, die ein Mailserver mit einer IP-Adresse verschickt hat, die nicht in der Liste berechtigter Mailserver der Absender-Domain auftaucht, dann muss es sich um Betrug handeln – ein einfaches, aber wirkungsvolles System.

Die wesentliche Einschränkung ist allerdings, dass das Verfahren nur für den ursprünglichen Einlieferer der Mail funktioniert. Sobald mehrere Zwischenstationen die Mail weiterleiten, geht die Authentifizierbarkeit verloren, weil der Empfänger die IP-Adresse des ersten Einlieferers nicht mehr zuverlässig feststellen kann.

Diese Einschränkung aller Formen der so genannten Pfad-basierten Authentifizierung ist allgemein unter dem Namen Forwarding-Problem bekannt. Es betrifft jede Form von Weiterleitung (Forwarding oder Relaying), also beispielsweise auch kommerzielle E-Mail-Weiterleitung, ausgegliederte SMTP-Services und so weiter genauso wie den klassischen Fall der privaten ».forward«-Datei.

Zwar wird ein guter Teil aller E-Mails von Punkt zu Punkt zugestellt und lässt sich auf diese Weise authentifizieren, aber ebenso ist das für einen anderen großen Teil aller Mails von vornherein unmöglich, weil der verschiedene Zwischenstationen passiert. So ist die Pfad-basierte Authentifizierung ein relativ einfaches und zuverlässiges Verfahren – aber eben nur für einen Teil aller E-Mails.

Dank seiner kryptografischen Technik funktioniert DKIM dagegen unabhängig davon, wie viele Zwischenstationen eine Mail auf dem Weg zum Empfänger durchläuft. In dieser Beziehung ist DKIM sicher die vollständigere Lösung. Ihr Nachteil ist, dass sie wesentlicher komplexer ist und es eines beträchtlichen Entwicklungsaufwands bedurfte, um einen Normalisierungsmechanismus zu entwickeln, der mit allen üblichen Änderungen im Verlauf des Übertragungsweges klarkommt.

Als Unterstützer von DKIM glaubt der Autor, dass es sich bei der Entwicklung des Kanonikalisierungsmodells um einen einmaligen Aufwand gehandelt hat und dass es die Industrie lernen wird, auf unnötige Änderungen der Mail während der Übertragung zu verzichten. Tatsächlich haben bereits einige der größten Provider DKIM adaptiert und verhalten sich DKIM-freundlich. Dies setzt sich hoffentlich fort.

Auf der anderen Seite ist das Forwarding-Problem bei Pfad-basierter Authentifizierung prinzipiell nicht aus der Welt zu schaffen, und gleichzeitig bleibt die Weiterleitung ein unverzichtbares Feature von E-Mail. Die daraus resultierende Beschränkung ist auch der Grund, weshalb die IETF SPF und Sender ID nur als experimentelle Protokolle veröffentlicht hat und vor zwei Jahren dazu bemerkte: „Die Community möge Erfolg oder Scheitern der beiden Protokolle in den nächsten beiden Jahren beobachten, sodass danach ein Konsens über ihre Zukunft erzielt werden kann.“ DKIM dagegen ist bereits in den Standards-Track aufgenommen.