• 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.

Input Warden Antispam & Virus Protection Extension for Plesk

Hello @danami ,

concerning the problem mentioned here, maybe the icon for "Warden Anti-Spam and Virus Protection" should not be displayed, if the logged in user has no access rights for it (e.g. "Webmaster" role in this case).

Best regards,
Michael

1632907264325.png
 
Hello @danami ,

it's nice to have the "Greylisting Management" back - as it is normally part of the standard Plesk installation.
We see only one problem: normally we need this feature by default disabled per domain because many clients do not understand when emails arrive "later". So the feature is only used for clients, that receive a lot of spam and that know about the impact, when it is enabled.

Right now in "Warden" we need first to enable it server-wide as per documentation:
"After greylising is enabled server wide you have the option of disabling greylisting per domain"

But then Greylisting is per default enabled for all domains and this is not an option for us. It would be nice - after enabling it server wide - that users can decide weather or not it should be used by an active decision / click.
 
Hello @danami ,
But then Greylisting is per default enabled for all domains and this is not an option for us. It would be nice - after enabling it server wide - that users can decide weather or not it should be used by an active decision / click.
@Hangover2 We fully support disabling greylisting per domain as per our KB article: How can I configure greylisting with Warden Anti-spam and Virus protection? - Knowledgebase - Danami

Also The greylisting feature just uses Plesk's built in implementation and supports the "plesk bin grey_listing" command line interface. You can easily add a Plesk event handler for newly created domains turning greylisting off by default. Example:

Bash:
plesk bin grey_listing --update-domain example.com -status off
 

Attachments

  • 114_2021-10-03_02h17_45.png
    114_2021-10-03_02h17_45.png
    52.8 KB · Views: 8
@Hangover2 Here is the event that you would add if you wanted greylisting turned off for newly created domains (after greylisting is enabled server wide):

In Plesk go to Tools & Settings -> Event Manager -> Add Event Handler

Code:
Event: Default domain (the first domain added to a subscription) created
Priorty: lowest(0)
User: root
Command: /usr/local/psa/bin/grey_listing --update-domain <NEW_DOMAIN_NAME> -status off
 
Hi, can I use it under Ubuntu 22.4?
No not yet. Remember that extension developers get new Plesk releases the same time as everyone else so we've only had access to it for less than a week. There are a number of issues that we've already identified in testing under Ubuntu 22.04 so they will have to be fixed before it's supported.
 
@Achim Drees Support for Ubuntu 22.04 LTS was added. Just be advised that Ubuntu users upgrading from 20.04 to 22.04 are required to run the upgrade script /opt/psa/admin/bin/modules/warden/install.sh after dist-upgrading :)
 
Hello at all Plesk Warden Anti-spam and Virus Protection users,

at the moment we are facing an outgoing spam problem caused by not blocking detected spam messages if mail was sent to an email alias address.

Steps to reproduce:

-> create an email address e.g.: [email protected]
-> create an email alias for the mailbox e.g.: [email protected]
-> switch on mail forwarding to e.g.: [email protected]
-> set spam action for the mailbox to "block" (for testing purpose maybe set spam level to -9)

If an email is sent to "[email protected]" and it is detected as spam all works fine:
-> delivery is rejected (milter-reject) and forwarding is not triggered

BUT if an email is sent to the alias address [email protected] the following happens:
-> message is still detected as SPAM
-> but it is not blocked, it is sent via postfix/pipe to the main address [email protected]
-> an then it is forwarded to the forward email address (outbound spam detected again!)
-> the provider on the other side then step by step blocks us as spammers

I know external forwarding is never a good solution, but we still need it in some cases. And the block solution would be ok for us because we set a low sensitivity. We are just wondering, why the alias email addresses of the mailbox can bypass the block rule that is working fine on the main email address of the mailbox.

Our only work-around right now is to not use alias addresses and create own mailboxes for every alias with a forwarding. But some clients will not understand / accept.

Any help or hint how to reconfigure the mail server to honor the block rule also for aliases is very appreciated. Thanks in advance!
 
With some little changes to Warden's sql_select_policy config parameter aliases will use the policy settings of the main mailboxes associated to them. We are now doing internal tests and when all works fine we will present a patch for all interested ones.
 
Here is the patched policy rule for the problem mentioned:

/etc/amavis/conf.d/99-warden

The application firewall of the forum does not let me post the new sql statement. I did attach it as pdf file.

The original query was just extended in the "where" clause by another "or" condition including a sub query to catch the policy rule of the main email address if an alias address was the recipient. Without this only the domain level fallback is used leading to the problems mentioned.

After the update reload the Content Filter to apply the changes.

Feel free to test it on your own risk. Our logs look good so far, we can avoid a lot of outgoing spam now. Hopefully the patch will find its way into the Warden Anti-spam and Virus Protection mainline.
 

Attachments

  • warden_sql_select_policy.pdf
    13.3 KB · Views: 5
Back
Top