44. pepsi-stage-anti-spam

Riegelt eine Nachricht hinter einer GNU-Taler-Zahlung ab (Pay-to-Send).

44.1. Rolle

pepsi-stage-anti-spam verlangt für eine andernfalls nicht klassifizierte Nachricht eine GNU-Taler-Zahlung, bevor sie die Pipeline weiter durchlaufen darf. Beim ersten Antreffen erstellt es eine Händler-Bestellung und pausiert die Nachricht; sobald die Nachricht erneut geweckt wird — durch den Händler-Webhook pepsi-resume, den pepsi-setup im Taler-Backend so einrichtet, dass er POST /resume auf pepsi-httpd aufruft, oder durch das Verstreichen der Frist —, leitet es weiter, lehnt ab oder wartet. Referenz: pepsi-stage-anti-spam(1).

44.2. Entscheidung

Getrieben vom state-JSON der Nachricht:

  • spam: true → verwerfen (den Datensatz löschen).

  • spam: false oder paid: true → weiterleiten zu NEXT_STAGE (eine explizite Klassifizierung überschreibt den Zahlungsablauf).

  • paid: false vorhanden → den Händler fragen, ob die Bestellung bezahlt ist:

    • bezahlt → weiterleiten zu NEXT_STAGE;

    • unbezahlt über die gespeicherte Frist hinaus → ablehnen: umleiten zu BOUNCE_STAGE (eine Ablehnungs-DSN durch pepsi-stage-bounce oder ein stilles Verwerfen durch pepsi-stage-discard) oder löschen, wenn kein BOUNCE_STAGE verdrahtet ist;

    • unbezahlt, aber noch vor der Frist → mit gesetztem DELAY_DSN_AFTER ist dies der Delay-Kontrollpunkt: dem Absender eine einmalige verzögerte DSN mailen (RFC 3461, nur wenn er NOTIFY=DELAY angefordert hat), ohne die Nachricht freizugeben, dann bis PAYMENT_DEADLINE erneut pausieren; andernfalls mit einer Warnung bis zur Frist erneut pausieren (sollte nicht vorkommen). Der Datensatz bleibt paused, nie pending, was gegen das vorzeitige Aufwecken in einer Busy-Loop kreisen würde.

  • kein paid-Feld → eine v1-Bestellung erstellen, bepreist durch ORDER_CHOICES (order_id ist das Nachrichten-Token), bis PAYMENT_DEADLINE pausieren (oder bis zum DELAY_DSN_AFTER-Kontrollpunkt, wenn dieser früher liegt), dabei paid: false und pay_deadline in state festhalten, und dem Absender eine Zahlungsaufforderung mailen (siehe unten).

Die Frist wird in state.pay_deadline gehalten, weil der Dispatcher das timeout des Datensatzes leert, wenn er eine pausierte Nachricht erneut einreiht.

Eine Nachricht mit dem leeren Umschlagabsender (ein Bounce oder eine Auto-Antwort) wird nie abgeriegelt: Die Stage versucht stattdessen, sie als Antwort auf Mail zu verifizieren, die diese Installation tatsächlich gesendet hat, unter Verwendung des Pepsi-Origin:-Herkunftsnachweis-Headers (siehe SMTP-Protokollerweiterungen). Ein Bounce, dessen eingebetteter Header sich verifizieren lässt, wird zu NEXT_STAGE weitergeleitet; ein nicht verifizierbarer Bounce — ein gefälschter oder abgelaufener Header oder jeder Bounce, wenn der Herkunftsnachweis nicht konfiguriert ist — wird zu BOUNCE_TARGET_STAGE geroutet (z. B. eine Quarantäne), sofern eine solche konfiguriert ist, und unverändert zu NEXT_STAGE weitergeleitet, wenn nicht — nie stillschweigend verworfen.

44.3. Zahlungsaufforderungs-Antwort

Nach diesem ersten Pausieren erzeugt die Stage eine Auto-Antwort an den Absender (wenn BLOCK_RESPONSE_STAGE gesetzt ist) — es sei denn, RFC 3834 verlangt, dass die Nachricht nicht automatisch beantwortet werden darf (Auto-Submitted mit einem anderen Wert als no, Precedence: bulk|list|junk, X-Auto-Response-Suppress, irgendein List-*-Feld, ein Dienstabsender wie mailer-daemon oder eine VERP-Bounce-Adresse einer Liste, ein multipart/report); das sind dieselben gemeinsamen Regeln, die auch der Abwesenheitsbeantworter anwendet. Die Nachricht wird in jedem Fall bis zur Zahlung zurückgehalten; nur die Aufforderung unterbleibt, sodass das Tor Listenverkehr und andere automatische Beantworter nicht in Backscatter verwandelt. Dasselbe gilt innerhalb von BLOCK_RESPONSE_SUPPRESS (Standardwert 1 h) nach einer früheren Aufforderung an denselben Absender für dasselbe geschützte Postfach: Eine Flut mit einem einzigen gefälschten Absender löst eine Aufforderung pro Fenster aus, nicht eine pro Nachricht. Das Fenster wird in einer einzigen Anweisung beansprucht und festgehalten (payment_request_should_send über pepsi.payment_request_reply, nach dem Muster von vacation_should_reply), sodass nebenläufige Worker nicht beide senden können. Die Antwort erklärt, dass der Empfänger von unbekannten Absendern zuerst eine Zahlung verlangt, und trägt die taler://pay/<backend>/<token>-URI als Link und als QR-Code (ein eingebettetes image/png, per cid: referenziert, sodass es in der breitesten Palette von Clients gerendert wird, während die Nachricht in sich geschlossen bleibt), die akzeptablen Zahlungsoptionen (die ORDER_CHOICES, wobei Token-Familien-Wahlmöglichkeiten weggelassen werden) und einen Verweis auf https://wallet.taler.net/ für Absender ohne Wallet. Wenn das ursprüngliche From: einen Anzeigenamen trägt, wird der Absender damit angesprochen. Der Nachrichtentext wird aus der payment-request.<lang>.body-Mustache-Vorlage unter [pepsi] TEMPLATE_DIR gerendert, ein Abschnitt pro erkannter Sprache, für die eine Vorlage existiert, mit Rückfall auf PAYMENT_MESSAGE_DEFAULT_LANGUAGE (standardmäßig en). Die Antwort verwendet den Null-Absender <> und tritt bei BLOCK_RESPONSE_STAGE ein (normalerweise eine Signier-/Relay-Kette), sodass sie wie jede andere Mail signiert und zugestellt wird. Die Antwort wird vor dem Pausieren gerendert, sodass eine fehlende Vorlage für die Standardsprache die Stage fehlschlagen lässt, statt eine Nachricht zu pausieren, deren Absender nie benachrichtigt werden könnte; das anschließende Einreihen der gerenderten Antwort erfolgt nach bestem Bemühen — ein Fehler wird protokolliert, macht das Pausieren aber nie rückgängig.

Die Antwort trägt außerdem zwei maschinenlesbare Header, damit ein sendendes Pepsi die Forderung automatisch begleichen kann (siehe pepsi-stage-auto-pay): einen Taler:-Header mit der taler://pay/…-URI und den Pepsi-Origin:-Header der ursprünglichen Nachricht, wörtlich kopiert (wenn vorhanden), sodass der Ursprungsstandort verifizieren kann, dass die Forderung seine eigene Mail betrifft, und seine Ausgaben pro Nachricht dosieren kann.

44.4. Konfiguration

[stage-<name>]: PROGRAM = pepsi-stage-anti-spam, NEXT_STAGE (erforderlich — eine bezahlte Nachricht, eine als kein Spam klassifizierte Nachricht und ein verifizierter Bounce gehen alle dorthin), BOUNCE_STAGE, ORDER_CHOICES (das wörtliche choices-JSON-Array der Taler-v1-Bestellung, erforderlich), PAYMENT_DEADLINE (h/m/s-Einheiten; Standardwert 2 Tage), DELAY_DSN_AFTER (h/m/s; optional, eine verzögerte DSN mitten im Fenster senden — siehe oben), SUMMARY (Standardwert E-mail delivery) und FULFILLMENT_MESSAGE. Für die Zahlungsaufforderungs-Antwort: BLOCK_RESPONSE_STAGE (wo sie injiziert wird; nicht gesetzt deaktiviert die Antwort), BLOCK_RESPONSE_FROM (ihr From:; Standard der ursprüngliche Empfänger), BLOCK_RESPONSE_SUBJECT, BLOCK_RESPONSE_SUPPRESS (h/m/s; Standardwert 1 h, 0 s beantwortet jede Nachricht) und PAYMENT_MESSAGE_DEFAULT_LANGUAGE (Standardwert en; die zugehörige Vorlage payment-request.<lang>.body muss existieren — pepsi-setup setzt das durch). BOUNCE_TARGET_STAGE nimmt einen nicht verifizierbaren Bounce auf; ist es nicht gesetzt, wird ein solcher Bounce unverändert zu NEXT_STAGE weitergeleitet. Erfordert das gemeinsame [pepsi-payments]-Händler-Backend und, für den Resume-Webhook, [pepsi-httpd] RESUME_AUTHORIZATION_TOKEN. Siehe pepsi-stage-anti-spam(1).

44.5. State

  • Eingaben: state.spam / state.paid (Booleans), state.pay_deadline (Epoch-Sekunden), state.dsn (Empfänger-notify/orcpt).

  • Ausgaben: Bei der ersten Begegnung wird {paid: false, pay_deadline} in state zusammengeführt, der Datensatz pausiert und eine Zahlungsaufforderungs-Antwort bei BLOCK_RESPONSE_STAGE injiziert; bei einer Ablehnung ein state.bounce-Objekt (permanent) für die Bounce-Stage.

44.6. Siehe auch

pepsi-stage-bounce, pepsi-stage-discard, pepsi-httpd, pepsi-setup, SMTP-Protokollerweiterungen, pepsi-stage-anti-spam(1).