ARC-Chain-Validator
Gruppiert ARC-Sets und prüft Instanzfolge, Pflicht-Tags, Chain-Status und Kontinuität.
E-Mail-SicherheitWie ARC Authentifizierung über Weiterleitungen rettet
Eine Weiterleitung ändert den sendenden Rechner; eine Mailingliste oft zusätzlich die Nachricht. ARC verhindert beides nicht und verwandelt keinen Fehler in einen Pass — es konserviert authentifizierte Beobachtungen, damit ein späterer Empfänger eine bessere, ausdrücklich eigene Entscheidung treffen kann.
SPF zerbricht am neuen SMTP-Hop
SPF prüft die verbindende IP gegen die Domain des Envelope-Senders. Ein Forwarder nimmt die ursprüngliche Nachricht an und öffnet aus seiner Infrastruktur eine neue SMTP-Verbindung. Solange diese Infrastruktur nicht zufällig von der ursprünglichen Envelope-Domain autorisiert ist, schlägt der nachgelagerte SPF-Check fehl. Niemand muss etwas gefälscht haben; die von SPF bewertete Identität hat schlicht eine Grenze überschritten, die ihre Policy nicht kennt. Für DMARC zählt SPF zudem nur, wenn die authentifizierte Envelope-Domain mit der sichtbaren From-Domain aligned ist. Genau deshalb ist „SPF fail nach Forwarding“ zunächst erwartete Topologie und noch kein Beweis für Spoofing.
Sender Rewriting Scheme kann dem Forwarder eine eigene Envelope-Domain geben und SPF für diese umgeschriebene Identität bestehen lassen. Das hält Bounces beherrschbar und beseitigt den nackten SPF-Fehler, erzeugt aber normalerweise kein Alignment zur ursprünglichen From-Domain. DMARC besteht dadurch nicht automatisch. SPF beschreibt den unmittelbaren Transport-Hop. Wer daraus eine dauerhafte Aussage über den Autor durch beliebige Weiterleitungen machen will, verlangt von dem Mechanismus Erinnerung, die er nie transportiert hat.
DKIM überlebt den Transport — bis Inhalt wandert
DKIM signiert ausgewählte Header und einen Body-Hash. Eine reine Weiterleitung kann deshalb problemlos gültig bleiben: Die neue Client-IP interessiert die Signatur nicht. Mailinglisten, Security-Gateways und Forwarding-Dienste ändern jedoch häufig signierte Daten. Subject-Präfix, Footer, MIME-Konvertierung, Zeilenumbruch oder Link-Rewriting können Body-Hash oder Header-Signatur ungültig machen. Relaxed Canonicalization toleriert begrenzte Whitespace-Varianten, aber keine redaktionellen Eingriffe.
Eine Liste kann die Originalsignatur entfernen und selbst signieren. Doch eine gültige Signatur der Listendomain ist nicht automatisch aligned mit der From-Domain des Autors. From auf die Listendomain umzuschreiben repariert Alignment, verändert aber sichtbare Identität und Antwortverhalten. Keine Variante ist transparent. Mit dem E-Mail-Header-Analyzer trennst du aktuelle SPF-, DKIM- und DMARC-Urteile von List-Headern und Transport-Hops; er strukturiert lokale Evidenz, rechnet Signaturen aber nicht neu. Vergleiche möglichst Original und zugestellte Fassung. Dann wird aus „DKIM fail“ eine konkrete Änderung: genau dieser Footer, dieses Subject-Rewriting oder dieser MIME-Umbau.
ARC transportiert Beobachtungen, keine Immunität
Ein ARC-Intermediär ergänzt pro Hop ein nummeriertes Dreierset. ARC-Authentication-Results hält fest, was er vor eigenen Änderungen beobachtet hat. ARC-Message-Signature signiert die von ihm verarbeitete Nachrichtenform. ARC-Seal versiegelt Set und bisherige Kette, sodass Entfernen, Umordnen oder unehrliches Verlängern bei kryptografischer Prüfung auffällt. Die Instanznummer i= beginnt bei eins und steigt mit jedem versiegelnden Hop.
Das erste Seal trägt cv=none, weil noch keine frühere ARC-Kette zu validieren ist. Spätere Sealer nennen cv=pass oder cv=fail für die empfangene Kette. So kann ein Empfänger sehen, dass ein vertrauter Intermediär aligned DKIM beobachtet hat, bevor ein Listen-Footer die Signatur brach. ARC hat Beobachtung und Übergabekette konserviert. Es hat weder die Originalsignatur repariert noch DMARC-Regeln geändert — und es zwingt niemanden zur Zustellung.
Vertraue erst dem Sealer, dann dem Ergebnis
Eine kryptografisch gültige ARC-Kette beweist, dass die genannten Sealer sie mit den passenden Keys geführt haben. Sie beweist nicht, dass deren Authentication-Engine kompetent war, ihr Konto nicht missbraucht wurde oder ihr Ergebnis Policy-Gewicht verdient. Empfänger führen eigene Vertrauensmodelle für ARC-Sealer, gespeist aus Betriebsbeziehungen, Größe, Reputation und beobachteter Genauigkeit. Ein bekannter großer Forwarder kann die Zustellentscheidung beeinflussen; eine perfekte Kette einer unbekannten Domain darf wirkungslos bleiben.
Darum ist „ARC pass“ kein universelles Authentifizierungsurteil. Ein Receiver kann vertrauenswürdige Upstream-Evidenz nutzen, um einen forwarding-bedingten DMARC-Fehler zu übersteuern, sie nur ins Spam-Scoring einspeisen oder ARC vollständig ignorieren. Die DMARC-Policy der Ursprungsdomain bleibt relevant; die Ausnahme gehört dem Empfänger. Ein Angreifer wird nicht dadurch vertrauenswürdig, dass er seine eigene Behauptung versiegelt — so wenig wie eine Unterschrift den Inhalt einer Behauptung wahr macht. Diese lokale Policy erklärt, warum dieselbe Nachricht bei einem Provider ankommt und beim nächsten im Spam landet: Die Kette ist identisch, ihre Gewichtung nicht.
Lies die erste gebrochene Naht
Beginne mit dem vollständigen Headerblock der zugestellten Nachricht. Gruppiere ARC-Seal, ARC-Message-Signature und ARC-Authentication-Results nach Instanz. Sets müssen vollständig und lückenlos nummeriert sein. Das erste Seal erwartet cv=none, spätere berichten über die Vorgängerkette. Der ARC-Chain-Validator prüft Struktur, Pflicht-Tags und Kontinuität lokal. DNS-Keys holt er nicht; kryptografisch validiert er ebenfalls nicht. Für den endgültigen Befund brauchst du das Urteil des empfangenden MTA oder einen vollständigen Validator mit Originalbody, exakter Canonicalization und DNS-Zugriff.
Suche das erste cv=fail, fehlende Mitglied oder die erste Nummernlücke und untersuche den Übergang direkt davor. Alles Spätere erbt die beschädigte Evidenz; ein weiteres Seal repariert keine Geschichte. Vergleiche danach die d=-Domains mit der Received-Kette und lies, welche Resultate jeder Hop behauptet. Saubere Struktur aus unerwarteter Infrastruktur ist eine Vertrauensfrage. Kaputte Struktur eines bekannten Providers ist ein Implementierungs- oder Handling-Incident. Beides gehört nicht in dasselbe pauschale „ARC kaputt“-Ticket.
Grenzen, die absichtlich bestehen bleiben
ARC verhindert keine bösartige Weiterleitung, garantiert keinen Posteingang, rettet keine Nachricht, deren ursprüngliche Authentifizierung wirklich scheiterte, und ersetzt am Ursprung weder SPF, DKIM noch DMARC. Ein Hop, der ARC-Header entfernt oder nicht versiegelt, beendet die Evidenz. Datenschutzorientierte Systeme kürzen Routingdetails, alte Systeme kennen ARC nicht. Lange Wege sammeln zudem Signaturen und Headergröße; ein einziger gescheiterter Link entwertet die nachfolgende Kontinuität.
Absender brauchen weiterhin aligned DKIM als forwarding-festen Hauptpfad und korrektes SPF für direkte Zustellung. Signiere möglichst Header, die Intermediäre nicht planmäßig verändern, und teste wichtige Listenpfade mit echten Nachrichten statt synthetischen Annahmen. Forwarder sollten Inhalte möglichst erhalten, SRS für Envelope-Hygiene nutzen, vor Änderungen authentifizieren und danach versiegeln. Empfänger benötigen kryptografische Prüfung und eine dokumentierte Sealer-Policy. Diese Policy braucht Reviews: Ein ehemals zuverlässiger Partner kann seine Infrastruktur oder Mandantengrenzen ändern. Vergleiche die Ursprungskontrollen mit dem SPF/DMARC/DKIM-Prüfer. ARC erklärt eine gebrochene Reise; einen schwachen Start macht es nicht vertrauenswürdig.