Geht schon, man muss die Blacklists in dem Fall bei den Mail Proxy Options unter DNSBL Sites eben rausnehmen und in der eigenen custom.cf für SpamAssassin eintragen.
Meine Empfehlung ist, nur solche Blacklists für harte Rejects zu verwenden, die "über alle Zweifel erhaben sind".
Bisher würde ich hier NiX Spam von manitu sehen (wobei es da gerade einige false-positives gibt, habe ich so bisher noch nicht erlebt), Spamhaus und Spamcop. Ich nutze zudem noch PSBL, IMP, Spamrats (aber nur NoPTR) und SORBS (aber nur Escalations).
Alles andere gehört dann in die custom.cf zum taggen. Dazu muss man sich sinnvolle Werte überlegen.
So ist die Barracuda Blacklist recht zuverlässig, hat aber auch ein leicht negatives "Geschmäckle", einfach mal googlen nach emailreg.org und den Zusammenhang mit der Barracuda Blacklist, gleiches dürfte wohl (nur noch extremer) für UCEPROTECT (Level 1) gelten. Auch noch recht zuverlässig ist GBUdb Truncate sowie WPBL, dann wird es schon deutlich unzuverlässiger mit RBLDNS.RU, SPFBL, s5h, JunkEmailFilter, DNSRBL, JustSpam, inps, V4BL (zumindest die freie), UCE Backscatterer, Tornevall, Singulari sowie der Gremlin Work Zone.
Einträge erfolgen im Stil
header RCVD_IN_BRBL eval:check_rbl('brbl-lastexternal', 'b.barracudacentral.org.', '127.0.0.2')
describe RCVD_IN_BRBL Received via a relay in Barracuda RBL
tflags RCVD_IN_BRBL net
score RCVD_IN_BRBL 6
wobei man die IP hinten weglassen kann, wenn man nicht explizit nach einem Ergebnis filtern möchte.
Alternative ist die komplette Anpassung der main.cf über das Templatesystem (siehe Dokumentation) und der Einsatz von postscreen mit Treshold und Gewichtungen. Jedoch kommt es hier letztendlich auch irgendwann wieder zum Hardblock, haben meiner Meinung nach die Whitelists, die man dagegen stellen sollte, nicht annähernd die Reputation und zu hohe False-Positive-Raten, auch sieht dann halt der Absender soweit ich weiß auch nicht mehr, auf welcher Liste er ist und kann direkt Maßnahmen ergreifen, finde ich alles in allem nicht so schön.