I recommend enabling verbose logging for Amavis in order to see precisely what SpamAssassin tests it's doing and what results it's coming up with.
I see you are using Debian, so edit /etc/amavis/conf.d/50-user to have:
# Amavis logging
$log_level = 5;
Restart Amavis and look at your mail logging output (/var/log/mail.log here) and you will see a load of information. For instance, on my system, when it does the Spamhaus Zen check (which will include SBLCSS) you should see lines like:
Jan 4 10:08:18 psiren amavis[6331]: (06331-04) SA dbg: dns: dns reply to 46728/IN/A/26.11.24.104.zen.spamhaus.org: NXDOMAIN
Hopefully, you'll be able to confirm whether this check is being done correctly, and whether it's getting a correct response (127.0.x.y if it's on a list, NXDOMAIN if it isn't).
These SpamAssassin rules matches if A relay in the message's Received headers was listed...
While RCVD_IN_SORBS_WEB works closer to what you'd like them all to do:
check tests the IP address of the last untrusted relay against
the DNSBL maintained by SORBS.
If you don't trust in these tests, you can always adjust rule scores. score RCVD_IN_BL_SPAMCOP_NET 0 doesn't add any score if the test matches, resulting that the test will be completely disabled.
There's no need for Spamassassin to test against only the latest Received: header as this is the Received from your own MTA that could have done the same test and actually rejected the mail from matching IP address instead of marking it as SPAM.
In Postfix main.cf the equivalent recipient restrictions would be:
smtpd_recipient_restrictions =
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client dnsbl.sorbs.net
And with Exim 4.x in acl_rcpt ACL in the exim.conf:
deny message = Access denied - $sender_host_address\
listed by $dnslist_domain\n$dnslist_text
dnslists = sbl.spamhaus.org : \
bl.spamcop.net : \
dnsbl.sorbs.net
If you use Exim dnslists in warn mode, you could simulate RCVD_IN_* style rules on only the last MTA delivery by adding X-blacklisted-at header
warn message = X-blacklisted-at: $dnslist_domain
dnslists = sbl.spamhaus.org : \
bl.spamcop.net : \
dnsbl.sorbs.net
and then scoring the existence (or content of) that header in Spamassassin instead of RCVD_IN_*:
header LAST_RCVD_BLACKLISTED exists:X-blacklisted-at
score LAST_RCVD_BLACKLISTED 10.0
Please notice that these reject lists might be too wide for what you actually need as for example the dnsbl.sorbs.net is a aggregate zone containing almost all SORBS zones available. Before rejecting or even flagging based on these list you should familiarize yourself with the purpose of each list and decide how aggressive you want to be.
Personally I'd trust SPF, DMARC and Bayesian filtering more and would be really sensitive in trusting DNSBLs, i.e. only using lists with IPs certainly only used for spam, like smtp.dnsbl.sorbs.net for open SMTP relay servers or edrop.spamhaus.org containing "hijacked" netblocks.
Best Answer
Spamassassin uses a number of rules to decide if an email is blocked and creates a score of each email. This is normally included in the header of each email, so you can see which rules have trigged.
The Spamassassin training improves the Bayesian spam testing, so if the training is working you should see the following appear
The BAYES_99 score means the email has spam probability is 99 to 100%, however you can get BAYES_00 to BAYES_99.
If you can't see the above line in any emails, then Spamassassin is not working.
On my Virtualmin setup i've changed to having a spam folder that i move emails to and then there is a daily job that runs the Spamassassing training and after 4 weeks deletes the email.
I currently setup the script for each user with the following: