DSPAM + procmail = trouble


I recently downloaded and installed DSPAM 3.6.1 according to the great user guide located here: http://www.lalkaka.com/dspam/

Corpus training worked as expected; I was able to feed in a bunch of messages through the supplied scripts (although I had to add “–stdout” to the dspam invocation on both of them).

I ran into a problem, though, which is that dspam, when invoked by procmail, dies an unseemly death, reporting the following to the procmail log file:

/home/dcheck/usr/bin/dspam: /lib/libc.so.6: version `GLIBC_2.3’ not found (required by /home/dcheck/usr/bin/dspam)
procmail: Error while writing to "/home/dcheck/usr/bin/dspam"
procmail: Rescue of unfiltered data succeeded

Any idea why I’m getting this? Is this a procmail problem? A DSPAM problem? Is there chroot’ing afoot? I’ve never seen an error like this for software I’ve compiled myself…

I’m getting the same issue with both DSpam 3.6.1 and 3.0.0. Corpus training and running the commands from the shell work fine but procmail fails with the same error.

I found this over in the knowledge base (https://panel.dreamhost.com/kbase/index.cgi?area=2626)

“Notice the LD_LIBRARY_PATH environment variable. This will force the PHP binary to search in the specified directory for any dynamic libraries that it needs to load. This is how we get the PHP binary to use the library files it actually works with, rather than trying to use the ones on the mail server (which doesn’t have all the libraries it needs.)”

So I guess my home directory (and Maildir) are nfsmounted on multiple machines, and the dspam binary that I built is not compatible with the glibc version on the other machine. Unfortunately, glibc.so.6 is statically linked to /lib/ld-linux.so.2, so even copying in the new glibc isn’t helpful.

Can you think of a way around this?

If the problem is that we’re linked against the wrong environment, might we be able to solve this by writing a shell script that does the configure / compile / install for us, and then creating another mail account and getting procmail to invoke the installation script for that account via a .procmailrc file? So you send it a message and it’ll install the new software? Probably a Really Bad Idea, but I don’t know how else we can compile for that arch.


Yup, it looks like you can get procmail to compile both a mysql binary and a dspam binary by writing the install script into a procmail recipe, at which point this thing just hums… I’ll post a howto in short order…

Is there a way to point dspam at the correct binaries, should we be able to find them? That seems easier, but I guess running the install inside of procmail could work…

Do you have it working, or is it theoretical right now?

Thanks for the idea, I got it.

Now if I could figure out how to get rid of the dspam signature at the bottom of every message… I did --enable-signature-headers when I installed but it didn’t seem to work (that might only be for an older version of dspam)

So here’s my solution to the install problem:


I’d be interested to know if you way of getting it up and running was harder or easier…

As far as the options go, I’d check ~/usr/etc/dspam.conf – I think most of the prefs have been migrated into there.

I thought I had it working, but it seems not. I didn’t do anything with the mysql libraries, and it seems I can’t fix any false-positives. I’m going to be trying a couple of things (a concurrent dspam installation) and then re-compile with what you did if that doesn’t work.

Hi guys, I’ve been trying to do this as well… is there something wrong with statically linking with glibc?

After I did all the stuff that I did, I thought that maybe statically linking things would be easier, but I’ll tell you what, I didn’t think of it before doing all the stuff that I did. If you get it to work with static linking, please let me know!

After reviewing some stuff on the web, I’ve concluded that statically linking with libc is really bad… and it takes up memory and such. I’m going to mail tech support to see about adding dspam as an option to dreamhost.

I’m a bit late with this comment, but FWIW, as of June 2006, with DSPAM 3.6.8, procmail seems to be happily running the dspam executable as compilied on the web server. I did not have to compile dspam on the mail server.

I suppose I should say that this comment applies to the webserver ‘pogo’.

– sdg