On Tue, Oct 04, 2016 at 05:37:33PM +1300, Peter wrote: > The main problem with this is that one of the primary advantages to > using a DNSRBL is that it sits in front of SpamAssassin. DNSRBL > blockign does not require deep inspection of message content so it can > be checked first and clients blocked without wasting valuable server > resources on anti-spam techniques that do require deep inspection (such > as SA). If you're only checking the DNSRBLs from within SA itself then > you negate this advantage completely. > > postscreen can do DNSRBL weighting so that you can require more than one > DNSRBL to contain an entry before rejecting messages from a given > client. Here's a very good doc on how to properly configure postscreen > to do this: > > http://rob0.nodns4.us/postscreen.html
That's true, however as I said in my previous message, I personally would rather err on the side of accepting a questionable message. I don't consider it a waste of resources. There are plenty of valid reasons one may want to accept and store spam messages. Having a corpus of spam allows for [re]training of bayesian filters. It also allows for manual inspection of the types of spam currently in circulation. It allows users the chance to check for false positives and flag them as such. In my opinion, outright rejection should be reserved for messages that you are 100% sure are spam. I don't consider RBLs to be 100% reliable, so I would not use them for message rejection. But of course, your setup / users / requirements may be different from mine, so don't take my advice as absolute. --Sean
