Rspamd führt Greylisting trotz greylist = null in ISPConfig-Policy aus

[fw114]

Hallo zusammen,

ich habe aktuell das Problem, dass Rspamd eingehende E-Mails greylistet, obwohl Greylisting für das betreffende Postfach in der von ISPConfig erzeugten Rspamd-Konfiguration deaktiviert ist.

System:

Debian 13
ISPConfig 3.3.2
Rspamd 4.2.1 aus dem offiziellen Rspamd-Repository

Betroffen ist beispielsweise:

User@domain.de

ISPConfig erzeugt dafür:

ispc_spamfilter_user_34 {
priority = 27;
rcpt = "User@domain.de";

apply {
CLAM_VIRUS = 1010;
JUST_EICAR = 1010;
actions {
"rewrite subject" = 6;
"add header" = null;
reject = 10;
greylist = null;
}
}
}

Ich habe geprüft, ob Rspamd diese Einstellung tatsächlich lädt.

rspamadm configdump settings zeigt ebenfalls:

ispc_spamfilter_user_34 {
priority = 27;
rcpt = "User@domain.de";
apply {
CLAM_VIRUS = 1010;
JUST_EICAR = 1010;
actions {
"rewrite subject" = 6;
"add header" = null;
reject = 10;
greylist = null;
}
}
}

Im Log wird bei der betreffenden E-Mail ebenfalls genau diese Policy ausgewiesen:

settings_id: ispc_spamfilter_user_34

Trotzdem wurde eine legitime Microsoft-Mail beim ersten Zustellversuch von Rspamd temporär abgewiesen:

set pre-result to 'soft reject' (no score): 'Try again later' from greylist(0)

und:

GREYLIST(0.00){greylisted;...;new record;}

Postfix antwortete entsprechend mit:

4.7.1 Try again later

Microsoft hat die Nachricht später erneut zugestellt. Beim zweiten Versuch erschien:

greylist.lua:483: greylisting pass (body)

sowie:

GREYLIST(0.00){pass;body;}

Danach wurde die Nachricht angenommen.

Es handelt sich also tatsächlich um Greylisting mit Soft-Reject und anschließendem erfolgreichen Retry und nicht nur um die Anzeige eines GREYLIST-Symbols.

Ein ispconfig_update.sh --force wurde bereits durchgeführt. Dabei wurden die Dienste einschließlich Rspamd von ISPConfig neu konfiguriert. Das Verhalten bzw. die erzeugte Policy blieb unverändert.

#7006 / MR !2120 habe ich ebenfalls überprüft. Die Migration scheint auf dem Server korrekt durchgeführt worden zu sein.

Die Datei /etc/rspamd/local.d/settings.conf ist vorhanden und enthält:

authenticated {
priority = 10;
authenticated = yes;
apply "default" {
symbols_disabled = [];
groups_disabled = ["rbl", "spf"];
}
}

whitelist {
priority = 5;
rcpt = "postmaster";
rcpt = "hostmaster";
rcpt = "abuse";
want_spam = yes;
}

.include(try=true; glob=true) "$LOCAL_CONFDIR/local.d/users/*.conf"
.include(try=true; priority=1,duplicate=merge) "$LOCAL_CONFDIR/local.d/users.local.conf"

Die alte Datei /etc/rspamd/local.d/users.conf existiert nicht mehr. Vorhanden ist lediglich /etc/rspamd/local.d/users.conf.old.

Auch /etc/rspamd/rspamd.conf enthält nicht mehr:

.include "$LOCAL_CONFDIR/local.d/users.conf"

Diese Zeile findet sich lediglich noch in der nicht aktiven /etc/rspamd/rspamd.conf.dpkg-old.

Der in dem Thread "ISPConfig 3.3.2 update breaks Rspamd 4.2.0 from official repository" beschriebene Fehler scheint hier daher nicht vorzuliegen.

Die globalen Actions von Rspamd sind:

reject = 15;
add_header = 6;
greylist = 4;

Meine Frage wäre daher:

Sollte das von ISPConfig für das Postfach gesetzte

greylist = null;

das Rspamd-Greylisting für dieses Postfach vollständig deaktivieren?

Falls ja: Was könnte noch dazu führen, dass greylist.lua trotzdem einen Soft-Reject

 

[Till]

Nein, greylist = null; deaktiviert das Greylisting für dieses Postfach nicht vollständig. Es deaktiviert nur die Rspamd-Action "greylist", also den Score-Bereich zwischen dem greylist-Schwellwert (bei dir 4) und dem add_header/rewrite_subject-Schwellwert (bei dir 6). Das Greylisting-Modul (GREYLIST_CHECK / GREYLIST_SAVE) läuft weiterhin.

Das Modul greylistet nämlich nicht nur, wenn die Action "greylist" ist. In greylist.lua wird eine Mail ohne bestehenden Redis-Eintrag ("new record") nur dann nicht greygelistet, wenn die Action "no action" oder "reject" ist. Bei jeder anderen Action, also auch "add header" oder "rewrite subject", wird eine Mail von einem bislang unbekannten Absender beim ersten Zustellversuch mit "Try again later" temporär abgewiesen. Das ist so gewollt: Rspamd verzögert Mails, die als spamverdächtig eingestuft wurden, wenn der Absender noch unbekannt ist.

In deinem Fall heißt das: Die Microsoft-Mail hat beim ersten Zustellversuch einen Score von mindestens 6 erreicht und damit die Action "rewrite subject" bekommen. Wäre der Score unter 4 gewesen, hätte Rspamd "Score too low - skip greylisting" geloggt. Bei einem Score zwischen 4 und 6 wäre die Action wegen greylist = null "no action" gewesen und die Mail wäre durchgegangen. Der Eintrag in der von ISPConfig erzeugten Konfiguration entspricht dem, was die Rspamd-Dokumentation für das Deaktivieren der greylist-Action vorsieht, und er wird laut deinem Log auch korrekt angewendet.

Wenn du das Greylisting für ein Postfach komplett abschalten willst, müssen laut Rspamd-Dokumentation die Symbole des Moduls deaktiviert werden. Dafür kannst du in /etc/rspamd/local.d/users.local.conf einen Eintrag mit höherer Priorität als der von ISPConfig erzeugte anlegen:

no_greylist_user {
priority = 30;
rcpt = "User@domain.de";
apply {
symbols_disabled = ["GREYLIST_CHECK", "GREYLIST_SAVE"];
}
}
Alternativ kannst du das Verhalten global in /etc/rspamd/local.d/greylist.conf anpassen, z. B. mit greylist_min_score oder whitelist_symbols.

Wir werden uns ansehen, ob ISPConfig bei deaktiviertem Greylisting zusätzlich die beiden Symbole deaktivieren sollte.

Noch ein Hinweis am Rande: Deine Datei enthält "add header" = null; und "rewrite subject" = 6;. ISPConfig 3.3.2 schreibt seit dem Fix für #6979 immer "add header" = 6;. Die Dateien unter /etc/rspamd/local.d/users/ wurden also noch von einer älteren Version erzeugt und beim Update nicht neu geschrieben, da ispconfig_update.sh die Benutzereinstellungen nicht neu generiert. Das hat mit dem Greylisting nichts zu tun, du kannst die Dateien aber über Tools > Resync (Mailboxen bzw. Spamfilter) neu erzeugen lassen.

 

[fw114]

Das war es: Tools > Resync

Danke