Panix Help System: SpamAssassin for Experts

Panix Help System -- SpamAssassin Pro

This page is for folks who are already familiar with SpamAssassin but want to know how to use it at Panix. It's specifically designed for shell users, not for mailbox-only accounts (which don't, for instance, have access to procmail).

You already know about the SpamAssassin web page at spamassassin.apache.org/. Here's what you have to keep in mind:

• SpamAssassin is third-party software. Upgrades may result in changes in the point value of any of the rules. (We make occasional local changes, but they are rare.) We advise users to explictly allow addresses they wish to protect.

•We have a shared filter rule set up at /net/local/filters/rc.spamassassin that you can include in your .procmailrc file with this line: INCLUDERC=/net/local/filters/rc.spamassassin

•If you don't use the shared rc.spamassassinfile, we must ask you to use
/usr/local/bin/spamc
rather than
/usr/local/bin/spamassassin
because the latter is very costly in terms of system resources. If you cannot use spamc, and if your invocation of spamassassin becomes a system hog, we'll require you to modify it and perhaps shut it down.

•It is inadvisable to use SpamAssassin's built-in blocklist feature for spam addresses for (at least) two reasons:

• Spammers use throw-away addresses, often forging legitimate user addresses (from one domain or another) into the headers of the mail they send out.: You won't reduce your spam load by filtering on these addresses because they're generally used only once, and you risk blocking people you want to hear from.
• Blocking spam addresses in SpamAssassin generally causes the user_prefs file to grow very large.: A large user_prefs file is extremely uneconomical for the system to process. SpamAssassin will not work with a user_prefs file longer than 1024 lines.; If you are a shell user, it is possible to use separate procmail rules to block addresses, and you might want to consider doing this instead of running your block or allow lists directly from SpamAssassin.

• Just as you can block addresses by using procmail recipes, you can also allow (i.e. protect) addresses in procmail.

If you choose to do this, you can protect messages by Subject: line (or any other characteristic you choose) as well as by address. It's handy to set up a special file of procmail recipes that you invoke in .procmailrc with an INCLUDERC line. Just make sure that you put that line ahead of the INCLUDERC that invokes SpamAssassin or your effort to allow these addressess will be in vain.

Suppose your procmail rules for allowlisting addresses is in a file called $HOME/.procmail/rc.allow; you might have these lines (in this order) in your .procmailrc file:
INCLUDERC=.procmail/rc.allow
INCLUDERC=/net/local/filters/rc.spamassassin

• We don't support sa-learn because it doesn't run with our spamc and spamd setup.

Running /usr/local/bin/spamassassin is too expensive for us to enable this, as the many users who would then run the standalone program would overload the system.

Activating SpamAssassin via Webmail
Using SpamAssassin with Procmail (UNIX shell-based filtering)

Other SpamAssassin Resources:

The master list of SpamAssassin tests and their default values:
spamassassin.apache.org/tests.html
Panix uses the "net" numbers, so if a particular test has four different default numbers on the list, Panix uses the second number on the list.
The SpamAssassin manpages:
spamassassin(1)
spamc(1)
Mail::SpamAssassin::Conf(3) (user_prefs config)
The spamassassin.org README file offers additional documentation (some of it relevant and some not).