75. pepsi-stage-list-bounce

Attribue un rejet entrant à l’abonnement qu’il concerne et le comptabilise.

75.1. Rôle

pepsi-stage-list-bounce consomme les rejets : un échec de remise revenu à l’adresse -bounces d’une liste est attribué au membre qu’il concerne et comptabilisé, et dès que le score franchit le seuil de la liste, la remise est désactivée pour ce membre, celui-ci est averti, puis finalement désabonné. Référence : pepsi-stage-list-bounce(1).

Avertissement

Trois choses portent le nom de « bounce » dans cet arbre et ce ne sont pas les mêmes. Celle-ci lit un rapport d’échec entrant. pepsi-stage-bounce génère une notification d’état de remise pour un message que Pepsi lui-même n’a pas pu remettre. pepsi-failure-bouncer récupère les messages sur lesquels le pipeline a renoncé et les confie à ce générateur. Une configuration qui pointe le NEXT_STAGE de cette étape vers le générateur répond à un rejet par un rejet, et pepsi-setup la refuse.

Ce sous-système est une réimplémentation de GNU Mailman 3 ; voir Listes de diffusion, qui nomme ce qui a été repris d’amont.

75.2. Attribution

Quatre étapes, par certitude décroissante. Les deux premières sont exactes, parce que c’est Pepsi qui a écrit l’adresse qu’elles lisent.

1. L’enveloppe VERP. Chaque copie qu’une liste envoie porte l’expéditeur d’enveloppe <list>-bounces+<local>=<domain>@<host> ; un rejet de cette copie nomme donc le membre sans ambiguïté. La partie <list>-bounces doit correspondre à la boîte de rejets propre à cette liste avant que l’adresse soit crue : sans ce contrôle, n’importe qui pourrait faire comptabiliser un rejet contre n’importe quel membre de n’importe quelle liste en écrivant à une adresse inventée. Une correspondance VERP doit encore ressembler à un échec – un échec temporaire est ignoré d’emblée, et un message VERP sans aucun échec reconnu est transféré et non comptabilisé, car ce peut être une réponse d’absence ou le rapport d’un antivirus, arrivé ici au seul motif que c’est ce qui figurait sur l’enveloppe.

2. Un jeton de sonde (<list>-bounces+<token>@<host>), lorsque BOUNCE_PROBES est actif.

3. Les détecteurs heuristiques, sur tout le message.

4. Rien n’a pu être établi – le rejet est emballé et transféré à un humain.

75.3. Comptabilisation

La logique est celle de GNU Mailman 3, reproduite pas à pas, parce que chaque attribut qu’elle lit est visible par l’API REST et que la documentation d’un serveur explique ce que chacun fait : une liste absente ou un non-membre est abandonné ; un rejet de sonde désactive immédiatement, sans comptabiliser, car un rejet de sonde est décisif ; chez un membre déjà désactivé pour cause de rejets il s’agit d’un rejet résiduel, qui est abandonné ; un second rejet pour le même membre le même jour civil ne met à jour que l’horodatage ; un premier rejet, ou un rejet plus ancien que bounce_info_stale_after, remet le score à 1, sinon il est incrémenté ; les propriétaires sont informés si bounce_notify_owner_on_bounce_increment est posé ; et à bounce_score_threshold ou au-delà, une sonde est envoyée si les sondes sont actives (ce qui remet le score à zéro), sinon le score est mis à zéro et la remise désactivée.

La règle « au plus une incrémentation par jour » est la raison pour laquelle une tempête de rejets ne peut pas vider une liste en un après-midi : avec le seuil par défaut de 5, il faut à un membre des échecs sur cinq jours différents.

75.4. Avertissement et retrait

Désactiver un membre n’est pas le désabonner. Deux passes périodiques, exécutées par pepsi-list tasks --once depuis une minuterie systemd (voir pepsi-list), achèvent l’histoire : un membre désactivé pour cause de rejets ayant reçu moins de bounce_you_are_disabled_warnings avertissements, dont le dernier remonte à au moins bounce_you_are_disabled_warnings_interval, en reçoit un ; et une fois les avertissements épuisés et l’intervalle de nouveau écoulé, le membre est désabonné, les propriétaires étant informés si bounce_notify_owner_on_removal est posé. Un membre qui s’est désactivé lui-même ou qu’un modérateur a désactivé n’est touché par aucune des deux passes.

Mettre bounce_you_are_disabled_warnings à zéro retire un membre désactivé à la passe suivante sans aucun courrier d’avertissement. C’est le comportement documenté d’amont, et il est délibéré, non un cas limite.

Les notifications de ces passes sont injectées à [pepsi-list] NOTICE_STAGE, parce que les passes tournent depuis une minuterie et non depuis une étape. pepsi-setup refuse une configuration qui fait tourner cette étape sans elle : sans étape où injecter, un membre serait averti trois fois dans la base et pas une seule par courrier.

75.5. Sondes

Avec [pepsi-list] BOUNCE_PROBES = yes, franchir le seuil envoie au membre une sonde au lieu de le désactiver : un message adressé à lui seul, depuis un expéditeur d’enveloppe portant un jeton à usage unique, avec le rejet déclencheur en pièce jointe, et son score remis à zéro tant que la sonde est en cours. Si la sonde est rejetée, le jeton l’identifie exactement et la remise est désactivée aussitôt ; si elle ne l’est pas, rien ne se passe et il continue de recevoir du courrier.

Les sondes sont désactivées par défaut, comme chez amont. Le compromis : un message de plus vers une adresse probablement morte, contre le fait de ne pas désactiver un membre dont le fournisseur a eu un mauvais après-midi. Un jeton de sonde vaut dix jours et ne porte aucun en-tête Precedence: bulk – une sonde existe pour être rejetée, et cet en-tête invite certains systèmes à ne pas la rejeter.

75.6. Rejets non reconnus

Un rejet que rien n’a reconnu est emballé dans une notification explicative, l’original joint tel quel en message/rfc822, et envoyé à qui le forward_unrecognized_bounces_to de la liste désigne : administrators (par défaut), site_owner ou discard.

C’est une fonctionnalité et non un recours. Chaque rejet qui passe à travers est un format que le corpus n’a pas, et celui qui le reçoit peut envoyer l’échantillon aux mainteneurs de Pepsi afin que le détecteur soit écrit. Sous chaque disposition – discard compris – ce passage à travers est compté dans pepsi.event_log sous list.bounce.unrecognized, car sa fréquence est ce qui dit si un serveur a besoin de détecteurs supplémentaires.

75.7. Formats de rejet reconnus

Dix-sept détecteurs, essayés dans un ordre fixe, le premier qui correspond l’emporte, portés depuis flufl.bounce (Apache-2.0, copyright Barry Warsaw) et chacun testé contre les données de test de cette bibliothèque : dsn, exim, sina, yahoo, yale, smtp32, postfix, qmail, groupwise, microsoft, caiwireless, exchange, netscape, aol, simplematch, simplewarning, llnl.

Un seul d’entre eux – dsn, la RFC 3464 – est une norme ; les autres nomment un éditeur ou un site. En pratique, ils comptent bien moins ici qu’en amont, car Pepsi applique VERP à chaque copie de chaque message : un rejet d’un message envoyé par Pepsi est donc attribué par son enveloppe sans que rien de tout cela soit consulté. Les détecteurs sont ce qui lit un rejet parvenu à une liste par un autre chemin.

Un message qu’aucun détecteur ne reconnaît n’est pas un rejet du point de vue de cette étape, et il est transféré plutôt que deviné. La distinction vaut d’être connue à la lecture d’un journal : « Pepsi ne l’a pas reconnu » et « Pepsi a décidé que ce n’était pas un échec » sont deux phrases différentes.

75.8. Configuration

[stage-<name>] : PROGRAM = pepsi-stage-list-bounce, NEXT_STAGE (où va un non-rejet transféré — pas le générateur de notifications d’état de remise) et RESPONSE_STAGE, tous deux obligatoires. [pepsi-list] fournit NOTICE_STAGE, BOUNCE_PROBES et BOUNCE_EVENT_RETENTION ; les attributs bounce_* propres à chaque liste sont dans la base. Voir pepsi-list et Listes de diffusion.

75.9. State

• Entrées : state.list – l’identifiant de liste, le rôle -bounces et tout détail VERP porté par l’adresse –, écrit par pepsi-stage-list.

• Sorties : des événements de rejet et l’état de remise du membre dans la base ; des notifications et des sondes injectées comme nouveaux messages.

• Transitions : achèvement (un rejet comptabilisé est consommé) ou passage à l’étape suivante (un non-rejet transféré).

75.10. Voir aussi

Listes de diffusion, pepsi-stage-list, pepsi-stage-bounce, pepsi-failure-bouncer, pepsi-list, pepsi-stage-list-bounce(1).