You already have a fully functioning mail server that even tags spam. But so far you left the actual task of sorting out the tagged spam to the user. We can do better by setting up server-side filters. The task ahead is to move all spam emails to a user's "Spam" folder. We are using the Sieve feature of Dovecot which is a mail filter like procmail (which does not work for virtual mailboxes). Sieve has a simple scripting language that allows us to forward all emails that are tagged by SpamAssassin to a "Spam" folder automatically. At the end of the /etc/dovecot/dovecot.conf file you will find a "plugin" section. Within there you can define a "sieve_global_path" which points to a default filter file that takes effect if the recipient user hasn't defined any per-user filtering rules.
By the way the term "server-side filtering" means that the rules are executed on the server automatically. As opposed to "client-side filtering" which is configured in the mail program on the user's computer. Apparently server-side filtering is preferred as it happens even if the user is offline. And it gives you interesting options such as a vacation autoresponder or filtering based on header fields.
A basic recipe will do the "Spam" sorting. Create a /var/vmail/globalsieverc file containing these lines:
require ["fileinto"];
# Move spam to spam folder
if header :contains "X-Spam-Flag" ["YES"] {
fileinto "spam";
stop;
}
Make sure that the globalsieverc file is readable by the vmail user:
$> chown vmail /var/vmail/globalsieverc
Define this file as a global filtering file within the "plugin { }" section of your /etc/dovecot/dovecot.conf file:
sieve_global_path = /var/vmail/globalsieverc
and restart Dovecot:
$> /etc/init.d/dovecot restart
Send John another spam email:$> sendmail john@example.com < /usr/share/doc/spamassassin/examples/sample-spam.txt
Then watch the /var/vmail/dovecot-deliver.log file. The last line should look like:
deliver(john@example.com): 2009-07-01 01:00:22 Info: msgid=<GTUBE1.1010101@example.net>: saved mail to spam
This says that the email was saved into the "spam" folder. If you fetch email you should see the email show up in that folder automatically.
Note that different folders only work when IMAP is used to fetch emails. POP3 doesn't have a notion of folders and will only show emails in the inbox. And the user will have to subscribe to the "Spam" folder manually. Alternatively you can add "spam" to the "/var/vmail/example.com/john/Maildir/subscriptions" file which contains a list of folders that John wants to see in his mail program.We were talking about per-user filter scripts. How does a user manage such a script? This is done by a low-level interface called "managesieve". Previously additional software like "pysieved" was needed to offer "managesieve". In Lenny's Dovecot this is already supported out of the box.
To enable it you'll have to add "managesieve" to the "protocols" line in your /etc/dovecot/dovecot.conf file. In its "protocol managesieve" section the line "sieve=~/.dovecot.sieve" should already be set. This means that a user's sieve filtering script will be stored in his virtual "home directory". John's sieve script would end up in "/var/mail/example.com/john/.dovecot.sieve".
Your users probably don't want to learn the sieve filtering language. So they need a comfortable way to administer their filtering rules. This can be accomplished by the "avelsieve" plugin to the "squirrelmail" web mail software. It's assumed that you have set up squirrelmail as decribed in its chapter. Install the "avelsieve" plugin:
$> aptitude install avelsieve
Fortunately that's all that needs to be done. If you login via squirrelmail you will see a new link at the top called "Filters". Click on it. You can now add rules of all kinds.
Note that avelsieve in Debian Lenny currently has a bug (Debian #516198 , Avelsieve #247) that can make existing rules disappear when using Dovecot and TLS. I have prepared a patched avelsieve Debian package that you can install with "dpkg -i" if you encounter the same problem.