Hello Stewart, Saturday, September 11, 2004, 11:57:46 PM, you wrote:
SN> Hi, SN> I have one linux-based account on a shared server with a hosting SN> provider; they presently use cpanel, exim 4.42, SpamAssassin 2.64, SN> and imapd. We are unhappy with the filtering performance SN> (> 10% false negatives, even with required_hits=5.0). Your situation is similar to mine, but I'm still at SA 2.63. Last week's performance stunk at 0 false positives and 20 false negatives (a rotten 99.5% accuracy record; I'm not satisfied unless I hit 99.8%). SN> I'd like to add custom rules, but the provider won't enable SN> allow_user_rules, citing security concerns. Also, he won't SN> be upgrading to 3.0.0 until it is released with cpanel. Adding custom rules is among the last things you want to do. I do them, and I can help you with the process (provided you can run bash scripts under cron), but there are things you want to do first. Step 1: If False Positives are your major problem, a) identify which rules are causing the false positives and lower their scores, or b) raise your required_hits, or c) both. I use required_hits of 9.0, and have modified the scores of several dozen rules. Step 2: Having done step 1, you'll increase the amount of spam that comes through. Identify which distribution rules hit that spam, and raise their scores enough to score the spam, without causing false positives. Step 3: Bayes is your friend. Identify all email as guaranteed spam, guaranteed not-spam, spam discussions, and uncertain. Feed the first two into the Bayes system consistently and accurately, and that will help enormously. So enormously that some people will recommend doing step 3 before steps 1 and 2. Step 4: Your system does allow for whitelist and blacklist entries. Maybe this should be in front of step 1 also: identify from your false positives those sites that can be reliably whitelisted with whitelist_from_rcvd (use the _rcvd version rather than just whitelist_from whenever possible). Copy William Sterns' blacklist file from http://www.stearns.org/sa-blacklist/sa-blacklist.current.cf into your user_prefs. Once you've done all four steps properly, you should have almost no false positives, and a 95%-98% accuracy rate on spam. SN> It appears that installing SpamAssassin 3.0.0 in my home directory SN> would be a good solution. However, we have several add-on domains, SN> each with several mailboxes, and I don't know a good way to deliver SN> the output to the proper box. Mail for [EMAIL PROTECTED] presently SN> gets delivered to SN> /home/myaccount/mail/domain.name/user/inbox or to SN> /home/myaccount/mail/domain.name/user/spam . SN> We also have many aliases "forwarders" that point to various boxes. SN> Ideally, there would be a way for each mailbox to have its own SN> user_prefs. Bayes: Do your people retrieve their email using POP3 (in which case they probably get the inbox mail only), or do they use webmail? If the latter, have them create two more folders: spam and notspam. Have them move all spam into the spam folder. Have them copy (not move) all non-spam intothe notspam folder. Have a cron job which runs sa-learn against these mbox files on a regular basis (mine runs hourly), deleting the mbox files when done. No, under your setup there's no way for each mailbox to have its own user_prefs; there's one user_prefs for each master domain and that's it. There's also no way for each mailbox to have its own bayes database -- there's one bayes database for the entire master domain. SN> There is lots of detailed info at SN> http://wiki.apache.org/spamassassin/UsedViaProcmail and at SN> http://wiki.apache.org/spamassassin/SingleUserUnixInstall , but SN> I could not find any examples with multiple independent email SN> accounts. Surely, hundreds of users have done this before, but SN> sorry, I was unable to find a solution with Google, or searching SN> the archives for this list. Once you've done the above three steps, then we can explore whether the method I use for implementing my own custom rules will work for you. Bob Menschel
