46. pepsi-stage-check-whitelist

Markiert Mail von vertrauenswürdigen Absendern als Nicht-Spam.

46.1. Rolle

pepsi-stage-check-whitelist konsultiert eine benannte weiße Liste vertrauenswürdiger Absender und hält, wenn der From:-Header der Nachricht passt, state.spam = false fest, sodass ein späteres pepsi-stage-anti-spam die Nachricht ohne Zahlung durchlässt. Platzieren Sie es vor der Anti-Spam-Stage. Es annotiert nur den State und schaltet weiter — es verwirft, bounct oder pausiert eine Nachricht nie. Referenz: pepsi-stage-check-whitelist(1).

46.2. Funktionen

  • Datenbankgestützte Whitelists: Die Tabelle pepsi.whitelist gruppiert Datensätze unter einem whitelist_name. WHITELIST_NAME ist eine kommagetrennte Liste der zu konsultierenden Gruppen, und ein Eintrag darf eine Vorlage sein, die {localpart} oder {login} enthält und je Umschlagempfänger expandiert wird — so konsultiert WHITELIST_NAME = correspondents, {localpart}/correspondents die gemeinsame Liste des Betreibers und die eigene jedes Empfängers, den Namensraum also, den pepsi-whitelist diesen Benutzer verwalten lässt. Nur ein Empfänger an einer lokalen Domain darf eine Whitelist benennen (sonst würde ein vom Angreifer gewählter Mitempfänger zur Liste eines beliebigen lokalen Benutzers expandieren), und {login} verlangt zusätzlich, dass sich die Adresse zu einem passwd-Konto auflöst; platzieren Sie die Stage bei dessen Verwendung also hinter pepsi-stage-aliases. Jeder zutreffende Name wird in einer einzigen Abfrage geprüft.

  • POSIX-ERE-Abgleich: Jeder whitelist_regex ist ein erweiterter regulärer POSIX-Ausdruck, der ohne Beachtung der Groß-/Kleinschreibung (PostgreSQLs ~*-Operator, in einem einzigen Round-Trip) gegen das Feld abgeglichen wird, das das match_field des Datensatzes benennt:

    • from (der Standardwert) — die aus dem From:-Header herausgeparste addr-spec, nie der rohe Header-Wert: Andernfalls würde eine Whitelist-Adresse in der Anzeigenamen-Position einen Treffer vortäuschen. RFC-5322-Kommentare und CFWS werden entfernt, und ein From:, das mehr als ein Postfach benennt, passt auf nichts (das DKIM-/DMARC-Urteil wird für die erste Adresse berechnet, ein Treffer auf einer späteren würde also zwei Fragen über zwei Absender beantworten).

    • list-id — der RFC-2919-Bezeichner aus dem List-Id:-Header der Nachricht. Die Beiträge einer Mailingliste tragen beliebige From:-Adressen, daher kann kein from-Muster sagen „alles, was über diese Liste kam“.

    Der Ausdruck selbst ist nicht verankert; verankern Sie ihn mit ^/$, um eine ganze Adresse abzugleichen (was pepsi-stage-auto-whitelist schreibt).

  • Optionale Bedingungen je Datensatz:

    • dkim_required → trifft nur zu, wenn die From:-Domain authentifiziert ist: state.auth.dkim = pass oder ein ARC-Pass, den DMARC ebenfalls bestätigt (state.auth.arc = pass und state.auth.dmarc = pass). Ein ARC-Pass allein belegt nur die Integrität der Kette (eine Ein-Hop-Kette kann über ein gefälschtes From: selbst erzeugt werden) und erfüllt den Datensatz daher nicht für sich genommen. Die Spalte ist standardmäßig wahr, wie bei pepsi-whitelist add.

    • signature_required → trifft nur zu, wenn state.signature_verified true ist, was pepsi-stage-decrypt für eine Nachricht setzt, deren Ende-zu-Ende-Signatur gegen einen vertrauenswürdigen Schlüssel verifiziert wurde. Ein valid-untrusted-Urteil setzt es bewusst nicht, sodass ein solcher Datensatz eine echte „dieser Korrespondent signiert, nachprüfbar“-Schranke ist und nicht ein „irgendjemand hat dies signiert“. Platzieren Sie eine Decrypt-Stage vor dieser, sonst trifft der Datensatz nie zu.

    • sealer_domain → passt nur, wenn die Nachricht mit einer ARC-Kette ankam, die validiert hat, und die benannte ADMD unter ihren Siegelnden ist (state.auth.arc = pass und die Domain in state.auth.arc_sealers). Das ist es, was einen list-id-Datensatz sicher macht: List-Id: ist unauthentifizierter Text, den jeder kopieren kann, und eine gültige ARC-Kette vermittelt für sich genommen kein Vertrauen (RFC 8617 §8.4) — erst die Benennung der siegelnden Stelle macht aus dem Paar einen Beleg.

  • Nicht-destruktiv: Bei einem Treffer führt es spam: false zusammen und schaltet zu NEXT_STAGE weiter; bei keinem Treffer schaltet es unverändert weiter. Eine Nachricht ohne From:-Header und eine, auf die kein konfigurierter Whitelist-Name zutrifft, passen auf nichts.

46.3. Konfiguration

[stage-<name>]: PROGRAM = pepsi-stage-check-whitelist, WHITELIST_NAME (erforderlich — die kommagetrennte Liste der whitelist_name-Gruppen, wörtlich oder als Vorlage), NEXT_STAGE (erforderlich — die Stage reicht die Nachricht immer weiter) sowie die gemeinsamen Lokalitätsoptionen LOCAL_DOMAINS (Standardwert [pepsi-ingress] ACCEPTED_DOMAINS), TARGETS und RECIPIENT_DELIMITER, die nur zum Expandieren der Platzhalter verwendet werden. Siehe pepsi-stage-check-whitelist(1).

46.4. State

  • Eingaben: state.auth.dkim / state.auth.arc / state.auth.dmarc (für dkim_required-Datensätze), state.auth.arc_sealers (für sealer_domain-Datensätze) und state.signature_verified (für signature_required-Datensätze; geschrieben von pepsi-stage-decrypt). Der From:-Header stammt aus der from_header-Spalte; List-Id: wird aus dem Header-Block gelesen, weshalb diese Stage die Header lädt (aber nie den Nachrichtentext).

  • Ausgaben: Bei einem Treffer wird spam: false in state zusammengeführt; andernfalls bleibt state unverändert.

46.5. Siehe auch

pepsi-stage-anti-spam, pepsi-stage-arc, Unterstützte Funktionen, pepsi-stage-check-whitelist(1).