ARC - Authenticated Received Chain

Wer schon mal in den Header einer Office 365 Mail geschaut hat, hat "ARC-Einträge gesehen. ich erkläre hier die Funktion von ARC und die Bedeutung mit DKIM und DMARC

DKIM und DMARC sind fast perfekt

Beim täglichen Kampf gegen Spam und Phishing haben sich SPF, DKIM und DMARC als wichtige Bausteine etabliert. Ein Versender kann per SPF die IP-Adressen und Namen der legitimen Versender für seine SMTP-Domäne veröffentlichen und per DKIM die Nachrichten signieren und damit gegen Veränderungen und Fälschungen schützen. DMARC gibt dem Empfänger die Information, wie streng dieser die SPF/DKIM-Einstellungen umsetzen soll. Das funktioniert in sehr vielen Fällen sehr gut aber immer wenn eine Mail umgeleitet werden soll, dann behindern diese Einstellungen.

Benutzer1 sendet etwas an Empfänger2, der aber die Mails an ein neues Postfach Ziel 3 zugestellt haben möchte. Hierbei sind im schlimmsten Falle drei Mailsysteme in zwei getrennte Verbindungen involviert Einmal die Verbindung vom Server des Absenders zum ersten Ziel und dann eine zweite Verbindung des mittleren Systems zum eigentlichen Ziel. Dabei gibt es zwei Arten zu unterscheiden:

  1. Weiterleitung
    Dabei wird auf dem Zwischensystem die Zieladresse aber auch die Absenderadresse verändert. Der finale Empfänger kommt also kein Mail vom Absender1 sondern vom Empfänger2. Bei IP-Verbindungen würde man quasi von Source-NAT und Destination-NAT sprechen.
  2. Umleitung
    Dabei wird nur das Ziel umgeschrieben aber der Absender bleibt unverändert. Dies ist durchaus manchmal gewollt, damit der Empfänger den ursprünglichen Absender noch als "From:" auswerten kann und nicht in der Mail selbst nachschauen muss.

Diese Verfahren kommen besonders gerne bei Listservern und Mailinglisten vor. Viele Empfänger sind dabei auf einer Mailingliste eingeschrieben und jede Mail an die Liste wird von dem Listserver an alle Teilnehmer weiter gegeben. Dabei kann der Listserver die Absenderadresse umschreiben und alle Empfänger sehen immer nur die "Liste" als Absender. Der Service kann aber auch einfach die originale Absenderadresse beibehalten und die Liste selbst z.B. als CC addieren. Das hat vor allem den Vorteil, dass die Empfänger auch in der Übersicht immer den Absender sehen.

Genau dieses wünschenswerte Verhalten kollidiert mit SPF, DKIM und DMARC, denn der Server von "Empfänger2" ist in der Regel nicht berechtigt mit der Domäne von "Absender1" zu versenden. Und damit haben speziell Mailinglisten das Problem, dass viele Mails im Spamfilter der Ziele stecken bleiben oder direkt abgelehnt werden.

Es gibt aber noch andere Fälle, z.B.: wenn Sie Mails von einem Postfach per Umleitung auf dem Server zu einem anderen neuen Postfach senden wollen. Oder Sie haben einen Prozess, der die Mails durch Hinzufügen von Disclaimer oder anderen Teilen verändert und daher die DKIM-Signatur bricht. Es gibt viele Fälle, die eine Message so verändern, dass SPF, DKIM und DMARC die Zustellung verhindern. Kaum ein Admin wird einen Listserver einer anderen Firma das Recht einräumen, mit der Domäne und beliebigen Absendern Mails zu versenden. Das Risiko eines Missbrauchs wäre sehr hoch und die eigene Reputation würde darunter leiden.

ARC in Office 365

In der Einleitung habe ich schon geschrieben, dass Office 365 schon mit ARC arbeitet, auch wenn die RFC noch nicht abgeschlossen ist. In einem Header von einem Office 365 Tenant zu einen 1und1-Postfach konnte ich folgende Header sehen. (Werte gekürzt)

DKIM-Signature: v=1; c=relaxed/relaxed; d=Netatwork.de; s=key1e; 
 t=1581542811; bh=xxxxxxxxx=; h= "Subject:Subject:From:From:Date:Date:ReplyTo:ReplyTo:Cc:Cc:Message-Id:Message-Id"; 
 a=ed25519-sha256; b=xxxxxxxx==
DKIM-Signature: v=1; c=relaxed/relaxed; d=Netatwork.de; s=key1; t=1581542811; 
 bh=x+xxxxx=; h="Subject:Subject:From:From:Date:Date:ReplyTo:ReplyTo:Cc:Cc:Message-Id:Message-Id"; 
 a=rsa-sha256; b=xxxxxxxxxxx
+xxxxxxxxxxxxx=
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
 b=xxxxxx
+xxxxxxx
+xxxxxx==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
 s=arcselector9901;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xxxxxxxxxxxxx=;
 b=xxxxxxxxxxxx==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass
 smtp.mailfrom=netatwork.de; dmarc=pass action=none header.from=netatwork.de;
 dkim=pass header.d=netatwork.de; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=netatwork.onmicrosoft.com; s=selector1-netatwork-onmicrosoft-com;
 h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
 bh=xxxxxxxL+BI=;
 xxxxxx
From: "Carius, Frank" <Frank.Carius@Netatwork.de>
To: frank <frank@carius.de>
Subject: ARC Test 1

Sie sehen am Anfang die beiden DKIM-Signaturen, mit denen Office 365 Mail signiert hat aber schon gleich darauf finden sich Header die mit folgenden Strings beginnen

In meinem Beispiel kommen alle Felder nur einmal vor Aber die Felder können durchaus mehrfach vorkommen. Damit ein Parser auch immer die richtigen drei Felder zusammenführt, werden diese über den Parameter "i=1" verbunden. Wenn ein Relay eigene ARC-Header addiert, dann muss er mit "i=2" weitermachen und so fort.

Die "Kette der Relays"

Das Zeichen "C" steht für "Chain" und gibt einen wichtigen Hinweis. Eine Mail durchläuft vom Absender bis zum Ziel in der Regel mehrere Mailserver und jede Station addiert natürlich eine "Received:"-Header. Bislang wird aber eine DKIM-Signatur in der Regel nur einmal beim Absender eingefügt. Das passiert meist entweder auf dem Server, bei dem der Absender die Mail authentifiziert einliefert oder auf dem Server, der die Mail dann über das Internet sendet. Alle Zwischenstationen sind in der Regel aber außen vor.

Bei ARC geht es nun darum, dass jede Zwischenstation, die eine Mail hinsichtlich DKIM/DMARC verifiziert und das Ergebnis in den Header addiert, zusätzlich auch seine Ergebnisse mit einem ARC-Eintrag wieder signiert. Wenn die Mail dann per Umleitung oder Weiterleitung an den nächsten Server gesendet wird, dann kann dieser zwar selbst wieder DKIM/DMARC auf Basis seiner Informationen prüfen, aber er kann und muss laut RFC zusätzlich auch alle ARC-Information der Zwischenstationen verifizieren. In der Spec wird in dem Zuge gerne von "Chain of Custiody" (Kontrollkette) gesprochen.

Ein entsprechend tauglicher Mailserver kann also prüfen, wie die DKIM/DMARC-Prüfung eines früheren Mailserver in der Kette ausgefallen ist. Was nun noch fehlt ist eine Art "Vertrauen" in diese Signaturen. Denn natürlich kann auch ein schlechter Mailserver ARC-Signaturen und Header addieren und so dem nachfolgenden Server die Illusion geben, dass die Mail schon früher als "sauber" geprüft wurde.

Das System steht und fällt damit, welche Mailserver welchen anderen Mailservern vertrauen. ARC ist also keine zusätzliche oder noch bessere Waffe gegen gegen Spam sondern primär ein Hilfsmittel, um Weiterleitungen und Umleitungen, die per DKIM/DMARC nicht mehr funktionieren, wieder lauffähig zu machen.

Allerdings ist ARC nun nicht die Lösung für alle Probleme die mit Weiterleitungen/Umleitungen einhergehen. Schließlich muss sich ein Server das "Vertrauen" erst einmal verdienen. Daher ist ARC ursprünglich für die großen Mailprovider (MSN, Outlok.com, AOL, GMail, Yahoo etc.) interessant, da hier wohl sehr oft Mails umgeleitet werden. Stellen Sie sich vor, sie haben zeit vielen Jahren ein MSN-Konto und sind auch zufrieden damit. Wenn Sie dann ihre "meinfamilienname.tld"-Domain gekauft haben, wollen Sie vielleicht nicht auch ihr Postfach zu dem neuen Provider umziehen sondern einfach Mails an die Domain an ihr gewohntes Postfach senden.

Der Trick mit ARC ist ein Reputationslevel, welches die Provider anfangs noch manuell pflegen, d.h. wenn z.B. ein großer Provider schon ARC verstehen würde, könnte es z.B. den ARC-Signaturen der anderen großen vertrauen und damit die Weiterleitung zwischen den Providern ermöglichen, die heute wegen SPF und Co. meist nicht funktionieren. Zumindest nicht, wenn die Domain des originalen Absenders z.B. mit "-all" den Versand von anderen Servern außer den eigenen Systemen verhindert.

Wo gibt es ARC

Eine vollständige Liste habe ich noch nichts gefunden. Der Trick ist eben einfach per Stichprobe oder Tests von Mails in den Header zu schauen. Aber einige "große" Provider und Mailserver machen schon mit oder sie könnten ARC-Support aktivieren. Gesehen habe ich bislang

  • Provider:
    Gmail und G-Suite, Office 365 und AOL
  • ListServer
    "Mailman" und Sympa
  • Mailserver
    HalonMTA, Exim, Oracle Mailserver
  • Spamfilter
    n.n

Da der Einsatzbereich aber eher bei Providern und Listservern zu finden ist, gehe ich nicht von einer allzu großen Verbreitung für de zentrale lokale Mailserver in Firmen aus. Am ehesten erwarte ich, dass vielleicht Spamfilter die Überprüfung von ARC-Einträgen in ihre Featureliste aufnehmen.

Weitere Links