spamass-milter dies when configured to not reject mails

[Todd Lyons]

I have for about the past 6 months been running a production system (2
load balanced mail servers, previously was 3) with spamass-milter
starting with the options "-r 6" so that it rejects emails with scores
of 6.0 or higher.  Note that I'm ignoring the portion of the commandline
that tells it to fork and where the socket is.  It has been working
fantastic.  I've never had to restart it because it died.

Now I'm working on making the quarantine system designed by one of the
users here.  I've set it up on my low volume personal mail server.  In
doing this, my commandline is now "-i 127.0.0.1 -r 20 -b quarantine" so
that it allows stuff in that wouldn't normally get through.  The
quarantine account is just a perl script that stores the email in an out
of the way location.  

The problem is that bouncing the emails through to the quarantine alias
are causing the spamass-milter process to die.  I'm running it under
valgrind right now to see if I can catch anything useful.

This is also a Gentoo build which doesn't seem to have any of the
stability patches that were floating around after the 0.2.0 release (if
my memory hasn't failed me).  I think that it probably never bit us
because we reject spam outright.  I look forward to a new release as
well, or a 0.2.1 release with those stability patches.  I'll have to dig
into it more later, right now gotta go fix a machine with scsi media
problems.

FYI, we will be heavily modifying the quarantine scripts to provide a
web interface with data served on the backend by mysql.  It will be
passwordless because a significant portion of our users don't have local
mailboxes but instead choose to forward to other providers such as AOL,
Earthlink, etc.  Instead, we'll generate a unique 40 character
hexadecimal hash for each notification email.  No indication of who the
emails belong to will exist in the URL provided.  The user will simply
click the URL and be shown all emails on hold for that user and can
choose to for each email or for all emails 1) go ahead and send 2)
delete or 3) ignore.  At no time will the user have access to the raw
email file(s).  Assuming multiple notices with unique hashes get sent to
a user, each unique hash will show all emails for that user.  The fact
that the URL is a 40 character unique hexadecimal session ID string
should mean that the odds of someone guessing another's session ID are
1:40^16.  Let me know if my math is off.

We're going to start developing this soon, but we need to get
spamass-milter stable before we can begin.  Any and all suggestions are
appreciated.
-- 
Regards...              Todd
They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety.       --Benjamin Franklin
Linux kernel 2.6.8.1-12mdkenterprise   3 users,  load average: 0.00, 0.00, 0.00