85.1.17. pepsi-stage-auto-pay

pay GNU Taler delivery demands automatically

Handbuchabschnitt:

1

85.1.17.1.1. Name

pepsi-stage-auto-pay - die automatische Pay-to-Send-Begleichungs-Stage der Pepsi-Pipeline.

85.1.17.1.2. Übersicht

pepsi-stage-auto-pay [GLOBAL-OPTIONS] worker

85.1.17.1.3. Beschreibung

pepsi-stage-auto-pay ist ein Stage-Programm, das von pepsi-dispatch(1) als persistenter Worker ausgeführt wird, der Nachrichten-IDs von der Standardeingabe liest. Es hat zwei Rollen, pro Nachricht gewählt:

• Auf dem eingehenden Pfad ist es das sendende Gegenstück zu pepsi-stage-anti-spam(1): Wenn von diesem Standort weitergeleitete Mail am fernen Ende hinter einer Pay-to-Send-Schranke zurückgehalten wird, mailt diese Schranke dem ursprünglichen Absender eine Zahlungsforderung, und diese Stage erkennt solche Forderungen und begleicht sie automatisch, sodass die zurückgehaltene Nachricht freigegeben und zugestellt wird.

• Auf dem Submission-Pfad ist es ein Wallet-Self-Service-Endpunkt: Eine lokal eingelieferte (authentifizierte) Nachricht an die Wallet-Steueradresse lässt den Absender sein eigenes GNU-Taler-Wallet per E-Mail bedienen — ein Guthaben prüfen, es aufladen, eine Peer-Push-Zahlung annehmen oder eine Peer-Pull-Anfrage initiieren. Diese Rolle ist nur aktiviert, wenn RESPONSE_STAGE konfiguriert ist (siehe Wallet-Self-Service unten).

Die beiden Rollen teilen sich ein Binärprogramm und werden automatisch erkannt, sodass ein einzelnes PROGRAM = pepsi-stage-auto-pay auf einer der beiden Pipelines platziert werden kann (oder auf beiden, als zwei [stage-<name>]-Abschnitte).

Eine Forderung wird am Taler:-Header erkannt, den pepsi-stage-anti-spam(1) seiner Zahlungsaufforderungs-Auto-Antwort hinzufügt und der eine oder mehrere taler://pay/…-URIs trägt. Beglichen werden ausschließlich taler://pay/-URIs — jedes andere taler://-Schema in diesem Header (eine pay-pull- oder withdraw-URI, die eine Angriffsfläche zum Leeren des Wallets wäre) wird ignoriert —, und eine über die Header hinweg wiederholte URI zählt einmal. Eine Nachricht ohne Taler:-Header ist gewöhnliche Mail und wird unberührt zu NEXT_STAGE weitergeleitet, sodass die Stage gefahrlos früh auf dem eingehenden Pfad platziert werden kann.

Pepsi bezahlt nur für Mail, die es nachweislich erzeugt hat. Dieselbe Auto-Antwort spiegelt den Pepsi-Origin:-Herkunftsnachweis-Header der ursprünglichen Nachricht zurück (siehe pepsi-stage-anti-spam(1) und pepsi-stage-relay-to-internet(1)). Diese Stage verifiziert ihn genauso wie ein zurückkehrender Bounce verifiziert wird — der HMAC muss gegen unser Geheimnis stimmen und die Nonce muss noch in pepsi.origin_nonce verfolgt werden. Eine Forderung, die keinen gültigen Nachweis trägt (einschließlich jeder Forderung, wenn [pepsi-origin] nicht konfiguriert ist), wird nie bezahlt: Sie wird unverändert zu NEXT_STAGE weitergeleitet.

Warnung

Der Header authentifiziert die Installation, nicht den einzelnen Bounce. Er wird auf die Nachricht gestempelt, die zugestellt wird, sodass jeder Empfänger dieser Nachricht eine gültige Kopie davon besitzt, und die Verifikation ist eine HMAC-Prüfung plus eine Existenz-Prüfung der Nonce — die Nonce wird nicht verbraucht, ist nicht auf eine Verwendung beschränkt und nicht an die Nachricht gebunden, für die sie geprägt wurde. Jeder Empfänger kann den Header daher für den Rest des Gültigkeitsfensters der Nonce (14 Tage) auf einer eigenen Nachricht wiedereinspielen und diese Stage dazu bringen, die von ihm angehängten Taler:-Forderungen als Forderungen zu Mail zu behandeln, die wir erzeugt haben. MAX_TOTAL ist die einzige Grenze dafür, was das kostet, und sie gilt je Nonce — setzen Sie sie also auf einen Betrag, den Sie je ausgehender Nachricht zu verlieren bereit sind, nicht je Pipeline.

Der Nachweis benennt außerdem das Konto, für das die ursprüngliche Nachricht gesendet wurde, und dieses Konto ist das einzige, dessen Wallet die Forderung begleichen darf: Der Umschlagempfänger der Forderung muss dasselbe Konto sein, ohne Beachtung der Groß-/Kleinschreibung verglichen. Diese Bindung ist es, die den Nachweis überhaupt etwas darüber sagen lässt, wer bezahlt. Für sich genommen sagt er nur, dass diese Installation irgendeine Nachricht unter dieser Nonce gesendet hat — und jeder Korrespondent, der je von Pepsi weitergeleitete Mail erhalten hat, besitzt eine gültige, noch verfolgte Kopie eines solchen Headers —, sodass eine Forderung, die den Pepsi-Origin eines anderen trägt und an einen anderen lokalen Benutzer gerichtet ist, sonst aus dem Wallet dieses Benutzers beglichen würde. Eine Forderung, deren Empfänger nicht das benannte Konto ist, wird unbezahlt zu NEXT_STAGE weitergeleitet. (Beachten Sie, dass eine Nachricht, deren Umschlagabsender vor dem Weiterleiten per SRS umgeschrieben wurde — weitergeleitete Fremdmail —, damit ebenfalls keine automatische Zahlung nach sich zieht: Der Nachweis benennt die umgeschriebene Adresse, nicht den Empfänger, an den der Bounce zurückkommt.)

Für eine verifizierte Forderung verarbeitet die Stage jede taler://pay/…-URI der Reihe nach und treibt das Wallet über den privilegierten pepsi-helper-auto-pay(1)-Helper an:

1. ihren Preis erfragen (die preview-Operation des Helpers liest die Vertragsbedingungen der Bestellung, ohne zu bezahlen);

2. sie gegen ein kumulatives Budget für die ursprüngliche Nachricht buchen, gedeckelt durch MAX_TOTAL, und gegen das Budget des zahlenden Wallets für die letzten 24 Stunden, gedeckelt durch MAX_TOTAL_PER_DAY (falls gesetzt); und

3. wenn sie unter beide passt, sie begleichen (die pay-Operation des Helpers gibt Wallet-Coins aus).

Jeder Helper-Aufruf ist begrenzt (fünf Minuten; der Kindprozess wird getötet, wenn er überzieht), und ein Timeout zählt als Fehlschlag, sodass die Forderung unbezahlt bleibt und der Bounce weitergeleitet wird. Eine Zahlung, die in einen Timeout lief, kann dennoch durchgegangen sein, was hier nichts feststellen kann; sie wird als Fehler protokolliert, der genau das sagt. Die Grenze gibt es, weil das Händler-Backend, das eine Forderung benennt, von demjenigen gewählt wird, der den Taler:-Header geschrieben hat: Ein unbegrenzter Wallet-Befehl würde den Datensatz running lassen, während sein Worker keine weitere Nachricht annehmen kann, und PARALLELISM solcher Forderungen würden die Stage zum Stillstand bringen — einschließlich der Wallet-Self-Service-Rolle, wenn sie sich den Abschnitt teilt.

Das Budget ist auf die Pepsi-Origin-Nonce geschlüsselt, die die ursprüngliche ausgehende Nachricht identifiziert. Eine an eine Mailingliste aufgefächerte Nachricht zieht mehrere Forderungen — eine pro Mitglied, dessen Standort Gebühren erhebt — die alle die gleiche Nonce tragen, sodass sie sich ein Budget teilen: Das nachrichtenweise Hauptbuch in pepsi.origin_nonce.amount wird atomar fortgeschrieben, sobald jede Forderung beglichen wird (die auto_pay_try_spend-Funktion), und eine Forderung, die die laufende Summe über MAX_TOTAL treiben würde, wird verweigert. Die Obergrenze kennt nur eine Währung: Eine Forderung, deren Währung von MAX_TOTAL abweicht, wird nicht bezahlt. Ein einzelnes Konto kann seine eigene Obergrenze mit pepsi-stage-edit-settings(1) anheben oder senken (die Überschreibung gilt für Mail an dieses Konto — d. h. den ursprünglichen Absender, der die Forderung erhält).

Das Tagesbudget. MAX_TOTAL_PER_DAY begrenzt, was ein Wallet in beliebigen 24 Stunden für Forderungen ausgibt, egal über wie viele ursprüngliche Nachrichten sie verteilt sind. Es wird pro Wallet bemessen, weil das Wallet das Einzige ist, was die Stage immer kennt: unter WALLET_MODE local-user das eigene Wallet jedes Benutzers; unter shared mit WALLET_SCOPE per-sender die Wallet-Datenbank jedes Absenders; unter unified das eine Wallet, das sich alle teilen, sodass die Grenze dann die der ganzen Installation ist. Es gilt bewusst nicht pro Korrespondent: Mailinglisten und Aliase bedeuten, dass die Stage nie sicher weiß, wer fordert. Jede Buchung wird in pepsi.auto_pay_spend durch denselben auto_pay_try_spend-Aufruf festgehalten, der das nachrichtenweise Hauptbuch fortschreibt — beide Prüfungen und beide Schreibvorgänge in einer Anweisung, pro Wallet serialisiert, sodass auch gleichzeitige Forderungen für verschiedene Nachrichten die Grenze nicht gemeinsam überschreiten können —, und eine von einem der Budgets abgelehnte Forderung bucht nichts gegen das andere. Das Fenster ist gleitend, kein Kalendertag (der über Mitternacht das Doppelte der Grenze erlauben würde), und Datensätze, die es verlassen haben, werden von derselben Funktion bereinigt. Die Grenze gilt für eine einzige Währung und muss in der Währung von MAX_TOTAL angegeben sein. Ist sie nicht gesetzt, gilt nur das nachrichtenweise Budget.

Was MAX_TOTAL begrenzt und was nicht. Der Taler:-Header — der Händler-Host, die Bestell-ID und damit der Preis — wird vollständig vom fernen Ende gewählt und ist durch nichts gedeckt: Der Pepsi-Origin-MAC bindet die Version, unseren Hostnamen, das erzeugende Konto, die Nonce und einen Zeitstempel und beweist damit nur, dass diese Installation eine Nachricht unter dieser Nonce für dieses Konto gesendet hat. Er bindet weder die Forderung noch den Händler noch einen Betrag. Jeder Korrespondent erhält einen gültigen, 14 Tage lang lebenden Nachweis schon dadurch, dass er die Mail liest, die Sie ihm gesendet haben, sodass ein Korrespondent jederzeit eine selbst bepreiste Forderung über bis zu MAX_TOTAL vorlegen und bezahlt werden kann. MAX_TOTAL ist daher eine Grenze je ursprünglicher Nachricht, nicht je Korrespondent und nicht je Zeitraum: Die Gesamtexponierung gegenüber einem entschlossenen Korrespondenten wächst mit der Zahl der Nachrichten, die Sie ihm gesendet haben. Setzen Sie sie auf eine Summe, die Sie für eine einzelne Zustellung zu zahlen bereit sind, und setzen Sie MAX_TOTAL_PER_DAY auf das, was ein Wallet an einem Tag verlieren darf, wenn jeder Korrespondent, der einen Nachweis besitzt, ihn einlöst — das ist das Ausgabenlimit.

Wenn jede Forderung an einer Nachricht beglichen wurde, wird der nun überflüssige Bounce verworfen (der Datensatz wird gelöscht). Wenn eine Forderung nicht bepreist werden kann, eines der beiden Budgets überschreiten würde oder in der Währung abweicht, wird die Nachricht stattdessen zu NEXT_STAGE weitergeleitet, sodass sie als gewöhnlicher Bounce fortfährt und der ursprüngliche Absender wie üblich über das Zustellproblem informiert wird. Eine Forderung, die unter dem Budget gebucht wurde, dann aber nicht bezahlt werden kann, wird zurückgerollt — die Reservierung wird dem nachrichtenweisen Hauptbuch gutgeschrieben und ihre Buchung aus dem täglichen gelöscht, beides durch die Funktion auto_pay_refund (sodass die fehlgeschlagene, nicht ausgegebene Zahlung keines der Budgets verbraucht) — und die Nachricht wird ebenfalls weitergeleitet, wobei der Fehler protokolliert wird. Auto-Pay versucht zu bezahlen; wenn es das nicht kann, tut es nichts und lässt den Bounce durch.

Die Ausnahme ist ein Helper, der überhaupt nicht gestartet werden kann (ein fehlendes Binary, ein verlorenes setuid-Bit): Das ist ein Fehler des Hosts, nicht der Forderung, daher wird die Nachricht, solange noch keine ihrer Forderungen bezahlt wurde, erneut versucht statt durchgelassen, und Auto-Pay hört nicht stillschweigend auf zu zahlen. Sobald eine Forderung bezahlt wurde, wird kein Fehler bei derselben Nachricht mehr wiederholt — eine Wiederholung würde die beglichenen Forderungen ein zweites Mal kalkulieren, buchen und bezahlen —, daher wird der Bounce weitergeleitet und der Fehler protokolliert.

85.1.17.1.4. Wallet-Konto

Das Wallet, aus dem der Helper bezahlt, wird durch WALLET_MODE gewählt:

local-user

Der Helper wechselt auf das eigene lokale Login des zahlenden Kontos — des Kontos, das der verifizierte Pepsi-Origin benennt und das zugleich der Umschlagempfänger der Forderung ist (der ursprüngliche Absender) — und verwendet das Standard-Wallet dieses Benutzers. Es muss auf ein erlaubtes lokales Konto auflösen (dieselbe LOCAL_DOMAINS/TARGETS/RECIPIENT_DELIMITER-Prüfung wie pepsi-stage-relay-to-maildir(1)); ein nicht-lokales Konto kann nicht belastet werden und die Nachricht wird weitergeleitet. Der Helper verweigert in diesem Modus eine UID unterhalb von UID_MIN aus /etc/login.defs, und pepsi-setup(1) warnt vor einem TARGETS-Token, das darunter reicht.

shared (Standardwert)

Der Helper wechselt auf ein einzelnes dediziertes Konto (WALLET_USER, Standardwert pepsi-wallets), dessen Home die Wallet-Datenbank(en) enthält. WALLET_SCOPE wählt, ob jeder ursprüngliche Absender seine eigene Wallet-Datenbank erhält (per-sender, der Standardwert) oder alle sich eine teilen (unified — z. B. ein Unternehmen, in dem individuelle Wallets keinen Sinn ergeben).

Die gesamte Wallet-Interaktion wird vom setuid-root pepsi-helper-auto-pay(1)-Helper durchgeführt; diese Stage startet ihn und berührt nie direkt ein Wallet. Das Stage-Binärprogramm wird daher SGID pepsi-wallets installiert, damit sein unprivilegierter Dispatcher-Worker den Helper ausführen darf (siehe Installation).

85.1.17.1.5. Wallet-Self-Service

Wenn RESPONSE_STAGE gesetzt ist, ist eine lokal erzeugte Nachricht (state.local_origin true; der Submission-Listener muss authentifizieren und den Umschlagabsender binden) an <CONTROL_LOCAL_PART>@<served-domain> (Standard-Local-Part pepsi-wallet; die Domain ist eine von [pepsi-ingress] ACCEPTED_DOMAINS) eine Wallet-Steuernachricht, die das eigene Wallet des Absenders bedient (durch WALLET_MODE/WALLET_SCOPE genau wie für die zahlende Rolle aufgelöst, aber auf den Absender geschlüsselt). Jede andere Nachricht wird unberührt zu NEXT_STAGE weitergeleitet, sodass die Stage gefahrlos überall auf dem Submission-Pfad platziert werden kann.

Der Befehl wird der Subject:-Zeile der Nachricht entnommen — ein Verb plus seine Argumente (die Groß- und Kleinschreibung des Verbs spielt keine Rolle):

balance

Berichtet das Wallet-Guthaben.

withdraw CURRENCY:VALUE EXCHANGE-URL (auch geschrieben topup / top-up)

Richtet eine manuelle Aufladung des angegebenen Betrags gegen den GNU-Taler-Exchange an der angegebenen Basis-URL ein (die eine http://- oder https://-URL sein muss). Der Exchange wird in der Anfrage benannt (nicht auf dem Server konfiguriert), weil ein Wallet mehrwährungsfähig ist und von vielen Exchanges abheben kann. Die Antwort trägt das Bank-payto://-Ziel und den zu verwendenden Überweisungsbetreff; sobald die Banküberweisung des Benutzers eintrifft, erscheinen die Mittel im Wallet.

pull CURRENCY:VALUE [subject]

Initiiert eine Peer-Pull-Zahlung; der Rest der Subject-Zeile wird, sofern vorhanden, zum Zahlungsbetreff. Die Antwort trägt eine taler://pay-pull/…-URI, die an denjenigen weiterzuleiten ist, der zahlen soll.

push taler://pay-push/… (auch geschrieben accept)

Nimmt eine eingehende Peer-Push-Zahlung an. Die URI kann im Subject oder im Nachrichtentext angegeben werden.

help

Antwortet mit der Gebrauchsanweisung — wie es auch ein leerer Subject, ein unbekanntes Verb oder ein fehlendes bzw. fehlerhaftes Argument tun.

Löst der Absender auf gar kein Wallet auf (WALLET_MODE = local-user und ein Absender, der kein zulässiges lokales Konto ist), wird nichts ausgeführt, und die Antwort sagt das.

Das Ergebnis wird dem Absender als lokalisierte Auto-Antwort zurückgemailt (Null-Absender, Auto-Submitted: auto-replied), gebaut aus der vom Operator anpassbaren wallet.<lang>.body-Vorlage und bei RESPONSE_STAGE injiziert (wo sie DKIM-signiert und weitergeleitet wird); die ursprüngliche Steuernachricht wird dann gelöscht. Eine Anfrage, die nicht verstanden werden kann, wird mit Verwendungshinweisen beantwortet. Eine Anfrage, die verstanden wurde, aber fehlschlug, wird mit einer festen Meldung „konnte nicht abgeschlossen werden“ beantwortet: Die Diagnose des Wallets geht nur in das Operator-Journal, denn sie beschreibt ein Wallet (unter WALLET_SCOPE = unified von allen geteilt) und nicht die Anfrage.

Die Antwortvorlage wird einmal vor der Ausführung des Wallet-Befehls gerendert, sodass eine fehlende Vorlage erneut versucht wird, ohne die Wallet anzurühren. Sobald der Befehl gelaufen ist, wird er für dieselbe Nachricht nie wieder ausgeführt: Eine Antwort, die dann nicht gerendert oder eingereiht werden kann, wird als Fehler protokolliert und die Anfrage gelöscht.

Wenn das Wallet auf eine KYC-(Identitätsprüfungs-)Anforderung stößt, trägt die Antwort stattdessen den KYC-Link, den der Benutzer öffnen soll — dies geschieht nur für die Self-Service-Rolle, nie beim Bezahlen eingehender Forderungen.

85.1.17.1.6. Konfiguration

Die Optionen liegen im eigenen [stage-<name>]-Abschnitt der Stage (PROGRAM = pepsi-stage-auto-pay): das erforderliche MAX_TOTAL (ein GNU-Taler-Betrag CURRENCY:VALUE, der die Gesamtausgabe pro ursprünglicher Nachricht begrenzt), das optionale MAX_TOTAL_PER_DAY (in derselben Währung, begrenzt die Ausgabe eines Wallets in beliebigen 24 Stunden), ein erforderliches NEXT_STAGE und die Wallet-Stellschrauben WALLET_MODE, WALLET_USER, WALLET_SCOPE, WALLET_CLI, WALLET_PAY_OPTIONS und HELPER. Die Wallet-Self-Service-Rolle ergänzt RESPONSE_STAGE (ihr Vorhandensein aktiviert die Rolle), CONTROL_LOCAL_PART, RESPONSE_FROM und RESPONSE_SUBJECT (ein withdraw benennt seine eigene Exchange-Basis-URL im Subject, sodass kein Exchange konfiguriert wird). Sie sind in pepsi.conf(5) dokumentiert. Das Herkunftsnachweis-Geheimnis ist der gemeinsame [pepsi-origin]-Abschnitt (siehe pepsi-stage-relay-to-internet(1)); ohne ihn kann die Stage keine Forderung verifizieren und zahlt daher keine (es betrifft den Self-Service nicht).

85.1.17.1.7. Installation

Weil die Stage den setuid-root-Wallet-Helper ausführt, wird ihr Binärprogramm eigenständig installiert (nicht in das vereinheitlichte pepsi-Binärprogramm eingefaltet) und SGID pepsi-wallets (Modus 2550, Eigentümer pepsi:pepsi-wallets — Ausführungsrecht für den Eigentümer und nicht für alle, denn das setgid-Bit ist die Schranke am Helper, und pepsi ist bewusst kein Mitglied der Gruppe, sodass das Ausführungsrecht von den Eigentümer-Bits kommen muss); der Helper wird setuid-root, root:pepsi-wallets, Modus 4750 installiert. make install (Targets install-auto-pay-stage / install-auto-pay-helper) und das Debian-Paket setzen diese Bits. Das pepsi-wallets-Konto und die -Gruppe werden vom Paket erstellt; andernfalls erstellen Sie sie von Hand.

Da das setgid-Bit diese Schranke ist, stellt das Programm dieselbe Regel selbst auf: Trägt das Binärprogramm dieses Bit tatsächlich, so beendet es sich, sofern der reale Benutzer nicht root oder das Dienstkonto pepsi ist, mit einem Fehler, bevor irgendeine Konfiguration gelesen wird, und — wie die setuid-Krypto-Stages — entfernt es die Umgebungsvariablen, die das Laden der Konfiguration steuern (HOME, XDG_CONFIG_HOME, PG*, TALER_*, PEPSI_*), und legt PATH auf einen sicheren Standardwert fest. (Ein ohne setgid-Bit installierter Bau — ein Entwicklungsbaum, make check — hat nichts hinzugewonnen und überspringt beide Schritte.) Ein Dateimodus ist eine Tatsache der Installation und dies eine Tatsache des Programms; keines von beiden soll für sich allein stehen.

85.1.17.1.8. State

Eingaben: die Taler:- und Pepsi-Origin:-Header der Nachricht (der Nachrichtentext wird ebenfalls nach einem eingebetteten Pepsi-Origin durchsucht). Das nachrichtenweise Ausgaben-Hauptbuch ist pepsi.origin_nonce.amount und das tägliche pro Wallet pepsi.auto_pay_spend, nicht das Nachrichten-state.

Ausgaben: Die Stage verändert die Nachricht nicht; sie schaltet sie weiter oder löscht sie. Das State-Layout wird in pepsi.state(7) beschrieben.

Übergänge: finish (löschen), wenn alle Forderungen beglichen sind, oder für eine Wallet-Self-Service-Steuernachricht (nach dem Injizieren der Antwort bei RESPONSE_STAGE); andernfalls advance zu NEXT_STAGE (keine Forderung, nicht verifizierbar, nicht bepreisbar, über Budget oder ein Begleichungsfehler). Die Stage pausiert, bounct oder schreibt eine Nachricht nie um.

85.1.17.1.9. Befehle

worker

Läuft als persistenter pepsi-dispatch(1)-Worker, der Nachrichten-IDs von der Standardeingabe liest.

85.1.17.1.10. Globale Optionen

-c FILE, –config FILE

Liest die Konfiguration aus FILE, statt die Standardorte zu durchsuchen.

-L LOGLEVEL, –log LOGLEVEL

Setzt die Log-Ausführlichkeit (Standardwert info).

-v, –verbose

Zeigt Log-Meldungen aus allen Quellen.

-h, –help; -V, –version

Gibt eine Verwendungsübersicht / die Version aus und beendet sich.

85.1.17.1.11. Exit-Status

0

Die Nachricht wurde verarbeitet (bezahlt und verworfen oder weitergeleitet).

1

Ein Fehler ist aufgetreten (Nachricht nicht gefunden oder nicht running, oder eine adressbezogene Einstellung, die den Abschnitt der Stage kaputt macht). Der Grund wird in das Log geschrieben.

Ein Fehler des Hosts (die Datenbank, eine Vorlage oder ein Helfer, die sich nicht verwenden lassen) wird nicht als Fehlschlag gemeldet: Die Nachricht wird pausiert und erneut versucht, wie unter Stage-Fehler in pepsi-dispatch(1) beschrieben. Ein Abschnitt, der sich nicht parsen lässt, lässt den Worker den Start verweigern (Status 78), statt eine Nachricht nach der anderen fehlschlagen zu lassen. Ein fehlendes MAX_TOTAL ist ein solcher Abschnitt.

85.1.17.1.12. Beispiele

Ein Pipeline-Abschnitt, der Zustellforderungen für lokal erzeugte Mail bis zu fünf Euro pro ursprünglicher Nachricht und insgesamt fünfzig pro Tag aus einem einzigen gemeinsamen pepsi-wallets-Wallet bezahlt:

[stage-auto-pay]
PROGRAM = pepsi-stage-auto-pay
MAX_TOTAL = EUR:5
MAX_TOTAL_PER_DAY = EUR:50
NEXT_STAGE = local-delivery
WALLET_MODE = shared
WALLET_SCOPE = unified

Oder, aus dem eigenen lokalen Wallet jedes ursprünglichen Absenders zahlend:

[stage-auto-pay]
PROGRAM = pepsi-stage-auto-pay
MAX_TOTAL = EUR:5
NEXT_STAGE = local-delivery
WALLET_MODE = local-user

Einem Konto erlauben, mehr auszugeben (von diesem Konto an pepsi@ gemailt, siehe pepsi-stage-edit-settings(1)):

[stage-auto-pay]
MAX_TOTAL = EUR:20

Ein Wallet-Self-Service-Abschnitt auf dem Submission-Pfad (eine Nachricht an pepsi-wallet@example.com mit einem Befehl im Subject bedient das Wallet des Absenders):

[stage-wallet]
PROGRAM = pepsi-stage-auto-pay
MAX_TOTAL = EUR:0
NEXT_STAGE = dkim-sign
RESPONSE_STAGE = dkim-sign
CONTROL_LOCAL_PART = pepsi-wallet

85.1.17.1.13. Siehe auch

pepsi-helper-auto-pay(1), pepsi-stage-anti-spam(1), pepsi-stage-relay-to-internet(1), pepsi-stage-edit-settings(1), pepsi-config(1), pepsi-dispatch(1), pepsi.conf(5), pepsi.state(7), pepsi-setup(1)

85.1.17.1.14. Fehler

Melden Sie Fehler an den Pepsi-Issue-Tracker.