details from associate whoc discovered this:
In the spamassassin subroutine there are several places that test
$spamc_options for a '-c' option. If the option is set, spamc just checks
the mail for spam, adding the X-Spam headers but not rewriting the
message. We are not using the '-c' option. However, the way the test is
done is flawed for certain domains. Here's the most relevant section of
code:

 1. $spamc_options="$spamc_options -u \"$cmdline_recip\"" if
($cmdline_recip ne "");
 2. &debug("SA: run $spamc_binary $spamc_options <
$scandir/$wmaildir/new/$file_id");
 3. open(SA,"$spamc_binary $spamc_options  \
     < $scandir/$wmaildir/new/$file_id|")||&error_condition("cannot run
$spamc_binary  \
     < $scandir/$wmaildir/new/$file_id - $!");
 4. open(SOUT,">$scandir/$wmaildir/new/$file_id.spamc") \
     ||&error_condition("cannot open for write
$scandir/$wmaildir/new/$file_id.spamc - $!");
 5.   while (<SA>) {
 6.     if (!$sa_tag) {
 7.       if ($spamc_options =~ /\-c/) {
 8.         chomp;
 9.        ($sa_score,$sa_max)=split(/\//,$_,2);
10.         $sa_tag++;
11.       } else {
12.         #X-Spam-Status: No, hits=2.8 required=5.0
13.         if (/^X-Spam-Status: (Yes|No), hits=(-?[\d\.]*)
required=([\d\.]*)/) {
14.           $sa_tag++;
15.           $sa_status=1 if ($1 eq "Yes");
16.          $sa_score=$2;$sa_max=$3;
17.         }
18.       }
19.     }
20.     print SOUT;
21.   }

In line 1, the program adds a '-u' option, followed by the recipient's
email address, to the $spamc_options variable.

In line 7, and in later lines of the same subroutine, it tests
$spamc_options for the presence of the '-c' option.

This is where the problem comes in. For our domain, c-cap.com, the
recipient's email address is now satisfying the '-c' test because it's
part of the $spamc_options. Any domain with a "-c" in it would cause the
same problem - essentially, telling this subroutine that spamc is not
rewriting the  message when it really is (and also messing up $sa_max,
which is why we were seeing the funky "X-Spam-Status: No, hits=Received:
from localhost [127.0.0.1] by webfree.nxsbg.com required=?" header.)

I've put a bandaid on this by inserting a space after the '-c' test in
each case. This isn't a good fix, though; if $spamc_options is set to, for
instance, "-c" (with no trailing space) and for some reason there doesn't
seem to be a $cmdline_recip, it will fail the test in the other direction.