85.1.43. pepsi-whitelist¶

manage the sender whitelist, by hand or by mailbox

Handbuchabschnitt:: 1

85.1.43.1.1. Name¶

pepsi-whitelist - Einträge der weißen Absenderliste hinzufügen, auflisten, entfernen und importieren.

85.1.43.1.2. Übersicht¶

pepsi-whitelist [GLOBAL-OPTIONS] add [–no-dkim-required] [–signature-required] [–sealer DOMAIN] NAME REGEX

pepsi-whitelist [GLOBAL-OPTIONS] add-list [–pattern] [–no-dkim-required] [–signature-required] [–sealer DOMAIN] NAME LIST-ID

pepsi-whitelist [GLOBAL-OPTIONS] list [NAME] [–json]

pepsi-whitelist [GLOBAL-OPTIONS] remove NAME REGEX

pepsi-whitelist [GLOBAL-OPTIONS] remove-list [–pattern] NAME LIST-ID

pepsi-whitelist [GLOBAL-OPTIONS] import [IMPORT-OPTIONS] [PATH…]

85.1.43.1.3. Beschreibung¶

pepsi-whitelist ist das Operator-Werkzeug für die pepsi.whitelist-Tabelle — die benannten Mengen von Mustern, die eine Nachricht als vertrauenswürdig (Nicht-Spam) markieren. Jeder Datensatz hat einen whitelist_name (die Gruppe, zu der er gehört), einen whitelist_regex (einen erweiterten POSIX-regulären Ausdruck, unabhängig von der Groß-/Kleinschreibung über den ~*-Operator abgeglichen), ein match_field, das benennt, wogegen dieser Ausdruck abgeglichen wird — die addr-spec des From: der Nachricht oder ihr List-Id: — und drei Bedingungen: dkim_required, signature_required und sealer_domain. Sie sind in pepsi-stage-check-whitelist(1) beschrieben, das sie auswertet.

Jedes Muster wird vor dem Speichern geprüft, indem PostgreSQL – die Engine, die es ausführen wird – gebeten wird, es zu kompilieren: add, add-list und import lehnen einen Ausdruck, der sich nicht kompilieren lässt, mit der Begründung von PostgreSQL ab, und ein import schreibt nichts, wenn eines seiner Muster abgelehnt wird.

Die weiße Liste wird von pepsi-stage-check-whitelist(1) konsultiert und von pepsi-stage-auto-whitelist(1) automatisch aus ausgehenden Empfängern befüllt; dieses Werkzeug erlaubt einem Administrator, Datensätze direkt zu verwalten, und jedem Benutzer, aus der bereits von ihm gesendeten Mail eine eigene weiße Liste zu säen (import). Es ist keine Stage. Es verbindet sich über den gemeinsamen [pepsi-postgres]-Abschnitt mit derselben Datenbank wie die anderen Komponenten und liest den optionalen [pepsi-whitelist]-Abschnitt, der in pepsi.conf(5) beschrieben ist.

Anders als pepsi-stage-auto-whitelist(1), das eine Empfängeradresse in ein grenzverankertes Muster escaped, speichert add den whitelist_regex genau wie angegeben, sodass der Operator den Abgleich direkt steuert. import escaped die Adressen, die es findet, genau so wie die Stage es tut.

85.1.43.1.3.1. Mailinglisten¶

add-list und remove-list verwalten die list-id-Datensätze, die eine Mailingliste als Ganzes auf die weiße Liste setzen — jeden Beitrag, den sie weiterleitet, gleich wer ihn geschrieben hat, was ein From:-Muster nicht ausdrücken kann, weil die Beiträge einer Liste beliebige Absenderadressen tragen.

Sie sind eigene Unterbefehle statt eines Schalters an add, weil sie eine andere Art von Argument nehmen. add speichert sein REGEX wortgetreu, was für ein bewusst zusammengestelltes Muster richtig ist; ein in diesen Platz getippter Listenbezeichner wäre ein nicht verankerter regulärer Ausdruck, sodass users.example.org auch auf users.example.org.attacker.example passen und eine Liste nach Wahl des Angreifers auf die weiße Liste setzen würde. add-list nimmt den Bezeichner so, wie er im Header erscheint — Klammern optional, Groß-/Kleinschreibung und umgebende Phrase ignoriert — und verankert ihn selbst. –pattern ist die Notluke für den bewussten Platzhalter (jede Liste einer Domain), und dann ist das Argument wieder ein regulärer Ausdruck, wie bei add.

Ein List-Id:-Header ist unauthentifizierter Text, den jeder Absender aus einem echten Beitrag kopieren kann, sodass eine Regel, die allein darauf beruht, eine Regel ist, die jeder erfüllen kann. –sealer DOMAIN ist die andere Hälfte: Der Datensatz verlangt dann zusätzlich, dass die Nachricht mit einer validierten ARC-Kette ankam und dass DOMAIN einer ihrer Versiegler war, so wie pepsi-stage-arc(1) es festhält. DOMAIN wird normalisiert (kleingeschrieben, abschließender Punkt entfernt) auf dieselbe Form, die die ARC-Stage festhält, sodass die beiden nicht uneins sein können. Es funktioniert auch bei add-Datensätzen, wo es ein Absendermuster auf Mail einschränkt, die über einen bekannten Weiterleiter gelaufen ist.

85.1.43.1.3.2. Namen weißer Listen und wer sie verwenden darf¶

Ein whitelist_name ist entweder

global — ein einzelnes Segment wie correspondents, das nur der Operator: verwalten darf; oder
einem Benutzer gehörend — <login>/<segment> wie alice/correspondents, und: alice/lists/rust-lang für weitere Unterlisten.

Ein Segment besteht aus Buchstaben, Ziffern, _, . und -; das Trennzeichen ist /. Ein Segment, das aus nichts als Punkten besteht, wird abgelehnt, sodass . und .. keine Segmente sein können und der Name einer weißen Liste nie ein relativer Pfad sein kann. Ein Punkt ist sonst erlaubt, weil das besitzende Segment das passwd-Login des Kontos ist und alice.smith auf jeder LDAP-/SSSD-/FreeIPA-Installation ein gewöhnliches Login ist — ebenso wie ein {localpart} der Form first.last in pepsi-stage-check-whitelist(1). / ist das Trennzeichen, weil kein POSIX-artiges System es in einem Login-Namen zulässt, während -, _, . und ein abschließendes $ darin allesamt legal sind und daher nicht eindeutig abgrenzen könnten. (Ein Login, das ein Zeichen außerhalb der Segmentgrammatik enthält, besitzt dennoch keinen Namensraum; import –all-users überspringt ein solches Konto mit einer Meldung, statt den ganzen Lauf fehlschlagen zu lassen.)

Weil dieses Programm setuid installiert ist (siehe unten), kann jeder lokale Benutzer es ausführen. Ein unprivilegierter Aufrufer darf nur Namen in seinem eigenen Namensraum lesen und schreiben — dem Login der realen uid, aus der passwd-Datenbank genommen, nie aus $USER oder einem Argument. Diese Einschränkung gilt auch für list: Die gemeinsame weiße Liste des Operators ist eine Aufzeichnung darüber, mit wem die Organisation korrespondiert, und dieses Programm darf sie nicht jedem Konto auf dem Host aushändigen. root sowie die Konten pepsi, pepsi-owner und pepsi-whitelist dürfen jede weiße Liste verwalten.

Damit eine benutzereigene weiße Liste überhaupt eine Wirkung hat, muss irgendeine Stage sie konsultieren; siehe die Platzhalter {localpart} und {login} von WHITELIST_NAME in pepsi-stage-check-whitelist(1).

85.1.43.1.3.3. Das setuid-Modell¶

Die gemeinsame pepsi.whitelist-Tabelle zu verwalten erfordert eine Datenbank-Identität, die gewöhnliche Benutzer nicht haben, während das Durchsuchen des Postfachs eines Benutzers dessen Identität erfordert. Das Programm wird daher setuid auf das pepsi-whitelist-Konto installiert (Modus 4755) und senkt seine effektiven IDs sofort wieder auf den aufrufenden Benutzer ab, wobei es den Eigentümer nur in der gespeicherten set-user-id behält. Es hebt sie für die wenigen Millisekunden, in denen es mit PostgreSQL spricht, wieder an — die Peer-Authentifizierung richtet sich nach der effektiven uid — und sonst für nichts.

Derselbe Mechanismus ist es, der root die Nutzung des Werkzeugs erlaubt. Die übrigen Operator-Befehle — pepsi-queue(1), pepsi-status(1), pepsi-settings(1), pepsi-tlsrpt(1), pepsi-failure-bouncer(1) — werden schlicht zum Dienstkonto pepsi, wenn sie als root gestartet werden, und zwar dauerhaft, weil sie als root nichts zu erledigen haben. Dieses hier schon: import –user und –all-users führen den Scan-Helper mit den Zugangsdaten eines anderen Benutzers aus, was nur root einrichten kann. Es behält daher die aufrufende Identität, root eingeschlossen, und wechselt nur seine effektiven IDs — zum Konto pepsi-whitelist, dessen Datenbankrolle allein die Tabelle der weißen Liste gewährt ist — für die Dauer jedes Datenbankaufrufs, um danach zu root zurückzukehren.

Dieses Konto ist bewusst nicht das pepsi-Dienstkonto: pepsi-setup(1) gewährt seiner Datenbankrolle SELECT, INSERT und DELETE auf der pepsi.whitelist-Tabelle und nicht mehr, sodass die Kompromittierung eines Binärprogramms, das jeder lokale Benutzer ausführen darf, weder die Nachrichten-Warteschlange noch die Statistiken noch die Signierschlüssel erreichen kann.

Das Parsen des Postfachs — der eine Teil, der angreiferkontrollierte Daten liest, nämlich jede Nachricht, die dem Benutzer je irgendjemand gesendet hat — findet überhaupt nicht in diesem Prozess statt. Es läuft in pepsi-helper-mailbox-scan(1), gestartet mit setresuid, das die reale, effektive und gespeicherte ID auf den Zielbenutzer setzt, sodass in den Zugangsdaten dieses Prozesses nirgends eine privilegierte ID verbleibt und er nicht einmal im Prinzip pepsi-whitelist werden kann.

Weil ein setuid-Programm nicht auf eine Konfigurationsdatei nach Wahl des Aufrufers gerichtet werden darf, wird -c/–config für unprivilegierte Aufrufer abgelehnt, und die Umgebungsvariablen, die sonst die Konfigurationssuche (HOME, XDG_CONFIG_HOME), die Expansion von ${DATADIR} (PATH) oder die Datenbankverbindung (PG*) umlenken würden, werden entfernt, bevor die Konfiguration gelesen wird.

85.1.43.1.4. Befehle¶

add [–no-dkim-required] [–signature-required] [–sealer DOMAIN] NAME REGEX

Fügt einen from-Eintrag ein, der REGEX unter der weißen Liste NAME speichert. Das Einfügen ist auf dem UNIQUE(whitelist_name, match_field, whitelist_regex)-Constraint idempotent: Ein vorhandenes Tripel erneut hinzuzufügen ist eine No-Op und lässt seine Bedingungen unverändert.

–no-dkim-required: Löscht das dkim_required-Flag des Datensatzes. Standardmäßig ist es gesetzt, sodass ein Treffer nur zählt, wenn die DKIM- oder ARC-Signatur des Absenders verifiziert hat.
–signature-required: Setzt das signature_required-Flag des Datensatzes. Standardmäßig ist es gelöscht. Wenn gesetzt, zählt ein Treffer nur, wenn die Signatur der Nachricht verifiziert hat.
–sealer DOMAIN: Setzt das sealer_domain des Datensatzes. Standardmäßig ist es leer (jeder Pfad). Ist es gesetzt, zählt ein Treffer nur, wenn die Nachricht mit einer validierten ARC-Kette ankam und DOMAIN einer ihrer Versiegler war. DOMAIN wird kleingeschrieben und um einen abschließenden Punkt gekürzt, passend zu dem, was pepsi-stage-arc(1) festhält.

add-list [–pattern] [CONDITION-OPTIONS] NAME LIST-ID

Fügt einen list-id-Eintrag unter der weißen Liste NAME ein, der auf jede Nachricht passt, deren List-Id:-Header den Bezeichner LIST-ID trägt. Der Bezeichner darf in Klammern oder nackt angegeben werden, in beliebiger Groß-/Kleinschreibung, mit oder ohne beschreibende Phrase; er wird auf die nackte kleingeschriebene Form reduziert und verankert, sodass er auf diese Liste passt und auf keine andere. Nimmt dieselben Bedingungsoptionen wie add, und die Paarung mit –sealer ist dringend zu empfehlen — siehe Mailinglisten oben.

–pattern: Behandelt LIST-ID als erweiterten POSIX-regulären Ausdruck, der wortgetreu gespeichert wird, statt als einen zu verankernden Bezeichner. Für den bewussten Platzhalterfall (jede Liste einer Domain); ein nicht verankerter Ausdruck passt auf jeden Bezeichner, der ihn enthält, schreiben Sie die Anker also selbst.

list [NAME] [–json]

Listet Einträge geordnet nach Name, Match-Feld und dann Regex auf. Mit NAME wird nur diese Gruppe der weißen Liste angezeigt.

–json: Gibt ein JSON-Array von Objekten (whitelist_id, whitelist_name, whitelist_regex, match_field, dkim_required, signature_required, sealer_domain) statt der menschenlesbaren Tabelle aus.

remove NAME REGEX

Löscht den from-Eintrag, dessen whitelist_name NAME und dessen whitelist_regex genau REGEX ist. Ein list-id-Datensatz mit demselben Mustertext ist ein anderer Eintrag und bleibt unangetastet; verwenden Sie dafür remove-list.

remove-list [–pattern] NAME LIST-ID

Löscht den list-id-Eintrag, den add-list für LIST-ID angelegt hätte, sodass der Bezeichner, der eine Liste hinzugefügt hat, sie auch entfernt. –pattern hat dieselbe Bedeutung wie in add-list und muss angegeben werden, wenn es damals angegeben wurde.

import [OPTIONS] [PATH…]

Sät eine weiße Liste aus den Empfängern der Mail, die der Benutzer gesendet hat.

Ein Postfach wird nach Nachrichten durchsucht, die der Benutzer gesendet hat, und die To:-, Cc:- und Bcc:-Adressen dieser Nachrichten werden zu Einträgen der weißen Liste, sodass die Antworten dieser Leute erkannt werden, wenn sie zurückschreiben. Empfänger auf einer lokalen Domain werden übersprungen — lokale Absender passieren die eingehende Schranke nie.

Eine Nachricht gilt als vom Benutzer gesendet, wenn ihr From: (oder Sender:) auf einer der lokalen Domains liegt und ihr Header-Block kein Received:-, Return-Path:-, Delivered-To:- oder X-Original-To:-Feld trägt. Beide Hälften werden gebraucht: From: ist unauthentifiziert, für sich genommen also eine Behauptung, die jeder aufstellen kann, und ein Fremder, der Ihnen eine Nachricht mit Ihrer eigenen Adresse im From: und seiner eigenen im To: schickt, bekäme diese Adresse sonst vom nächsten import in Ihre weiße Liste eingefügt — was genau die Schranke ist, die die weiße Liste öffnet. Eine Signatur zu verlangen schließt sie nicht, denn der Fälscher signiert die Mail seiner eigenen Domain. Die vier obigen Felder werden von einem empfangenden MTA oder MDA geschrieben und nie von einem Mail-User-Agent, der eine Nachricht verfasst, sodass ihr Fehlen der Beleg dafür ist, dass die Nachricht hier abgelegt und nicht hier zugestellt wurde.

Empfangene Mail wird daher ignoriert, und alles andere, was angekommen ist, ebenso. –include-delivered schaltet diese Prüfung ab; lesen Sie unten nach, bevor Sie sie verwenden.

Wo eine Nachricht abgelegt ist, spielt weiterhin keine Rolle: Ein Maildir-Scan läuft den ganzen Baum ab, sodass ~/Maildir in einem Lauf .Sent und jeden Archivordner abdeckt. Von jeder Nachricht wird nur der Header-Block gelesen, nie der Nachrichtentext.

PATH… sind Postfachdateien oder Maildir-Verzeichnisse. Ohne Angabe wird ~/Maildir durchsucht, sofern es existiert, sonst /var/mail/<login>; [pepsi-whitelist] MAILBOX überschreibt diesen Standardwert. Beachten Sie, dass /var/mail/<login> ein Zustell-Spool ist und nichts als empfangene Mail enthält, sodass der Standardwert auf einem Host ohne Maildir nichts findet und ein Sent-Ordner ausdrücklich benannt werden muss.

–name NAME

Zu säende weiße Liste. Standardwert ist <login>/correspondents (oder das globale correspondents bei einem privilegierten Aufrufer).

–include-delivered

Zählt eine Nachricht allein anhand ihres From: als gesendet und lässt die obige Zustellspuren-Prüfung fallen. Unsicher auf jedem Postfach, das empfangene Mail enthält — ein gefälschtes From: genügt dann, um einen Eintrag in die weiße Liste zu pflanzen. Es existiert für den ungewöhnlichen Speicher, dessen gesendete Kopien tatsächlich durch die Zustellung gelaufen sind, und sollte nur auf diesen Sent-Ordner gerichtet werden, nie auf einen Posteingang.

–format auto|mbox|maildir

Erzwingt das Postfachformat, statt es je Pfad zu erkennen (ein Verzeichnis ist ein Maildir, eine Datei eine mbox).

–auto-wildcard

Bietet an, die einzelnen Adressen einer Domain durch einen einzigen *@domain-Eintrag zu ersetzen, wenn dort mindestens N verschiedene Adressen gesehen wurden (N ist --threshold, Standardwert [pepsi-whitelist] WILDCARD_THRESHOLD, 10).

Vorschläge werden auf einem Terminal einzeln ausgegeben und bestätigt; einen abzulehnen behält schlicht die Adressen dieser Domain einzeln bei. Mit –yes werden alle angenommen; ohne Terminal und ohne –yes werden alle abgelehnt, sodass ein unbeaufsichtigter Lauf eine weiße Liste nie von sich aus auf eine ganze Domain ausweiten kann.

Öffentliche E-Mail-Hoster werden nie vorgeschlagen, wie viele Korrespondenten der Benutzer dort auch haben mag: „alle bei gmail.com“ ist keine Menge von Leuten, die der Benutzer kennt. Die Liste dieser Domains ist [pepsi-whitelist] HOSTERS_FILE (/usr/share/pepsi/hosters.txt).

–threshold N

Verschiedene Adressen bei einer Domain, bevor eine Wildcard vorgeschlagen wird.

–hosters FILE

Verwendet FILE als Liste der öffentlichen Hoster statt der konfigurierten.

–no-hosters

Schließt keine Domain vom Wildcarding aus.

–dry-run

Meldet, was hinzugefügt würde, und ändert nichts.

-y, –yes

Nimmt jeden Wildcard-Vorschlag ohne Nachfrage an.

–max-entries N

Höchstzahl der Datensätze, die dieser Import hinzufügen darf (Standardwert [pepsi-whitelist] MAX_ENTRIES, 5000). Jeder Datensatz einer weißen Liste wird gegen das From: jeder eingehenden Nachricht abgeglichen, die sie konsultiert, sodass ein unbegrenzter Import dauerhafte Kosten je Nachricht bedeutet.

–max-messages N

Untersucht höchstens N Nachrichten. Das deckelt, wie viele geparst und klassifiziert werden, nicht, wie viel vom Postfach gelesen wird: Die Datei, der Baum oder das IMAP-Konto wird weiterhin bis zum Ende durchlaufen.

–own-address ADDRESS

Behandelt nur Mail, die von genau dieser Adresse gesendet wurde, als die eigene des Benutzers, statt jeden Absender auf einer lokalen Domain. Wiederholbar.

–imap URL

Durchsucht einen Mail-Speicher, der nicht auf diesem Dateisystem liegt, z. B. imaps://alice@mail.example.com/. imaps:// ist implizites TLS (Port 993), imap:// ist STARTTLS (Port 143); eine Pfadkomponente ist ein Postfachmuster (Standardwert *, jedes Postfach). Postfächer werden nur lesend geöffnet (EXAMINE) und es werden nur Header-Blöcke abgerufen, sodass ein Scan nichts als \Seen markiert.

LMTP kann das nicht — es ist ein Zustellprotokoll ohne ein Verb, das irgendetwas auflistet oder abruft —, weshalb IMAP die Netzwerk-Option ist.

–imap-user NAME

IMAP-Login, falls es nicht in der URL steht.

–imap-password-file FILE

Liest das Passwort aus der ersten Zeile von FILE, statt danach zu fragen. Halten Sie sie auf Modus 0600: Dieser Pfad liest die Datei selbst und prüft ihre Rechte nicht, anders als die gleichnamige Option von pepsi-helper-mailbox-scan(1), die eine Datei ablehnt, die ein anderer Benutzer lesen kann. Das Passwort wird nie auf einer Kommandozeile übergeben, wo jeder andere Benutzer es aus ps auslesen könnte.

–doveadm

Liest einen lokalen Dovecot-Speicher über doveadm, für Formate, die kein Datei-Scanner parsen kann (mdbox/sdbox). doveadm wird von diesem Programm ausgeführt (es benötigt Privilegien) und seine Ausgabe wird in den unprivilegierten Scan-Helper geleitet.

–doveadm-path PATH

Das zu verwendende doveadm-Binärprogramm.

–user LOGIN

Importiert für einen anderen Benutzer, in dessen Namensraum. Erfordert einen privilegierten Aufrufer; der Scan-Helper wird auf die Zugangsdaten dieses Benutzers abgesenkt.

–all-users

Importiert für jedes lokale Konto, das [pepsi-whitelist] TARGETS zulässt, jeweils in dessen eigenes <login>/correspondents. Erfordert einen privilegierten Aufrufer. Es werden nur Konten in der lokalen passwd-Datei gefunden; ein Konto aus einem Verzeichnisdienst benennen Sie mit –user.

–no-dkim-required, –signature-required

Wie bei add, angewendet auf jeden Datensatz, den der Import hinzufügt.

85.1.43.1.5. Globale Optionen¶

Diese globalen Optionen stehen vor dem Unterbefehl (ein nachgestelltes Flag wird abgelehnt).

-c FILE, –config FILE: Liest die Konfiguration aus FILE, statt die Standardorte zu durchsuchen. Für unprivilegierte Aufrufer abgelehnt, wenn dieses Programm setuid installiert ist: Die Konfiguration entscheidet über die Datenbankverbindung, sodass ein setuid-Prozess nur eine root-eigene liest.
-L LOGLEVEL, –log LOGLEVEL: Setzt die Log-Ausführlichkeit. LOGLEVEL ist eines von error, warn, info, debug oder trace (Standardwert: info).
-v, –verbose: Zeigt Log-Meldungen aus allen Quellen, einschließlich Drittanbieter-Bibliotheken.
-h, –help: Gibt eine Verwendungsübersicht aus und beendet sich.
-V, –version: Gibt die Version aus und beendet sich.

85.1.43.1.6. Exit-Status¶

0: Erfolgreicher Abschluss.
1: Ein Fehler ist aufgetreten: eine fehlerhafte Konfigurationsdatei oder eine fehlgeschlagene Datenbankverbindung oder -abfrage. Der Grund wird in das Journal geschrieben.

85.1.43.1.7. Dateien¶

Wenn –config nicht angegeben ist, wird die erste existierende Datei aus der folgenden Liste verwendet. Jede Pepsi-Komponente teilt sich dieselbe Konfigurationsdatei, dies ist also dieselbe Liste, die jede von ihnen durchsucht:

$XDG_CONFIG_HOME/pepsi.conf
$HOME/.config/pepsi.conf
/etc/pepsi/pepsi.conf
/etc/pepsi.conf

${DATADIR}/hosters.txt: Die Liste öffentlicher Hoster, für die import –auto-wildcard nie eine Wildcard vorschlägt, von make install aus contrib/hosters.txt installiert (/usr/share/pepsi/hosters.txt bei einer Standardinstallation). Wird durch [pepsi-whitelist] HOSTERS_FILE oder, für einen einzelnen Lauf, durch –hosters überschrieben.
~/Maildir, /var/mail/login: Die Postfächer, die import durchsucht, wenn kein PATH angegeben ist, in dieser Reihenfolge; [pepsi-whitelist] MAILBOX überschreibt das Paar.

85.1.43.1.8. Beispiele¶

Einen Absender auf die weiße Liste setzen (DKIM/ARC standardmäßig erforderlich):

pepsi-whitelist -c /etc/pepsi/pepsi.conf add trusted-senders '^alice@example\.com$'

Das Muster wird wortgetreu gespeichert, es zu verankern ist also Sache des Operators. Ein nicht verankertes alice@example\.com passt auch auf alice@example.com.attacker.example und "alice@example.com!"@attacker.example, die ein Angreifer beide in einen From:-Header setzen kann. Die erzeugten Muster (import und pepsi-stage-auto-whitelist(1)) verankern aus diesem Grund immer auf ^/$.

Eine ganze Domain auf die weiße Liste setzen, ohne eine Signatur zu verlangen:

pepsi-whitelist -c /etc/pepsi/pepsi.conf add trusted-senders --no-dkim-required '@example\.org$'

Die trusted-senders-Gruppe als JSON auflisten:

pepsi-whitelist -c /etc/pepsi/pepsi.conf list trusted-senders --json

Einen Eintrag entfernen:

pepsi-whitelist -c /etc/pepsi/pepsi.conf remove trusted-senders '@example\.org$'

Als gewöhnlicher Benutzer eine Mailingliste, die Sie abonniert haben, auf die weiße Liste setzen, sodass ihre Beiträge Sie erreichen, gleich wer sie geschrieben hat, aber nur, wenn die ADMD der Liste selbst sie versiegelt hat:

pepsi-whitelist add-list alice/lists users.rust-lang.org \
    --sealer mail.rust-lang.org

Jede an einer Domain betriebene Liste, was die Anker von Hand geschrieben verlangt:

pepsi-whitelist add-list alice/lists --pattern '^[a-z0-9-]+\.lists\.example\.org$' \
    --sealer lists.example.org

Abbestellt; die Regel mit dem Bezeichner, der sie angelegt hat, wieder entfernen:

pepsi-whitelist remove-list alice/lists users.rust-lang.org

Als gewöhnlicher Benutzer die eigene weiße Liste aus dem eigenen Postfach säen und zuerst sehen, was das täte:

pepsi-whitelist import --dry-run
pepsi-whitelist import

Dasselbe, aber die Domains, an die Sie breit schreiben, zu je einem Eintrag zusammenfassen (öffentliche Hoster werden nie zusammengefasst):

pepsi-whitelist import --auto-wildcard

Nur den eigenen Sent-Ordner und ein entferntes Konto über IMAP durchsuchen:

pepsi-whitelist import ~/Maildir/.Sent
pepsi-whitelist import --imap imaps://alice@mail.example.com/Sent

Als root die eigene weiße Liste jedes lokalen Kontos aus einem Dovecot-Speicher säen:

pepsi-whitelist import --all-users --doveadm --auto-wildcard --yes

85.1.43.1.9. Siehe auch¶

pepsi-config(1), pepsi-helper-mailbox-scan(1), pepsi-stage-check-whitelist(1), pepsi-stage-auto-whitelist(1), pepsi-queue(1), pepsi.conf(5), pepsi-setup(1)

85.1.43.1.10. Fehler¶

Melden Sie Fehler an den Pepsi-Issue-Tracker.