These are the MTA-level blacklists I use:
Based on years of experience with our previous mail system, which only had RBL blocking without scoring, the above lists have had just about zero false positives. This is in contrast to the higher-level uceprotect lists, for example, psbl.surriel.com, or some of the other SORBS lists, which would generally produce a false positive about once or twice/month.
I can't remember exactly why I don't use zen except that I seem to recall that it was a superset of several blacklists but didn't get updated instantly when those did. I have seen cases where spam slipped through in the interim.
Because Zimbra offers scoring via SA, I pared my list down to those found above, eliminating both the ones with more false positives and a number of country-based blacklists which I felt weren't entirely fair.
Then just recently I made the following changes:
1) Lowered my spam tagging threshold to 23 percent, which works out to 4.6 points. This was based on observation--i.e., going through a sample of spam and a sample of ham, seeing how it was being scored, ELIMINATING anything that was underscored by Bayesian scoring (on the theory that the system would eventually catch up), and then picking the highest number which would still ensure that all the spam would be caught and none of the ham.
2) Modified salocal.cf.in to score for uceprotect-2 and uceprotect-3. Also added scoring for hostkarma based on uxbod's recommendation (Thanks!). Note that I chose a score of 1.1 for uceprotect-2 on the theory that a positive on that RBL + BAYES_99=3.5 would get me to the threshhold.3) Modified zmmta.cf to treat authenticated external users as if they were local. This keeps SA from penalizing my boss and others who use, say, Verizon wireless internet connections.# Single-zone BLs for UCEPROTECT
# No entry for UCEPROTECT_1 because we use it to block at MTA level.
# Could create entry and score 0, or comment out, to prevent lookup.
header RCVD_IN_UCEPROTECT_2 eval:check_rbl('UCEPROTECT-2', 'dnsbl-2.uceprotect.net.')
describe RCVD_IN_UCEPROTECT_2 Received via a relay in dnsbl-2.uceprotect.net
tflags RCVD_IN_UCEPROTECT_2 net
score RCVD_IN_UCEPROTECT_2 1.1
header RCVD_IN_UCEPROTECT_3 eval:check_rbl('UCEPROTECT-3', 'dnsbl-3.uceprotect.net.')
describe RCVD_IN_UCEPROTECT_3 Received via a relay in dnsbl-3.uceprotect.net
tflags RCVD_IN_UCEPROTECT_3 net
score RCVD_IN_UCEPROTECT_3 0.5
# Multi-zone BL for hostkarma, see Spam DNS Lists - Computer Tyme Support Wiki
# also http://www.zimbra.com/forums/adminis...et-plugin.html
# I use Uxbod's scoring.
header __RCVD_IN_JMF eval:check_rbl('JMF-lastexternal','hostkarma.junkemailfilter.com.')
describe __RCVD_IN_JMF Sender listed in JunkEmailFilter
tflags __RCVD_IN_JMF net
header RCVD_IN_JMF_W eval:check_rbl_sub('JMF-lastexternal', '127.0.0.1')
describe RCVD_IN_JMF_W Sender listed in JMF-WHITE
tflags RCVD_IN_JMF_W net nice
score RCVD_IN_JMF_W -1.5
header RCVD_IN_JMF_BL eval:check_rbl_sub('JMF-lastexternal', '127.0.0.2')
describe RCVD_IN_JMF_BL Sender listed in JMF-BLACK
tflags RCVD_IN_JMF_BL net
score RCVD_IN_JMF_BL 1.5
header RCVD_IN_JMF_BR eval:check_rbl_sub('JMF-lastexternal', '127.0.0.4')
describe RCVD_IN_JMF_BR Sender listed in JMF-BROWN
tflags RCVD_IN_JMF_BR net
score RCVD_IN_JMF_BR 0.5EDIT: forgot to mention: after making these modifications, I restarted zimbra. You can avoid a restart by editing salocal.cf directly, but you'll lose the changes on your next restart, so you should edit both salocal.cf and salocal.cf.in. DON'T copy one to the other, though--they're not supposed to be identical, as diff salocal.cf salocal.cf.in will show. (I don't think there's an easy way to avoid a restart for the zmmta.cf modification to take effect.)POSTCONF smtpd_sasl_authenticated_header yes