44. pepsi-stage-anti-spam

Faire barrière à un message derrière un paiement GNU Taler (péage à l’envoi).

44.1. Rôle

pepsi-stage-anti-spam exige un paiement GNU Taler pour un message par ailleurs non classifié avant qu’il puisse continuer dans le pipeline. Au premier passage, elle crée un bon de commande marchand et met le message en pause ; une fois le message réveillé — par le webhook marchand pepsi-resume, que pepsi-setup provisionne sur le backend Taler pour qu’il appelle POST /resume sur pepsi-httpd, ou par l’expiration du délai —, elle transfère, rejette ou attend. Référence : pepsi-stage-anti-spam(1).

44.2. Décision

Pilotée par le JSON state du message :

  • spam: true → abandonner (supprimer la ligne).

  • spam: false ou paid: true → transférer vers NEXT_STAGE (une classification explicite l’emporte sur le flux de paiement).

  • paid: false présent → demander au marchand si le bon de commande est payé :

    • payée → transférer vers NEXT_STAGE ;

    • impayé au-delà du délai stocké → rejeter : réacheminer vers BOUNCE_STAGE (un DSN de rejet pepsi-stage-bounce, ou un abandon silencieux pepsi-stage-discard), ou supprimer lorsqu’aucun BOUNCE_STAGE n’est câblé ;

    • impayé mais encore avant le délai → avec DELAY_DSN_AFTER réglé, c’est le point de contrôle de délai : envoyer par e-mail à l’expéditeur un DSN de délai à usage unique (RFC 3461, seulement s’il a demandé NOTIFY=DELAY) sans libérer le message, puis remettre en pause jusqu’à PAYMENT_DEADLINE ; sinon remettre en pause jusqu’au délai avec un avertissement (ne devrait pas arriver). La ligne reste paused, jamais pending, ce qui tournerait en boucle active contre le réveil anticipé.

  • pas de champ paid → créer un bon de commande v1 tarifé par ORDER_CHOICES (order_id est le jeton du message), mettre en pause jusqu’à PAYMENT_DEADLINE (ou jusqu’au point de contrôle DELAY_DSN_AFTER lorsqu’il tombe plus tôt), en notant paid: false et pay_deadline dans state, et envoyer par e-mail à l’expéditeur une demande de paiement (voir ci-dessous).

Le délai est conservé dans state.pay_deadline car le dispatcher efface le timeout de la ligne lorsqu’il remet en file un message en pause.

Un message à l”expéditeur d’enveloppe nul (un rebond ou une réponse automatique) ne passe jamais par la barrière : l’étape tente plutôt de le vérifier comme une réponse à un courrier que ce déploiement a réellement envoyé, en utilisant l’en-tête de preuve d’origine Pepsi-Origin: (voir Extensions du protocole SMTP). Un rebond dont l’en-tête intégré se vérifie est transféré vers NEXT_STAGE ; un rebond invérifiable — un en-tête falsifié ou expiré, ou tout rebond lorsque la preuve d’origine n’est pas configurée — est acheminé vers BOUNCE_TARGET_STAGE (par exemple une quarantaine) lorsqu’une telle étape est configurée, et transféré tel quel vers NEXT_STAGE lorsqu’il n’y en a pas — jamais silencieusement abandonné.

44.3. Réponse de demande de paiement

Après cette première pause, l’étape émet une réponse automatique à l’expéditeur (lorsque BLOCK_RESPONSE_STAGE est réglé) — sauf si la RFC 3834 dit que le message ne doit pas recevoir de réponse automatique (Auto-Submitted autre que no, Precedence: bulk|list|junk, X-Auto-Response-Suppress, tout champ List-*, un expéditeur de service tel que mailer-daemon ou une adresse de rebond de liste VERP, un multipart/report), les mêmes règles partagées que celles qu’applique le répondeur d’absence. Le message est retenu en attente de paiement dans tous les cas ; seule l’invitation est omise, de sorte que la barrière ne transforme pas le trafic des listes et les autres répondeurs en backscatter. Il en va de même dans les BLOCK_RESPONSE_SUPPRESS (par défaut 1 h) qui suivent une demande précédente au même expéditeur pour la même boîte protégée : un flot portant un même expéditeur falsifié suscite une demande par fenêtre, pas une par message. La fenêtre est revendiquée et enregistrée en une seule instruction (payment_request_should_send sur pepsi.payment_request_reply, le modèle de vacation_should_reply), de sorte que des workers concurrents ne peuvent pas envoyer tous les deux. La réponse explique que le destinataire exige des expéditeurs inconnus qu’ils paient d’abord, et porte l’URI taler://pay/<backend>/<token> sous forme de lien et de code QR (un image/png en ligne référencé par cid:, de sorte qu’il s’affiche dans la plus large gamme de clients tout en gardant le message autonome), les options de paiement acceptables (les ORDER_CHOICES, en omettant les choix de la famille jeton), et un pointeur vers https://wallet.taler.net/ pour les expéditeurs sans wallet. Lorsque le From: d’origine porte un nom d’affichage, l’expéditeur est interpellé par ce nom. Le corps est rendu à partir du modèle Mustache payment-request.<lang>.body sous [pepsi] TEMPLATE_DIR, un fragment par langue détectée disposant d’un modèle, avec repli sur PAYMENT_MESSAGE_DEFAULT_LANGUAGE (en par défaut). La réponse utilise l”expéditeur nul <> et entre à BLOCK_RESPONSE_STAGE (normalement une chaîne de signature ou de relais), de sorte qu’elle est signée et remise comme tout autre courrier. La réponse est rendue avant la pause, de sorte qu’un modèle manquant pour la langue par défaut fait échouer l’étape plutôt que de mettre en pause un message dont l’expéditeur ne pourrait jamais être prévenu ; la mise en file de la réponse rendue se fait ensuite au mieux — un échec est journalisé mais n’annule jamais la pause.

La réponse porte aussi deux en-têtes lisibles par machine afin qu’un Pepsi émetteur puisse régler la demande automatiquement (voir pepsi-stage-auto-pay) : un en-tête Taler: avec l’URI taler://pay/…, et l’en-tête Pepsi-Origin: du message d’origine copié verbatim (lorsqu’il est présent), ce qui permet au site d’origine de vérifier que la demande concerne son propre courrier et de mesurer sa dépense par message.

44.4. Configuration

[stage-<name>] : PROGRAM = pepsi-stage-anti-spam, NEXT_STAGE (obligatoire — un message payé, un message classé comme non indésirable et un rebond vérifié y aboutissent tous), BOUNCE_STAGE, ORDER_CHOICES (le tableau JSON choices verbatim d’un bon de commande Taler v1, obligatoire), PAYMENT_DEADLINE (unités h/m/s ; par défaut 2 jours), DELAY_DSN_AFTER (h/m/s ; facultatif, envoyer un DSN de délai en milieu de fenêtre — voir ci-dessus), SUMMARY (par défaut E-mail delivery) et FULFILLMENT_MESSAGE. Pour la réponse de demande de paiement : BLOCK_RESPONSE_STAGE (où l’injecter ; non réglé, la réponse est désactivée), BLOCK_RESPONSE_FROM (son From: ; par défaut le destinataire d’origine), BLOCK_RESPONSE_SUBJECT, BLOCK_RESPONSE_SUPPRESS (h/m/s ; par défaut 1 h, 0 s répond à chaque message) et PAYMENT_MESSAGE_DEFAULT_LANGUAGE (par défaut en, et son modèle payment-request.<lang>.body doit exister — pepsi-setup l’impose). BOUNCE_TARGET_STAGE reçoit un rebond invérifiable ; lorsqu’elle n’est pas réglée, un tel rebond est transféré tel quel vers NEXT_STAGE. Nécessite le backend marchand [pepsi-payments] partagé et, pour le webhook de reprise, [pepsi-httpd] RESUME_AUTHORIZATION_TOKEN. Voir pepsi-stage-anti-spam(1).

44.5. État

  • Entrées : state.spam / state.paid (booléens), state.pay_deadline (secondes epoch), state.dsn (notify/orcpt du destinataire).

  • Sorties : à la première rencontre, {paid: false, pay_deadline} fusionné dans state, la ligne mise en pause, et une réponse de demande de paiement injectée à BLOCK_RESPONSE_STAGE ; au rejet, un objet state.bounce (permanent) pour l’étape de rebond.

44.6. Voir aussi

pepsi-stage-bounce, pepsi-stage-discard, pepsi-httpd, pepsi-setup, Extensions du protocole SMTP, pepsi-stage-anti-spam(1).