Ungültige DKIM-Signatur bei fehlendem 8BITMIME

Warum DKIM-Signaturen bei fehlendem 8BITMIME ungültig werden können und welche Workarounds es gibt

Von der Theorie…

Wer heutzutage einen Mailserver betreibt, der kommt an DKIM, SPF und DMARC nicht vorbei. Diese Techniken helfen dabei, gefälschte E-Mail-Absender leichter zu identifizieren und somit auch Spam und Phishing einzudämmen.

Hinterlegt werden die relevanten Informationen jeweils im DNS-Eintrag der Domain. Ein SPF-Eintrag (Sender Policy Framework) definiert vereinfacht gesagt, welche Mailserver legitimerweise E-Mails für die entsprechende Domain versenden dürfen. So soll beispielsweise verhindert werden, dass sich ein Dritter als Bank oder Paketdienstleister ausgibt und Kundendaten abgreift.

Tipp: SPF-Einträge werden nicht automatisch auf alle Subdomains vererbt. Diese benötigen jeweils einen eigenen Eintrag.

Bei DKIM (DomainKeys Identified Mail) wird, wieder vereinfacht gesagt, ein kryptographischer Schlüssel hinterlegt, mit dem die E-Mails unsichtbar digital signiert werden müssen. So kann festgestellt werden, ob die Nachrichten beim Transport modifiziert wurden. Gleichzeitig wird dadurch auch erschwert, dass bei großen Mailsystemen mit Tausenden von Domains ein Kunde die Identität des anderen annehmen kann, denn die IP-Adresse wäre in einem solchen Fall ja trotzdem korrekt.

Gründe, warum einer dieser Mechanismen fehlschlägt, gibt es viele: weitergeleitete E-Mails werden meist über einen anderen Server verschickt, sodass SPF nicht validiert und manche Mailinglisten modifizieren den Betreff jeder Nachricht, was die DKIM-Signatur ungültig macht.

Zusammengeführt werden die beiden Mechanismen daher durch DMARC (Domain-based Message Authentication, Reporting and Conformance). Postmaster konfigurieren damit unter anderem, wie mit Mails umgegangen werden soll, deren DMARC-Prüfung fehlschlägt.

Tipp: DMARC-Einträge werden automatisch auf alle Subdomains vererbt, es sei denn, diese haben einen eigenen Eintrag.

Die DMARC-Prüfung wiederum gilt als bestanden, wenn einer der beiden Mechanismen – SPF oder DKIM – validiert. Weitergeleitete E-Mails werden nicht zurückgewiesen, solange die DKIM-Signatur noch intakt ist und Nachrichten mit fehlender oder kaputter Signatur kommen an, solange der einliefernde Mailserver im SPF-Eintrag hinterlegt ist.

…zur Praxis

Neben einer bewussten Modifikation der E-Mail gibt es aber noch weitere Gründe, warum die DKIM-Signatur ungültig werden kann, wie ich vor einer Weile lernen musste. Meine E-Mails an einen bestimmten Empfänger sind mit folgender Meldung zurückgekommen:

550 DKIM Sender Invalid - envelope rejected

Zunächst dachte ich an eine fehlende DKIM-Signatur, einen fehlenden DNS-Eintrag, Probleme am DNS-Server selbst oder einen zu langen DKIM-Schlüssel. Verschiedene Testnachrichten zu anderen Mailprovidern wurden jedoch erfolgreich zugestellt und die DKIM-Signatur als gültig angezeigt. Auch diverse Testseiten, beispielsweise DKIMValidator.com oder mail-tester.com zeigten keinerlei Fehler an.

Nach längerer Recherche und dank mehrerer sehr hilfreicher Tipps der Mailop-Mailingliste, auf der auch der Betreiber von AboutMy.email eingeschrieben ist, wurde das Problem nach und nach klarer. Eine E-Mail an AboutMy.email schlug in der Tat fehl und resultierte in einer ungültige DKIM-Signatur – sofern die Nachricht Umlaute oder Sonderzeichen enthielt und mit bestimmten Mailclients verschickt wurde. Mails von anderen Mailclients funktionierten auch mit Umlauten problemlos.

8-Bit als Problem

Das Geheimnis war die Nutzung von 8-Bit-Zeichen. Vereinfacht gesagt gibt es zwei Möglichkeiten, Umlaute und Sonderzeichen in einer E-Mail darzustellen. Nativ als 8-Bit, oder aber als Quoted-Printable, was letztlich eine Konvertierung in 7-Bit-Zeichen ist. Die Entscheidung, wie die Nachricht kodiert wird, trifft der genutzte Mailclient. Fällt die Wahl auf 8-Bit, dann müssen auch alle involvierten Mailserver diese Art der Übermittlung beherrschen, was wiederum durch den SMTP-Standard 8BITMIME sichergestellt wird (nicht zu verwechseln mit SMTPUTF8).

Dieser stellt sicher, dass die Mailserver Daten auch im 8-Bit-Format austauschen können. Unterstützt auch nur einer der Mailserver in der Übermittlungskette kein 8BITMIME, so wird die Nachricht automatisch in Quoted-Printable, d.h. ins 7-Bit-Format konvertiert.

Das ermöglicht zwar die Übermittlung, führt aber auch dazu, dass die DKIM-Signatur als ungültig betrachtet wird – denn sie wurde ja für die ursprüngliche Nachricht erstellt und dient gerade dazu, Modifikationen zu erkennen.

Der Betreiber von AboutMy.email hat 8BITMIME auf seinem System nach meinen Informationen absichtlich deaktiviert, um eben solche Probleme zu identifizieren - an der Stelle nochmals herzlichen Dank, sonst wäre mir die Ursache wohl nicht so schnell aufgefallen!

Workarounds

Für dieses Problem gibt es verschiedene Workarounds. amavisd-new hat eine eingebaute Konvertierung auf Quoted-Printable bzw. 7-Bit für ausgehende Nachrichten, bevor diese per DKIM signiert werden. Das von mir mittlerweile eingesetzte Rspamd bringt diese Möglichkeit nicht mit.

Postfix hat ab Version 3.9 jedoch die Option force_mime_input_conversion, die für genau solche Fälle entwickelt wurde. Sie sorgt dafür, dass E-Mails immer ins Quoted-Printable-Format konvertiert werden, d.h. in 7-Bit.

Die Einrichtung hängt dabei von der konkreten Konfiguration des Mailservers ab. Bei mir kommt eine Mischung aus den exzellenten Howtos von Christoph Haas und Thomas Leister samt zahlreicher eigener Ergänzungen zum Einsatz, die ich zu einem späteren Zeitpunkt hier im Blog veröffentlichen will.

Wichtig ist, die Postfix-Option nicht generell zu aktivieren, da andernfalls eingehende E-Mails nicht mehr korrekt validiert werden können, da die DKIM-Signatur dann in umgekehrte Richtung ungültig wird. Stattdessen dürfen nur ausgehende E-Mails konvertiert werden.

In meiner master.cf habe ich je einen Dienst für SMTPS und Submission eingerichtet, hier ein kurzer Ausschnitt:

smtps     inet  n       -       y       -       -       smtpd
 -o syslog_name=postfix/smtps
 -o smtpd_tls_wrappermode=yes
 -o smtpd_tls_security_level=encrypt
 -o smtpd_sasl_auth_enable=yes
 [..]

submission inet n       -       y       -       -       smtpd
 -o syslog_name=postfix/submission
 -o smtpd_tls_security_level=encrypt
 -o smtpd_sasl_auth_enable=yes
 [..]

Um die Postfix-Option zu aktivieren, muss nun am Ende eines jeden Blocks ein spezieller cleanup-Dienst konfiguriert werden, was durch die folgende Zeile geschieht:

 -o cleanup_service_name=cleanup_out

Der Dienst selbst ist ebenfalls in der master.cf konfiguriert und fügt dem bestehenden cleanup-Dienst nur diese eine Option hinzu:

cleanup_out     unix    n       -       y       -       0       cleanup
 -o force_mime_input_conversion=yes

Nach einem Neustart von Postfix klappt nun auch die DKIM-Validierung mit Gegenstellen, die kein 8BITMIME unterstützen.

Schlussgedanken

Ich habe obige Einstellung erst seit kurzer Zeit im Einsatz, kann über mögliche Probleme und Nebenwirkungen also noch nichts sagen. Jahrzehntelang hatte ich keine Probleme mit ausgehenden Nachrichten, da die Zahl der reinen 7-Bit-Server überschaubar ist.

Zudem liegt dem Bounce (550 DKIM Sender Invalid - envelope rejected) meiner Meinung nach eine sehr strenge DMARC-Handhabung zugrunde. SPF hat korrekt validiert, nur DKIM nicht – damit hätte die Mail die DMARC-Prüfung bestanden und hätte zumindest nicht zurückgewiesen werden sollen.

Vielen Dank an die Leserinnen und Leser von Mailop für die zahlreiche Unterstützung, und an Christian, der diese Implementation gemeinsam mit mir getestet hat