85.1.47. pepsi-list

manage Pepsi’s mailing lists

Handbuchabschnitt:

1

85.1.47.1.1. Name

pepsi-list – Mailinglisten, ihre Mitglieder und ihre Verwalter anlegen und verwalten.

85.1.47.1.2. Übersicht

pepsi-list [GLOBALE-OPTIONEN] domain add|list|remove [ARGS]

pepsi-list [GLOBALE-OPTIONEN] list create|show|set|set-ext|remove|find|styles [ARGS]

pepsi-list [GLOBALE-OPTIONEN] members list|add|remove [ARGS]

pepsi-list [GLOBALE-OPTIONEN] owner add|remove|reset-password [ARGS]

pepsi-list [GLOBALE-OPTIONEN] import mailman3|mailman21 [ARGS]

pepsi-list [GLOBALE-OPTIONEN] invite send|status [ARGS]

pepsi-list [GLOBALE-OPTIONEN] digest send|bump|periodic|status [ARGS]

pepsi-list [GLOBALE-OPTIONEN] ban add|list|remove [ARGS]

pepsi-list [GLOBALE-OPTIONEN] template list|set|clear [ARGS]

pepsi-list [GLOBALE-OPTIONEN] unsub-token LISTE E-MAIL [–serial N] [–uri]

pepsi-list [GLOBALE-OPTIONEN] tasks –once

pepsi-list [GLOBALE-OPTIONEN] check [–strict]

85.1.47.1.3. Beschreibung

pepsi-list ist das Kommandozeilenwerkzeug des Betreibers für Pepsis Mailinglisten-Subsystem. Es ist keine Stage: es liest und schreibt die Listentabellen des pepsi-Schemas direkt, in der Gestalt von pepsi-whitelist(1) und pepsi-settings(1).

Pepsis Mailinglisten-Subsystem ist eine Neuimplementierung von GNU Mailman 3. Sein Datenmodell, seine Rule/Chain- und Handler/Pipeline-Architektur, seine REST-API, sein E-Mail-Befehlsvokabular und die Namen seiner Benachrichtigungsvorlagen sind der Entwurf des GNU-Mailman-Projekts, urheberrechtlich geschützt durch die Free Software Foundation, und Pepsi existiert, um damit kompatibel zu sein. Die Dokumentation von upstream unter <https://docs.mailman3.org> beschreibt Begriffe, die unmittelbar hier gelten, und ist neben dieser Seite lesenswert. Einige Dateien in Pepsi sind aus GNU Mailman, Postorius oder HyperKitty übernommen und bleiben unter der GNU General Public License; vendor/PEPSI-VENDORING.md führt sie auf.

Die Konfiguration je Liste liegt in der Datenbank und nicht in pepsi.conf(5). Listen werden zur Laufzeit angelegt, möglicherweise zu Tausenden, von Leuten, die nicht der Betreiber sind; die Konfigurationsdatei enthält nur, was der Betreiber besitzt, im Abschnitt [pepsi-list].

85.1.47.1.4. Globale Optionen

Die globalen Flags stehen vor dem Unterbefehl, wie überall sonst in Pepsi:

-c, --config DATEI

Zu lesende Konfigurationsdatei.

-L, --log STUFE

Protokollstufe.

-v, --verbose

Zeigt Log-Meldungen aus allen Quellen, einschließlich Drittanbieter-Bibliotheken.

-V, --version

Die Version ausgeben und beenden.

85.1.47.1.5. Eine Liste benennen

Jedes Verb, das eine Liste annimmt, akzeptiert beide Schreibweisen:

name@domain

Die Absendeadresse, also die, die Leute eintippen.

name.domain

Die list_id von upstream, mit einem Punkt. Das ist der Bezeichner, den die REST-API verwendet, und er ist nicht mit der Absendeadresse austauschbar – beide kommen in der API vor, und den falschen zu schreiben ist ein Kompatibilitätsfehler.

85.1.47.1.6. Befehle

domain add DOMAIN [–base-url URL] [–description TEXT]

Registriert eine Maildomain, in der Listen angelegt werden dürfen. Das ist nicht dasselbe wie ACCEPTED_DOMAINS von pepsi-ingress(1): eine Domain kann Post annehmen, ohne Listen zu beherbergen. Ist eine Listendomain keine, die ingress annimmt, wird Post an die Liste bei RCPT abgewiesen, und nichts in den Protokollen dieses Subsystems sagt es.

domain list

Zeigt die Listendomains und wie viele Listen jede enthält.

domain remove DOMAIN

Entfernt eine Listendomain. Wird verweigert, solange sie noch Listen enthält: sie zu löschen würde durch die Mitgliederliste, die zurückgehaltenen Nachrichten und das Archiv jeder Liste hindurch kaskadieren.

list create ADRESSE [–style STIL] [–set NAME=WERT]…

Legt eine Mailingliste an. --style wendet einen benannten Satz von Attributvorgaben an, bevor irgendein --set greift; siehe Stile unten. Ein unbekannter Stilname ist ein Fehler und keine stille Leeroperation.

list show ADRESSE [–explain]

Gibt jedes der 99 REST-Attribute mit seinem aktuellen Wert aus. --explain ergänzt zu jedem Attribut die einzeilige Erläuterung. (Das Flag heißt --explain und nicht --help, weil letzteres dem Argumentparser gehört.)

list set ADRESSE NAME WERT

Setzt ein Attribut. Der Wert läuft durch denselben Prüfer, den die REST-API und die Verwalteroberfläche benutzen, die drei können sich also nicht darüber uneinig sein, was ein gültiger Wert ist. Mehrwertige Attribute nehmen einen Eintrag pro Zeile; ein Komma ist kein Trenner, weil ein regulärer Ausdruck eines enthalten darf.

list set-ext ADRESSE SCHLÜSSEL WERT

Setzt eine Pepsi-eigene Einstellung je Liste. Diese sind für die Mailman-REST-API absichtlich unsichtbar: das PUT von upstream über die ganze Ressource verlangt, dass jedes schreibbare Attribut vorhanden ist, ein gegen Mailman 3.3.10 gebauter Client würde also alles auslassen, was Pepsi erfunden hat, und abgewiesen werden. Ein leerer Wert stellt den Serverstandard wieder her. Die Schlüssel sind search_trigram, archive_show_addresses und archive_retention_days.

list remove ADRESSE –yes

Löscht eine Liste, ihre Mitgliederliste, ihre zurückgehaltenen Nachrichten und ihr Archiv. --yes ist erforderlich.

list find [TEILZEICHENFOLGE]

Listet die Mailinglisten auf, wahlweise die, die zu einer Teilzeichenfolge passen.

list styles

Zeigt die Stile und ihre Aliase.

members list ADRESSE [–role ROLLE]

Zeigt die Mitgliederliste einer Liste. ROLLE ist member, owner, moderator oder nonmember.

members add ADRESSE EMAIL [–display-name NAME] [–role ROLLE]

Meldet eine Adresse an. Das umgeht die Abonnementrichtlinie vollständig, und dafür ist ein Kommandozeilenwerkzeug da, und genau das macht es gefährlich: der ganze Sinn des Bestätigungsablaufs ist, dass eine Adresse belegt, dass sie dort sein will. Benutzen Sie es, um eine Mitgliederliste zu migrieren oder einen Fehler zu beheben, nicht, um Leute hinzuzufügen, die nicht gefragt haben.

members remove ADRESSE EMAIL [–role ROLLE]

Meldet eine Adresse aus einer Rolle ab.

owner add ADRESSE EMAIL

Macht eine Adresse zum Verwalter. Anders als ein gewöhnlicher Abonnent erhält ein Verwalter ein Benutzerkonto, weil er sich an der Verwalteroberfläche anmelden wird.

owner remove ADRESSE EMAIL

Entfernt einen Verwalter.

owner reset-password ADRESSE EMAIL [–password PASSWORT]

Setzt das Kontopasswort eines Verwalters und gibt es aus. Es gibt absichtlich aus statt zu versenden: dieser Weg muss funktionieren, wenn die Post kaputt ist, und genau dann braucht ein Betreiber ihn.

Der gewöhnliche Weg, ein Passwort zu ändern, ist der Zurücksetzungsablauf im Web unter /lists/reset, der einen Link versendet und nie ein Passwort – ein zugesandtes Passwort ist ein Passwort, das für immer in einem Postfach liegt. Dieser Unterbefehl ist die Notluke für den Fall, den dieser Ablauf nicht abdecken kann: die Adresse des Kontos empfängt keine Post, oder auf dem Rechner stellt überhaupt nichts zu. Er setzt denselben list_user.password_hash wie der Weblauf, mit denselben Argon2-Parametern, und beendet, wie eine im Browser vorgenommene Passwortänderung, jede offene Sitzung dieses Kontos.

ban add MUSTER [–list ADRESSE]

Sperrt eine Adresse oder einen regulären Ausdruck, der mit ^ beginnt. Ohne --list gilt die Sperre serverweit.

ban list [–list ADRESSE]

Zeigt die Sperren.

ban remove MUSTER [–list ADRESSE]

Hebt eine Sperre auf.

tasks –once

Führt die periodischen Durchläufe einmal aus und beendet sich: die Bounce-Durchläufe zum Warnen und Entfernen, das Entfernen verarbeiteter Bounce-Ereignisse ([pepsi-list] BOUNCE_EVENT_RETENTION), das Ablaufen zurückgehaltener Nachrichten nach max_days_to_hold, die Durchläufe für abgelaufene Bestätigungstoken und Löschgrabsteine sowie den Archiv-Aufbewahrungsdurchlauf. Das ist, was die Unit pepsi-list-tasks.timer täglich ausführt. --once ist erforderlich: Ohne die Option verweigert der Befehl die Ausführung, weil der Zeitplan dem Timer gehört und nicht einer Schleife in diesem Programm.

Alles im Subsystem, was nach einem Zeitplan geschieht, steht hier, und jeder Teil davon ist unsichtbar, wenn der Timer nicht läuft: ein Mitglied, dessen Bounce-Punktestand die Schwelle überschritten hat, wird von der Bounce-Stage abgeschaltet, und die Warnungen und die schließliche Abmeldung gehören diesem Durchlauf – eine Installation ohne ihn schaltet Mitglieder ab und warnt sie dann nicht und entfernt sie nicht.

Bemerkung

tasks --once verwirft außerdem zurückgehaltene Nachrichten, die älter sind als das max_days_to_hold ihrer Liste. Dieses Attribut ist in GNU Mailman 3 wirkungslos – ein grep über den ganzen Nicht-Test-Baum findet die Spalte, den Stilstandard und den REST-Prüfer und keinen Job, der es liest – und hier wirksam. Es ist eine strikte Obermenge: die Voreinstellung 0 bedeutet „läuft nie ab“, und genau das geschieht bei upstream, für eine Liste, die es nicht anfasst, ändert sich also nichts. Jedes Verwerfen wird ins Prüfprotokoll geschrieben, und die Moderatoren werden einmal je Durchlauf mit einer Anzahl benachrichtigt und nicht einmal je Nachricht.

Bemerkung

Der Archiv-Aufbewahrungsdurchlauf löscht die archivierten Nachrichten jeder Liste, die älter als deren Aufbewahrungsdauer sind, genau wie es pepsi-archive expire täte (Threads und Zähler werden danach repariert). Die Aufbewahrungsdauer wird je Liste bestimmt: Der eigene Wert archive_retention_days einer Liste (gesetzt mit list set-ext) hat Vorrang, 0 eingeschlossen; eine Liste ohne ihn verwendet [pepsi-list] ARCHIVE_RETENTION, dessen eigener Standardwert 0 ist; und 0 behält alles. Ein gespeicherter Wert, der keine Anzahl von Tagen ist, wird mit einer Warnung übersprungen, statt geraten zu werden.

check [–strict]

Prüft die Konfiguration jeder Liste und die der Installation. Jeder Befund ist ein error, eine warning oder eine note, mit einer Abhilfe, wo es eine offensichtliche gibt. Endet mit einem Fehlerstatus bei einem Fehler, mit --strict auch bei einer Warnung.

import mailman3 –rest URL [–user NAME] [–password-file DATEI] [–dry-run] [–report DATEI]

Importiert einen laufenden GNU-Mailman-3-Server über dessen eigene REST-API: Domains, Listen Attribut für Attribut, Benutzer, Adressen (unter Beibehaltung ihres verified_on), Mitglieder, Sperren, Header-Regeln und Vorlagen-URIs.

REST ist der voreingestellte Weg und nicht der Rückfall, denn er funktioniert gegen einen laufenden Server, braucht kein Wissen über das Schema von upstream und ist von upstreams eigenen Migrationen abgeschirmt. Er ist auch das, was den Import prüfbar macht: beide Enden antworten auf /3.1/lists/<id>/config, ein attributweiser Vergleich ist also möglich.

Bevorzugen Sie --password-file gegenüber --password: ein Argument ist für jeden anderen Prozess auf dem Rechner sichtbar.

import mailman21 –listdir VERZ [–list NAME] [–domain HOST] [–dry-run] [–report DATEI]

Importiert einen Mailman-2.1-Server aus seinem lists/-Verzeichnis und liest dabei jede config.pck. Die Attributzuordnung ist die von GNU Mailman selbst – die achtzehn Umbenennungen, die Ganzzahl-zu-Enum-Tabellen, die zwei Boolean-Zusammenfassungen, die DMARC-Vorrangregel und das user_options-Bitfeld sind aus upstreams utilities/importer.py übertragen.

--domain liefert den Mailhost für ein Pickle, das keinen nennt.

Bemerkung

pepsi-list startet als root und wechselt sofort auf den Dienstbenutzer ``pepsi``, ein --report-Pfad muss daher einer sein, den dieser Benutzer schreiben kann. --report /root/import.txt scheitert mit einem Berechtigungsfehler und erzeugt keinen Bericht; /tmp oder ein Verzeichnis, das pepsi gehört, funktioniert. Ohne --report geht der vollständige Bericht auf die Standardausgabe und ist daher nie verloren.

import mailman21 –json DATEI [–list NAME]

Die Notluke. Dieser Leser konstruiert nichts – kein Modul wird nachgeschlagen und kein Aufrufbares aufgerufen, denn eine config.pck kommt vom Server eines anderen. Der Preis ist Strenge; weigert er sich also bei einer Datei, führen Sie contrib/mm21-export.py auf dem alten Server mit dessen eigenem Python aus und geben Sie das JSON hier hinein. Beide Wege gehen durch dieselbe Zuordnung.

invite send [–list ADRESSE] [–rate N] [–limit N] [–dry-run]

Lädt alle ohne Passwort ein, eines zu wählen. import sendet absichtlich nichts, dies ist daher das Verb, das entscheidet, wann die größte Sendung, die der Server je verschicken wird, tatsächlich geschieht.

--rate ist standardmäßig [pepsi-list] INVITE_RATE (300/Stunde). --dry-run gibt das Histogramm je Domain aus, und das ist ein Werkzeug für die Zustellbarkeit und kein Fortschrittsbalken: ein Anbieter, der die Hälfte eines migrierten Servers hält, ist das, was die Rate bestimmt. Der Lauf setzt dort fort, wo er aufhörte – eine Adresse mit gültiger Einladung wird übersprungen – und Einladungen gelten vier Wochen, denn eine konkurriert mit einem Urlaub und nicht mit einem Abend.

invite status [–list ADRESSE]

Wie viele Konten ein Passwort haben, wie viele eine offene Einladung haben und wie viele noch einzuladen sind. Niemand wird je abgemeldet, weil er nicht antwortet.

digest send ADRESSE

Sendet die angewachsene Sammelnachricht einer Liste jetzt, was auch immer digest_size_threshold sagt. Ein Betreiber, der eine Ausgabe verlangt, hat schon entschieden.

digest bump ADRESSE

Erhöht den Band und setzt die Nummer auf 1 zurück, ohne zu senden, was das --bump von upstream ist. Was ein Verwalter am Jahresanfang tut, oder nach einer Ausgabe, die falsch hinausging.

digest periodic

Sendet jede Liste, deren Sammelnachricht fällig ist: über digest_size_threshold, oder überhaupt angewachsen, wenn digest_send_periodic an ist. Das ist das Verb des Timers. Upstream hat überhaupt keinen periodischen Läufer für Sammelnachrichten – maybe_send_digest_now feuert synchron bei einer Listennachricht, sobald die Schwelle überschritten ist, und mailman digests --send soll vom Betreiber in den Cron gelegt werden. Pepsi behält beide Hälften und legt die zweite auf einen systemd-Timer, dieselbe Anordnung, die tasks --once hat.

digest status [ADRESSE]

Was jede Liste angesammelt hat und ob sie fällig ist.

template list

Zeigt die 28 Namen der Hinweisvorlagen und alle URI-Überschreibungen, die für sie auf Site-, Domain- oder Listenebene gesetzt sind.

template set NAME URI [–list ADRESSE | –domain DOMAIN] [–user BENUTZER] [–password PASSWORT]

Richtet eine Vorlage auf einen URI aus: mailman: (der eingebaute Text) oder eine http(s):-URL, optional mit HTTP-Basic-Zugangsdaten. Ohne --list oder --domain gilt die Überschreibung für die ganze Site. Ein http(s):-URI wird vom Server abgerufen, unter den Grenzen in [pepsi-list] TEMPLATE_FETCH_TIMEOUT, TEMPLATE_FETCH_MAX_BYTES und TEMPLATE_FETCH_ALLOW_INTERNAL. Ein file:-URI wird verweigert, hier wie auf jedem anderen Schreibpfad (der REST-API und den Importern), weil er den Server seine eigene Festplatte lesen ließe; ein bereits in der Tabelle stehender file:-Datensatz wird nie gelesen, und der Hinweis wird so gerendert, als fehlte er.

template clear NAME [–list ADRESSE | –domain DOMAIN]

Entfernt eine Überschreibung, sodass wieder der eingebaute Text verwendet wird.

unsub-token LISTE E-MAIL [–serial N] [–uri]

Gibt das RFC-8058-One-Click-Abmeldetoken aus, das eine Zustellung an E-MAIL tragen würde, berechnet vom selben Code, der es erzeugt; --uri gibt stattdessen den ganzen https:-URI aus. --serial signiert eine angegebene Abonnement-Seriennummer statt der aktuellen des Mitglieds. Benötigt [pepsi-list] UNSUBSCRIBE_SECRET. Es legt nichts offen, was das Mitglied nicht bereits in seinem Postfach hat.

85.1.47.1.7. Reservierte Verben

Drei Verben werden von --help aufgeführt und antworten damit, wo die Fähigkeit tatsächlich liegt, statt mit „unbekannter Unterbefehl“:

held, requests

Zurückgehaltene Nachrichten und Abonnementanfragen zu moderieren ist auf der Kommandozeile nicht implementiert. Es liegt in der Verwalteroberfläche unter /lists/<list-id>/admin (pepsi-httpd(1)), über die REST-API und per Post an list-request.

inject

Nicht implementiert und nicht nötig: senden Sie an die eigene Adresse der Liste, mit pepsi-sendmail(1) oder einem beliebigen SMTP-Client. Eine von einem Verb hier eingespeiste Nachricht und eine normal gesendete gingen ohnehin durch dieselbe Stage.

Diese antworten, bevor irgendeine Datenbankverbindung versucht wird, die Antwort ist daher auf einem Rechner ohne Listenschema dieselbe.

85.1.47.1.8. Stile

Ein Stil ist ein benannter Satz von Attributvorgaben, der beim Anlegen einer Liste angewandt wird. GET /3.0/lists/styles meldet drei, die von upstream sind, mit den Namen und Beschreibungen von upstream:

legacy-default

Gewöhnlicher Stil für Diskussionsmailinglisten. Die Voreinstellung. Wird auch als discussion oder default angenommen.

legacy-announce

Stil für Listen nur mit Ankündigungen – Mitglieder dürfen nicht senden. Wird auch als announce-only oder announce angenommen.

private-default

Stil für Diskussionsmailinglisten mit privatem Archiv; nicht beworben, und Abonnements brauchen sowohl eine Bestätigung als auch einen Moderator. Wird auch als private angenommen.

Ein weiterer Stil ist Pepsis eigener und wird hier angenommen, aber nicht über REST aufgeführt, aus demselben Grund, aus dem die Pepsi-eigenen Einstellungen je Liste es nicht sind:

moderated

Eine Diskussionsliste, auf der jede Nachricht eines Mitglieds für einen Moderator zurückgehalten wird.

85.1.47.1.9. Rückgabewert

0 bei Erfolg, nicht Null bei einem Fehlschlag. check endet mit einem Fehlerstatus, wenn es einen Fehler gefunden hat (oder mit --strict eine Warnung). import endet mit einem Fehlerstatus, wenn irgendetwas nicht übernommen wurde, obwohl alles andere geschrieben wurde.

85.1.47.1.10. Dateien

/etc/pepsi/pepsi.conf

Konfiguration; siehe pepsi.conf(5), Abschnitt [pepsi-list].

85.1.47.1.11. Siehe auch

pepsi.conf(5), pepsi-setup(1), pepsi-settings(1), pepsi-whitelist(1).

Die Dokumentation von GNU Mailman 3 unter <https://docs.mailman3.org>.