75. pepsi-stage-list-bounce

Ordnet einen eingehenden Bounce dem betroffenen Abonnement zu und bewertet ihn.

75.1. Aufgabe

pepsi-stage-list-bounce verbraucht Bounces: ein Zustellfehler, der an die -bounces-Adresse einer Liste zurückkam, wird dem betroffenen Mitglied zugeordnet und bewertet, und sobald der Punktestand die Schwelle der Liste überschreitet, wird die Zustellung für dieses Mitglied abgeschaltet, das Mitglied gewarnt und schließlich abgemeldet. Referenz: pepsi-stage-list-bounce(1).

Warnung

Drei Dinge in diesem Baum heißen „Bounce“ und sind nicht dasselbe. Dieses hier liest einen eingehenden Fehlerbericht. pepsi-stage-bounce erzeugt eine Zustellungsstatusbenachrichtigung für eine Nachricht, die Pepsi selbst nicht zustellen konnte. pepsi-failure-bouncer rettet Nachrichten, an denen die Pipeline gescheitert ist, und übergibt sie diesem Erzeuger. Eine Konfiguration, die das NEXT_STAGE dieser Stage auf den Erzeuger richtet, beantwortet einen Bounce mit einem Bounce, und pepsi-setup verweigert sie.

Dieses Subsystem ist eine Neuimplementierung von GNU Mailman 3; siehe Mailinglisten, wo benannt ist, was von upstream übernommen wurde.

75.2. Zuordnung

Vier Schritte, mit abnehmender Sicherheit. 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 den Umschlagabsender <list>-bounces+<local>=<domain>@<host>; ein Bounce davon benennt das Mitglied daher eindeutig. 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 anrechnen lassen, indem er Post an eine selbst erfundene Adresse schickt. Auch ein VERP-Treffer muss noch wie ein Fehler aussehen – ein vorübergehender Fehler wird unbeachtet gelassen, und eine VERP-Nachricht ohne jeden erkannten Fehler wird weitergeleitet und nicht bewertet, denn sie kann eine Abwesenheitsantwort oder der Bericht eines Virenscanners sein, der hier nur deshalb ankam, weil das auf dem Umschlag stand.

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

  3. Die heuristischen Erkenner, über die ganze Nachricht.

  4. Nichts ließ sich klären – der Bounce wird verpackt und an einen Menschen weitergeleitet.

75.3. Bewertung

Die Logik 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 eines Servers erklärt, was jedes davon tut: eine fehlende Liste oder ein Nichtmitglied wird verworfen; ein Proben-Bounce schaltet die Zustellung sofort und ohne Bewertung ab, denn ein Proben-Bounce ist entscheidend; bei einem Mitglied, das bereits wegen Bounces abgeschaltet ist, handelt es sich um einen Nachläufer, der verworfen wird; ein zweiter Bounce für dasselbe Mitglied am selben Kalendertag aktualisiert nur den Zeitstempel; ein erster Bounce oder einer, der älter als bounce_info_stale_after ist, setzt den Punktestand auf 1 zurück, andernfalls wird er erhöht; die Verwalter werden benachrichtigt, wenn bounce_notify_owner_on_bounce_increment gesetzt ist; und bei Erreichen oder Überschreiten von bounce_score_threshold wird eine Probe gesendet, falls Proben eingeschaltet sind (was den Punktestand auf null setzt), andernfalls wird der Punktestand genullt und die Zustellung abgeschaltet.

Die Regel „höchstens eine Erhöhung pro Tag“ ist der Grund, weshalb ein Bounce-Sturm eine Liste nicht an einem Nachmittag leerräumen kann: ein Mitglied braucht bei der voreingestellten Schwelle 5 Fehler an fünf verschiedenen Tagen.

75.4. Warnung und Entfernung

Ein Mitglied abzuschalten ist nicht dasselbe, wie es abzumelden. Zwei periodische Durchläufe, die pepsi-list tasks --once von einem systemd-Timer ausführt (siehe pepsi-list), führen die Geschichte zu Ende: 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; und 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, rührt keiner der beiden Durchläufe an.

bounce_you_are_disabled_warnings auf null zu setzen entfernt ein abgeschaltetes Mitglied beim nächsten Durchlauf ohne jede Warnmail. Das ist das dokumentierte Verhalten von upstream, und es ist beabsichtigt und kein Randfall.

Die Benachrichtigungen dieser Durchläufe werden bei [pepsi-list] NOTICE_STAGE eingespeist, weil die Durchläufe von einem Timer und nicht von einer Stage aus laufen. pepsi-setup verweigert eine Konfiguration, die diese Stage ohne sie betreibt: ohne Stage zum Einspeisen würde ein Mitglied dreimal in der Datenbank gewarnt und kein einziges Mal per Post.

75.5. Proben

Mit [pepsi-list] BOUNCE_PROBES = yes wird beim Überschreiten der Schwelle eine Probe an das Mitglied gesendet, statt es abzuschalten: eine Nachricht allein an dieses Mitglied, von einem Umschlagabsender mit einem Einmal-Token, mit dem auslösenden Bounce als Anhang, und der Punktestand wird auf null gesetzt, solange die Probe aussteht. Kommt die Probe als Bounce zurück, benennt das Token das Mitglied genau und die Zustellung wird sofort abgeschaltet; kommt sie nicht zurück, geschieht nichts und das Mitglied erhält weiter Post.

Proben sind standardmäßig aus, wie bei upstream. Der Handel lautet: eine weitere Nachricht an eine Adresse, die vermutlich tot ist, gegen das Nicht-Abschalten eines Mitglieds, dessen Anbieter einen schlechten Nachmittag hatte. Ein Proben-Token gilt zehn Tage und trägt keinen Precedence: bulk-Header – eine Probe existiert, um zurückzukommen, und dieser Header lädt manche Systeme dazu ein, sie nicht zurückzuschicken.

75.6. Unerkannte Bounces

Ein Bounce, den nichts erkannt hat, wird in eine erklärende Benachrichtigung verpackt, mit dem Original wörtlich als message/rfc822 beigefügt, und an den gesendet, den forward_unrecognized_bounces_to der Liste benennt: administrators (der Standard), site_owner oder discard.

Das ist eine Funktion und kein Rückfall. Jeder Bounce, der durchfällt, ist ein Format, das der Korpus nicht hat, und wer ihn erhält, kann das Beispiel an die Pepsi-Betreuer senden, damit der Erkenner geschrieben werden kann. Unter jeder Einstellung – discard eingeschlossen – wird das Durchfallen in pepsi.event_log als list.bounce.unrecognized gezählt, denn wie oft es vorkommt, ist das, was sagt, ob ein Server überhaupt mehr Erkenner braucht.

75.7. Erkannte Bounce-Formate

Siebzehn Erkenner, in fester Reihenfolge versucht, der erste Treffer gewinnt, portiert aus flufl.bounce (Apache-2.0, Copyright Barry Warsaw) und jeder gegen die Testdaten dieser Bibliothek geprüft: 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 einen Betrieb. In der Praxis zählen sie hier weit weniger als bei upstream, denn Pepsi VERPt jede Kopie jeder Listennachricht; ein Bounce einer von Pepsi gesendeten Nachricht wird daher über den Umschlag zugeordnet, ohne dass davon irgendetwas herangezogen wird. Die Erkenner sind das, was einen Bounce liest, der auf anderem Weg zu einer Liste kam.

Eine Nachricht, die kein Erkenner erkennt, ist für diese Stage kein Bounce und wird weitergeleitet statt erraten. Diese Unterscheidung lohnt sich beim Lesen eines Protokolls: „Pepsi hat das nicht erkannt“ und „Pepsi hat entschieden, dass das kein Fehler war“ sind verschiedene Sätze.

75.8. Konfiguration

[stage-<name>]: PROGRAM = pepsi-stage-list-bounce, NEXT_STAGE (wohin ein weitergeleiteter Nicht-Bounce geht – nicht der Erzeuger von Zustellungsstatusbenachrichtigungen) und RESPONSE_STAGE, beide erforderlich. [pepsi-list] liefert NOTICE_STAGE, BOUNCE_PROBES und BOUNCE_EVENT_RETENTION; die listenbezogenen bounce_*-Attribute liegen in der Datenbank. Siehe pepsi-list und Mailinglisten.

75.9. State

  • Eingaben: state.list – die Listen-ID, die Rolle -bounces und etwaige VERP-Angaben, die die Adresse trug –, geschrieben von pepsi-stage-list.

  • Ausgaben: Bounce-Ereignisse und der Zustellstatus des Mitglieds in der Datenbank; Benachrichtigungen und Proben, als neue Nachrichten eingespeist.

  • Übergänge: Abschließen (ein bewerteter Bounce ist verbraucht) oder Weiterschalten (ein weitergeleiteter Nicht-Bounce).

75.10. Siehe auch

Mailinglisten, pepsi-stage-list, pepsi-stage-bounce, pepsi-failure-bouncer, pepsi-list, pepsi-stage-list-bounce(1).