Eine Weiterleitung ist die harmloseste Einrichtung, die ein Postfach kennt: Post kommt an Adresse A an und geht automatisch an Adresse B weiter. Genau diese Einrichtung bringt seit der Verbreitung von DMARC regelmäßig Nachrichten zu Fall, die auf direktem Weg problemlos angekommen wären. Der Grund liegt nicht in der Weiterleitung selbst, sondern darin, was die Prüfverfahren eigentlich prüfen.
Was beim Weiterleiten technisch passiert
Eine Weiterleitung ist keine Kopie und keine Umlenkung. Der weiterleitende Server nimmt die Nachricht vollständig an und verschickt sie neu — mit seiner eigenen IP-Adresse, aus seinem eigenen Netz. Für den Empfänger am Ende der Kette ist der Weiterleiter der sendende Server. Von der ursprünglichen Verbindung ist nichts mehr übrig als ein zusätzlicher Received:-Eintrag im Kopf.
Damit fällt eine Voraussetzung weg, auf der SPF vollständig aufbaut.
SPF überlebt eine Weiterleitung nicht
SPF fragt: darf diese IP-Adresse für diese Domain senden? Der Empfänger sieht als sendende IP die des Weiterleiters, als Domain im Umschlag aber weiterhin die des ursprünglichen Absenders. Die IP des Weiterleiters steht selbstverständlich nicht im SPF-Eintrag der fremden Domain — warum sollte sie. Ergebnis: fail.
Das ist kein Fehler in der Einrichtung. Es ist die unvermeidliche Folge daraus, dass SPF eine Verbindung prüft und nicht eine Nachricht. Jede Weiterleitung bricht SPF, ausnahmslos.
DKIM überlebt sie — solange niemand den Text anfasst
DKIM arbeitet anders. Der ursprüngliche Absender bildet eine kryptografische Signatur über den Nachrichtentext und eine Auswahl von Kopfzeilen und hängt sie an. Diese Signatur reist mit. Ob die Nachricht über einen Zwischenserver lief, spielt keine Rolle — geprüft wird der Inhalt, nicht der Weg.
Deshalb kommt der übliche Fall trotz gebrochenem SPF durch: DKIM besteht, DKIM ist ausgerichtet, und DMARC verlangt nur, dass einer der beiden Wege ausgerichtet besteht. Wie dieser Abgleich funktioniert, ist an anderer Stelle beschrieben.
Wo die Signatur dann doch bricht
Die Einschränkung „solange niemand den Text anfasst" ist keine theoretische. Mehrere verbreitete Einrichtungen fassen ihn an:
- Mailinglisten hängen eine Fußzeile mit Abmeldehinweis an und setzen ein Kürzel wie
[intern]vor den Betreff. Beides fällt in den signierten Bereich. Die Signatur ist danach ungültig. - Virenscanner und Anhangsfilter ersetzen Anhänge durch Hinweistexte oder hängen einen Prüfvermerk an.
- Zentrale Signaturen — der Rechtshinweis, den ein Gateway an jede ausgehende Nachricht setzt — treffen weitergeleitete Post genauso.
- Umkodierung. Ein Server, der eine Nachricht von
8bitaufquoted-printableumschreibt, ändert den Text auf Byte-Ebene, auch wenn der Leser nichts davon sieht.
Ist auch DKIM gebrochen, bleibt für DMARC kein Weg mehr übrig. Die Nachricht wird abgelehnt oder in den Spam-Ordner gelegt — und zwar korrekt, denn aus Sicht des Empfängers ist sie von einer nicht autorisierten Quelle gekommen und unterwegs verändert worden.
SRS: die Reparatur, die das Problem verschiebt
Weiterleiter behelfen sich mit dem Sender Rewriting Scheme. Der Weiterleiter schreibt die Umschlagadresse auf sich selbst um, aus anna@firma.de wird etwa SRS0=abc=xy=firma.de=anna@uni.example. Damit prüft SPF gegen uni.example, die IP passt, und das Ergebnis ist wieder pass.
Nur: für DMARC ist damit nichts gewonnen. Die geprüfte Domain lautet jetzt uni.example und steht damit erst recht nicht in Übereinstimmung mit dem From: auf firma.de. SRS repariert die Unzustellbarkeitsmeldungen — die sollen ja beim Weiterleiter auflaufen und nicht beim ursprünglichen Absender — aber nicht die Ausrichtung. Auch mit SRS trägt allein DKIM das Ergebnis.
Was ARC macht
Hier setzt die Authenticated Received Chain an. Die Idee ist einfach: wenn der Weiterleiter die Prüfung ohnehin schon durchgeführt hat, bevor er die Nachricht verändert hat, dann soll er dieses Ergebnis beglaubigt weitergeben.
Jeder ARC-fähige Zwischenserver hängt drei Kopfzeilen an:
| Kopfzeile | Inhalt |
|---|---|
ARC-Authentication-Results | Das Prüfergebnis, das dieser Server beim Empfang gesehen hat |
ARC-Message-Signature | Eine Signatur über die Nachricht in dem Zustand, in dem sie hier ankam |
ARC-Seal | Eine Signatur über die bisherige Kette, damit sie nicht nachträglich umgeschrieben werden kann |
Der Empfänger am Ende sieht dann: SPF und DKIM scheitern zwar bei mir, aber die Kette bezeugt, dass beides beim ersten Empfänger bestanden hat, und die Kette selbst ist unversehrt.
Die entscheidende Einschränkung
ARC beweist nichts. Es überträgt eine Aussage — und ob diese Aussage etwas wert ist, hängt vollständig davon ab, ob der Empfänger dem Server glaubt, der sie unterschrieben hat. Ein beliebiger Server kann eine ARC-Kette anlegen, die behauptet, alles habe bestanden.
Deshalb ist ARC keine Einrichtung, die man aktiviert und die dann wirkt. Große Anbieter werten ARC-Ketten von Absendern aus, die sie kennen und über längere Zeit als zuverlässig eingestuft haben. Für einen frisch aufgesetzten Weiterleiter ohne Vorgeschichte ändert eine ARC-Kette zunächst wenig. Das ist keine Schwäche des Verfahrens, sondern seine Bauart: ARC ist ein Vertrauensvermerk, kein Beweis.
Was das praktisch heißt
Wenn Sie weiterleiten lassen: Rechnen Sie damit, dass Post von Absendern mit p=reject unterwegs verloren geht. Der sauberere Weg ist, das Zielpostfach die Nachrichten selbst abholen zu lassen — per POP3- oder IMAP-Import statt per Weiterleitung. Dann gibt es keinen zweiten Versand und nichts zu brechen.
Wenn Sie eine Liste betreiben: Setzen Sie das From: auf die Listenadresse und die ursprüngliche Adresse in Reply-To:. Das ist die Lösung, die große Listenverwaltungen gewählt haben. Sie sieht unschön aus, ist aber die einzige, die zuverlässig funktioniert, wenn die Liste den Text verändert.
Wenn Sie senden: Sorgen Sie dafür, dass DKIM ausgerichtet ist, bevor Sie die Richtlinie verschärfen. Ein Absender, der sich allein auf SPF stützt, verliert bei jeder Weiterleitung seiner Nachrichten die einzige Grundlage, auf der DMARC noch bestehen könnte.