31. pepsi-stage-arc

ARC-Verifikation, Signieren und Versiegeln — die Einstiegs-Stage auf dem eingehenden Pfad.

31.1. Rolle

pepsi-stage-arc implementiert ARC (RFC 8617). Es verifiziert jede vorhandene eingehende ARC-Kette und versiegelt, wenn ein ARC_DOMAIN und seine Schlüssel konfiguriert sind, die Nachricht als unsere ADMD, sodass das Grenz-Authentifizierungsurteil Pepsis Weiterleitungs-Hop überdauert. Weil es nur für Mail gilt, die wir empfangen und weiterleiten, darf es niemals unsere eigenen Submissions (state.local_origin) berühren — diese werden stattdessen von pepsi-stage-dkim-sign als Autor-Domain signiert, und die Stage überspringt jede solche Nachricht. Auf einem Host, der sowohl empfängt als auch einliefert, platzieren Sie sie nur auf dem eingehenden Zweig, nach der state.local_origin-Aufteilung (vor SRS); auf einem reinen Empfangs-Host ist sie die [stage-init]-Stage. Referenz: pepsi-stage-arc(1).

31.2. Funktionen

  • ARC-Verifikation jeder eingehenden Kette; das Urteil wird unter state.auth.arc festgehalten.

  • ARC-Versiegelung: stellt ein frisches ARC-Set voran — ARC-Authentication-Results (AAR), ARC-Message-Signature (AMS) und ARC-Seal (AS) — als die ARC_DOMAIN-Identität, signiert mit dem einzigen ARC_ALGORITHM (rsa oder ed25519; ARC erlaubt eine Signatur pro Hop).

  • AAR aus dem Urteil an der Grenze: Die AAR verwendet das Authentication-Results-Fragment wieder, das Ingress unter state.origin.ar_results gespeichert hat, sodass SPF/DKIM/DMARC genau einmal verifiziert werden, bei Ingress. Hier wird nur die eingehende ARC-Kette verifiziert, um den Kettenvalidierungswert (cv=) und die arc=-Zeile der AAR zu berechnen.

  • Nur-Voranstellen: Die Versiegelung wird oben hinzugefügt, sodass bestehende tiefere Signaturen und der Ingress-Received:-Header unberührt bleiben; nur die headers-Spalte wird umgeschrieben, nie der Nachrichtentext.

  • Fail-open: Wenn der Ursprungskontext, die [pepsi]-Konfiguration oder die Schlüssel fehlen oder die Versiegelung fehlerhaft ist, wird die Nachricht unversiegelt mit einer Warnung weitergeschaltet (das Urteil wird dennoch festgehalten, wenn berechenbar).

31.3. Konfiguration

[stage-<name>]: PROGRAM = pepsi-stage-arc, NEXT_STAGE (erforderlich — die Stage reicht die Nachricht immer weiter, sodass ein fehlendes jede Nachricht scheitern lässt), die DNS-Einstellungen DNS_SERVERS (leer = Systemresolver) / DNS_TIMEOUT sowie die gemeinsamen Signaturparameter HEADER_CANONICALIZATION / BODY_CANONICALIZATION (standardmäßig relaxed, oder simple), SIGNED_HEADERS (das From enthalten muss) und SIGNATURE_EXPIRATION_DAYS (standardmäßig kein x=), angewandt auf die AMS und das ARC-Seal. Die Signieridentität, die Schlüssel und der Algorithmus stammen aus dem gemeinsamen [pepsi]-Abschnitt (ARC_DOMAIN, ARC_ALGORITHM, KEY_DIR, DKIM_SELECTOR). Siehe pepsi-stage-arc(1).

31.4. State

  • Eingaben: state.local_origin — wenn wahr, wird die Nachricht unberührt weitergeschaltet (kein ARC bei Mail, die wir erzeugen); andernfalls state.origin — die authserv_id (erforderlich, um die AAR-Identität zu reproduzieren; ohne sie schaltet die Stage unversiegelt weiter), ar_results (in der AAR wiederverwendet) und remote_ip / helo für den Kontext der ARC-Verifikation.

  • Ausgaben: überschreibt state.auth.arc mit dem neu bewerteten Kettenurteil und hält die Siegler-Domains der Kette unter state.auth.arc_sealers fest (der Rest von state, einschließlich der übrigen state.auth-Geschwister und state.dsn, bleibt erhalten). Zu beachten ist, dass arc_sealers nur sagt, wer zu siegeln behauptet hat; jeder Leser muss daher zuerst state.auth.arc == "pass" verlangen.

31.5. Siehe auch

pepsi-ingress, pepsi-stage-dkim-sign, Unterstützte Funktionen, pepsi-stage-arc(1).