also sprach martin f krafft madduck@madduck.net [2012.08.09.1423 +0200]:
and then put the following sieve script into /etc/dovecot/sieve.before.d/spamassassin.sieve:
require [ "vnd.dovecot.filter" ]; filter "spamc" [ "--no-safe-fallback" ];
and then ran
sievec spamassassin.sieve && chmod 444 spamassassin.svbin
To tell the LDA where to find the spamc filter, I added (to 90-sieve.conf):
sieve_filter_bin_dir = /etc/dovecot/sieve-filter
and symlinked spamc there
ln -s /usr/bin/spamc /etc/dovecot/sieve-filter/spamc
Btw, this won't work reliably. The reason is that vnd.dovecot.filter currently requires the filter executable to soak up all of the input before it even bothers reading its output. Under certain conditions, however — for instance when the input is larger than the SpamAssassin max_size setting, spamc just pipes input to output, without buffering. This would yield a deadlock because vnd.dovecot.filter would not be reading output yet but still be writing input, whereas spamc would no longer be willing to handle input while its output was not being read.
Stephan Bosch has indicated a solution to this problem (asynchronous IO), but until that's in place, I simply put the following shell script in place:
-----8<----8<----8<----- #!/bin/sh set -eu
TMPFILE=$(tempfile -p spamc) cleanup() { rm -f $TMPFILE; trap - EXIT; } trap cleanup EXIT
cat > $TMPFILE spamc -x < $TMPFILE
cleanup -----8<----8<----8<-----
This is ugly because Dovecot itself may already have spooled the mail message to disk (if it was too large for in-memory buffering), and now we're spooling it a second time. Asynchronous IO will alleviate this need for the second roundtrip via the filesystem.
Hope this helps,
--
.''. martin f. krafft <madduck@d.o> Related projects: : :' : proud Debian developer http://debiansystem.info . ' http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems