10. SMTP-Protokollerweiterungen

Über die standardisierten ESMTP-Dienst-Erweiterungen hinaus, die in Unterstützte Funktionen und RFC-Index katalogisiert sind, definiert Pepsi zwei eigene Nachrichten-Header-Felder:

• den Pepsi-Origin:-Herkunftsnachweis-Header, der auf ausgehende Mail gestempelt wird; und

• den Taler:-Zahlungs-Header, der einem Wallet eine Pay-to-Send-Zahlungsaufforderung ankündigt.

Keiner von beiden ist bei der IANA nach RFC 3864 registriert. Beide sind private Erweiterungen, die nur eine Pepsi-Installation (und, für den Zahlungs-Header, ein GNU-Taler-fähiges Wallet) interpretiert, und beide sind optionale Felder im Sinne von RFC 5322 §3.6.8: ein Feldname aus druckbarem US-ASCII, gefolgt von einem unstrukturierten Wert, den jeder konforme MTA unangetastet weiterleitet und jeder konforme Leser ignoriert, wenn er ihn nicht kennt.

Pepsi benennt seine Header-Felder nach ihrem Zweck. Die beiden obigen Protokollfelder wandern zwischen Installationen und tragen kein X--Präfix: RFC 6648 erklärt X- für veraltet, weil ein Feld, das sich durchsetzt, umbenannt werden muss, was jede Implementierung bricht, die es früh übernommen hat.

Felder, die eine Nachricht nur für ihren lokalen Empfänger annotieren oder eine Anfrage eines lokalen Mail-Clients tragen — X-Pepsi-Crypto, X-Pepsi-Detected-Languages, X-Pepsi-Sign und die übrigen —, teilen sich den Namensraum X-Pepsi-*, der nie eine andere Installation erreichen soll. pepsi-stage-decrypt entfernt diesen gesamten Namensraum von eingehender Mail, sodass kein entfernter Absender ein lokales Urteil fälschen kann. Dieselbe Regel ist der Grund, warum Pepsi-Origin: außerhalb davon bleiben muss: Ein Herkunftsnachweis in diesem Namensraum würde genau bei dem zurückkehrenden Bounce entfernt, bei dem er gebraucht wird. Die lokalen Felder sind bei der Stage dokumentiert, die sie schreibt oder liest, nicht hier.

10.1. Der Pepsi-Origin:-Herkunftsnachweis-Header

Wenn Pepsi eine ausgehende Nachricht nach außerhalb weiterleitet, stempelt es sie mit einem Pepsi-Origin:-Header, der kryptografisch beweist, dass diese Installation die Nachricht erzeugt hat, und festhält, welcher ihrer autorisierten Absender es war. Das erlaubt es, einem zurückkehrenden Bounce zu vertrauen: Eine DSN, die Tage später zurückkommt, bettet (eine Kopie) der ursprünglichen Nachricht — und damit den Pepsi-Origin:-Header — in ihren Berichtstext ein, sodass pepsi-stage-anti-spam diesen Header wiedergewinnen und bestätigen kann, dass der Bounce eine Antwort auf Mail ist, die Pepsi wirklich gesendet hat, statt Backscatter oder ein gefälschter Bounce, der auf die Pay-to-Send-Schranke zielt.

10.1.1. Feldsyntax

Der Header-Wert ist eine Liste von key=value-Feldern, durch ; getrennt:

Pepsi-Origin: v=1; host=mail.example.org; sender=alice@example.org;
 nonce=<base64url>; ts=<epoch-seconds>; mac=<base64url>

Feld	Bedeutung
v	Formatversion; ein Verifizierer akzeptiert nur 1.
host	Der Hostname der erzeugenden Installation ([pepsi-ingress] HOSTNAME), im Klartext.
sender	Das autorisierte Umschlagabsender-Konto, von dem die Nachricht stammt.
nonce	Eine zufällige 128-Bit-Nonce, base64url-kodiert (RFC 4648, ohne Padding).
ts	Der Unix-Zeitstempel (Sekunden), zu dem der Header geprägt wurde.
mac	HMAC-SHA256 über die vorangehenden Felder, base64url-kodiert.

Der MAC deckt Version, Hostname, Absenderkonto, Nonce und Zeitstempel ab, wobei jedem Feld seine Big-Endian-u32-Länge vorangestellt und alles aneinandergehängt wird, sodass keine Feldgrenze verschoben werden kann. Der Hostname wird sowohl im Klartext mitgeführt als auch in den MAC eingefaltet: Die Klartextkopie lässt einen Verifizierer einen für eine andere Pepsi-Installation geprägten Bounce günstig ablehnen, noch vor jeder Datenbankabfrage, während die Einbindung in den MAC bedeutet, dass ein abgefangener Header nicht gegen eine Schwester-Installation erneut eingespielt werden kann, die zufällig ein Geheimnis teilt. Weil nur Pepsi diese Header jemals erzeugt oder verifiziert, muss das Drahtformat mit nichts interoperieren.

10.1.2. Prägung und Verifikation

• Stempeln. Beide Relay-Stages — pepsi-stage-relay-to-internet und pepsi-stage-relay-to-smarthost — rufen die gemeinsame pepsi-common::origin-Engine auf, um den Header auf dem jeweils gewählten ausgehenden Pfad voranzustellen, und halten die frisch geprägte Nonce in der Tabelle pepsi.origin_nonce mit einer zweiwöchigen Ablauffrist fest. Das Stempeln erfolgt nach bestem Bemühen: Ist die Funktion aus, bleibt die Nachricht unverändert, und ein Fehler beim Festhalten der Nonce wird protokolliert, blockiert aber nie die Zustellung.

• Verifikation. pepsi-stage-anti-spam durchsucht bei einem zurückkehrenden Bounce die gesamte Nachricht (der Header liegt im DSN-Nachrichtentext, nicht im eigenen Header-Block des Bounces), entfaltet etwaige Fortsetzungszeilen und akzeptiert den ersten Header, dessen Version und Hostname passen und dessen MAC unter dem Geheimnis verifiziert. Erst wenn die günstige kryptografische Prüfung besteht, wird die (langsamere) pepsi.origin_nonce-Abfrage herangezogen; ein Bounce verifiziert nur, wenn seine Nonce noch verfolgt wird. Ein Bounce, der nicht verifiziert — ein fehlender/gefälschter/abgelaufener Header oder jeder Bounce, wenn der Herkunftsnachweis nicht konfiguriert ist — wird zur BOUNCE_TARGET_STAGE der Stage geroutet (z. B. eine Quarantäne- oder Discard-Stage), sofern eine solche verdrahtet ist, und andernfalls unverändert zu NEXT_STAGE weitergeleitet; ein echter Bounce wird immer normal weitergeleitet. Ein Bounce wird niemals stillschweigend verworfen und nie an eine Zahlung gebunden.

10.1.3. Konfiguration

Die Schlüsselverwaltung liegt im gemeinsamen Abschnitt [pepsi-origin] (SECRET / SECRET_FILE, plus das erforderliche [pepsi-ingress] HOSTNAME, das in jeden MAC eingebunden wird). Die Funktion ist standardmäßig aktiv: Wenn kein Geheimnis konfiguriert ist, richtet pepsi-setup beim ersten Lauf ein zufälliges ein. Das Geheimnis muss über die Zeit stabil bleiben (ein Tage später zurückgesendeter Bounce muss weiterhin verifizieren) und über alle Instanzen einer Installation hinweg identisch sein.

Um die Funktion abzuschalten, setzen Sie ENABLED = no in [pepsi-origin]. Ausgehende Mail ist dann ungestempelt, jeder Bounce ist nicht verifizierbar (geroutet gemäß BOUNCE_TARGET_STAGE der Anti-Spam-Stage, andernfalls weitergeleitet), und pepsi-setup erzeugt kein Geheimnis; ein vorhandenes secrets.d/pepsi-origin.secret bleibt bestehen, sodass ein erneutes Einschalten mit demselben Schlüssel fortfährt. Das Entfernen des Abschnitts ist kein Ausschalter: Der nächste pepsi-setup run fände kein Geheimnis und würde ein neues einrichten. Siehe pepsi-stage-anti-spam und pepsi.conf(5).

10.2. Der Taler:-Zahlungs-Header

Wenn pepsi-stage-anti-spam eine Nachricht zur Zahlung zurückhält, erzeugt es eine automatische Zahlungsaufforderungs-Antwort an den Absender (Auto-Submitted: auto-replied nach RFC 3834, leerer Umschlagabsender). Diese Antwort trägt die GNU-Taler-Zahlungs-URI

Taler: taler://pay/<backend>/<order-id>/

als Header-Feld und in ihrem Nachrichtentext als anklickbaren Link und eingebetteten cid:-PNG-QR-Code (RFC 2392 für die cid:-Referenz), zusammen mit einem Verweis auf https://wallet.taler.net/ für Absender ohne Wallet. Der Header wird neben der Kopie im Nachrichtentext hinzugefügt, nie an ihrer Stelle, sodass ein menschlicher Leser und ein Nicht-Taler-Client völlig unberührt bleiben.

Der Wert ist genau die URI, die die Stage prägt, mit order_id == token, sodass ein Wallet die Bestellung gegen das Händler-Backend genauso auflöst wie über den Link im Nachrichtentext. taler:// ist kein IANA-registriertes URI-Schema (RFC 7595 legt das Verfahren fest); es ist GNU Talers eigenes, und die Drahtform ist von jenem Projekt dokumentiert, nicht hier.

10.2.1. Warum ein Header und nicht nur der Nachrichtentext

Der Header ist es, der die Forderung maschinell erkennbar macht, und Pepsi ist selbst die Maschine, die ihn liest. pepsi-stage-auto-pay — das sendeseitige Gegenstück, auf dem eingehenden Pfad ausgeführt — erkennt eine zurückkehrende Zahlungsforderung an diesem Feld: Es faltet Fortsetzungszeilen auf, akzeptiert mehrere URIs in einem Feld und mehrere ``Taler:``-Felder (eine Nachricht an eine Liste kann mehr als eine Forderung nach sich ziehen) und ignoriert taler://-URIs jeder anderen Art, sodass nur echte Zahlungsforderungen je beglichen werden.

Erkennung allein ist keine Autorisierung. Die Stage bezahlt nur für Mail, die diese Installation nachweislich erzeugt hat, was sie mit dem oben beschriebenen Pepsi-Origin:-Header feststellt — aus der zurückgekommenen Nachricht wiedergewonnen und gegen pepsi.origin_nonce geprüft. Das Budget wird gegen diese Herkunfts-Nonce gebucht, sodass eine einzelne Ursprungsnachricht nicht zweimal belastet werden kann.

Die Antwort kopiert außerdem den Pepsi-Origin:-Header der ursprünglichen Nachricht wortgetreu, und das ist es, was die Zuordnung die Rundreise überstehen lässt.

10.2.2. Zusammenspiel mit DKIM und ARC

Die automatische Antwort wird bei BLOCK_RESPONSE_STAGE injiziert und wird daher auf dem Weg hinaus wie jede andere Nachricht DKIM-signiert. Ob das Taler:-Feld von dieser Signatur abgedeckt ist, folgt der gewöhnlichen h=-Konfiguration der Stage (SIGNED_HEADERS, siehe pepsi-stage-dkim-sign), deren Standard es nicht enthält; es wird nicht gesondert behandelt. Da die DKIM-Header-Auswahl von unten nach oben erfolgt (RFC 6376 §5.4.2), stört das Hinzufügen des Feldes keine bereits vorhandene Signatur.

10.3. Siehe auch

pepsi-stage-anti-spam, pepsi-stage-auto-pay, pepsi-stage-relay-to-internet, pepsi-stage-relay-to-smarthost, Unterstützte Funktionen, RFC-Index.