85.1.25. pepsi-stage-auto-whitelist

whitelist recipients of outgoing mail

Handbuchabschnitt:

1

85.1.25.1.1. Name

pepsi-stage-auto-whitelist - die empfänger-aufzeichnende Stage der Pepsi-Pipeline.

85.1.25.1.2. Übersicht

pepsi-stage-auto-whitelist [GLOBAL-OPTIONS] worker

85.1.25.1.3. Beschreibung

Diese Stage hat den Standardwert FUSION = yes: Wenn Stage-Fusion aktiviert ist ([pepsi] ALLOW_FUSION, der Standardwert) und diese Stage in das vereinheitlichte pepsi-Binärprogramm eingefaltet ist, kann ein Vorgänger sie in seinem eigenen Worker-Prozess ausführen, statt sie separat zu dispatchen. Siehe pepsi-dispatch(1) und pepsi.conf(5).

pepsi-stage-auto-whitelist ist ein Stage-Programm, das von pepsi-dispatch(1) als persistenter Worker ausgeführt wird, der Nachrichten-IDs von der Standardeingabe liest. Es lädt diesen pepsi.workqueue-Datensatz (und weigert sich zu handeln, sofern sein status nicht running ist) und liest seinen [stage-<stage>]-Abschnitt. Es ist das schreibseitige Gegenstück zu pepsi-stage-check-whitelist(1): Während eine ausgehende Nachricht durchläuft, hält es jeden Umschlagempfänger (rcpt_to) in einer benannten weißen Liste fest, sodass pepsi-stage-check-whitelist(1) ihren From:-Header erkennt und die Antwort die Zahlungsschranke des Anti-Spam überspringen lässt, wenn diese Person später antwortet. Platzieren Sie es auf dem ausgehenden Pfad (zum Beispiel vor einer Relay-Stage).

Die weiße Liste liegt in der pepsi.whitelist-Tabelle, geteilt mit pepsi-stage-check-whitelist(1) — diese Stage fügt nur in sie ein, sodass sie kein eigenes Schema benötigt. Jede Empfängeradresse wird als whitelist_regex gespeichert: Die Adresse wird kleingeschrieben, jedes nicht-alphanumerische Zeichen wird mit einem Backslash escaped, sodass es wörtlich passt, und das Ergebnis wird an ^/$ verankert, sodass es genau auf diese Adresse und auf nichts sonst passt. Die Prüf-Stage gleicht diesen Regex unabhängig von der Groß-/Kleinschreibung (PostgreSQLs ~*-Operator) gegen die aus dem From:-Header einer Antwort geparste addr-spec ab — nicht gegen den rohen Header-Wert, sodass eine Adresse auf der weißen Liste, die in die Anzeigenamen-Position geschrieben wird (From: "bob@example.com" <evil@attacker.example>), keinen Treffer vortäuschen kann. Die Verankerung an den Grenzen ist es, die zusätzlich verhindert, dass bob@example.com.evil passt.

Jeder eingefügte Datensatz trägt zwei Bedingungs-Flags, die bestimmen, wann eine künftige Antwort als auf der weißen Liste stehend zählt:

• dkim_required wird aus der DKIM_REQUIRED-Option der Stage gesetzt (Standardwert yes): Wenn true, wird der Antwort nur vertraut, wenn ihre DKIM- oder ARC-Signatur verifiziert hat.

• signature_required wird auf true gesetzt, wenn der State der ausgehenden Nachricht encrypted: true hat (die Nachricht war Ende-zu-Ende-verschlüsselt), sonst false. Diesen Schlüssel schreibt pepsi-stage-encrypt(1), daher muss diese Stage nach der Verschlüsselungs-Stage laufen (und darf, da sie keinen Inhalt ändert, zwischen ihr und pepsi-stage-dkim-sign(1) laufen, wo pepsi-setup(1) --wizard sie platziert). Weiter vorn platziert, trägt kein Datensatz jemals das Flag. Die Datensätze für verschlüsselt korrespondierende Gegenstellen verlangen dann, dass deren Antworten mit einer verifizierten Signatur eintreffen (state.signature_verified, das pepsi-stage-decrypt(1) setzt), um überhaupt zu passen.

Jeder Datensatz wird mit match_field = 'from' geschrieben: Was diese Stage festhält, ist eine Adresse, von der eine Antwort eintreffen wird. Sie schreibt nie die list-id-Datensätze, die pepsi-stage-check-whitelist(1) ebenfalls versteht — zu erkennen, dass ein Benutzer einer Mailingliste beigetreten ist, ist eine andere Schlussfolgerung über andere Header und wird von Hand mit pepsi-whitelist add-list erledigt.

Bestehende Datensätze bleiben unberührt (das Einfügen ist ON CONFLICT DO NOTHING auf dem UNIQUE(whitelist_name, match_field, whitelist_regex)-Constraint), sodass das erneute Verarbeiten einer Nachricht harmlos ist. Die Stage schaltet die Nachricht dann zu NEXT_STAGE weiter. Sie verändert nie das eigene state der Nachricht und verwirft, bounct oder pausiert eine Nachricht nie; eine Nachricht ohne Empfänger schaltet einfach weiter.

85.1.25.1.4. Konfiguration

Die Optionen liegen im eigenen [stage-<name>]-Abschnitt der Stage (PROGRAM = pepsi-stage-auto-whitelist): die erforderliche zu befüllende WHITELIST_NAME-Gruppe (ein literaler Whitelist-Name; die Stage expandiert keinen {login}- oder {localpart}-Platzhalter und weist einen Wert zurück, der einen enthält), DKIM_REQUIRED (Standardwert yes) und ein NEXT_STAGE — ebenfalls erforderlich, denn die Stage vermerkt die Empfänger und reicht die Nachricht danach immer weiter, sodass pepsi-setup einen Abschnitt ohne ein solches zurückweist. Sie sind in pepsi.conf(5) dokumentiert.

85.1.25.1.4.1. Wessen Whitelist

Die Stage läuft auf dem ausgehenden Pfad, daher werden die adressbezogenen Schichten der Konfiguration für den Absender des Umschlags nachgeschlagen: Die pepsi.config_override-Datensätze dieser Adresse im Geltungsbereich domain:/address: und ihr pepsi.settings-Datensatz entscheiden, in welche Liste ihre Empfänger geschrieben werden.

Der Operator darf in jeder seiner eigenen Schichten jede Whitelist benennen, auch eine gemeinsame: in der INI-Datei, in pepsi.config_override in jedem Geltungsbereich und in einem mit pepsi-settings(1) geschriebenen pepsi.settings-Datensatz. Die Stage schreibt in den effektiven Wert, so wie sie ihn vorfindet.

Ein Kontoinhaber, der diese Stage per Mail bearbeiten darf (sie steht in EDITABLE_STAGES von pepsi-stage-edit-settings(1)), darf nur eine eigene Whitelist wählen: einen Namen im Namensraum <login>/... des Kontos, zu dem seine Adresse aufgelöst wird (etwa alice/sent), oder die Whitelist, die die Konfiguration des Operators bereits für ihn benennt. Alles andere – eine gemeinsame Liste, die eines anderen Benutzers oder irgendein Wert für eine Adresse, die kein lokales Konto ist – würde ihm erlauben, diese Liste mit Adressen seiner Wahl zu füllen, und pepsi-stage-edit-settings(1) weist es zurück. Der Login wird so aufgelöst, wie pepsi-stage-check-whitelist(1) {login} auflöst: Die Domain der Adresse muss eine der LOCAL_DOMAINS sein (Standard [pepsi-ingress] ACCEPTED_DOMAINS), ihr Local-Part ohne die Subadresse nach RECIPIENT_DELIMITER muss ein passwd-Login sein, und dieses Konto muss von TARGETS zugelassen sein. Diese drei Optionen werden aus dem Stage-Abschnitt des Operators gelesen, nie aus der eigenen Überschreibung des Inhabers.

Ein Unternehmen, das jeden Korrespondenten erkannt haben möchte, egal wem er antwortet – etwa ein Kunde, der gebeten wurde, einem Kollegen statt dem Mitarbeiter zu schreiben, der ihn zuerst angeschrieben hat –, teilt eine Whitelist unter allen lokalen Benutzern, die diese Stage schreibt und die Prüf-Stage liest:

[stage-auto-whitelist]
PROGRAM = pepsi-stage-auto-whitelist
NEXT_STAGE = dkim-sign
WHITELIST_NAME = correspondents

[stage-check-whitelist]
PROGRAM = pepsi-stage-check-whitelist
NEXT_STAGE = anti-spam
WHITELIST_NAME = correspondents

85.1.25.1.5. State

Eingaben: Die Umschlagempfänger stammen aus der rcpt_to-Spalte; state.encrypted setzt das gespeicherte signature_required-Flag. Dieser Schlüssel wird von pepsi-stage-encrypt(1) geschrieben, früher auf demselben ausgehenden Pfad, wenn die ausgehende Nachricht tatsächlich an einen Empfängerschlüssel verschlüsselt wurde — sodass ein unter Verschlüsselung erreichter Korrespondent später am selben Maßstab gemessen wird.

Ausgaben: keine an der Nachricht selbst — das Nachrichten-state bleibt unberührt. Der Nebeneffekt ist ein pepsi.whitelist-Datensatz pro Empfänger. Das State-Layout wird in pepsi.state(7) beschrieben.

Übergänge: schaltet immer zu NEXT_STAGE weiter — nach dem Einfügen eines Datensatzes der weißen Liste pro Umschlagempfänger, oder unverändert, wenn es keine gibt. Es gibt keine Verzweigung; die Stage pausiert, schlägt fehl, leitet um oder schließt nie ab.

85.1.25.1.6. Befehle

worker

Läuft als persistenter pepsi-dispatch(1)-Worker, der Nachrichten-IDs von der Standardeingabe liest.

85.1.25.1.7. Fehlschläge

Das Festhalten ist fail-open. Schlägt das INSERT fehl (ein Datenbankfehler, eine fehlende Berechtigung), protokolliert die Stage eine Warnung und schaltet die Nachricht trotzdem weiter: Die Whitelist ist eine Annehmlichkeit für die Antwort des Empfängers, und die ausgehende Mail des Benutzers zurückzuhalten, bis sie festgehalten werden kann, wäre verkehrt herum. Ein Muster, das PostgreSQL nicht kompilieren konnte, wird nie geschrieben (die Muster sind maskierte Adressen, daher ist dies eine Absicherung, kein erwarteter Fall).

85.1.25.1.8. Globale Optionen

-c FILE, –config FILE

Liest die Konfiguration aus FILE, statt die Standardorte zu durchsuchen.

-L LOGLEVEL, –log LOGLEVEL

Setzt die Log-Ausführlichkeit (Standardwert info).

-v, –verbose

Zeigt Log-Meldungen aus allen Quellen.

-h, –help; -V, –version

Gibt eine Verwendungsübersicht / die Version aus und beendet sich.

85.1.25.1.9. Exit-Status

0

Die Nachricht wurde verarbeitet (Empfänger festgehalten und die Nachricht weitergeschaltet).

1

Ein Fehler ist aufgetreten (Nachricht nicht gefunden oder nicht running, fehlkonfigurierte Stage — z. B. ein fehlendes WHITELIST_NAME — oder ein Datenbankfehler). Der Grund wird in das Journal geschrieben.

85.1.25.1.10. Beispiele

Die Empfänger von Nachricht 42 festhalten (sie muss running sein):

echo 42 | pepsi-stage-auto-whitelist -c /etc/pepsi/pepsi.conf worker

Ein ausgehender Pipeline-Abschnitt, der jeden auf die weiße Liste setzt, dem wir mailen, und verlangt, dass ihre Antworten DKIM/ARC-signiert sind:

[stage-auto-whitelist]
PROGRAM = pepsi-stage-auto-whitelist
NEXT_STAGE = srs
WHITELIST_NAME = trusted-senders
DKIM_REQUIRED = yes

85.1.25.1.11. Siehe auch

pepsi-config(1), pepsi-stage-check-whitelist(1), pepsi-stage-anti-spam(1), pepsi-stage-arc(1), pepsi-dispatch(1), pepsi.conf(5), pepsi.state(7), pepsi-setup(1)

85.1.25.1.12. Fehler

Melden Sie Fehler an den Pepsi-Issue-Tracker.