Control Web Panel
WebPanel => E-Mail => Topic started by: Wonder on September 24, 2026, 12:12:47 PM
-
Hello,
I am reviewing and tuning the spam/malware filtering configuration on a production CWP server running AlmaLinux 8.10.
Before describing the two issues I am currently trying to solve, I would like to give some context about the current mail setup, because we have already checked most of the SpamAssassin/Amavis chain.
The current inbound mail flow is:
Postfix → Amavis → SpamAssassin / ClamAV → Postfix reinjection → Dovecot LMTP
Postfix sends incoming SMTP mail to Amavis on:
127.0.0.1:10024
and Amavis reinjects it into Postfix on:
127.0.0.1:10025
We have verified this flow using real incoming messages and Postfix Queue-IDs.
The active Amavis configuration is:
/etc/amavisd/amavisd.conf
The server is currently running:
AlmaLinux 8.10
CWP
Amavis 2.13.1
SpamAssassin 3.4.6
Postfix
Dovecot/LMTP
ClamAV
SpamAssassin is being used through Amavis. An older direct Postfix → SpamAssassin pipe that existed previously is no longer used.
Additional SpamAssassin components
We have also reviewed the additional SpamAssassin components.
Razor2
I found this CWP forum thread:
“Install Razor2 for Postfix/Dovecot Spam Filtering along with SpamAssassin”
and particularly the June 2026 AlmaLinux 8/9 update.
Razor is installed and initialized for the user under which Amavis runs. razor-admin -discover completes successfully and TCP outbound port 2703 is allowed in CSF.
Pyzor
Pyzor 1.1.1 is installed.
The SpamAssassin Pyzor plugin was already enabled. We also found that Pyzor required outbound UDP/24441 on this server, so UDP port 24441 was added to CSF outbound rules.
Running Pyzor as the Amavis user now returns:
public.pyzor.org:24441 (200, 'OK')
Bayes
The Bayes database used by the Amavis account exists under:
/var/spool/amavisd/.spamassassin/
and it is active. The HAM count is increasing with real mail. At the moment the SPAM learned count is still zero, which we are monitoring before changing any autolearn thresholds.
DNSBL / URIBL
We discovered that the server's default DNS resolvers were being blocked specifically by URIBL.
Rather than changing the system DNS configuration, dedicated DNS resolvers were configured only for SpamAssassin using the dns_server directives in local.cf.
We have successfully tested queries against:
URIBL
SURBL
Spamhaus ZEN
Spamhaus DBL
DNSWL
The system DNS configuration itself was left unchanged.
Archive decoders
We also checked the archive/attachment decoders used by Amavis. Missing support for RAR/LZ4/Zstandard/7z was installed and the corresponding Amavis startup warnings disappeared.
ClamAV
Amavis has clamdscan available as its primary ClamAV scanner, with clamscan available as a secondary scanner.
Spam filtering itself is working
The current Amavis SpamAssassin thresholds are:
sa_tag_level_deflt = 2.0
sa_tag2_level_deflt = 5.0
sa_kill_level_deflt = 10.0
Messages scoring above the spam threshold but below the kill threshold are delivered with the expected X-Spam-* headers and ***SPAM*** subject prefix.
Messages reaching the kill threshold are discarded according to the current Amavis configuration.
We also performed a GTUBE test through the normal external SMTP → Postfix → Amavis path. It was correctly identified as spam and Amavis returned:
250 2.7.0 Ok, discarded ... - spam
So the actual SpamAssassin filtering through Amavis is working.
However, I have two Amavis/CWP questions which I have not been able to resolve cleanly.
1. Amavis per-recipient logging / Hits
The normal CWP Amavis configuration currently contains:
$log_level = 0;
$log_recip_templ = undef;
$do_syslog = 1;
$syslog_facility = 'mail';
Normally we do not see Amavis per-message entries such as:
Passed CLEAN ... Hits: ...
in /var/log/maillog.
The Postfix logs clearly show the same messages going to 127.0.0.1:10024, being accepted by Amavis and being reinjected through 127.0.0.1:10025, so Amavis is definitely processing them.
Interestingly, at least one Passed CLEAN {RelayedInbound} ... Hits: ... entry did appear previously in maillog.
For testing, we temporarily removed/commented:
$log_recip_templ = undef;
The installed Amavis source contains the standard default log_recip_templ, including the Passed, Blocked, CLEAN, SPAMMY, SPAM, BANNED, INFECTED, Hits, tag/tag2/kill information, etc.
amavisd -c /etc/amavisd/amavisd.conf test-config completed successfully and Amavis was restarted. We even rebooted the server during testing.
However, the expected per-recipient Passed/Blocked/Hits entries still did not appear in /var/log/maillog.
The temporary test has now been completely reverted and the production configuration is back to:
$log_recip_templ = undef;
Is there any CWP-specific configuration, Amavis packaging change, syslog configuration or additional option required to enable these normal per-recipient Amavis log entries?
2. Administrative notifications for VIRUS / BANNED / UNCHECKED
I have created a dedicated local mailbox:
mailsecurity@skytime.es
I would like Amavis to notify this mailbox only for important security events initially:
VIRUS
BANNED
UNCHECKED
I do not want administrative email notifications for every ordinary spam message or every clean message.
The current CWP Amavis configuration contains:
$virus_admin = undef;
Looking at the installed Amavis 2.13.1 Conf.pm, VIRUS and UNCHECKED appear to use virus_admin_maps, while banned_admin_maps also appears to fall back to the virus administrator configuration.
As a controlled test I tried:
$virus_admin = "mailsecurity\@$mydomain";
but test-config rejected this configuration with:
Can't use string ("skytime.es") as an ARRAY ref while "strict refs" in use at /etc/amavisd/amavisd.conf line 125.
Amavis was not restarted with that invalid configuration. The change was immediately reverted and test-config is successful again.
What is the correct/recommended syntax in the current CWP + Amavis 2.13.1 configuration to send administrator notifications for VIRUS, BANNED and UNCHECKED to this local mailbox, without enabling notifications for normal spam?
I would prefer to use the configuration expected by CWP rather than continue experimenting directly on a production mail server.
Thanks in advance.