Well, that is documented quite expressly here: https://cwiki.apache.org/confluence/display/SPAMASSASSIN/CachingNameserver
A pointer to the wiki might be useful in the config files as well as the docs. Suggestions of which files? -- Kevin A. McGrail Member, Apache Software Foundation Chair Emeritus Apache SpamAssassin Project https://www.linkedin.com/in/kmcgrail - 703.798.0171 On Tue, Jul 14, 2020 at 3:46 PM Martin Gregorie <mar...@gregorie.org> wrote: > On Tue, 2020-07-14 at 12:53 -0400, Kevin A. McGrail wrote: > > I agree with you about the idea of turning off everything and just > > delivering 100% commented configuration files.. I believe SA is a > > framework that must have walls & paint added to make it a > > house. Others want it ready to go as a pre-fab house aka a drop-in > > spam filter. As a project, the majority supports the drop-in model so > > I support the will of the PMC. The DNSBlocklist inclusion policy from > > 2011 has served us well with a lot of users and very few > > complaints. But if you think of edits it might need, we can always > > improve it. DNS Blocklists and the free for some model really help > > the drop in spam filter be effective. > > > Maybe all that's needed is to better emphasize the point that that free > use of RBLs, whose use by SA is configured on by default, require the > user to have their own non-forwarding DNS installed and explain why. > > This should go in: > - the online docs in the SA website > - SA manpages > - the standard SA configuration file included in the SA package > > This info should include lots of black (hashmarks, asterisks etc). The > main thing is to put these warnings were they can't be missed - and some > people can miss almost anything. > > As an added bonus, the SA installation package might include basic > config files for popular DNSes, say bind and unbound, that let it > support SA out of the box by simply: > (a) installing one of the supported DNS packages > (b) putting the supplied configuration where the DNS expects to find > it. > > If the SA user wants their DNS to do more, they can read its docs and > add their own tweaks. > > But the important point is to have SA docs say, in places that a new > user can't miss that "If you want free use of the default RBLs then > INSTALL YOUR OWN NON-FORWARDING DNS. > > Martin > > > > Regards, > > KAM > > -- > > Kevin A. McGrail > > Member, Apache Software Foundation > > Chair Emeritus Apache SpamAssassin Project > > https://www.linkedin.com/in/kmcgrail - 703.798.0171 > > > > > > On Tue, Jul 14, 2020 at 12:08 PM M. Omer GOLGELI <o...@chronos.com.tr> > > wrote: > > > > > July 14, 2020 6:07 PM, "Kevin A. McGrail" <kmcgr...@apache.org> > > > wrote: > > > > > > > The question you ask is exactly why we have the DNSBL Inclusion > > > > policy > > > and require the free for > > > > some model. > > > > > > > > We might need to kick up the need for the BLOCKED rule with > > > > instructions > > > in that description on how > > > > to disable the rules. What are your thoughts on that? > > > > > > > > > > Don't get me wrong, I use them in the scoring process as well and > > > I'm glad > > > to use them along with a few others as I'm not that hard bent on > > > keeping > > > everything free. > > > > > > And if I hit the limits somehow, I'll either pay for them or turn > > > them off. > > > > > > But there will always be people that doesn't want it. > > > Or those who wouldn't want to see their OSS software relies on > > > commercial > > > products. > > > Or there will be those who does this non-commercially. > > > Or there will be people who installed it as part of their OSS mail > > > product > > > and doesn't know that there's such a limit etc. > > > > > > So for that matter, maybe these can be left for the admins decision > > > to > > > enable them after installation. > > > Or all users should be made aware of these limitations in a better > > > manner > > > and clearly for each semi-commercial RBL used. > > > > > > </2¢> > > > > > > > > > > > > > > > > > > > > > M. Omer GOLGELI > > > > >
