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
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