It takes quite a bit of configuration to get spamassassin to work together well with your mail delivery agent. often times, it works ok, but other times, it requires quite a bit of fine tuning. ill try to explain my general tactics when it comes to training spamassasin to do its job better. i will also attach my configuration to this post… but remember to tune the scores according to your setup, and that simply copying and pasting mine will likely have unintended consequences.
first off, as to the title of the OP; there is a grey-listing milter, but its not what you think it is. it effectively asks the sender to return the mail at a later time (if it thinks it might be spam). most spam operators have not configured there scripts or mail servers to support this, thus, the mail will never come back, and it will block the spam.
it’s currently being used by virtualmin for rate-limiting mail going in and out of the server. however, this plugin can be reconfigured to do grelisting as per its original intention… among other things. see the rate-limiting feature in virtualmin to install this (the package is called milter-greylist).
secondly, i suggest going into your spamassassin configuration directory (on debian/ubntu, this is located under /etc/spamassassin), and looking through each and every file. most of these files contain definitions for enabling different plugins… most of these can be enabled to help deter spam. some of these will need to be configured (on debian/ubuntu, in the configuration file /etc/spamassassin/local.cf)
i suggest you configure virtualmin to deliver mail to a subdirectory in their mailbox called ./Spam. this way, they can poke through the suspected spam on their own time, seperating it from the legitimate mail.
you can reconfigure some of the spamassassin scores to help better classify mail that is almost-always spam. if spam starts at a score level of 5, and you delete the mail at 8 (my scores are tweaked so that it deletes spam marked as 12), you can tweak your scores to reflect this. i will attach my spamassassin configuration below.
ensure that spamassassin can actually write to the auto-learning bayes database under the users home directories. after everything is setup the way you want it, you might want to clear the auto-learning databases and the auto-whitelists and allow them to rebuild themselves. this may help your changes take effect. moreover, it might help get rid of bad rules which a poorly scoring mail, left as artifacts from a previous configuration.
the URIBL plugin is like a DNSBL, but rather than checking host names, it checks URL’s found in the email. this can be beneficial in removing some more mail. you must set this up manually in your spamassassin configuration, and enable the plugin, likewise. it will be available in the configuration which will be attached.
finally, the virus scanner (clamav or clamscan) can do a whole lot more than just scan for virus’s. check out a package called clamav-unofficial-sigs : i am not sure what operating systems it is available on, but on ubuntu, i found it in one of the provided repos.
basically, it has ClamAV signatures for all sorts of things, such as many more kinds of viruses, but also for Phishing mail, and other kinds of Spam. this will help raise the hit rate for the virus scanning component in virtualmin. i have virtualmin deliver mail marked as “virus” to a ./Virus folder within the users mail box, so that false-positives can be sifted through by the user likewise. however, it seems to be fairly accurate.
anyways, i hope this helps. i have attached my spamassasin configuration file to help you get an idea of how i configured some of these plugins, and how i reconfigured scores to help deter obvious spam. individual results may vary.