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.

Beachten Sie dazu auch die Seite: EXO Antispam-Support zu Exchange Online und SPF, DKIM, DMARC, ARC, SRS, u.a.

Eignung von ARC

Mails können auf dem Transport durch Relay-Stationen verändert werden. Es gibt gewollte Veränderungen wie z.B. Disclaimer/Signaturen oder Weiterleitungen über Mailinglisten etc. Für einen Empfänger ist es auch ohne SMIME-Signatur nützlich, wenn die Authentizität des Absenders überprüfbar ist. Bei ARC signiert der Mailserver die Nachricht, auch wenn er nicht für die Domain zuständig ist und daher keine DKIM-Signatur im eigentlichen Sinne anlegen kann. Aber der Empfänger kann nun einfach dem ARC-Signierer vertrauen.

Für ARC gibt es meiner Ansicht nach nur die folgenden Einsatzszenarien:

  • Backup-MX/Smarthost vor deinem Server
    Wenn der eigene Mailserver eine Nachrichten nicht nur direkt, sondern z.B. von einem Relay beim Provider erhält, dann kann der Provider die Mail per ARC signieren und ihre Mailserver vertraut dieser Signatur. Der Fall ist aber selten, da ein Backup-MX bei anderen Firmen immer weniger zum Einsatz kommen. DA war was zur Zeiten von wackeligen Verbindungen oder Dialup-Verbindungen. Heute würde ich dann eher TLS/STARTTLS bauen. Hier ist dann die komplette SMTP-Übertragung verschlüsselt und der sendende Server kann sich per Zertifikat ausweisen.
  • Große Consumer-Provider
    Wenn sie als Hoster (z.B. Yahoo, MSN/Hostmail, GMail, T-Online, GMX u.a. Millionen Kunden haben, dann bedeutet jede zu unrecht abgelehnte Mail Kosten. Der Nutzer ruft an, macht ein Support-Ticket auf und es kostet einfach viel Zeit, sorgt für Verdruss und Kosten.
    Bei ARC muss ein Mailserver-Administrator aber explizit einen Trust konfigurieren. Das machen aber wohl Comcast, Yahoo, Microsoft/MSN/Hotmail, GoogleMail gegenseitig.

Umgekehrt bedeutet das aber auch, dass ARC uns nicht beim Thema Spamfilter oder Spam-Allowlisting hilft.

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 Exchange Online

In der Einleitung habe ich schon geschrieben, dass Exchange Online 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 weiter.

Ich habe noch keinen Weg gefunden, die Kennzeichnung mit einem ARC-Seal zu unterbinden. Das kann zu Problemen führen, wenn Sie ausgehend vom Tenant ins Internet ein eigenes Relay davor schalten, welches die Mails noch einmal verändert, z.B. Disclaimer oder SMIME-Signatur. Das ARC-Seal von Microsoft wird dann ungültig.

Ein ungültiges ARC-Siegel sollte aber kein Problem darstellen, wenn Sie weiterhin eine DKIM-Signatur anbinden oder die ausliefernde IP-Adresse als SPF-Eintrag bereitstellen.

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. Hier mal am Beispiel einer Mal von Teams in meinem Postfach, welche eingehend von NoSpamProxy verifiziert wurde

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.

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