ARC - Authenticated Received Chain
Der DMARC-Check beim Empfänger kann nur dann sinnvoll eingesetzt werden, wenn entweder der Absender direkt beim Empfänger einliefert (SPF) oder die Mail bei mehreren Zwischenstationen mit Weiterleitungen unverändert bleibt (DKIM). Zwischenstationen, die Mails modifizieren, können nun ARC benutzen, um dem Empfänger mit ARC-Signaturen kryptografisch gesichert mitzuteilen, wie der Stand von SPF, DKIM und DMARC beim Empfang der Mail ausgesehen hat.
Der Empfänger kann nun diese ARC-Signaturen auswerten und entscheiden, ob er die ursprünglichen SPF-, DKIM- und DMARC-Checkergebnisse der Zwischenstation zur Bewertung heranzieht oder auch nicht.
Problem:
Eine Zwischenstation kann mit ARC-Signaturen beliebig behaupten, sie hätte Checks beim Eingang durchgeführt und damit auch beliebige Absender fälschen.
Konsequenzen:
- Man darf nicht beliebigen ARC-Signaturen vertrauen, man benötigt eine eigene Reputations-Datenbank (z.B. Whitelist).
- Bei längerer Chain mit mehreren Zwischenstationen muss man jeder Zwischenstation einzeln vertrauen, nur eine vertrauenswürdige Signatur reicht nicht.
- Nicht vertrauenswürdige Chains sollten ignoriert werden.
- Bei vertrauenswürdiger ARC-Chain kann das SPF/DKIM/DMARC-Check-Ergebnis aus dem ersten ARC-Authentication-Results-Header übernommen und die eigenen Check-Ergebnisse damit überschrieben werden.
Einsatz-Szenarien
- Forwarding durch Mailprovider oder Mailinglisten, die Mails modifizieren.
- Secure-Mail-Appliances, die Mails modifizieren, z.B. am Eingang einer großen Einrichtung.
Best Practices für das Weiterleiten von Emails
- Wenn man beim Weiterleiten den From-Header modifiziert, dann benutzt man kein ARC, sondern signiert mit DKIM.
- Wenn man die Mail unverändert lässt, benutzt man ARC, aber kein DKIM.
- Mailinglistenserver mit mehreren Listen müssen DKIM-'strict'-Alignments verwenden, damit zwischen den Listen unterschieden werden kann.
- Man benutzt nicht die SPF/DKIM/DMARC/ARC-Features der Listserversoftware, sondern die Features der ein- und ausgehenden Mailer. Eingehend setzt man Authentication-Results-Header, ausgehend erzeugt man mit dessen Hilfe die ARC-Signaturen.
- Schlägt der eingehende DMARC/ARC-Check fehl, so sollte eine Mailinglisten-Policy entscheiden, ob die Mail angenommen wird oder nicht. Wird sie angenommen, so muss der Server danach schauen, dass seine Mails bei den Empfängern auch angenommen werden. Es sollten daher sämtliche ARC-Header entfernt und die Mails DKIM-signiert werden.
Vorgang der ARC-Signierung
Für ARC kommt derselbe Signatur-Algorithmus zum Einsatz wie bei DKIM und man veröffentlicht ebenfalls domainkey-DNS-Records. Im Prinzip könnte man auch dasselbe Keypaar verwenden wie für DKIM-Signaturen.
1. Der Mailserver checkt eingehend auf SPF/DKIM/DMARC/ARC und schreibt die Ergebnisse in einen Header namens Authentication-Results:
Authentication-Results: mgw6-han.srv.dfn.de (amavisd-new);
dkim=fail (1024-bit key) reason="fail (message has been altered)"
header.d=redhat.com
2. Sobald die Mail weitergeleitet wird, kommt ARC ins Spiel. Der Authentication-Results-Header wird gelöscht und der Inhalt in einen ARC-Authentication-Results-Header übernommen:
ARC-Authentication-Results: i=1; mx.microsoft.com; spf=pass
smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com;
dkim=pass header.d=oracle.com; arc=none
3. Danach wird eine DKIM-analoge Signatur über die Mail ohne ARC-Header erzeugt und in den ARC-Message-Signature-Header geschrieben:
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=gF9w4nOveA6VSvDyJ9Psfb3QHGTx5bOFK8qBgFuKb78=
b=H/5v1PF2BD5g7rYHNwcUjrv2ZhbOzmIa71O2jlqX77vqVpYj8V03H4OykBreZayjUkH1XRTj1hdJLBpm63V57f4q+F34+OkiOH0Q7NbCiPXqGx1/zZAMhh71c0unZH8Z7zKaVFOF4pPIczy8gvX1M/zKOfxzT3pTc+BcY1dBjAFVbyNqiHV/Cfl+pjfd0R1MaJMNvlZwPHJPuiMz+BLhInCsHr6DHmZhMPAZZrVBvtYcS7BrtxkzQhK2tgrg02UqfICG477zEYvu6j6Kpffb8dZjW+RbsrFgPC/UDJD/nlyPl+FKaLcbHysmcarpQTC+9pn5+RrEbOtJd2LHD0nOhQ==
4. Schließlich werden alle ARC-Header signiert und die Signatur in den ARC-Seal-Header geschrieben:
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=d10tTQZdafaYRf4eYzK5JXuRZ8XAhHXwzXBMrCwMCEWLNl+6eBdMj9L6WzYJzAm+TQivD/IFXZnMKbrDLZfFfXwtkH1AKbDamwIi+syoC3Bnsg1ufn6FTqudVEB7w6g9xK/trOQIs7VNJfkI8k78gi7UMKDZJVVb3Tin/irQ3qszZIVcElN04Z1Arqjl09b2FpzdGKfTurqg4AoDZL38NMpe+tmhzrLspSM3SnGWZV4A0QjYK/2WbQ89PQk/ok2uQmFNWXp/AkeG/uR9hzSfqLPO4aZm8KKvlzhgH0Clmt/1zEJ49NFHY5myXsCy8xV0Fr4UH6dDKo99DF+krheEug==
5. Geht die Mail durch einen weiteren Hop, kann dieser Server die Prozedur wiederholen und einen weiteren Satz ARC-Header einfügen. Die Sätze werden durch den enthaltenen i= Parameter unterschieden.
Verifikation der ARC-Signaturen
Die ARC-Sätze werden anhand des i-Parameters vom neuesten zum ältesten validiert. Nur wenn alle Sätze gültig sind, gilt die Validierung als bestanden.
Interpretation der Authentication-Results-Header
Der Inhalt der Authentication-Results-Header kann recht vielfältig ausfallen, wir verweisen hier auf die Literatur:
ARC im DFN-MailSupport
ARC-Signaturen werden vom Spamassassin durch das DKIM-Plugin geprüft und je nach Ergebnis folgende Hits in den X-Spam-Report-Header bzw. in die Amavis-Syslogzeile geschrieben:
| Hit | Score | Bedeutung |
|---|---|---|
| ARC_SIGNED | 0.001 | Es sind ARC-Signaturen in der Mail enthalten |
| ARC_VALID | -0.1 | Die Arc-Signaturen sind gültig |
| ARC_INVALID | 0.1 | Die ARC-Signaturen sind ungültig |
Eine weitergehende Interpretation der ARC-Authentication-Results:-Header-Inhalte ist vorerst nicht vorgesehen.