CentOS 4.3 with DSPAM + dspam.cgi

What a nightmare. My longtime mail server lost power at the colo facility about a month ago and when it came back up, it only recognized one processor. It’s been bloody slow since so this weekend I went in with an extra gig of ram and two servers worth of spare parts to fix the hardware issues and upgrade the operating system from Redhat 7.2 to CentOS 4.3.

I also wanted to bring the mail server up to date which includes Qmail, Vpopmail, QmailAdmin and Dspam. I mostly followed Bill Shupp’s toaster because he doesn’t use simscan/SpamAssassin like the QmailToaster project. DSPAM would be doing the job of SpamAssassin.

Here are my assumptions about the install environment:

• You have already installed Dspam/Vpopmail/etc following someone elses instructions
• Using built-in Apache 2.0.x
• SELinux is in permissive or disabled state

What you will need to suck up and just do, despite wanting to try other methods (I tried most of them, and failed, coming back to these):

• Use SuExec
• Place the dspam.cgi under /var/www

I’ve never used suexec before because it scares me and I like to keep all of my web files under /web because I’m a neat freak. I tried to fight these two realities and lost. Here are the problems with the toaster/common install methods on the web and a default install of CentOS:

• Suexec as delivered with CentOS will only process files under /var/www and with uid/gids greater than 500
• Most vpopmail install instructions call for uid/gid 89
• dspam.cgi must be modified to make false-positive deliveries from the quarantine work properly
• You need to place the css and dspam logo somewhere that the .cgi can reference them to avoid breaking the UI

If you followed someone’s vpopmail install instructions and used uid/gid 89, y ou will need to make some adjustments. The changes aren’t bad:

1. Create directory /var/www/dspam
2. Copy all files from dspam/webui/htdocs and dspam/webui/cgi-bin into /var/www/dspam
3. Fix ownership: chown -R vpopmail:vchkpw /var/www/dspam
4. Modify /var/www/dspam/configure.pl from $CONFIG{'DSPAM_ARGS'} = "--deliver=innocent --class=innocent --source=error --user %CURRENT_USER% -d %u" to $CONFIG{'DSPAM_ARGS'} = "--deliver=innocent --class=innocent --feature=whitelist,noise,chained --source=error --user $ENV{'REMOTE_USER'} --stdout | /var/qmail/bin/qmail-inject $ENV{'REMOTE_USER'}"; (thanks)
5. Also change configure.pl: $CONFIG{'WEB_ROOT'} = "". This will make it use the CSS and logo from the same directory.
6. Setup a virtualhost for dspam:
   <VirtualHost xx.xxx.xxx.xxx:80>
   ServerName dspam.yourdomain.com
   SuexecUserGroup vpopmail vchkpw
   DocumentRoot /var/www/dspam
   CustomLog /etc/httpd/logs/dspam.access combined
   ErrorLog /etc/httpd/logs/dspam.errors

   <Directory "/var/www/dspam/">
DirectoryIndex dspam.cgi
Options +ExecCGI
AuthType Basic
AuthName "DSPAM LOGIN"
AuthUserFile /var/www/dspam/.htpasswd
Require valid-user
Order allow,deny
Allow from all
</Directory>
</VirtualHost> (thanks)

7. Now this part sucks; because most install instructions assume using vpopmail and vchkpw with uid/gid of 89 respectively, it won’t work with suexec out of the box. You need to fix the uid/gid (I’m going from 89 to 589 here, 589 is arbitrary but must be > 500):
   /usr/sbin/groupmod -g 589 vchkpw
/usr/sbin/usermod -u 589 vpopmail
find / -uid 89 -exec chown vpopmail {} \;
find / -gid 89 -exec chgrp vchkpw {} \;
8. All of the startup scripts use id -u vpopmail to get the vpopmail UID so you don’t need to change those. However I came back to my server about 4 hours later to find 1000s of these errors: deferral: Unable_to_switch_to_/home/vpopmail/domains/[domain.com]:_access_denied._(#4.3.0)/. The fix is easy: edit /var/qmail/users/assign and change the UID/GID from 89 to 589. Then you need to recompile it into the cdb file. I just did /mail/bin/vadddomain foo.com foo; /mail/bin/vdeldomain foo.com which does the same thing.

At this point, all files should be properly owned and Suexec should be able to technically access the files. I forgot to make sure /var/www/dspam was owned by vpopmail:vchkpw in addition to the contents so I had an error on my first try.

I rely entirely on email addresses as the “username” since that’s how vpopmail works more or less. To make http authorization work, you’ll need to add an entry for each user to the .htpasswd file like so: htpasswd /var/www/dspam/.htpasswd [email protected]. For large installs that probably won’t scale well but a mod_auth_mysql or something could probably work here instead, perhaps even against the vpopmail tables?