31. pepsi-stage-arc

Vérification, signature et scellement ARC — l’étape d’entrée du chemin entrant.

31.1. Rôle

pepsi-stage-arc implémente ARC (RFC 8617). Elle vérifie toute chaîne ARC entrante existante et, lorsqu’un ARC_DOMAIN et ses clés sont configurés, scelle le message en tant que notre ADMD afin que le verdict d’authentification pris à la limite survive au saut de redirection de Pepsi. Comme elle ne s’applique qu’au courrier que nous recevons et redirigeons, elle ne doit jamais toucher nos propres soumissions (state.local_origin) — celles-ci sont signées comme domaine auteur par pepsi-stage-dkim-sign à la place, et l’étape ignore tout message de ce type. Sur un hôte qui à la fois reçoit et soumet, placez-la sur la branche entrante uniquement, après la scission state.local_origin (en amont de SRS) ; sur un hôte en réception seule, elle est l’étape [stage-init]. Référence : pepsi-stage-arc(1).

31.2. Fonctionnalités

  • Vérification ARC de toute chaîne entrante ; le verdict est noté sous state.auth.arc.

  • Scellement ARC : ajoute en tête un nouvel ensemble ARC — ARC-Authentication-Results (AAR), ARC-Message-Signature (AMS) et ARC-Seal (AS) — sous l’identité ARC_DOMAIN, signé avec l”unique ARC_ALGORITHM (rsa ou ed25519 ; ARC permet une signature par saut).

  • AAR issu du verdict à la frontière : l’AAR réutilise le fragment Authentication-Results qu’ingress a stocké sous state.origin.ar_results, de sorte que SPF/DKIM/DMARC sont vérifiés exactement une fois, à l’ingress. Seule la chaîne ARC entrante est vérifiée ici, pour calculer la valeur de validation de chaîne (cv=) et la ligne arc= de l’AAR.

  • Ajout en tête uniquement : le sceau est ajouté en haut, de sorte que les signatures inférieures existantes et l’en-tête Received: de l’ingress ne sont pas perturbés ; seule la colonne headers est réécrite, jamais le corps.

  • Fail-open : si le contexte d’origine, la config [pepsi] ou les clés manquent, ou si le scellement échoue, le message est avancé non scellé avec un avertissement (le verdict est tout de même noté lorsqu’il est calculable).

31.3. Configuration

[stage-<name>] : PROGRAM = pepsi-stage-arc, NEXT_STAGE (obligatoire — l’étape transmet toujours le message, si bien qu’une valeur manquante fait échouer chaque message), les paramètres DNS DNS_SERVERS (vide = résolveur système) / DNS_TIMEOUT, et les paramètres de signature partagés HEADER_CANONICALIZATION / BODY_CANONICALIZATION (relaxed par défaut, ou simple), SIGNED_HEADERS (qui doit inclure From) et SIGNATURE_EXPIRATION_DAYS (pas de x= par défaut) appliqués à l’AMS et à l’ARC-Seal. L’identité de signature, les clés et l’algorithme proviennent de la section partagée [pepsi] (ARC_DOMAIN, ARC_ALGORITHM, KEY_DIR, DKIM_SELECTOR). Voir pepsi-stage-arc(1).

31.4. État

  • Entrées : state.local_origin — lorsqu’il est vrai, le message est avancé sans être touché (pas d’ARC sur le courrier que nous émettons) ; sinon state.origin — l”authserv_id (requis pour reproduire l’identité de l’AAR ; sans lui, l’étape avance non scellée), ar_results (réutilisé dans l’AAR), et remote_ip / helo pour le contexte de vérification ARC.

  • Sorties : écrase state.auth.arc avec le verdict de chaîne réévalué et enregistre les domaines scelleurs de la chaîne sous state.auth.arc_sealers (le reste de state, y compris les autres voisins de state.auth et state.dsn, est préservé). Noter que arc_sealers indique seulement qui a prétendu sceller : tout lecteur doit donc d’abord exiger state.auth.arc == "pass".

31.5. Voir aussi

pepsi-ingress, pepsi-stage-dkim-sign, Fonctionnalités prises en charge, pepsi-stage-arc(1).