If X-Spam-Status and the report in the message body don't line up, you probably have an error in your MTA setup that's causing the message to be run through SpamAssassin twice. This causes the message to be rewritten on the first run, then the second run sees a very different message so the rules hit are also very different. Double check your configuration to make sure this doesn't happen. (some examples: the MTA filters the message, then it's filtered again through procmail. procmail is setup globally to filter, then the individual's procmailrc filters as well. etc.)
Here's an example of such a mangled message (headers have been trimmed for clarity and privacy):
Subject: *****SPAM***** recuperate column
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mepis1
X-Spam-Level: *
X-Spam-Status: No, hits=1.8 required=5.0 tests=DNS_FROM_RFCI_DSN,HTML_MESSAGE,
MANY_EXCLAMATIONS autolearn=no version=2.60
Spam detection software, running on the system "mail", has
identified this incoming email as possible spam. The original message
has been attached to this so you can view it (if it isn't spam) or block
similar future email. If you have any questions, see
the administrator of that system for details.
Content analysis details: (7.6 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.1 HTML_60_70 BODY: Message is 60% to 70% HTML
0.0 HTML_MESSAGE BODY: HTML included in message
2.2 HTML_IMAGE_ONLY_02 BODY: HTML: images with 0-200 bytes of words
1.1 RCVD_IN_DSBL RBL: Received via a relay in list.dsbl.org
[<http://dsbl.org/listing?ip=123.123.123.123>]
2.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
[Blocked - see <http://www.spamcop.net/bl.shtml?123.123.123.123>]
0.1 RCVD_IN_SORBS RBL: SORBS: sender is listed in SORBS
[123.123.123.123 listed in dnsbl.sorbs.net]
1.4 DNS_FROM_RFCI_DSN RBL: From: sender listed in dsn.rfc-ignorant.org
0.4 MANY_EXCLAMATIONS Subject has many exclamations
*Note: I just found where I was getting duplicate scans when using Maildrop. The file /etc/maildroprc had the following call to user's $HOME/.mailfilter to check & run it's $HOME/.mailfilter. My xfilter spamc trigger is contained in $HOME/.mailfilter. It seems $HOME/.mailfilter is read automatically by maildrop. As such, commenting this code in /etc/maildroprc should fix this.
/etc/maildroprc
## WE'RE CALLING SPAMASSASSIN TWICE. Once here and once ~/.mailfilter.
## $HOME/.mailfilter is being automatically read by maildrop and this check isn't needed.
#
# Include any rules set up for the user - this gives the
# administrator a way to override the domain's mailfilter file
#
# this is also the "suggested" way to set individual values
# for maildrop such as quota. (why do you need quota on your own PC?)
#
#`test -r $HOME/.mailfilter`
#if( $RETURNCODE == 0 )
# {
# log "(==) Including $HOME/.mailfilter"
# exception {
# include $HOME/.mailfilter
# }
# }