NAME spamassassin - mail filter to identify spam using text analysis SYNOPSIS spamassassin [options] < *mailmessage* > *output* spamassassin -d < *mailmessage* > spamassassin -r [-w *addr*] < *mailmessage* spamassassin -k [-w *addr*] < *mailmessage* spamassassin -W|-R < *mailmessage* Options: -P, --pipe Deliver to STDOUT (now default) -L, --local Local tests only (no online tests) -r, --report Report message as spam -k, --revoke Revoke message as spam -w addr, --warning-from=addr Send a warning mail to sender from addr -d, --remove-markup Remove spam reports from a message -C path, --configpath=path, --config-file=path Path to standard configuration dir -p prefs, --prefspath=file, --prefs-file=file Set user preferences file --siteconfigpath=path Path for site configs (def: /etc/mail/spamassassin) -x, --nocreate-prefs Don't create user preferences file -e, --exit-code Exit with a non-zero exit code if the tested message was spam -l filename, --log-to-mbox=file Log messages to a mbox file -t, --test-mode Pipe message through and add extra report to the bottom --lint Lint the rule set: report syntax errors -a, --auto-whitelist Use auto-whitelists (AWL) -W, --add-to-whitelist Add addresses in mail to whitelist (AWL) --add-to-blacklist Add addresses in mail to blacklist (AWL) -R, --remove-from-whitelist Remove all addresses found in mail from whitelist (AWL) --add-addr-to-whitelist=addr Add addr to whitelist (AWL) --add-addr-to-blacklist=addr Add addr to blacklist (AWL) --remove-addr-from-whitelist=addr Remove addr from whitelist (AWL) -M, --whitelist-factory Select whitelist factory (AWL) -D, --debug [area=n,...] Print debugging messages -V, --version Print version -h, --help Print usage message OPTIONS -P, --pipe The -P parameter will cause SpamAssassin to pipe the output to STDOUT. This is now the default mode of operation, so this switch is obsolete, and should not be used anymore. -a, --auto-whitelist, --whitelist Use auto-whitelists. Auto-whitelists track the long-term average score for each sender and then shift the score of new messages toward that long-term average. This can increase or decrease the score for messages, depending on the long-term behavior of the particular correspondent. For more information about the auto-whitelist system, please look at the the "Automatic Whitelist System" section of the README file. The auto-whitelist is not intended as a general-purpose replacement for static whitelist entries added to your config files -e, --error-code, --exit-code Exit with a non-zero error code, if the message is determined to be spam. -h, --help Print help message and exit. -t, --test-mode Test mode. Pipe message through and add extra report. Note that the report text assumes that the message is spam, since in normal use it is only visible in this case. Pay attention to the score instead. If you run tests with the -a option, the scores will be added to the AWL. This may not be what you want to do. If it is not, then don't use -a -t. -r, --report Report this message as verified spam. This will submit the mail message read from STDIN to various spam-blocker databases. Currently, these are Vipul's Razor ( http://razor.sourceforge.net/ ), the Distributed Checksum Clearinghouse ( http://www.rhyolite.com/anti-spam/dcc/ ), and Pyzor. If the message contains SpamAssassin markup, this will be stripped out automatically before submission. The support modules for DCC, Razor and/or Pyzor must be installed for spam to be reported to each service. The message will also be submitted to SpamAssassin's learning systems; currently this is the internal Bayesian statistical-filtering system (the BAYES rules). (Note that if you *only* want to perform statistical learning, and do not want to report mail to a third-party server, you should use the "sa-learn" command directly instead.) -k, --revoke Revoke this message. This will revoke the mail message read from STDIN from various spam-blocker databases. Currently, these are Vipul's Razor ( http://razor.sourceforge.net/ ). Revocation support for the Distributed Checksum Clearinghouse ( http://www.rhyolite.com/anti-spam/dcc/ ), and Pyzor is not currently available. If the message contains SpamAssassin markup, this will be stripped out automatically before submission. The support modules for Razor must be installed for spam to be revoked from the service. The message will also be submitted as 'ham' (non-spam) to SpamAssassin's learning systems; currently this is the internal Bayesian statistical-filtering system (the BAYES rules). (Note that if you *only* want to perform statistical learning, and do not want to report mail to a third-party server, you should use the "sa-learn" command directly instead.) --lint Syntax check (lint) the rule set and configuration files, reporting typos and rules that do not compile correctly. Exits immediately with 0 if there are no errors, or greater than 0 if any errors are found. -W, --add-to-whitelist Add all email addresses, in the headers and body of the mail message read from STDIN, to the automatic whitelist. Note that you must be running "spamassassin" or "spamd" with the -a switch for this to work. See the -a documentation for more information. --add-to-blacklist Add all email addresses, in the headers and body of the mail message read from STDIN, to the automatic whitelist with a high score (ensuring they will be ''blacklisted''). Note that you must be running "spamassassin" or "spamd" with the -a switch. See the -a documentation for more information. -R, --remove-from-whitelist Remove all email addresses, in the headers and body of the mail message read from STDIN, from the automatic whitelist. STDIN must contain a full email message, so to remove a single address you should use --remove-addr-from-whitelist instead. Note that you must be running "spamassassin" or "spamd" with the -a switch. See the -a documentation for more information. --add-addr-to-whitelist Add the named email address to the automatic whitelist. Note that you must be running "spamassassin" or "spamd" with the -a switch. See the -a documentation for more information. --add-addr-to-blacklist Add the named email address to the automatic whitelist with a high score (ensuring they will be ''blacklisted''). Note that you must be running "spamassassin" or "spamd" with the -a switch. See the -a documentation for more information. --remove-addr-from-whitelist Remove the named email address from the automatic whitelist. Note that you must be running "spamassassin" or "spamd" with the -a switch. See the -a documentation for more information. -w *fromaddr*, --warning-from=*fromaddr* This flag is only useful in conjunction with -r. It will send a reply mail to the sender of the tested mail, notifying them that their message has been trapped as spam, from the address supplied in *fromaddr*. See "SPAM TRAPPING". -l *filename*, --log-to-mbox=*filename* Log all mail messages that pass through the filter, to an mbox-format file named by *filename*. Handy for use with -r and -w. -L, --local Do only the ''local'' tests, ones that do not require an internet connection to operate. Normally, SpamAssassin will try to detect whether you are connected to the net before doing these tests anyway, but for faster checks you may wish to use this. -d, --remove-markup Remove SpamAssassin markup (the "SpamAssassin results" report, X-Spam-Status headers, etc.) from the mail message. The resulting message, which will be more or less identical to the original, pre-SpamAssassin input, will be output to stdout. (Note: the message will not be exactly identical; some headers will be reformatted due to some features of the Mail::Internet package, but the body text will be.) -C *path*, --configpath=*path*, --config-file=*path* Use the specified path for locating the distributed configuration files. Ignore the default directories (usually "/usr/share/spamassassin" or similar). --siteconfigpath=*path* Use the specified path for locating site-specific configuration files. Ignore the default directories (usually "/etc/mail/spamassassin" or similar). -p *prefs*, --prefspath=*prefs*, --prefs-file=*prefs* Read user score preferences from *prefs* (usually "$HOME/.spamassassin/user_prefs"). -D [*area=n,...*], --debug [*area=n,...*] Produce diagnostic output. The level of diagnostic output can be set for each area separately; *area* is the area of the code to instrument, and *n* is a positive or negative number indicating the debug level or bitmask for that area of code. For example, to produce diagnostic output on all rules that hit, use: spamassassin -D rulesrun=255 -x, --nocreate-prefs Disable creation of user preferences file. -M *factory*, --whitelist-factory=*factory* Select alternative whitelist factory. DESCRIPTION SpamAssassin is a mail filter to identify spam using text analysis and several internet-based realtime blacklists. Using its rule base, it uses a wide range of heuristic tests on mail headers and body text to identify "spam", also known as unsolicited commercial email. Once identified, the mail is then tagged as spam for later filtering using the user's own mail user-agent application. SpamAssassin also includes support for reporting spam messages to collaborative filtering databases, such as Vipul's Razor ( http://razor.sourceforge.net/ ). The default tagging operations that take place are detailed in "TAGGING". CONFIGURATION FILES The rule base, text templates, and rule description text are loaded from the configuration files. By default, configuration data is loaded from the first existing directory in: /home/jm/perl584/share/spamassassin; /home/jm/perl584/share/spamassassin; /usr/local/share/spamassassin; /usr/share/spamassassin . Site-specific configuration data is used to override any values which had already been set. This is loaded from the first existing directory in: /home/jm/perl584/etc/mail/spamassassin; /home/jm/perl584/etc/mail/spamassassin; /home/jm/perl584/etc/spamassassin; /usr/local/etc/spamassassin; /usr/pkg/etc/spamassassin; /usr/etc/spamassassin; /etc/mail/spamassassin; /etc/spamassassin . Spamassassin will read *.cf in these directories, in alphanumeric order within each directory (similar to SysV-style startup scripts). In other words, it will read 10_misc.cf before 50_scores.cf and 20_body_tests.cf before 20_head_test.cf. Options in later files will override earlier files. The user preferences (such as scores to attach to each rule), are loaded from the file specified in the -p argument. If this is not specified, ~/.spamassassin/user_prefs is used if it exists. "spamassassin" will create this file if it does not exist, using user_prefs.template as a template. This file will be looked for in: /home/jm/perl584/etc/mail/spamassassin; /home/jm/perl584/etc/mail/spamassassin; /home/jm/perl584/share/spamassassin; /etc/spamassassin; /etc/mail/spamassassin; /usr/local/share/spamassassin; /usr/share/spamassassin. TAGGING The following two sections detail the tagging that takes place for messages. Note that if you use the -t argument, all mails will be tagged as if they are spam messages. TAGGING FOR SPAM MAILS If an incoming message is tagged as spam, instead of modifying the original message, SpamAssassin will create a new report message and attach the original message as a message/rfc822 MIME part (ensuring the original message is completely preserved and easier to recover). The new report message inherits the following headers (if they are present) from the original spam message: Subject: header The string "*****SPAM*****" is also prepended to the subject, if the "rewrite_subject 1" configuration option is given. From: header To: header Cc: header Date: header And (by default) these headers are added: X-Spam-Status: header A string, "Yes, hits=nn required=nn tests=xxx,xxx autolearn=(ham|spam|no)" is set in this header to reflect the filter status. X-Spam-Flag: header Set to "YES". X-Spam-Report: header Please note that the headers that added are now fully configurable via the add_header option. Please see the manpage for Mail::SpamAssassin::Conf(3) for more information. spam mail body text The SpamAssassin report is added to top of the mail message body, if the message is marked as spam. DEFAULT TAGGING FOR HAM (NON-SPAM) MAILS X-Spam-Status: header A string, "No, hits=nn required=nn tests=xxx,xxx autolearn=(ham|spam|no)" is set in this header to reflect the filter status. Added headers are fully configurable via the add_header configuration option. Please see the manpage for Mail::SpamAssassin::Conf(3) for more information. SPAM TRAPPING Quite often, if you've been on the internet for a while, you'll have accumulated a few old email accounts that nowadays get nothing but spam. SpamAssassin lets you set them up as aliases, as follows: spamtrap1: "| /path/to/spamassassin -r -w spamtrap1" This will add any incoming mail messages straight into spam-tracking databases, such as Vipul's Razor; send an explanatory reply message to the sender, from the *spamtrap1* address; then drop the mail into the bit-bucket. The explanatory reply text is taken from the SpamAssassin configuration file, where it is stored in the "spamtrap" lines. If you want to keep a copy of the mails, use something like this: spamtrap1: "| /path/to/spamassassin -r -w spamtrap1 -l /var/spam/caught" It is suggested you familiarise yourself with how MTAs run programs specified in aliases, if you plan to do this; for one thing, spamassassin will not run under your user id in this case. If you are nervous about this, create a user for spamtrapping, and set up spamassassin in its .forward file. INSTALLATION The spamassassin command is part of the Mail::SpamAssassin Perl module. Install this as a normal Perl module, using "perl -MCPAN -e shell", or by hand. For further details on how to install, please read the "INSTALL" file from the SpamAssassin distribution. ENVIRONMENT No environment variables, aside from those used by perl, are required to be set. SEE ALSO sa-learn(1) Mail::SpamAssassin(3) Mail::SpamAssassin::Conf(3) Mail::Audit(3) Razor(3) BUGS http://bugzilla.spamassassin.org/ AUTHOR Justin Mason PREREQUISITES "Mail::Audit" COREQUISITES "Net::DNS" "Razor"