Paul Aviles wrote: > Quick question guys, I am a bit confused reading the documentation in > 3.1.8 under Centos 4.4 so forgive for asking a few questions. > > Is the concept that if you use RBL's in the sendmail configuration you > should disable them in sendmail and then use skip_rbl_checks instead? Erm.. that would disable RBLs in both sendmail AND spamassassin.. Clearly not what you want. > Right now I have them in the sendmail.cf file and was wondering which > one should stay or go. If I should remove the one's from the > sendmail.cf, where do you define the black lists to use in SA, is that > in 20_dnsbl_tests.cf? No. That's where the DEFAULT rules define them. DO NOT edit any of your default rulefiles. SA will obliterate the files when you update.
Always restrict your edits to files in your site rules directory (/etc/mail/spamassassin). Should you wish to disable any stock rule (including disabling one RBL without disabling them all) create a score command for the rule and set its score to 0. Note that many RBLs in SA are actually multiple lists from a single querry. In these cases there's generally an unscored rule that triggers the query that has a name starting with double-underscore. To disable the DNS querry, and effectively inhibit all rules that depend on it, set this rule's score to 0. > What if you want to add other RBL's? Create your own rules for them in .cf files located in /etc/mail/spamassassin. copy the ones out of 20_dnsrbl.cf as a model to edit from. > Right now the way sendmail is configured is that if is in one of the > RBLs it is rejected. Does SA does the same or just increases the score? SA cannot reject mail directly. Depending on how you have it integrated in your mail chain, it might even be impossible (baring time travel) because the time to reject is already past by the time SA gets called. SA's use of RBLs just increases score. Actually, SA itself can never do ANYTHING to directly alter the delivery of mail. It's a generic mail filter, and as such has no control over the message delivery parameters/envelope. If it were to try to alter delivery, most integration tools would detect the message as missing and recover the pre-SA copy of the message and proceed to deliver without SA. > > Also, are all the config settings what you get from running # perldoc > Mail::SpamAssassin::Conf, or there are more config settings to see? > Like for example defang-mime is not there. defang-mime died ages ago. It was a valid option in SA 2.4x and older. As of SpamAssassin 2.50 and higher it's been superseded by the report_safe option. Ditto report_header. > > Do you need to list your rules in SA local.cf like: > > score UPPERCASE_50_75 2.000 > or that is just to increase a scoring using that rule? That's just a score over-ride. > Is there a way to select which rules to enable or not from what you > have under /usr/share/spamassassin? Set their scores to 0, they get disabled. > > what is the difference between ok_languages and ok_locales? Aren't > they the same? No. ok_locales works by detecting character sets used. It makes no analysis of the text itself. ok_languages works by examining the text itself and tries to figure out what language it is based on character groupings. > ok_languages is not in Mail::SpamAssassin::Conf, but appears so many > times googling that I wonder. ok_languages is documented in the textcat plugin docs, as this feature is dependant on that plugin. http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Plugin_TextCat.html > > I was also getting "/etc/mail/spamassassin/auto-whitelist.lock: > Permission denied" and added this to procmailrc > DROPPRIVS=yes > :0fw > | /usr/bin/spamc > > But is that the correct solution? No. This has nothing to do with procmail locks. Why is your AWL database in /etc/mail/spamassassin? That's dangerous. Fix your auto_whitelist_path to point somewhere that can be written to (and DO NOT fix this by making the site config dir writable by the SA process.) Or better yet, delete it, and make sure your users have valid home directories. > And last... I get > > dbg: bayes: no dbs present, cannot tie DB R/O: > /etc/mail/spamassassin/bayes_toks and > bayes: no dbs present, cannot tie DB R/O: > /tmp/spamd-20133-init/.spamassassin/bayes_toks Ditto bayes_path. > I can change the chmod for /etc/mail/sendmail, but I am sure that is > not the right direction, so how do you solve it? > > Thanks a lot for your help and to the SA team. > > Best regards, > > Paul >
