Egbert Jan van den Bussche wrote:
-----Oorspronkelijk bericht----- Van: dovecot-bounces+egbert=vandenbussche.nl@dovecot.org [mailto:dovecot-bounces+egbert=vandenbussche.nl@dovecot.org] Namens James Butler Verzonden: vrijdag 17 april 2009 20:58 Aan: Dovecot Mailing List Onderwerp: [Dovecot] For the record: Postfix+Spamassassin+ClamAV+Dovecot
Postfix 2.5.5 SpamAssassin 3.2.5 (under Perl 5.10.0) ClamAV 0.95.1 Dovecot 1.2.rc2
works fine on Fedora 10.
Installed Dovecot and ClamAV from source and everything else using yum.
I'm using the ClamAV plugin for Spamassassin:
http://wiki.apache.org/spamassassin/ClamAVPluginI'm calling Spamassassin with:
/etc/postfix/main.cf: mailbox_command = /usr/bin/spamc -f -e /usr/local/libexec/dovecot/deliver
Postfix hands off to Spamassassin, which processes ALL mail (not just attachments) through the ClamAV plugin before parsing for spam, and then hands the whole mess off to Dovecot for 'deliver' to handle.
How simple is that?
Since ClamAV scanns all mail, it might be too processor-intensive for really large mail systems, but it is working great for our 120+ user system with lots of spam coming in. If you're using Procmail or some other preprocessor that can hand off to a pipe, then you could skip the plugin and pipe messages over a certain size (i.e. >1024) to clamd, instead.
Enjoy!
James
Hi!
Apologies for digging an old thread from the bin. I was wondering how this relates to Amavisd? Should I regard the proposed plugin solution as a 'poor mans' solution when one does not want to install amavis?
Thanks! Egbert Jan (NL)
The plugin setup is required for my solution because of issues between Procmail and Postfix when Postfix is running in a QMail-style Maildir setup, which Procmail seems to have issues with, at least for me. (I couldn't get Procmail to recognize environment variables correctly in my Fedora 10 installation, so I just stopped using it in favor of Dovecot's Sieve.)
Amavisd would *replace* Procmail, similar to what Sieve would do. You would pipe your mail to Amavisd, test messages there, and then send qualified messages to 'deliver' or to another program for further processing/flagging. For example, under Amavisd, you would want to test for messages >1024 bytes (1 MB) and pipe them through your anti-virus app and then from there *back* to Amavisd to check for virus flags (into the bit bucket or 'deliver' to the user's 'Possible Virus' directory) and then on to 'deliver' for normal delivery if there were no flags.
I've never used Amavisd, but this seems to be its purpose. FYI, the above setup is easy to administer and since additional apps are not required, it keeps the overhead down a bit. It could be considered a "poor man's replacement" for Amavisd in that it makes Amavisd irrelevant, AFAIK ... but Amavisd probably does other stuff that I simply haven't found the need for, so I really couldn't tell you.
James