[Dovecot] Running spamc during LMTP delivery

[martin f krafft]

also sprach martin f krafft <madduck at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1124 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: <http://dovecot.org/pipermail/dovecot/attachments/20120812/5f92a3cb/attachment-0004.bin>