Facebook
Twitter
papahausa
Basic Pleskian
Thanks, Already updated.
Input Warden Antispam & Virus Protection Extension for Plesk
danami
Silver Pleskian
@papahausa These are the only settings that you should be migrating across servers are policy settings, blacklists and whitelists.
Many settings are OS specific so you will break your server trying to migrate anything else unless each server is identical.
Many settings are OS specific so you will break your server trying to migrate anything else unless each server is identical.
Hangover2
Regular Pleskian
Is there any way to improve DCC performance — both server availability and response times — by adjusting certain settings?
Code:
# cdcc rtt
# 11/13/25 07:41:28 CET /var/lib/dcc/map
# Re-resolve names after 09:41:23 Check RTTs after 07:56:27
# 2363.78 ms threshold, 1555.11 ms average 12 total, 2 working servers
IPv6 on version=3
dcc1.dcc-servers.net,- RTT+1000 ms anon
# 2001:470:1f05:10ed::49,-
# not answering
# 2001:470:1f05:10ed::52,-
# not answering
dcc2.dcc-servers.net,- RTT+1000 ms anon
# 2001:628:404:8::63,- wuwien ID 1290
# 67% of 12 requests ok 1263.79+1000 ms RTT 100 ms queue wait
# 2a02:708:0:23::2,-
# not answering
dcc3.dcc-servers.net,- RTT+1000 ms anon
# *2604:bf00:1a0:2::2,- ID 1006
# 67% of 12 requests ok 892.55+1000 ms RTT 500 ms queue wait
# 2a0c:8540:10:1000::1204,-
# not answering
dcc4.dcc-servers.net,- RTT+1000 ms anon
# 2001:470:1f05:10ed::51,-
# not answering
# 2001:5a8:5:3b::5,-
# not answering
dcc5.dcc-servers.net,- RTT+1000 ms anon
# 2001:470:1f05:10ed::53,-
# not answering
# 2001:760:2a12:2::6,-
# not answeringMy stats are a bit better...
It looks like you're using IPv6. I wonder if that has any effect. The DCC webpage might offer some help (Distributed Checksum Clearinghouses).
Hangover2
Regular Pleskian
@Bobbbb Thanks for the suggestion — switching to IPv4 did the trick.
Code:
# 11/13/25 16:34:34 CET /var/lib/dcc/map
# Re-resolve names after 18:33:37 Check RTTs after 16:48:42
# 1256.09 ms threshold, 1232.92 ms average 12 total, 11 working servers
IPv6 off version=3
dcc1.dcc-servers.net,- RTT+1000 ms anon
# *137.208.8.63,- wuwien ID 1290
# 100% of 2 requests ok 155.11+1000 ms RTT 100 ms queue wait
# 184.23.168.46,- sonic ID 1254
# 100% of 2 requests ok 254.79+1000 ms RTT 100 ms queue wait
# 193.30.34.11,- www.nova53.net ID 1204
# 100% of 2 requests ok 156.09+1000 ms RTT 50 ms queue wait
dcc2.dcc-servers.net,- RTT+1000 ms anon
# 193.30.34.14,- www.nova53.net ID 1207
# 100% of 2 requests ok 156.10+1000 ms RTT 50 ms queue wait
# 194.119.212.6,- dcc1 ID 1182
# 100% of 2 requests ok 4000.00+1000 ms RTT 4000 ms queue wait
dcc3.dcc-servers.net,- RTT+1000 ms anon
# 72.18.213.53,- x.dcc-servers ID 104
# 100% of 2 requests ok 233.82+1000 ms RTT 100 ms queue wait
# 208.88.55.138,- ID 1006
# 100% of 2 requests ok 595.24+1000 ms RTT 500 ms queue wait
dcc4.dcc-servers.net,- RTT+1000 ms anon
# 38.124.232.227,- ID 1102
# 100% of 2 requests ok 208.51+1000 ms RTT 100 ms queue wait
# 72.18.213.49,- x.dcc-servers ID 104
# 100% of 2 requests ok 234.90+1000 ms RTT 100 ms queue wait
dcc5.dcc-servers.net,- RTT+1000 ms anon
# 157.131.0.46,- sonic ID 1255
# 100% of 2 requests ok 254.94+1000 ms RTT 100 ms queue wait
# 204.90.71.235,- MGTINTERNET ID 1170
# 100% of 2 requests ok 196.38+1000 ms RTT 100 ms queue waitdanami
Silver Pleskian
@Hangover2 Also make sure that you are running DCC as a service and not just calling the binary. We have instructions here:
docs.danami.com
DCC | Warden Anti-spam and Virus Protection Documentation
Warden Anti-spam and Virus Protection
docs.danami.com
danami
Silver Pleskian
@Hangover2 Warden will detect if DCC is setup as a service and you will see it listed on the Warden dashboard under the services section. It should run way faster then just using the DCC binary.
Attachments
Hangover2
Regular Pleskian
@danami
On our servers, the detailed message log accessed via journald is quite slow. After investigating the issue, we noticed that Warden always scans the entire journald log with commands like the following:
This command always performs a full scan of the complete journald log in order to find results with grep.
In our case, this leads to delays of 30 seconds or more while waiting for the output. The server process also uses a significant amount of resources during that time.
This makes it very difficult to investigate email issues when trying to view the detailed log.
A quick fix would be to restrict the search to a specific time period using the creation timestamp of the message log entry.
For example, if the relevant log entry was created at 2025-11-17 06:35:17, you could search around this timestamp (- 5 minutes till + 1 hour or similar):
With this approach, the log is displayed almost instantly and in a very resource-friendly way.
At the moment, the feature is not really usable on servers with more than 1 GB of mail log stored in journald.
Thank you in advance for considering a fix in a future version!
On our servers, the detailed message log accessed via journald is quite slow. After investigating the issue, we noticed that Warden always scans the entire journald log with commands like the following:
Bash:
/usr/bin/journalctl --no-pager --quiet --unit=pc-remote --unit=dovecot_authdb_plesk --unit=amavisd-milter --unit=postfix@- --unit=amavis --output=short --lines=180000 --grep='\<[email protected]\>|5E26468936F2|[email protected]'This command always performs a full scan of the complete journald log in order to find results with grep.
In our case, this leads to delays of 30 seconds or more while waiting for the output. The server process also uses a significant amount of resources during that time.
This makes it very difficult to investigate email issues when trying to view the detailed log.
A quick fix would be to restrict the search to a specific time period using the creation timestamp of the message log entry.
For example, if the relevant log entry was created at 2025-11-17 06:35:17, you could search around this timestamp (- 5 minutes till + 1 hour or similar):
Bash:
/usr/bin/journalctl --since "2025-11-17 06:30:17" --until "2025-11-17 07:35:17" --no-pager --quiet --unit=pc-remote --unit=dovecot_authdb_plesk --unit=amavisd-milter --unit=postfix@- --unit=amavis --output=short --lines=180000 --grep='\<[email protected]\>|5E26468936F2|[email protected]'With this approach, the log is displayed almost instantly and in a very resource-friendly way.
At the moment, the feature is not really usable on servers with more than 1 GB of mail log stored in journald.
Thank you in advance for considering a fix in a future version!
danami
Silver Pleskian
@Hangover2 Yes we've optimized the journald log parser in the next version of Warden so log lookups are almost instant now reguardless of journald size 
danami
Silver Pleskian
We have released Warden 5.05 which adds Debian 13 support, log parser optimizations, bug fixes, and more:
Hangover2
Regular Pleskian
@danami
We just tested the new
A typical lookup now takes approximately 6 seconds (we have around 4 GB of log data per day). This is still acceptable, but currently our servers are handling only about 100 clients per server. Larger systems with 1k+ clients and a more extensive logging configuration will certainly be impacted much more.
Maybe in the future a smaller request window should be considered.
We just tested the new
journald optimization. On our servers it is still quite slow, as it still needs to scan a full day of logs:
Bash:
/usr/bin/journalctl --no-pager --quiet --unit='pc-remote' --unit='dovecot_authdb_plesk' --unit='amavisd-milter' --unit='postfix@-' --unit='amavis' --output='short' --lines='30000' --since='2025-12-07 06:19:46' --until='2025-12-08 06:20:16' --grep='\<[email protected]\>'A typical lookup now takes approximately 6 seconds (we have around 4 GB of log data per day). This is still acceptable, but currently our servers are handling only about 100 clients per server. Larger systems with 1k+ clients and a more extensive logging configuration will certainly be impacted much more.
Maybe in the future a smaller request window should be considered.
danami
Silver Pleskian
@Hangover2 I recommend that you open a ticket in our client area and if you can provide us access to a server then I can see if I can optimize things further for you. Things are really going to be server hardware and configuration dependent.
Hangover2
Regular Pleskian
@danami
Thank you for your answer. I think there is not much we can optimize as long as we are still querying a full day of the
I did some testing to demonstrate the differences:
Our
Thank you for your answer. I think there is not much we can optimize as long as we are still querying a full day of the
journald log. Searching with --grep is an expensive operation, and on top of that the log files need to be read from disk first.I did some testing to demonstrate the differences:
Bash:
# initial request (files are not cached / buffered yet)
time /usr/bin/journalctl --no-pager --quiet --unit='pc-remote' --unit='dovecot_authdb_plesk' --unit='amavisd-milter' --unit='postfix@-' --unit='amavis' --output='short' --lines='30000' --since='2025-12-07 06:19:46' --until='2025-12-08 06:20:16' --grep='\<[email protected]\>'
real 0m11.604s
user 0m1.353s
sys 0m4.006s
Bash:
# same request again with file caching
time /usr/bin/journalctl --no-pager --quiet --unit='pc-remote' --unit='dovecot_authdb_plesk' --unit='amavisd-milter' --unit='postfix@-' --unit='amavis' --output='short' --lines='30000' --since='2025-12-07 06:19:46' --until='2025-12-08 06:20:16' --grep='\<[email protected]\>'
real 0m4.354s
user 0m1.338s
sys 0m2.979
s
Bash:
# reduced time window to check from 1 day to 3 hours
time /usr/bin/journalctl --no-pager --quiet --unit='pc-remote' --unit='dovecot_authdb_plesk' --unit='amavisd-milter' --unit='postfix@-' --unit='amavis' --output='short' --lines='30000' --since='2025-12-07 06:19:46' --until='2025-12-07 09:20:16' --grep='\<[email protected]\>'
real 0m1.042s
user 0m0.172s
sys 0m0.870sOur
journald config for reference:
Code:
[Journal]
Storage=persistent
SystemMaxUse=32768M
SystemMaxFileSize=512M
SystemMaxFiles=8192
RuntimeMaxFiles=1024
MaxRetentionSec=30ddanami
Silver Pleskian
@Hangover2 Thanks for providing your systemd-journal configuration. I have some additional ideas I we can do for the next release of Warden to optimize things even further.
