Mail::SpamAssassin::Conf - SpamAssassin configuration file
# a comment
rewrite_header Subject *****SPAM*****
full PARA_A_2_C_OF_1618 /Paragraph .a.{0,10}2.{0,10}C. of S. 1618/i
describe PARA_A_2_C_OF_1618 Claims compliance with senate bill 1618header FROM_HAS_MIXED_NUMS From =~ /\d+[a-z]+\d+\S*@/i describe FROM_HAS_MIXED_NUMS From: contains numbers mixed in with letters
score A_HREF_TO_REMOVE 2.0
lang es describe FROM_FORGED_HOTMAIL Forzado From: simula ser de hotmail.com
SpamAssassin is configured using traditional UNIX-style configuration files,
loaded from the /usr/share/spamassassin and
/etc/mail/spamassassin directories.
The # character starts a comment, which continues until end of
line. NOTE: using the # character in the regular
expression rules requires escaping. i.e.: \#
Whitespace in the files is not significant, but please note that starting a line with whitespace is deprecated, as we reserve its use for multi-line rule definitions, at some point in the future.
Currently, each rule or configuration setting must fit on one-line; multi-line settings are not supported yet.
Paths can use ~ to refer to the user's home directory.
Where appropriate below, default values are listed in parentheses.
The following options can be used in both site-wide (local.cf)
and user-specific (user_prefs) configuration files to customize how
SpamAssassin handles incoming email messages.
n.nn
can be an integer or a real number. 5.0 is the default setting, and is quite
aggressive; it would be suitable for a single-user setup, but if you're an ISP
installing SpamAssassin, you should probably set the default to be more
conservative, like 8.0 or 10.0. It is not recommended to automatically delete
or discard messages marked as spam, as your users will
complain, but if you choose to do so, only delete messages with an
exceptionally high score such as 15.0 or higher. This option was previously
known as required_hits and that name is still accepted, but is
deprecated.
SYMBOLIC_TEST_NAME
is the symbolic name used by SpamAssassin for that test; for example,
'FROM_ENDS_IN_NUMS'.
If only one valid score is listed, then that score is always used for a test.
If four valid scores are listed, then the score that is used depends on how SpamAssassin is being used. The first score is used when both Bayes and network tests are disabled (score set 0). The second score is used when Bayes is disabled, but network tests are enabled (score set 1). The third score is used when Bayes is enabled and network tests are disabled (score set 2). The fourth score is used when Bayes is enabled and network tests are enabled (score set 3).
Setting a rule's score to 0 will disable that rule from running.
If any of the score values are surrounded by parenthesis '()', then all of the scores in the line are considered to be relative to the already set score. ie: '(3)' means increase the score for this rule by 3 points in all score sets. '(3) (0) (3) (0)' means increase the score for this rule by 3 in score sets 0 and 2 only.
If no score is given for a test by the end of the configuration, a default score is assigned: a score of 1.0 is used for all tests, except those who names begin with 'T_' (this is used to indicate a rule in testing) which receive 0.01.
Note that test names which begin with '__' are indirect rules used to compose meta-match rules and can also act as prerequisites to other rules. They are not scored or listed in the 'tests hit' reports, but assigning a score of 0 to an indirect rule will disable it from running.
whitelist_from_rcvd as explained below.
Whitelist and blacklist addresses are now file-glob-style patterns, so
friend@somewhere.com, *@isp.com, or
*.domain.net will all work. Specifically, * and
? are allowed, but all other metacharacters are not. Regular
expressions are not used for security reasons.
Multiple addresses per line, separated by spaces, is OK. Multiple
whitelist_from lines is also OK.
The headers checked for whitelist addresses are as follows: if
Resent-From is set, use that; otherwise check all addresses taken
from the following set of headers:
Envelope-Sender
Resent-Sender
X-Envelope-From
From
In addition, the ``envelope sender'' data, taken from the SMTP envelope data where this is available, is looked up.
e.g.
whitelist_from joe@example.com fred@example.com whitelist_from *@example.com
user_prefs file. The specified email address has to match exactly
the address previously used in a whitelist_from line.
e.g.
unwhitelist_from joe@example.com fred@example.com unwhitelist_from *@example.com
This string is matched against the reverse DNS lookup used during the
handover from the internet to your internal network's mail exchangers. It can
either be the full hostname, or the domain component of that hostname. In
other words, if the host that connected to your MX had an IP address that
mapped to 'sendinghost.spamassassin.org', you should specify
sendinghost.spamassassin.org or just
spamassassin.org here.
Note that this requires that internal_networks be correct. For
simple cases, it will be, but for a complex network, or running with DNS
checks off or with -L, you may get better results by setting that
parameter.
e.g.
whitelist_from_rcvd joe@example.com example.com whitelist_from_rcvd *@axkit.org sergeant.org
whitelist_from_rcvd, but used for the default
whitelist entries in the SpamAssassin distribution. The whitelist score is
lower, because these are often targets for spammer spoofing.
whitelist_from_rcvd that
sometimes send through a mail relay other than the listed ones. By default
mail with a From address that is in whitelist_from_rcvd that does
not match the relay will trigger a forgery rule. Including the address in
whitelist_allows_relay prevents that.
Whitelist and blacklist addresses are now file-glob-style patterns, so
friend@somewhere.com, *@isp.com, or
*.domain.net will all work. Specifically, * and
? are allowed, but all other metacharacters are not. Regular
expressions are not used for security reasons.
Multiple addresses per line, separated by spaces, is OK. Multiple
whitelist_allows_relays lines is also OK.
The specified email address does not have to match exactly the address previously used in a whitelist_from_rcvd line as it is compared to the address in the header.
e.g.
whitelist_allows_relays joe@example.com fred@example.com whitelist_allows_relays *@example.com
user_prefs file.
The specified email address has to match exactly the address previously used in a whitelist_from_rcvd line.
e.g.
unwhitelist_from_rcvd joe@example.com fred@example.com unwhitelist_from_rcvd *@axkit.org
whitelist_from.
user_prefs file.
e.g.
unblacklist_from joe@example.com fred@example.com unblacklist_from *@spammer.com
whitelist_from.
There are three levels of To-whitelisting, whitelist_to,
more_spam_to and all_spam_to. Users in the first
level may still get some spammish mails blocked, but users in
all_spam_to should never get mail blocked.
The headers checked for whitelist addresses are as follows: if
Resent-To or Resent-Cc are set, use those; otherwise
check all addresses taken from the following set of headers:
To
Cc
Apparently-To
Delivered-To
Envelope-Recipients
Apparently-Resent-To
X-Envelope-To
Envelope-To
X-Delivered-To
X-Original-To
X-Rcpt-To
X-Real-To
blacklist_from.
Subject, From or To lines tagged to
indicate spam. By setting this option, the header will be tagged with
STRING to indicate that a message is spam. For the From or To
headers, this will take the form of an RFC 2822 comment following the address
in parantheses. For the Subject header, this will be prepended to the original
subject. Note that you should only use the _REQD_ and _SCORE_ tags when
rewriting the Subject header unless report_safe is 0. Otherwise,
you may not be able to remove the SpamAssassin markup via the normal methods.
Parentheses are not permitted in STRING if rewriting the From or To headers. (They will be converted to square brackets.)
If rewrite_header subject is used, but the message being
rewritten does not already contain a Subject header, one will be
created.
A null value for STRING will remove any existing rewrite for
the specified header.
X-Spam-
(so a header_name Foo will generate a header called X-Spam-Foo).
header_name is restricted to the character set [A-Za-z0-9_-].
string can contain tags as explained below in the
TEMPLATE TAGS section. You can also use \n and
\t in the header to add newlines and tabulators as desired. A
backslash has to be written as \\, any other escaped chars will be silently
removed.
All headers will be folded if fold_headers is set to 1. Note:
Manually adding newlines via \n disables any further automatic
wrapping (ie: long header lines are possible). The lines will still be
properly folded (marked as continuing) though.
You can customize existing headers with add_header (only the specified subset of messages will be changed).
See also clear_headers
for removing headers.
Here are some examples (these are the defaults, note that Checker-Version can not be changed or removed):
add_header spam Flag _YESNOCAPS_ add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ tests=_TESTS_ autolearn=_AUTOLEARN_ version=_VERSION_ add_header all Level _STARS(*)_ add_header all Checker-Version SpamAssassin _VERSION_ (_SUBVERSION_) on _HOSTNAME_
X-Spam-
(so header_name will be appended to X-Spam-).
See also clear_headers
for removing all the headers at once.
Note that X-Spam-Checker-Version is not removable because the version information is needed by mail administrators and developers to debug problems. Without at least one header, it might not even be possible to determine that SpamAssassin is running.
Note that X-Spam-Checker-Version is not removable because the version information is needed by mail administrators and developers to debug problems. Without at least one header, it might not even be possible to determine that SpamAssassin is running.
If this option is set to 2, then original messages will be attached with a content type of text/plain instead of message/rfc822. This setting may be required for safety reasons on certain broken mail clients that automatically load attachments without any action by the user. This setting may also make it somewhat more difficult to extract or view the original message.
If this option is set to 0, incoming spam is only modified by adding some
X-Spam- headers and no changes will be made to the body. In
addition, a header named X-Spam-Report will be added to spam.
You can use the remove_header option to remove that header
after setting report_safe to 0.
See report_safe_copy_headers if you want to copy headers from the original mail into tagged messages.
Note that the language cannot always be recognized with sufficient confidence. In that case, no points will be assigned.
The rule UNWANTED_LANGUAGE_BODY is triggered based on how this
is set.
In your configuration, you must use the two or three letter language
specifier in lowercase, not the English name for the language. You may also
specify all if a desired language is not listed, or if you want
to allow any language. The default setting is all.
Examples:
ok_languages all (allow all languages) ok_languages en (only allow English) ok_languages en ja zh (allow English, Japanese, and Chinese)
Note: if there are multiple ok_languages lines, only the last one is used.
Select the languages to allow from the list below:
If you receive lots of spam in foreign languages, and never get any non-spam in these languages, this may help. Note that all ISO-8859-* character sets, and Windows code page character sets, are always permitted by default.
Set this to all to allow all character sets. This is the
default.
The rules CHARSET_FARAWAY, CHARSET_FARAWAY_BODY,
and CHARSET_FARAWAY_HEADERS are triggered based on how this is
set.
Examples:
ok_locales all (allow all locales) ok_locales en (only allow English) ok_locales en ja zh (allow English, Japanese, and Chinese)
Note: if there are multiple ok_locales lines, only the last one is used.
Select the locales to allow from the list below:
As nearly all DCC clients are auto-reporting these checksums you should set
this to a relatively high value, e.g. 999999 (this is DCC's MANY
count).
The default is 999999 for all these options.
The default is 5.
pyzor(1) command line. Note that
for security, only characters in the ranges A-Z, a-z, 0-9, -, _ and / are
permitted.
http://www.spamcop.net/. If this is not
set, SpamCop reports will go to a generic reporting address for SpamAssassin
users and your reports will probably have less weight in the SpamCop system.
MXes for your domain(s) and internal relays should
also be specified using the internal_networks
setting. When there are 'trusted' hosts that are not MXes or internal relays
for your domain(s) they should only be specified
in trusted_networks.
If a /mask is specified, it's considered a CIDR-style
'netmask', specified in bits. If it is not specified, but less than 4 octets
are specified with a trailing dot, that's considered a mask to allow all
addresses in the remaining octets. If a mask is not specified, and there is
not trailing dot, then just the single IP address specified is used, as if the
mask was /32.
Examples:
trusted_networks 192.168/16 127/8 # all in 192.168.*.* and 127.*.*.*
trusted_networks 212.17.35.15 # just that host
trusted_networks 127. # all in 127.*.*.*
This operates additively, so a trusted_networks line after
another one will result in all those networks becoming trusted. To clear out
the existing entries, use clear_trusted_networks.
If trusted_networks is not set and
internal_networks is, the value of internal_networks
will be used for this parameter.
If you're running with DNS checks enabled, SpamAssassin includes code to infer your trusted networks on the fly, so this may not be necessary. (Thanks to Scott Banister and Andrew Flury for the inspiration for this algorithm.) This inference works as follows:
trusted_networks, above.
This value is used when checking 'dial-up' or dynamic IP address
blocklists, in order to detect direct-to-MX spamming. Trusted relays that
accept mail directly from dial-up connections should not be listed in
internal_networks. List them only in
trusted_networks.
If trusted_networks is set and internal_networks
is not, the value of trusted_networks will be used for this
parameter.
If neither trusted_networks or internal_networks
is set, no addresses will be considered local; in other words, any relays past
the machine where SpamAssassin is running will be considered external.
queries left 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% timeout 15 15 14 14 13 11 10 8 5 3 0
In addition, whenever the effective timeout is lowered due to additional query results returning, the remaining queries are always given at least one more second before timing out, but the wait time will never exceed rbl_timeout.
For example, if 20 queries are made at the beginning of a message check and 16 queries have returned (leaving 20%), the remaining 4 queries must finish within 5 seconds of the beginning of the check or they will be timed out.
You can however specify your own list by specifying
dns_available test: domain1.tld domain2.tld domain3.tld
Please note, the DNS test queries for NS records.
SpamAssassin's network rules are run in parallel. This can cause overhead in terms of the number of file descriptors required; it is recommended that the minimum limit on file descriptors be raised to at least 256 for safety.
mean), and then once we have otherwise fully
calculated the score for this message (score), we calculate the
final score for the message as:
finalscore = score + (mean -
score) * factor
So if factor = 0.5, then we'll move to half way between the
calculated score and the mean. If factor = 0.3, then we'll move
about 1/3 of the way from the score toward the mean. factor = 1
means just use the long-term mean; factor = 0 mean just use the
calculated score.
PreferredModuleName SecondBest ThirdBest ...
ie. a space-separated list of perl module names. The default is:
DB_File GDBM_File NDBM_File SDBM_File
Note that certain tests are ignored when determining whether a message should be trained upon:
- rules with tflags set to 'learn' (the Bayesian rules)
- rules with tflags set to 'userconf' (user white/black-listing rules, etc)
- rules with tflags set to 'noautolearn'
Also note that auto-training occurs using scores from either scoreset 0 or 1, depending on what scoreset is used during message check. It is likely that the message check and auto-train scores will be different.
Note: SpamAssassin requires at least 3 points from the header, and 3 points from the body to auto-learn as spam. Therefore, the minimum working value for this option is 6.
bayes_ignore_header X-Upstream-Spamfilter
bayes_ignore_header X-Upstream-SomethingElse
sa-learn will also ignore the
listed addresses if it is invoked using the --use-ignores option.
One or more addresses can be listed, see whitelist_from.
Spam messages from certain senders may contain many words that frequently occur in ham. For example, one might read messages from a preferred bookstore but also get unwanted spam messages from other bookstores. If the unwanted messages are learned as spam then any messages discussing books, including the preferred bookstore and antiquarian messages would be in danger of being marked as spam. The addresses of the annoying bookstores would be listed. (Assuming they were halfway legitimate and didn't send you mail through myriad affiliates.)
Those who have pieces of spam in legitimate messages or otherwise receive ham messages containing potentially spammy words might fear that some spam messages might be in danger of being marked as ham. The addresses of the spam mailing lists, correspondents, etc. would be listed.
bayes_ignore_from for details.
spamassassin -r) as spam. If you do not want this to happen, set
this option to 0.
If this options is set the BayesStore::SQL module will override the set username with the value given. This could be useful for implementing global or group bayes databases.
This will be quite a bit faster, but may risk file corruption if the files are ever accessed by multiple clients at once, and one or more of them is accessing them through an NFS filesystem.
Note that different platforms require different locking systems.
The supported locking systems for type are as follows:
flock() lockingsysopen (..., O_CREAT|O_EXCL).nfssafe and flock are only available on UNIX, and win32 is only available on Windows. By default, SpamAssassin will choose either nfssafe or win32 depending on the platform in use.
The automatic wrapping can be disabled here. Note that this can generate very long lines.
report_safe, a few of the headers from the original
message are copied into the wrapper header (From, To, Cc, Subject, Date, etc.)
If you want to have other headers copied as well, you can add them using this
option. You can specify multiple headers on the same line, separated by
spaces, or you can just use multiple lines.
EnvelopeFrom pseudo-header, and for various rules such as SPF
checking.
By default, various MTAs will use different headers, such as the following:
X-Envelope-From
Envelope-Sender
X-Sender
Return-Path
SpamAssassin will attempt to use these, if some heuristics (such as the header placement in the message, or the absence of fetchmail signatures) appear to indicate that they are safe to use. However, it may choose the wrong headers in some mailserver configurations. (More discussion of this can be found in bug 2142 in the SpamAssassin BugZilla.)
To avoid this heuristic failure, the envelope_sender_header
setting may be helpful. Name the header that your MTA adds to messages
containing the address used at the MAIL FROM step of the SMTP transaction.
If the header in question contains < or >
characters at the start and end of the email address in the right-hand side,
as in the SMTP transaction, these will be stripped.
If the header is not found in a message, or if it's value does not contain
an @ sign, SpamAssassin will fall back to its default
heuristics.
(Note for MTA developers: we would prefer if the use of a single header be
avoided in future, since that precludes 'downstream' spam scanning.
http://wiki.apache.org/spamassassin/EnvelopeSenderInReceived
details a better proposal using the Received headers.)
example:
envelope_sender_header X-SA-Exim-Mail-From
Note that test names which begin with '__' are reserved for meta-match sub-rules, and are not scored or listed in the 'tests hit' reports.
Also note that by convention, rule descriptions should be limited in length to no more than 50 characters.
10_misc.cf configuration file in
/usr/share/spamassassin for an example.
If you change this, try to keep it under 78 columns. Each
report line appends to the existing template, so use clear_report_template
to restart.
Tags can be included as explained above.
10_misc.cf configuration
file in /usr/share/spamassassin for an example.
Each unsafe-report line appends to the existing template, so
use clear_unsafe_report_template
to restart.
Tags can be used in this template (see above for details).
These settings differ from the ones above, in that they are considered
'privileged'. Only users running spamassassin from their
procmailrc's or forward files, or sysadmins editing a file in
/etc/mail/spamassassin, can use them. spamd users
cannot use them in their user_prefs files, for security and
efficiency reasons, unless allow_user_rules is enabled (and then,
they may only add rules from below).
user_prefs files for use with spamd. It defaults to
off, because this could be a severe security hole. It may be possible for
users to gain root level access if spamd is run as root. It is
NOT a good idea, unless you have some other way of ensuring that users' tests
are safe. Don't use this unless you are certain you know what you are doing.
Furthermore, this option causes spamassassin to recompile all the tests each
time it processes a message for a user with a rule in his/her
user_prefs file, which could have a significant effect on server
load. It is not recommended.
Note that it is not currently possible to use allow_user_rules
to modify an existing system rule from a user_prefs file with
spamd.
SYMBOLIC_TEST_NAME
is a symbolic test name, such as 'FROM_ENDS_IN_NUMS'. header is
the name of a mail header, such as 'Subject', 'To', etc.
Appending :raw to the header name will inhibit decoding of
quoted-printable or base-64 encoded strings.
Appending :addr to the header name will cause everything
except the first email address to be removed from the header. For example, all
of the following will result in ``example@foo'':
Appending :name to the header name will cause everything
except the first real name to be removed from the header. For example, all of
the following will result in ``Foo Blah''
There are several special pseudo-headers that can be specified:
ALL
can be used to mean the text of all the message's headers.ToCc
can be used to mean the contents of both the 'To' and 'Cc'
headers.EnvelopeFrom
is the address used in the 'MAIL FROM:' phase of the SMTP transaction that
delivered this message, if this data has been made available by the SMTP
server.MESSAGEID
is a symbol meaning all Message-Id's found in the message; some mailing list
software moves the real 'Message-Id' to 'Resent-Message-Id' or
'X-Message-Id', then uses its own one in the 'Message-Id' header. The value
returned for this symbol is the text from all 3 headers, separated by
newlines.op is either =~ (contains regular expression) or
!~ (does not contain regular expression), and
pattern is a valid Perl regular expression, with
modifiers as regexp modifiers in the usual style. Note that
multi-line rules are not supported, even if you use x as a
modifier. Also note that the # character must be escaped
(\#) or else it will be considered to be the start of a comment
and not part of the regexp.
If the [if-unset: STRING] tag is present, then
STRING will be used if the header is not found in the mail
message.
Test names should not start with a number, and must contain only alphanumerics and underscores. It is suggested that lower-case characters not be used, and names have a length of no more than 22 characters, as an informal convention. Dashes are not allowed.
Note that test names which begin with '__' are reserved for meta-match sub-rules, and are not scored or listed in the 'tests hit' reports. Test names which begin with 'T_' are reserved for tests which are undergoing QA, and these are given a very low score.
If you add or modify a test, please be sure to run a sanity check
afterwards by running spamassassin --lint. This will avoid
confusing error messages, or other tests being skipped as a side-effect.
name_of_header is the name of
a header to test for existence. This is just a very simple version of the
above header tests.
name_of_eval_method
is the name of a method on the Mail::SpamAssassin::EvalTests
object. arguments are optional arguments to the function call.
trusted_networks logic, and query that
DNSBL zone. There's a few things to note:
check_rbl_sub()
calls must use that zone ID.
Also, if more than one IP address gets a DNSBL hit for a particular rule, it does not affect the score because rules only trigger once per message.
check_rbl_sub()
below.
In addition, you can test all untrusted IP addresses by placing '-untrusted' at the end of the set name.
Note that this requires that SpamAssassin know which relays are trusted.
For simple cases, SpamAssassin can make a good estimate. For complex cases,
you may get better results by setting trusted_networks
manually.
Note: the set name must be exactly the same for as the main query rule, including selections like '-notfirsthop' appearing at the end of the set name.
pattern is a Perl regular
expression. Note: as per the header tests, # must be escaped
(\#) or else it is considered the beginning of a comment.
The 'body' in this case is the textual parts of the message body; any non-text MIME parts are stripped, and the message decoded from Quoted-Printable or Base-64-encoded format if necessary. The message Subject header is considered part of the body and becomes the first paragraph when running the rules. All HTML tags and line breaks will be removed before matching.
pattern is a Perl regular
expression. Note: as per the header tests, # must be escaped
(\#) or else it is considered the beginning of a comment.
The 'uri' in this case is a list of all the URIs in the body of the email, and the test will be run on each and every one of those URIs, adjusting the score if a match is found. Use this test instead of one of the body tests when you need to match a URI, as it is more accurately bound to the start/end points of the URI, and will also be faster.
pattern is a Perl regular
expression. Note: as per the header tests, # must be escaped
(\#) or else it is considered the beginning of a comment.
The 'raw body' of a message is the raw data inside all textual parts. The text will be decoded from base64 or quoted-printable encoding, but HTML tags and line breaks will still be present. The pattern will be applied line-by-line.
pattern is a Perl regular
expression. Note: as per the header tests, # must be escaped
(\#) or else it is considered the beginning of a comment.
The full message is the pristine message headers plus the pristine message body, including all MIME data such as images, other attachments, MIME boundaries, etc.
meta META1 TEST1 && !(TEST2 || TEST3)
Note that English language operators (``and'', ``or'') will be treated as
rule names, and that there is no XOR operator.
meta META2 (3 * TEST1 - 2 * TEST2) > 0
Note that Perl builtins and functions, like abs(),
can't be used, and will be treated as rule names.
If you want to define a meta-rule, but do not want its individual sub-rules to count towards the final score unless the entire meta-rule matches, give the sub-rules names that start with '__' (two underscores). SpamAssassin will ignore these for scoring.
bayes_auto_learn
and use_auto_whitelist
for more information about tflag interaction with those systems. The following
flags can be set:
These settings differ from the ones above, in that they are considered 'more
privileged' -- even more than the ones in the PRIVILEGED
SETTINGS section. No matter what allow_user_rules is set
to, these can never be set from a user's user_prefs file.
The version_tag will be lowercased, and any non-alphanumeric or period character will be replaced by an underscore.
e.g.
version_tag myrules1 # version=2.41-myrules1
These tests are only run as part of the test suite - they should not affect the general running of SpamAssassin.
pyzor client instead of relying on SpamAssassin to find it in the
current PATH. Note that if taint mode is enabled in the Perl
interpreter, you should use this, as the current PATH will have been cleared.
dcc_path is not specified, it will default to looking in
dcc_home/bin for dcc client instead of relying on SpamAssassin to
find it in the current PATH. If it isn't found there, it will look in the
current PATH. If a dccifd socket is found in
dcc_home, it will use that interface that instead of
dccproc.
dcc_dccifd_path is not specified, it will default to
looking in dcc_home If a dccifd socket is found, it
will use it instead of dccproc.
dccproc client instead of relying on SpamAssassin to find it in
the current PATH. Note that if taint mode is enabled in the Perl
interpreter, you should use this, as the current PATH will have been cleared.
dccproc(8) command. Please
note that only [A-Z -] is allowed (security).
The default is -R.
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.
Note that certain tests are ignored when determining the final message score:
- rules with tflags set to 'noautolearn'
~/.spamassassin directory with mode 0700, but for
system-wide SpamAssassin use, you may want to share this across all users.
_toks, _seen
etc. appended to this filename; so the default setting results in files called
~/.spamassassin/bayes_seen,
~/.spamassassin/bayes_toks etc.
By default, each user has their own, in their ~/.spamassassin
directory with mode 0700/0600, but for system-wide SpamAssassin use, you may
want to reduce disk space usage by sharing this across all users. (However it
should be noted that Bayesian filtering appears to be more effective with an
individual database per user.)
Make sure you specify this using the 'x' mode bits set, as it may also be used to create directories. However, if a file is created, the resulting file will not have any execute bits set (the umask is set to 111).
Make sure you specify this using the 'x' mode bits set, as it may also be used to create directories. However, if a file is created, the resulting file will not have any execute bits set (the umask is set to 111).
This option give the connect string used to connect to the SQL based Bayes storage.
This option gives the username used by the above DSN.
This option gives the password used by the above DSN.
DBI:mysql:spamassassin:localhost
If you load user scores from an LDAP directory, this will set the DSN used to connect. You have to write the DSN as an LDAP URL, the components being the host and port to connect to, the base DN for the seasrch, the scope of the search (base, one or sub), the single attribute being the multivalued attribute used to hold the configuration data (space separated pairs of key and value, just as in a file) and finally the filter being the expression used to filter out the wanted username. Note that the filter expression is being used in a sprintf statement with the username as the only parameter, thus is can hold a single __USERNAME__ expression. This will be replaced with the username.
Example:
ldap://localhost:389/dc=koehntopp,dc=de?spamassassinconfig?uid=__USERNAME__
The query must be one one continuous line in order to parse correctly.
Here are several example queries, please note that these are broken up for easy reading, in your config it should be one continuous line.
SELECT preference, value FROM _TABLE_ WHERE username = _USERNAME_
OR username = '@GLOBAL' ORDER BY username ASC
SELECT preference, value FROM _TABLE_ WHERE username = _USERNAME_
OR username = '@GLOBAL' OR username = '@~'||_DOMAIN_ ORDER BY username
ASC
SELECT preference, value FROM _TABLE_ WHERE username = _USERNAME_
OR username = '@GLOBAL' ORDER BY username DESC
DBI:mysql:spamassassin:localhost
Example: cn=master,dc=koehntopp,dc=de
PluginModuleName is
the perl module name, used to create the plugin object itself.
/path/to/module.pm is the file to load, containing the
module's perl code; if it's specified as a relative path, it's considered to
be relative to the current configuration file. If it is omitted, the module
will be loaded using perl's search path (the @INC array).
See Mail::SpamAssassin::Plugin for more details on writing
plugins.
filename. Relative paths are
considered relative to the current configuration file or user preferences
file.
endif line, will be
ignored unless the conditional expression evaluates as true (in the perl
sense; that is, defined and non-0).
The conditional accepts a limited subset of perl for security -- just enough to perform basic arithmetic comparisons. The following input is accepted:
( ) - + * / _ . , < = > ! ~ 0-9 whitespace
x.yyyzzz, where x is major version, y
is minor version, and z is maintenance version. So 3.0.0 is
3.000000, and 3.4.80 is 3.004080.
plugin(Name::Of::Plugin)1 if the plugin named
Name::Of::Plugin is loaded, or undef otherwise.
If the end of a configuration file is reached while still inside a if
scope, a warning will be issued, but parsing will restart on the next
file.
For example:
if (version > 3.000000)
header MY_FOO ...
endifloadplugin MyPlugin plugintest.pm
if plugin (MyPlugin)
header MY_PLUGIN_FOO eval:check_for_foo()
score MY_PLUGIN_FOO 0.1
endif
if
plugin(PluginModuleName).
Note: The version used is in the internal SpamAssassin version format which
is x.yyyzzz, where x is major version, y is minor version, and z
is maintenance version. So 3.0.0 is 3.000000, and 3.4.80 is
3.004080.
The following tags can be used as placeholders in certain
options. They will be replaced by the corresponding value when they are
used.
Some tags can take an argument (in parentheses). The argument is optional, and the default is shown below.
_YESNOCAPS_ "YES"/"NO" for is/isn't spam
_YESNO_ "Yes"/"No" for is/isn't spam
_SCORE(PAD)_ message score, if PAD is included and is either spaces or
zeroes, then pad scores with that many spaces or zeroes
(default, none) ie: _SCORE(0)_ makes 2.4 become 02.4,
_SCORE(00)_ is 002.4. 12.3 would be 12.3 and 012.3
respectively.
_REQD_ message threshold
_VERSION_ version (eg. 3.0.0 or 3.1.0-r26142-foo1)
_SUBVERSION_ sub-version/code revision date (eg. 2004-01-10)
_HOSTNAME_ hostname of the machine the mail was processed on
_REMOTEHOSTNAME_ hostname of the machine the mail was sent from, only
available with spamd
_REMOTEHOSTADDR_ ip address of the machine the mail was sent from, only
available with spamd
_BAYES_ bayes score
_TOKENSUMMARY_ number of new, neutral, spammy, and hammy tokens found
_BAYESTC_ number of new tokens found
_BAYESTCLEARNED_ number of seen tokens found
_BAYESTCSPAMMY_ number of spammy tokens found
_BAYESTCHAMMY_ number of hammy tokens found
_HAMMYTOKENS(N)_ the N most significant hammy tokens (default, 5)
_SPAMMYTOKENS(N)_ the N most significant spammy tokens (default, 5)
_AWL_ AWL modifier
_DATE_ rfc-2822 date of scan
_STARS(*)_ one * (use any character) for each score point (note: this
is limited to 50 'stars' to stay on the right side of the RFCs)
_RELAYSTRUSTED_ relays used and deemed to be trusted
_RELAYSUNTRUSTED_ relays used that can not be trusted
_AUTOLEARN_ autolearn status ("ham", "no", "spam", "disabled",
"failed", "unavailable")
_TESTS(,)_ tests hit separated by , (or other separator)
_TESTSSCORES(,)_ as above, except with scores appended (eg. AWL=-3.0,...)
_DCCB_ DCC's "Brand"
_DCCR_ DCC's results
_PYZOR_ Pyzor results
_RBL_ full results for positive RBL queries in DNS URI format
_LANGUAGES_ possible languages of mail
_PREVIEW_ content preview
_REPORT_ terse report of tests hit (for header reports)
_SUMMARY_ summary of tests hit for standard report (for body reports)
_CONTACTADDRESS_ contents of the 'report_contact' setting
The HAMMYTOKENS and SPAMMYTOKENS tags have an
optional second argument which specifies a format. See the
HAMMYTOKENS/SPAMMYTOKENS TAG FORMAT section, below, for
details.
The HAMMYTOKENS and SPAMMYTOKENS tags have an
optional second argument which specifies a format:
_SPAMMYTOKENS(N,FMT)_, _HAMMYTOKENS(N,FMT)_ The
following formats are available:
add_header all Spammy _SPAMMYTOKENS(2,short)_
Results in message header:
X-Spam-Spammy: remove.php, UD:jpg
Indicating that the top two spammy tokens found are remove.php
and UD:jpg. (The token itself follows the last colon, the text
before the colon indicates something about the token. UD means
the token looks like it might be part of a domain name.)
add_header all Spammy _SPAMMYTOKENS(2,compact)_
Results in message header:
0.989-6--remove.php, 0.988-+--UD:jpg
Indicating that the probabilities of the top two tokens are 0.989 and
0.988, respectively. The first token has a declassification distance of 6,
meaning that if the token had appeared in at least 6 more ham messages it
would not be considered spammy. The + for the second token
indicates a declassification distance greater than 9.
For example, preference file entry:
add_header all Spammy _SPAMMYTOKENS(2,long)_
Results in message header:
X-Spam-Spammy: 0.989-6--0h-4s--4d--remove.php,
0.988-33--2h-25s--1d--UD:jpg
In addition to the information provided by the compact option, the long
option shows that the first token appeared in zero ham messages and four spam
messages, and that it was last seen four days ago. The second token appeared
in two ham messages, 25 spam messages and was last seen one day ago. (Unlike
the compact
option, the long option shows declassification distances that are greater than
9.)
A line starting with the text lang xx will only be interpreted
if the user is in that locale, allowing test descriptions and templates to be
set for that language.
Mail::SpamAssassin spamassassin
spamd