i've modified spamassassin to what i consider a more secure setup,
the summary is as follows:

- by default spamd accepts whatever username is presented on its
  socket ... there is the option of using identd to "verify" the identity,
  but i think that's a gross hack.  my less gross hack is to use a unix
  domain socket in a group-protected directory, and a setgid spamc so
  that the only way to get at the socket is to be root or use spamc.

- by default spamd spawns long-lived children which do *not* drop root privs
  while servicing requests.  they setuid to a user, but retain root setuid
  privs and become root at the end of every request.  this is lame -- a spamd
  weakness could compromise root.  there's no serious perf benefit to having
  long-lived children, so i limit my children to one request each and have
  patched spamd to drop privs entirely.

my .debs are available at <http://arctic.org/~dean/debian/>

the individual patches are at <http://arctic.org/~dean/patches/>

here are more detailed instructions on setting things up (using the .debs):

- create a group spamc

- issue these commands:

	dpkg-statoverride --update --add root spamc 2551 /usr/bin/spamc
	mkdir /var/run/spamd
	chgrp spamc /var/run/spamd
	chmod 750 /var/run/spamd

- modify /etc/default/spamassassin as follows:
	ENABLED=1
	OPTIONS="--create-prefs --max-children 10 --max-conn-per-child=1 --user-config --socketpath /var/run/spamd/sock"
	NICE="--nicelevel 4"

- you probably also need to add "allow_user_rules 1" to
  /etc/spamassassin/local.cf

then your users can use "| /usr/bin/spamc" and it will default to
connecting to the daemon via /var/run/spamd/sock.

the spamc -u option is restricted to root only -- so with this
setgid spamc configuration and the protected socket we know that
the user invoking spamc is the user reported to spamd.

spamd --max-conn-per-child=1 is important not only for the security
reason listed above, but also there's a bug in SA 3.0.1 which causes
some user config to bleed across requests in spamd.

-dean