46. pepsi-stage-check-whitelist

Marquer comme non-spam le courrier des expéditeurs de confiance.

46.1. Rôle

pepsi-stage-check-whitelist consulte une liste blanche nommée d’expéditeurs de confiance et, lorsque l’en-tête From: du message correspond, note state.spam = false afin qu’une étape pepsi-stage-anti-spam ultérieure laisse passer le message sans paiement. Placez-la avant l’étape anti-spam. Elle ne fait qu’annoter l’état et avancer — elle ne rejette, ne fait rebondir ni ne met jamais un message en pause. Référence : pepsi-stage-check-whitelist(1).

46.2. Fonctionnalités

  • Listes blanches en base de données : la table pepsi.whitelist regroupe les lignes sous un whitelist_name. WHITELIST_NAME est une liste séparée par des virgules des groupes à consulter, et une entrée peut être un modèle contenant {localpart} ou {login}, développé pour chaque destinataire d’enveloppe — ainsi WHITELIST_NAME = correspondents, {localpart}/correspondents consulte la liste partagée de l’opérateur et celle propre à chaque destinataire, l’espace de noms que pepsi-whitelist permet à cet utilisateur de gérer. Seul un destinataire d’un domaine local peut nommer une liste blanche (sinon un co-destinataire choisi par un attaquant se développerait en la liste de n’importe quel utilisateur local), et {login} exige en outre que l’adresse se résolve vers un compte passwd : placez donc l’étape après pepsi-stage-aliases lorsque vous l’utilisez. Tous les noms applicables sont vérifiés en une seule requête.

  • Correspondance ERE POSIX : chaque whitelist_regex est une expression régulière étendue POSIX comparée sans tenir compte de la casse (l’opérateur ~* de PostgreSQL, en un seul aller-retour) au champ que nomme le match_field de la ligne :

    • from (la valeur par défaut) — l”addr-spec extraite de l’en-tête From:, jamais la valeur brute de l’en-tête : autrement, une adresse figurant sur liste blanche placée à l’emplacement du nom d’affichage permettrait d’usurper une correspondance. Les commentaires RFC 5322 et les CFWS sont supprimés, et un From: nommant plus d’une boîte aux lettres ne correspond à rien (le verdict DKIM/DMARC est calculé pour la première adresse ; faire correspondre une adresse ultérieure répondrait à deux questions portant sur deux expéditeurs).

    • list-id — l’identifiant RFC 2919 de l’en-tête List-Id: du message. Les envois d’une liste de diffusion portent des adresses From: arbitraires ; aucun motif from ne peut donc exprimer « tout ce qui est passé par cette liste ».

    L’expression elle-même n’est pas ancrée ; ancrez-la avec ^/$ pour correspondre à une adresse entière (ce qu’écrit pepsi-stage-auto-whitelist).

  • Conditions facultatives par ligne :

    • dkim_required → ne correspond que si le domaine From: est authentifié : state.auth.dkim = pass, ou un succès ARC que DMARC confirme également (state.auth.arc = pass et state.auth.dmarc = pass). Un succès ARC seul n’est qu’une intégrité de chaîne (une chaîne à un seul saut peut être forgée par l’expéditeur lui-même sur un From: falsifié), il ne satisfait donc pas la ligne à lui seul. La colonne vaut true par défaut, comme le fait pepsi-whitelist add.

    • signature_required → ne correspond que si state.signature_verified vaut true, ce que pepsi-stage-decrypt positionne pour un message dont la signature de bout en bout a été vérifiée contre une clé digne de confiance. Un verdict valid-untrusted ne le positionne délibérément pas, de sorte qu’une telle ligne est une véritable barrière « ce correspondant signe, de manière vérifiable » plutôt qu’un « quelqu’un a signé ceci ». Placez une étape de déchiffrement avant celle-ci, sinon la ligne ne correspond jamais.

    • sealer_domain → ne correspond que si le message est arrivé avec une chaîne ARC qui a validé et que l’ADMD nommé figure parmi ses scelleurs (state.auth.arc = pass et le domaine dans state.auth.arc_sealers). C’est ce qui rend une ligne list-id sûre : List-Id: est un texte non authentifié que n’importe qui peut copier, et une chaîne ARC valide ne véhicule par elle-même aucune confiance (RFC 8617 §8.4) — c’est le fait de nommer le scelleur qui transforme le couple en preuve.

  • Non destructif : en cas de correspondance, elle fusionne spam: false et avance vers NEXT_STAGE ; sans correspondance, elle avance inchangée. Un message sans en-tête From:, comme un message auquel aucun nom de liste blanche configuré ne s’applique, ne correspond à rien.

46.3. Configuration

[stage-<name>] : PROGRAM = pepsi-stage-check-whitelist, WHITELIST_NAME (obligatoire — la liste, séparée par des virgules, des groupes whitelist_name, littéraux ou sous forme de modèle), NEXT_STAGE (obligatoire — l’étape transmet toujours le message), ainsi que les options de localité partagées LOCAL_DOMAINS (par défaut [pepsi-ingress] ACCEPTED_DOMAINS), TARGETS et RECIPIENT_DELIMITER, qui ne servent qu’à développer les substituants. Voir pepsi-stage-check-whitelist(1).

46.4. État

  • Entrées : state.auth.dkim / state.auth.arc / state.auth.dmarc (pour les lignes dkim_required), state.auth.arc_sealers (pour les lignes sealer_domain) et state.signature_verified (pour les lignes signature_required ; écrit par pepsi-stage-decrypt). L’en-tête From: provient de la colonne from_header ; List-Id: est lu dans le bloc d’en-têtes, ce qui explique pourquoi cette étape charge les en-têtes (mais jamais le corps).

  • Sorties : en cas de correspondance, spam: false est fusionné dans state ; sinon state est inchangé.

46.5. Voir aussi

pepsi-stage-anti-spam, pepsi-stage-arc, Fonctionnalités prises en charge, pepsi-stage-check-whitelist(1).