• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Input Warden Antispam & Virus Protection Extension for Plesk

and when I use DQS as plugin (sh)?
If you use the DQS plugin then you could remove zen.spamhaus.org leaving others in place. There are a lot of good DNSBLs like b.barracudacentral.org and spam.spamrats.com that are not related to SpamHaus. Also I generally recommend using DNSBLs because they are rejected at at the lower SMTP level so there is less work for Amavis to do :)
 
@danami

Thanks for your help. Unfortunately, it's taking moderators 12-24 hours to approve my posts, so by the time you get back to the thread, mine are buried half a dozen deep. I'll go ahead and just install Plesk AV for now as we need something right away, but it seems like Warden is certainly more powerful. If this message isn't buried too deep to notice it when you get back, would you mind addressing my two questions above in message #115?

I realize you probably just didn't see them when you replied to posts overnight because the post was either buried, or the post was still invisible as moderators hadn't approved it yet.

Thanks again.
 
1. It mentions that we need an AbusePDB key, and the free key is good for 1000 lookups per day, and 100 prefix lookups per day. That sounds like a lot, but if you think about even 15-20 users, which would be a very small server, that are getting spammed on top of legitimate email, 1000 lookups per day doesn't go very far. What happens once that free account level of 1000 is exceeded?

2. You mentioned DCC is not installed because it is not open source, yet it's recommended that we add that. What is the cost for DCC if it's not open source?

Thanks again for the help.
1. AbuseIPDB is only used when looking up IP addresses though the Warden interface. It isn't used by Amavis directly so you would never go though your daily limit.
2. There is not cost for DCC (The licensing just prohibits packaging it). Here is documentation for how to compile and install DCC:

 
i have a problem with my license with warden antispam.

The software update subscription for this license key is no longer active. You must renew your software update subscription or downgrade to a version that was released before the renewal date expires.

Last checked
2023-01-24
Next due date
2023-03-01

So I have a valid license but can't use it?!
 
@danami My warden was running REALLY slowly. With your pointers earlier in this thread, I diagnosed this down to some (anonymised) log lines saying:

Feb 19 00:40:19 hosting amavis[1744011]: (1744011-01) SA dbg: async: timing: 9.250 X SH:sending.domain.your_DQS_key.zrd.dq.spamhaus.net
Feb 19 00:40:19 hosting amavis[1744011]: (1744011-01) SA dbg: async: timing: 9.251 X SH:sending.server.your_DQS_key.dbl.dq.spamhaus.net
Feb 19 00:40:19 hosting amavis[1744011]: (1744011-01) SA dbg: async: timing: 9.252 X SH:sending.domain.your_DQS_key.dbl.dq.spamhaus.net
Feb 19 00:40:19 hosting amavis[1744011]: (1744011-01) SA dbg: async: timing: 9.254 X SH:sending.server.your_DQS_key.zrd.dq.spamhaus.net
Feb 19 00:40:19 hosting amavis[1744011]: (1744011-01) SA dbg: async: timing: 9.318 X dns:A:SERVER_REVERSE_IP.your_DQS_key.authbl.dq.spamhaus.net
Feb 19 00:40:19 hosting amavis[1744011]: (1744011-01) SA dbg: async: timing: 9.320 X dns:A:ORIGINATOR_REVERSE_IP.your_DQS_key.authbl.dq.spamhaus.net
Feb 19 00:40:19 hosting amavis[1744011]: (1744011-01) SA dbg: async: timing: 9.336 X dns:A:ORIGINATOR_REVERSE_IP.your_DQS_key.zen.dq.spamhaus.net
Feb 19 00:40:19 hosting amavis[1744011]: (1744011-01) SA dbg: async: timing: 9.360 X dns:A:SERVER_REVERSE_IP.your_DQS_key.zen.dq.spamhaus.net

I found the "your_DQS_key" fifty times in /etc/spamassassin/SH.cf

As I understand it, Warden installed SpamAssassin as part of its toolset.

I've updated this file manually to include my DQS key, but I'd like to know:
1) Why Warden wasn't telling me that I needed to enter this key somewhere.
2) How this is supposed to be maintained if SpamAssassin is updated and installs a new SH.cf file, without my DQS key in it.

Thanks in advance for your input on this.
 
@danami My next question is that, from monitoring the logs, it looks like your processes run single-sequentially and that lots of email is delayed waiting for the one thread to process. How do I increase the number of threads so that scanning can happen in parallel?
 
1) Why Warden wasn't telling me that I needed to enter this key somewhere.

We do have an input for filling in the API key under Settings -> Plugin Settings -> SH . I have included a screenshot.

2) How this is supposed to be maintained if SpamAssassin is updated and installs a new SH.cf file, without my DQS key in it.

Warden installs the SH.cf file when you enable the plugin then replaces your_DQS_key when you fill in your API key so it doesn't get overwritten by Spamssassin updates.
 

Attachments

  • 2023-02-19_01h25_53.png
    2023-02-19_01h25_53.png
    175.6 KB · Views: 11
We do have an input for filling in the API key under Settings -> Plugin Settings -> SH . I have included a screenshot.
So it is. Thank you for the pointer. Sorry that I completely missed finding this when configuring warden.
Warden installs the SH.cf file when you enable the plugin then replaces your_DQS_key when you fill in your API key so it doesn't get overwritten by Spamssassin updates.
Excellent. I've configured it now and glad that it'll be maintained.

@danami The email scanning still seems to be running sequentially / single-threaded. Could you point me in the direction of the settings so that our email throughput rate isn't limited by this please?
 
We had the same problem with those forwardings which led to blacklisted mail servers on our side. One solution could be to disable external forwardings at all - there is even an old Plesk extension available for that. In our case this was no option. So we decided to setup an own automatic applied rule: all mailboxes that activate external forwardings will automatically be set to "spam action" = "block" and also very important "spam level" = "1" or "2". With spam levels >=3 we did not have satisfying results. It would be nice to have such an option already in the extension settings. E.g. disable external forwardings at all or do not forward if spam is detected and spam action is move or set a global rule for mailboxes, where external forwardings are activated.
@Hangover2 We do have a feature in the works that handles this use case.

@danami Is there any progress on that feature after 1 year passed by?
 
The new feature does only partly improve the situation for outgoing mails.
The main problem still remains: the rules are applied for both - incoming and outgoing mails - and cannot be defined individually per direction.
On top outgoing mails can only be influenced by the server wide global value.
This leads to several issues, that cannot be addressed by the possible settings currently available.

In our case the default server wide global value for the filter policy is already quite restrictive on different servers:
Spam action: move
Spam level: 1-3
Spam kill level: 7-10

For incoming mails this is a good way to go. The "Spammy"-level is still quite high and clients can check for false positive matchings in their mailboxes.
A lower kill level / default block action is not negotiable with our clients.

For outgoing mails this setting is not strong enough as by design the spam level is lower than for incoming mails with the same content.
On top the kill level is far away from being suitable.
As a result our mail servers are sometimes affected by outgoing spam leading to issues with other mail service providers (beeing blacklisted / low IP rating / [...]).

This is for example the case in the following scenarios:
- email forwarding to external email addresses (work around: enforce a low kill level of e.g. -0.1 or use block action for those email accounts, problem: incoming emails are affected too)
- email accounts get compromised and spam is sent (work around: Turn on limitations on outgoing email messages in Plesk, problem: a lot of detected spammy content is still sent, till the threshold is triggered)
- email accounts are used to send emails from websites with SMTP auth (contact form spam, fake orders, [...]) (no real work around available, detected spammy content just goes through)

For all three scenarios it would help, to have a global or even local possibility to set the block action or spam kill level only for outgoing mails to a much lower value (e.g. -0.1 till 1) while the incoming mail policies are not touched.

Maybe with some tricky sender/receiver SQL logic ($sql_select_policy) amavisd-new could be convinced, to handle such individual policies based on mail direction.

Or maybe do I miss something? How do other Plesk users of this plugin handle the outgoing spam problematic? Thanks in advance for any hint!
 
@Hangover2 I'm curious have you gone though the Warden getting started guide to make sure that Warden is configured properly? Normally you should never need to set the spam level to such a low level. I recommend going though the guide:


I've seen cases where some people are running external firewalls and forget to open the network ports that Warden requires so Warden can't run at it's full potential. I just looked at some servers running Warden and almost all of the spam scores are well above 15 with all of the spammy scores above 8.
 

Attachments

  • 2023-09-18_03h02_48.png
    2023-09-18_03h02_48.png
    327.3 KB · Views: 25
  • 2023-09-18_03h07_34.png
    2023-09-18_03h07_34.png
    360.4 KB · Views: 26
Back
Top