Quoting "Dan Mahoney, System Admin" <[EMAIL PROTECTED]>:
On Wed, 15 Sep 2004, [EMAIL PROTECTED] wrote:
Hello all. Ive been lurking for a week or two hoping to learn something, but I think my starting knowledge is too far behind!
I have a Redhat server running sendmail 8.12 that can pre-installed with spamassassin. Ive never used spamassassin before, and Im a sysadmin who going by the trial by fire method currently. When I fired it up and made it live the thresh hold was too low, and spamassassin was catching loads of ham. I put it up to 15 till I could figure things out.
I think ideally Id like to start by filtering server wide then perhaps moving to a user controlled environment. I have noticed spamassassin is making user_prefs when they dont exist.
Yup, it's a good doobie like that. Only real issue is when two users share a homedir (which shouldn't ever really be the case).
doobie? Just what are you talkin about here? ;)
Note if you are doing a system wide config, you can and probably should turn this behavior off by calling spamd with -x.
with redhat you should be able to do this by editing the spamassassin startup script which (atleast on my redhat 9 system) is /etc/init.d/spamassassin
man spamd might help you out with other options as well.
-x, --nouser-config Disable user config files
My first question is: any way to turn specific rules on/off easily? Where do I do this? /usr/share/spamassassin has some conf files, should I comment things out there? I think that for an isp situation the rules need to be a bit more lax, as there is a plethora of different email coming in at all times, but at the same time i gotta get the viagra crap out of here.
If it's a system-wide install, then you should find your config file (on a default install of spamassassin it's /etc/mail/spamassassin/local/cf I believe -- but DOUBLE CHECK).
minor correction, but it could stump a beginner. It should be /etc/mail/spamassassin/local.cf, not local/cf. Im guessing its a typo as i do it myself all the time.
As shown below, giving a test a score of 0 will turn it off. Dan showed how to
do it, but he didnt actually mention anywhere that this will turn a test off
(or change the score if you put any number other than 0).
When osirusoft shut down their DNSbl's and started returning "yes" for every ip queried, I added these lines to that file:
score RCVD_IN_OSIRUSOFT_COM 0.00 score X_OSIRU_OPEN_RELAY 0.00 score X_OSIRU_DUL 0.00 score X_OSIRU_SPAM_SRC 0.00 score X_OSIRU_SPAMWARE_SITE 0.00 score X_OSIRU_DUL_FH 0.00
You could do the same with any other rule.
By the way, the defaults are usually pretty decent (and get way better once the bayes magic starts working). Perhaps you should look at WHY ham is being caught, and be sure to teach your users how to properly whitelist their mail if there's a problem. There are presently solutions for this with IMAP, Procmail, and for shell users.
I second this one. I would check the headers of the mail and see exactly what
tests are scoring. If you arent running any extra rules (which im guessing you
arent if your just starting with this) you really shouldnt be having any false
positives unless your ham mails are REALLY spammy for some reason.
Oh and a quick note, dont touch anything in /usr/share/spamassassin. these are
templates that get overwritten every time you upgrade SA. All rules and
changes to rules should go into /etc/mail/spamassassin.
-Jim
