Input Warden Antispam & Virus Protection Extension for Plesk

[Hangover2]

@danami

Since the latest release we cannot set our own individual "Spam level" and "Spam kill level" anymore. Only the default values from the dropdowns can be chosen.

Please revert this change and make the input fields editable again. Right now we can only make our own settings by editing directly the policy table of the danami database. Thanks in advance!

 

[danami]

@Hangover2 What spam level do you need to set that isn't included in the provided select lists? This was removed because there were too many people setting improper values.

 

[Hangover2]

@danami Our clients like to set their own spam levels. Here are the values for one of our smaller servers with 150 mailboxes:

SELECT DISTINCT(`spam_tag2_level`) FROM `policy`;

1
null
-0.1
7.5
2
3
0.9
-2
0
5
-1
2.5
3.5
5.5

We got already the first support tickets asking why this feature is not available anymore.

 

[danami]

@Hangover2 Unfortunately we aren't going to add that back. It's better to guide the inexperienced user. A bunch of those values you provided are basically invalid proving my point.

 

[Hangover2]

@danami Then please integrate a setting to make this feature accessible again if the server admin wants so.

We have a lot of users that are using spam levels of 1 or 2 for their mailboxes and they need this values because they are under high loads of incoming spam. Our servers are configured completely as your documentation says. The lowest spam level we can choose right now is 3. That will not work out for some of our clients.

Now we have a lot of extra work to apply lower values by direct database manipulation after support requests. This is a big step backwards for the extension.

We hope you reconsider this new regression by:

a) adding an option to activate manual input for experienced users (our favorit)
b) revert the change
c) give more options in the dropdown (0 / 0.5 / 1 / 1.5 / 2 / 2.5 / 3 / and so on)

The lower values of 0 or -0.1 we enforce on mailboxes with external forwardings to avoid any kind of spam forwardings and the possibility to get blacklisted.

As you can see there are use cases for these values and for sure we are not the only clients that rely on this lost option.

 

[danami]

The lower values of 0 or -0.1 we enforce on mailboxes with external forwardings to avoid any kind of spam forwardings and the possibility to get blacklisted.

@Hangover2 Why don't you just enable the spam kill level and reject the email before it gets redirected?

How can I enable the policy spam kill level in order to reject mail over a certain score? - Knowledgebase - Danami

 

[Hangover2]

@Hangover2 Why don't you just enable the spam kill level and reject the email before it gets redirected?

How can I enable the policy spam kill level in order to reject mail over a certain score? - Knowledgebase - Danami

This is what we are doing already. But since the latest update, the lowest value in the dropdown we can set is 3 for a mailbox in block mode. That is not enough. So how can I now set a spam level of 0 or 1 or -0.1 for a specific mailbox with spam action = "block"?

 

[danami]

I think you have something else going on here. Why are all your spam scores so low (maybe your bayes is poisoned)? Is this spam originating from the server itself? Your spam scores should be much higher. With a spam level of 1 how is any legitimate email supposed to go though?

I recommend that you enable verbose mode in Amavis so that you log what rules are applying negative scoring.

How can I enable verbose mode in Amavis to see what SpamAssassin rules were matched by a message? - Knowledgebase - Danami

If you open a support ticket I can provide you with a hotfix for you which will add spam level scoring for 1 or 2.

 

[Bobbbb]

Quick thought... I'd love for the Warden ASN plugin to be able to use the Spamhaus ASN-DROP list of "bad" ASNs. Either by copy and pasting the text of the JSON file they provide, or grabbing it from the site directly. Then maybe updating it every several months. Or maybe there is another source of spammy ASNs that could be used.

 

[danami]

@Bobbbb sorry that really wouldn't be effective against blocking spam. The bulk of spam isn't sent from the ASNs on this list. We already support the SpamHaus SH plugin which does a much better job than this could.

 

[danami]

Warden Anti-spam and Virus Protection 4.04 has been released:

Announcements - Danami

This release adds Ubuntu 24.04 LTS support (which uses SpamAssasin 4.0) and the ability to manage banned files at the policy level!

 

[danami]

Warden Anti-spam and Virus Protection 4.05 has been released:

Announcements - Danami

This release adds Distributed Checksum Clearinghouses interface daemon support, Spamhaus DQS hash blocklist support, new POP3/IMAP and SMTP Auth success/failure reports, and more!

 

[Hangover2]

Is there any plan to implement a solution to block outgoing spammy emails? Please see my post about the issue in 2023.

 

[danami]

Is there any plan to implement a solution to block outgoing spammy emails? Please see my post about the issue in 2023.

Warden will already reject outgoing mail marked as spam with the spam kill level enabled (the default now). We have no plans to reject "spammy" mail because with Amavis "spammy" mail is mail that it "thinks" might be spam but isn't sure (You could always just lower the spam kill level). This would likely cause too much trouble for the bulk of users as with spammy mail as it would have a high false positive rate. Most of the time admins will get much better results by getting to the source of the spam (compromised email accounts or web forms on the server that are abused). Installing modsecurity with a good ruleset can stop that.

How can I use Warden to monitor outgoing mail so that my server does not get listed on any DNSBLs?

How can I use Warden to monitor outgoing mail so that my server does not get listed on any DNSBLs? - Knowledgebase - Danami

 

[danami]

@Hangover2 I also recommend that you use new the SMTP auth reports that were just added in the latest release. We've seen a lot of mail accounts that are compromised and the end user doesn't even know it. They usually only send a few emails then rotate IP addresses to try and get around Plesk email limits. The SMTP Auth - Success - User Client Addr report is good as you can see every IP address and network that has authenticated to a specific mail account.

 

[danami]

@Hangover2 I think that I have a solution for your redirect spam problem. I'm just going to test it out over the weekend then do up a KB article for you so that others who have this problem can implement it.

 

[Hangover2]

Warden will already reject outgoing mail marked as spam with the spam kill level enabled (the default now).

We overlooked this nice change. The spam kill level should be sufficient. Now we can more easily secure and block spam from, for example, SMTP email-sending mailboxes used for websites.

 

[Hangover2]

This time, I need the support of the users of the "Warden Antispam & Virus Protection Extension for Plesk."

We are currently experiencing a bug that affects our clients when using individual spam levels or spam kill levels that are not part of the dropdown in the extension. We have already submitted a bug report, but the issue has been given a very low priority, as it seems not many users are affected. To raise awareness of the issue, I would like to ask the community to check if the mailboxes of their users might also be affected.

Example steps to reproduce:

- On the server or domain level, set the default as:
Spam action = Move
Receive spam = No
Spam level = 3.5
Spam kill level = 9.5
- Now create a new mailbox and go to the spam filter:
Choose the new spam action = Block and click "Update."

As you can see at that moment, the 3.5 is still visible as the default value in the field. However, when you update, it will not be saved for the mailbox in the database table, nor will the spam kill level be set to the new value.

As a result, the mailbox will not block emails with a spam score of 3.5. It will fall back to the domain/server spam kill level of 9.5. Only if you manually re-enter the 3.5 into the field, the settings will update correctly.

Our clients have complained about this issue, so we now have a check-and-repair script in place that can detect and update affected mailboxes or domains.

You can easily check if your server is affected by this bug by executing the following command in the `danami_warden` database:

SELECT * FROM `policy` WHERE `spam_action` IS NOT NULL AND (`spam_tag2_level` IS NULL OR `spam_kill_level` IS NULL);

If the result is empty, all is fine. If not, you need to take action.

For us this feature is very important, because individual values allow us, to make the needed finetuning per case or customer on server, domain or mailbox level.

Thanks in advance for any responses from other affected users!

 

[danami]

@Hangover2 I think the best fix for this is to just remove the ability to set custom spam levels outside of the select lists like we originally had. Because spam policies are hierarchical it becomes difficult to program every edge case once users start entering in their own custom values.

 

[Hangover2]

As custom values are extremely important to us, we can live with the bug and will create our own workaround.