85.1.23. pepsi-stage-list-bounce

score an inbound bounce against the member it names

Handbuchabschnitt:

1

85.1.23.1.1. Name

pepsi-stage-list-bounce - die Mailinglisten-Bounce-Stage der Pepsi-Pipeline.

85.1.23.1.2. Übersicht

pepsi-stage-list-bounce [GLOBAL-OPTIONS] worker

85.1.23.1.3. Beschreibung

pepsi-stage-list-bounce ist ein Stage-Programm, das von pepsi-dispatch(1) ausgeführt wird. Es verbraucht Bounces: Ein Zustellfehler, der an die -bounces-Adresse einer Liste zurückkam, wird dem Mitglied zugeordnet, das er betrifft, bewertet, und — sobald der Punktestand die Schwelle der Liste überschreitet — wird die Zustellung an dieses Mitglied abgeschaltet, es wird gewarnt und schließlich abgemeldet.

Drei Dinge in diesem Baum heißen „Bounce“, und sie sind nicht dasselbe. Dieses liest einen eingehenden Fehlerbericht. pepsi-stage-bounce(1) erzeugt eine DSN für eine Nachricht, die Pepsi selbst nicht zustellen konnte. pepsi-failure-bouncer(1) rettet Nachrichten, die die Pipeline aufgegeben hat, und übergibt sie diesem Erzeuger. Eine Konfiguration, die das NEXT_STAGE dieser Stage auf den Erzeuger richtet, beantwortet einen Bounce mit einem Bounce; pepsi-setup(1) weist sie zurück.

Die Stage wird von pepsi-stage-list(1) erreicht, dem Router, der eine Nachricht hierher schickt, wenn ihr Umschlagempfänger die -bounces-Adresse einer Liste ist. Auf anderem Weg wird sie nie erreicht: Eine Nachricht, die ohne den state.list-Deskriptor des Routers hier ankommt, schlägt fehl.

85.1.23.1.4. Zuordnung

Vier Schritte, in abnehmender Gewissheit. Die ersten beiden sind exakt, weil Pepsi die Adresse geschrieben hat, die sie lesen.

  1. Der VERP-Umschlag. Jede Kopie, die eine Liste versendet, trägt einen Umschlagabsender <list>-bounces+<local>=<domain>@<host>, sodass ein Bounce davon das Mitglied eindeutig benennt. Der Teil <list>-bounces muss zum eigenen Bounces-Postfach dieser Liste passen, bevor der Adresse geglaubt wird: Ohne diese Prüfung könnte jeder einen Bounce gegen jedes Mitglied jeder Liste werten lassen, indem er Mail an eine ausgedachte Adresse sendet.

    Auch ein VERP-Treffer muss wie ein Fehler aussehen. Ein vorübergehender Fehler wird schlicht ignoriert, und eine per VERP adressierte Nachricht ganz ohne erkannten Fehler wird weitergeleitet statt bewertet — sie kann eine Abwesenheitsnotiz oder der Bericht eines Virenscanners sein, die nur deshalb an dieser Adresse ankam, weil sie im Umschlag stand.

  2. Ein Proben-Token (<list>-bounces+<token>@<host>), wenn BOUNCE_PROBES eingeschaltet ist. Siehe Proben.

  3. Die heuristischen Detektoren, über die ganze Nachricht. Siehe Erkannte Bounce-Formate.

  4. Nichts aufgelöst; in diesem Fall wird der Bounce verpackt und an einen Menschen weitergeleitet — siehe Nicht erkannte Bounces.

85.1.23.1.5. Bewertung

Die Mechanik ist die von GNU Mailman 3, Schritt für Schritt nachgebildet, weil jedes Attribut, das sie liest, über die REST-API sichtbar ist und die Dokumentation einer Site sagt, was jedes davon bewirkt.

  1. die Liste existiert nicht mehr — verwerfen

  2. die Adresse ist kein Mitglied — verwerfen

  3. der Bounce ist eine Probe — sofort abschalten, ohne Bewertung; ein Proben-Bounce ist entscheidend

  4. das Mitglied ist bereits wegen Bounces abgeschaltet — ein verbliebener Bounce; verwerfen

  5. für dieses Mitglied wurde heute bereits ein Bounce bewertet — nur den Zeitstempel aktualisieren. Höchstens eine Erhöhung pro Kalendertag.

  6. kein vorheriger Bounce, oder einer, der älter als bounce_info_stale_after ist — den Punktestand auf 1 zurücksetzen; andernfalls um eins erhöhen

  7. wenn bounce_notify_owner_on_bounce_increment gesetzt ist und (der Punktestand unter der Schwelle liegt oder Proben ausgeschaltet sind) — die Verwalter benachrichtigen

  8. bei oder über bounce_score_threshold: eine Probe senden, wenn BOUNCE_PROBES eingeschaltet ist (was den Punktestand auf null zurücksetzt), andernfalls den Punktestand auf null setzen und die Zustellung abschalten

  9. das Ereignis als verarbeitet markieren

Schritt 5 ist der Grund, warum eine Bounce-Flut eine Liste nicht an einem Nachmittag leeren kann: Ein Mitglied mit der Standardschwelle von 5 braucht Fehler an fünf verschiedenen Tagen.

85.1.23.1.6. Warnung und Entfernung

Ein Mitglied abzuschalten heißt nicht, es abzumelden. Zwei periodische Durchläufe, ausgeführt von pepsi-list tasks --once (siehe pepsi-list(1)), bringen die Geschichte zu Ende:

  • warn — ein wegen Bounces abgeschaltetes Mitglied, das weniger als bounce_you_are_disabled_warnings Warnungen erhalten hat und dessen letzte Warnung mindestens bounce_you_are_disabled_warnings_interval zurückliegt, erhält eine;

  • remove — sobald die Warnungen aufgebraucht sind und das Intervall erneut verstrichen ist, wird das Mitglied abgemeldet, und die Verwalter werden benachrichtigt, wenn bounce_notify_owner_on_removal gesetzt ist.

Ein Mitglied, das sich selbst abgeschaltet hat oder von einem Moderator abgeschaltet wurde, wird von keinem der beiden Durchläufe angetastet.

Wird bounce_you_are_disabled_warnings auf null gesetzt, entfernt der nächste Durchlauf ein abgeschaltetes Mitglied ganz ohne Warnmail. Das ist das dokumentierte Verhalten von Upstream, und es ist beabsichtigt, kein Randfall.

Die Benachrichtigungen, die diese Durchläufe senden, werden bei [pepsi-list] NOTICE_STAGE eingespeist, weil die Durchläufe von einem Timer statt von einer Stage aus laufen. pepsi-setup(1) weist eine Konfiguration zurück, die diese Stage ohne sie betreibt: Ohne eine Stage zum Einspeisen würde ein Mitglied dreimal in der Datenbank gewarnt und kein einziges Mal per Mail.

85.1.23.1.7. Proben

Mit [pepsi-list] BOUNCE_PROBES = yes sendet das Überschreiten der Schwelle dem Mitglied eine Probe, statt es abzuschalten: eine allein an das Mitglied adressierte Nachricht von einem Umschlagabsender, der ein Einmal-Token trägt, mit dem auslösenden Bounce als Anhang. Der Punktestand des Mitglieds wird auf null zurückgesetzt, solange die Probe aussteht. Kommt die Probe als Bounce zurück, identifiziert das Token das Mitglied exakt, und die Zustellung wird sofort abgeschaltet; kommt sie nicht zurück, geschieht nichts, und das Mitglied erhält weiterhin Mail.

Proben sind standardmäßig ausgeschaltet, wie bei Upstream. Die Abwägung ist eine weitere Nachricht an eine Adresse, die wahrscheinlich tot ist, gegen das Nicht-Abschalten eines Mitglieds, dessen Provider einen schlechten Nachmittag hatte. Ein Proben-Token ist zehn Tage gültig und trägt keinen Precedence: bulk-Header — eine Probe existiert, um als Bounce zurückzukommen, und dieser Header verleitet manche Systeme dazu, keinen Bounce zu erzeugen.

85.1.23.1.8. Nicht erkannte Bounces

Ein Bounce, den nichts erkannt hat, wird in eine erläuternde Benachrichtigung verpackt, mit dem Original unverändert als message/rfc822 angehängt, und an das gesendet, was forward_unrecognized_bounces_to der Liste benennt: administrators (der Standard), site_owner oder discard.

Das ist eine Funktion und kein Notbehelf. Jeder durchfallende Bounce ist ein Format, das der Korpus nicht kennt, und die Person, die ihn erhält, kann das Muster an die Pepsi-Maintainer schicken, damit der Detektor geschrieben werden kann. Bei jeder Verfügung — discard eingeschlossen — wird das Durchfallen in pepsi.event_log als list.bounce.unrecognized gezählt, denn wie oft es vorkommt, zeigt, ob eine Site überhaupt weitere Detektoren braucht.

85.1.23.1.9. Erkannte Bounce-Formate

Siebzehn Detektoren, in dieser Reihenfolge versucht, der erste Treffer gewinnt. Sie sind aus flufl.bounce portiert (Apache-2.0, Copyright Barry Warsaw), und jeder wird gegen die eigenen Testdaten dieser Bibliothek getestet:

dsn, exim, sina, yahoo, yale, smtp32, postfix, qmail, groupwise, microsoft, caiwireless, exchange, netscape, aol, simplematch, simplewarning, llnl

Genau einer davon — dsn, RFC 3464 — ist ein Standard; die übrigen benennen einen Hersteller oder eine Site. In der Praxis spielen sie hier eine weit geringere Rolle als bei Upstream: Pepsi versieht jede Kopie jedes Beitrags mit VERP, sodass ein Bounce einer von Pepsi gesendeten Nachricht über ihren Umschlag zugeordnet wird, ohne dass irgendetwas hiervon befragt wird. Die Detektoren lesen einen Bounce, der eine Liste auf anderem Weg erreicht hat.

Eine Nachricht, die kein Detektor erkennt, ist für diese Stage kein Bounce und wird weitergeleitet, statt geraten zu werden. Diese Unterscheidung ist beim Lesen eines Logs wissenswert: „Pepsi hat dies nicht erkannt“ und „Pepsi hat entschieden, dass dies kein Fehler war“ sind verschiedene Sätze.

85.1.23.1.10. Konfiguration

[stage-list-bounce]

PROGRAM

pepsi-stage-list-bounce.

NEXT_STAGE (erforderlich)

Wohin ein nicht erkannter Bounce geht, nachdem er für einen Menschen verpackt wurde: gewöhnliche Zustellung, keine Listen-Stage. pepsi-setup(1) weist einen Wert zurück, der pepsi-stage-bounce(1) oder den Listen-Router benennt.

RESPONSE_STAGE (erforderlich)

Wo die Probe an das Mitglied und die Benachrichtigungen an die Verwalter eingespeist werden — der signierende Schluss der Pipeline, nicht die Listen-Zustellungs-Stage. Jene Stage akzeptiert nur die Kopie eines Mitglieds aus dem Fan-out und lässt alles andere fehlschlagen, sodass eine dorthin gesendete Benachrichtigung nie hinausgeht; pepsi-setup(1) weist den falschen Wert zurück.

[pepsi-list]

NOTICE_STAGE

Wo die periodischen Warn- und Entfernungsdurchläufe ihre Benachrichtigungen einspeisen. Erforderlich, sobald diese Stage existiert.

BOUNCE_PROBES

yes oder no (Standard no). Siehe Proben.

BOUNCE_EVENT_RETENTION

Wie lange eine verarbeitete Bounce-Ereigniszeile aufbewahrt wird, in Tagen (Standard 1). Nach der Bewertung dienen die Zeilen nur noch der Diagnose. Das ist kein Verfall des Punktestands — dafür ist das listenbezogene Attribut bounce_info_stale_after zuständig, und es wird bei Bedarf angewendet statt durch einen nächtlichen Durchlauf.

Die neun listenbezogenen Attribute — process_bounces, bounce_score_threshold, bounce_info_stale_after, bounce_notify_owner_on_bounce_increment, bounce_notify_owner_on_disable, bounce_notify_owner_on_removal, bounce_you_are_disabled_warnings, bounce_you_are_disabled_warnings_interval und forward_unrecognized_bounces_to — liegen in der Datenbank, wo die REST-API sie sehen kann. Setzen Sie sie mit pepsi-list list set.

85.1.23.1.11. Unterschiede zu GNU Mailman 3

  • Die Bewertung ist synchron. Upstream registriert ein Bounce-Ereignis und bewertet es in einem späteren Durchlauf; Pepsi bewertet es in der Transaktion, die es aufzeichnet. Die Regel „höchstens eine Erhöhung pro Kalendertag“ macht zwei gleichzeitige Bounces für ein Mitglied harmlos.

  • Die Bounce-Historie einer migrierten Site wird nicht übernommen. Auch der eigene Importer von Upstream liest sie nie, daher beginnt ein migriertes Mitglied mit dem Punktestand null, und eine längst tote Adresse erhält einen weiteren Zustellversuch.

85.1.23.1.12. Exit-Status

Der Worker beendet sich nur dann mit einem Wert ungleich null, wenn er überhaupt nicht laufen kann. Ein Bounce, aus dem er nicht schlau wird, wird weitergereicht, nicht fehlgeschlagen; einer für eine Liste, die nicht mehr existiert, oder einer, den der MIME-Parser ablehnt, wird mit einer Log-Zeile verworfen (er kam an die eigene -bounces-Adresse der Liste, und ihn zu beantworten ist der Anfang von Schleifen). Jeder andere Fehler wird mit Backoff bis MAX_LIFETIME wiederholt (siehe pepsi-dispatch(1)).

Nennt ein Bounce mehrere Mitglieder, tragen die Benachrichtigungen an die Eigentümer für jedes Mitglied eine Kennung, die sowohl aus der Adresse des Mitglieds als auch aus der Position des Eigentümers abgeleitet ist, sodass die Benachrichtigung jedes Mitglieds gesendet wird und nicht nur die erste.

85.1.23.1.13. Siehe auch

pepsi-stage-list(1), pepsi-stage-list-post(1), pepsi-stage-list-command(1), pepsi-stage-list-deliver(1), pepsi-list(1), pepsi-stage-bounce(1), pepsi-failure-bouncer(1), pepsi-dispatch(1), pepsi.conf(5).