知識庫

Overview

This article provides resolution steps for scenarios where email messages are correctly identified as spam but fail to relocate to the user's designated Spam folder, despite the applicable policy being configured to do so.

Prerequisites

• Administrative access to the mail server and command-line interface (CLI).
• Familiarity with hierarchical content filter policies in Warden.

Troubleshooting Steps

1. Verify Policy Spam Action Configuration
   Confirm that the spam action is explicitly set to **move**. Note that spam policies operate hierarchically; child policies configured at the mailbox or domain level will override default server-level settings. For detailed information on policy hierarchy, refer to How do hierarchical content filter policies work in Warden?.
2. Restart the Dovecot Service
   The Dovecot service handles the relocation of spam messages to the Spam folder. If policy configurations are correct, restart the service to apply changes and resolve potential synchronization issues:

   systemctl restart dovecot

3. Remove Conflicting Plesk Email Security Sieve Filters
   Legacy sieve filters from Plesk Email Security may interfere with Warden's native filtering rules. Identify and remove these conflicting files using the following commands:

   To locate existing Plesk Email Security sieve filters:

   find /var/qmail/mailnames -name ".dovecot.sieve" -type f -exec grep -H "Plesk Email Security" {} \; 

   To delete the identified filters:

   find /var/qmail/mailnames -name ".dovecot.sieve" -type f -exec grep -H "Plesk Email Security" {} \; -delete

Common Issues & Notes

• Ensure the target Spam folder exists in the user's mailbox before applying sieve rules.
• If issues persist after completing these steps, review Dovecot error logs and mail queue status for additional diagnostic information.