Input Warden Antispam & Virus Protection Extension for Plesk

Hi. I cant restore settings on a new server.

TypeError [ 0 ]: File::write(): Argument #1 ($filename) must be of type string, null given, called in /opt/psa/admin/plib/modules/warden/library/modules/common/classes/Model/Settings/File.php on line 155


1762478833282.png
 
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 answering
 
Hangover2 said:
Is there any way to improve DCC performance — both server availability and response times — by adjusting certain settings?
Click to expand...

My stats are a bit better...

$ cdcc rtt
# 11/13/25 08:55:04 EST /var/lib/dcc/map
# Re-resolve names after 10:55:00 Check RTTs after 09:10:04
# 1237.05 ms threshold, 1222.19 ms average 12 total, 10 working servers
IPv6 on version=3

dcc1.dcc-servers.net,- RTT+1000 ms anon
# 38.124.232.227,- ID 1102
# 91% of 32 requests ok 210.16+1000 ms RTT 100 ms queue wait
# 72.18.213.49,- x.dcc-servers ID 104
# 100% of 32 requests ok 757.37+1000 ms RTT 700 ms queue wait
# 184.23.168.46,- sonic ID 1254
# 91% of 32 requests ok 333.59+1000 ms RTT 100 ms queue wait

dcc2.dcc-servers.net,- RTT+1000 ms anon
# 193.30.34.13,- www.nova53.net ID 1206
# 88% of 32 requests ok 137.05+1000 ms RTT 50 ms queue wait
# 194.119.212.6,- dcc1 ID 1182
# 100% of 32 requests ok 817.15+1000 ms RTT 300 ms queue wait

dcc3.dcc-servers.net,- RTT+1000 ms anon
# 69.89.207.193,-
# not answering
# 208.88.55.138,- ID 1006
# 100% of 32 requests ok 725.54+1000 ms RTT 700 ms queue wait

dcc4.dcc-servers.net,- RTT+1000 ms anon
# 72.18.213.52,- x.dcc-servers ID 104
# 100% of 32 requests ok 755.75+1000 ms RTT 700 ms queue wait
# *193.30.34.11,- www.nova53.net ID 1204
# 100% of 32 requests ok 93.06+1000 ms RTT 50 ms queue wait

dcc5.dcc-servers.net,- RTT+1000 ms anon
# 192.84.137.21,- INFN-TO ID 1233
# 94% of 32 requests ok 408.54+1000 ms RTT 100 ms queue wait
# 204.90.71.235,- MGTINTERNET ID 1170
# 100% of 32 requests ok 526.46+1000 ms RTT 500 ms queue wait
Click to expand...

It looks like you're using IPv6. I wonder if that has any effect. The DCC webpage might offer some help (Distributed Checksum Clearinghouses).
 
@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 wait
 
@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

  • 2025-11-14_00h03_20.png
    2025-11-14_00h03_20.png
    269.4 KB · Views: 5
@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:

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.

1763358000319.png

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!
 
You must log in or register to reply here.

Similar threads

T
Question E-mail anti spam suggestion (incoming/outgoing)
Replies
2
Views
3K
T2121
T
mschenk
Question Warden Anti-spam and Virus Protection - license question
Replies
4
Views
3K
mschenk
mschenk
Jürgen_T
Question Migration from Plesk Email Security (Amavis, SpamAssassin 3.x) to Rspamd 3.12 – Experiences?
Replies
9
Views
5K
Jürgen_T
Jürgen_T
K
Issue Message is regarded as spam (but isn't spam) and then the spam report is regarded as spam
Replies
3
Views
4K
Kaspar
K
andreios
Question How to remove viruses with Clamav via Spamassassin
2
Replies
38
Views
16K
andreios
andreios
Back
Top