1Mail::SpamAssassin::ConUfs(e3r)Contributed Perl DocumentMaatiilo:n:SpamAssassin::Conf(3)
2
6 Mail::SpamAssassin::Conf - SpamAssassin configuration file
7
9 # a comment
10 rewrite_header Subject *****SPAM*****
12 full PARA_A_2_C_OF_1618 /Paragraph .a.{0,10}2.{0,10}C. of S. 1618/i
14 describe PARA_A_2_C_OF_1618 Claims compliance with senate bill 1618
15 header FROM_HAS_MIXED_NUMS From =~ /\d+[a-z]+\d+\S*@/i
17 describe FROM_HAS_MIXED_NUMS From: contains numbers mixed in with letters
18 score A_HREF_TO_REMOVE 2.0
20 lang es describe FROM_FORGED_HOTMAIL Forzado From: simula ser de hotmail.com
22 lang pt_BR report O programa detetor de Spam ZOE [...]
24
26 SpamAssassin is configured using traditional UNIX-style configuration
27 files, loaded from the "/usr/share/spamassassin" and
28 "/etc/mail/spamassassin" directories.
29 The following web page lists the most important configuration settings
31 used to configure SpamAssassin; novices are encouraged to read it
32 first:
33 http://wiki.apache.org/spamassassin/ImportantInitialConfigItems
35
37 The "#" character starts a comment, which continues until end of line.
38 NOTE: if the "#" character is to be used as part of a rule or
39 configuration option, it must be escaped with a backslash. i.e.: "\#"
40 Whitespace in the files is not significant, but please note that
42 starting a line with whitespace is deprecated, as we reserve its use
43 for multi-line rule definitions, at some point in the future.
44 Currently, each rule or configuration setting must fit on one-line;
46 multi-line settings are not supported yet.
47 File and directory paths can use "~" to refer to the user's home
49 directory, but no other shell-style path extensions such as globing or
50 "~user/" are supported.
51 Where appropriate below, default values are listed in parentheses.
53
55 The following options can be used in both site-wide ("local.cf") and
56 user-specific ("user_prefs") configuration files to customize how
57 SpamAssassin handles incoming email messages.
58 SCORING OPTIONS
60 required_score n.nn (default: 5)
61 Set the score required before a mail is considered spam. "n.nn"
62 can be an integer or a real number. 5.0 is the default setting,
63 and is quite aggressive; it would be suitable for a single-user
64 setup, but if you're an ISP installing SpamAssassin, you should
65 probably set the default to be more conservative, like 8.0 or 10.0.
66 It is not recommended to automatically delete or discard messages
67 marked as spam, as your users will complain, but if you choose to
68 do so, only delete messages with an exceptionally high score such
69 as 15.0 or higher. This option was previously known as
70 "required_hits" and that name is still accepted, but is deprecated.
71 score SYMBOLIC_TEST_NAME n.nn [ n.nn n.nn n.nn ]
73 Assign scores (the number of points for a hit) to a given test.
74 Scores can be positive or negative real numbers or integers.
75 "SYMBOLIC_TEST_NAME" is the symbolic name used by SpamAssassin for
76 that test; for example, 'FROM_ENDS_IN_NUMS'.
77 If only one valid score is listed, then that score is always used
79 for a test.
80 If four valid scores are listed, then the score that is used
82 depends on how SpamAssassin is being used. The first score is used
83 when both Bayes and network tests are disabled (score set 0). The
84 second score is used when Bayes is disabled, but network tests are
85 enabled (score set 1). The third score is used when Bayes is
86 enabled and network tests are disabled (score set 2). The fourth
87 score is used when Bayes is enabled and network tests are enabled
88 (score set 3).
89 Setting a rule's score to 0 will disable that rule from running.
91 If any of the score values are surrounded by parenthesis '()', then
93 all of the scores in the line are considered to be relative to the
94 already set score. ie: '(3)' means increase the score for this
95 rule by 3 points in all score sets. '(3) (0) (3) (0)' means
96 increase the score for this rule by 3 in score sets 0 and 2 only.
97 If no score is given for a test by the end of the configuration, a
99 default score is assigned: a score of 1.0 is used for all tests,
100 except those whose names begin with 'T_' (this is used to indicate
101 a rule in testing) which receive 0.01.
102 Note that test names which begin with '__' are indirect rules used
104 to compose meta-match rules and can also act as prerequisites to
105 other rules. They are not scored or listed in the 'tests hit'
106 reports, but assigning a score of 0 to an indirect rule will
107 disable it from running.
108 WHITELIST AND BLACKLIST OPTIONS
110 whitelist_from user@example.com
111 Used to whitelist sender addresses which send mail that is often
112 tagged (incorrectly) as spam.
113 Use of this setting is not recommended, since it blindly trusts the
115 message, which is routinely and easily forged by spammers and phish
116 senders. The recommended solution is to instead use
117 "whitelist_auth" or other authenticated whitelisting methods, or
118 "whitelist_from_rcvd".
119 Whitelist and blacklist addresses are now file-glob-style patterns,
121 so "friend@somewhere.com", "*@isp.com", or "*.domain.net" will all
122 work. Specifically, "*" and "?" are allowed, but all other
123 metacharacters are not. Regular expressions are not used for
124 security reasons. Matching is case-insensitive.
125 Multiple addresses per line, separated by spaces, is OK. Multiple
127 "whitelist_from" lines are also OK.
128 The headers checked for whitelist addresses are as follows: if
130 "Resent-From" is set, use that; otherwise check all addresses taken
131 from the following set of headers:
132 Envelope-Sender
134 Resent-Sender
135 X-Envelope-From
136 From
137 In addition, the "envelope sender" data, taken from the SMTP
139 envelope data where this is available, is looked up. See
140 "envelope_sender_header".
141 e.g.
143 whitelist_from joe@example.com fred@example.com
145 whitelist_from *@example.com
146 unwhitelist_from user@example.com
148 Used to override a default whitelist_from entry, so for example a
149 distribution whitelist_from can be overridden in a local.cf file,
150 or an individual user can override a whitelist_from entry in their
151 own "user_prefs" file. The specified email address has to match
152 exactly (although case-insensitively) the address previously used
153 in a whitelist_from line, which implies that a wildcard only
154 matches literally the same wildcard (not 'any' address).
155 e.g.
157 unwhitelist_from joe@example.com fred@example.com
159 unwhitelist_from *@example.com
160 whitelist_from_rcvd addr@lists.sourceforge.net sourceforge.net
162 Works similarly to whitelist_from, except that in addition to
163 matching a sender address, a relay's rDNS name or its IP address
164 must match too for the whitelisting rule to fire. The first
165 parameter is a sender's e-mail address to whitelist, and the second
166 is a string to match the relay's rDNS, or its IP address. Matching
167 is case-insensitive.
168 This second parameter is matched against a TCP-info information
170 field as provided in a FROM clause of a trace information (i.e. in
171 a Received header field, see RFC 5321). Only the Received header
172 fields inserted by trusted hosts are considered. This parameter can
173 either be a full hostname, or a domain component of that hostname,
174 or an IP address (optionally followed by a slash and a prefix
175 length) in square brackets. The address prefix (mask) length with a
176 slash may stand within brackets along with an address, or may
177 follow the bracketed address. Reverse DNS lookup is done by an MTA,
178 not by SpamAssassin.
179 For backward compatibility as an alternative to a CIDR notation, an
181 IPv4 address in brackets may be truncated on classful boundaries to
182 cover whole subnets, e.g. "[10.1.2.3]", "[10.1.2]", "[10.1]",
183 "[10]".
184 In other words, if the host that connected to your MX had an IP
186 address 192.0.2.123 that mapped to 'sendinghost.example.org', you
187 should specify "sendinghost.example.org", or "example.org", or
188 "[192.0.2.123]", or "[192.0.2.0/24]", or "[192.0.2]" here.
189 Note that this requires that "internal_networks" be correct. For
191 simple cases, it will be, but for a complex network you may get
192 better results by setting that parameter.
193 It also requires that your mail exchangers be configured to perform
195 DNS reverse lookups on the connecting host's IP address, and to
196 record the result in the generated Received header field according
197 to RFC 5321.
198 e.g.
200 whitelist_from_rcvd joe@example.com example.com
202 whitelist_from_rcvd *@* mail.example.org
203 whitelist_from_rcvd *@axkit.org [192.0.2.123]
204 whitelist_from_rcvd *@axkit.org [192.0.2.0/24]
205 whitelist_from_rcvd *@axkit.org [192.0.2.0]/24
206 whitelist_from_rcvd *@axkit.org [2001:db8:1234::/48]
207 whitelist_from_rcvd *@axkit.org [2001:db8:1234::]/48
208 def_whitelist_from_rcvd addr@lists.sourceforge.net sourceforge.net
210 Same as "whitelist_from_rcvd", but used for the default whitelist
211 entries in the SpamAssassin distribution. The whitelist score is
212 lower, because these are often targets for spammer spoofing.
213 whitelist_allows_relays user@example.com
215 Specify addresses which are in "whitelist_from_rcvd" that sometimes
216 send through a mail relay other than the listed ones. By default
217 mail with a From address that is in "whitelist_from_rcvd" that does
218 not match the relay will trigger a forgery rule. Including the
219 address in "whitelist_allows_relay" prevents that.
220 Whitelist and blacklist addresses are now file-glob-style patterns,
222 so "friend@somewhere.com", "*@isp.com", or "*.domain.net" will all
223 work. Specifically, "*" and "?" are allowed, but all other
224 metacharacters are not. Regular expressions are not used for
225 security reasons. Matching is case-insensitive.
226 Multiple addresses per line, separated by spaces, is OK. Multiple
228 "whitelist_allows_relays" lines are also OK.
229 The specified email address does not have to match exactly the
231 address previously used in a whitelist_from_rcvd line as it is
232 compared to the address in the header.
233 e.g.
235 whitelist_allows_relays joe@example.com fred@example.com
237 whitelist_allows_relays *@example.com
238 unwhitelist_from_rcvd user@example.com
240 Used to override a default whitelist_from_rcvd entry, so for
241 example a distribution whitelist_from_rcvd can be overridden in a
242 local.cf file, or an individual user can override a
243 whitelist_from_rcvd entry in their own "user_prefs" file.
244 The specified email address has to match exactly the address
246 previously used in a whitelist_from_rcvd line.
247 e.g.
249 unwhitelist_from_rcvd joe@example.com fred@example.com
251 unwhitelist_from_rcvd *@axkit.org
252 blacklist_from user@example.com
254 Used to specify addresses which send mail that is often tagged
255 (incorrectly) as non-spam, but which the user doesn't want. Same
256 format as "whitelist_from".
257 unblacklist_from user@example.com
259 Used to override a default blacklist_from entry, so for example a
260 distribution blacklist_from can be overridden in a local.cf file,
261 or an individual user can override a blacklist_from entry in their
262 own "user_prefs" file. The specified email address has to match
263 exactly the address previously used in a blacklist_from line.
264 e.g.
266 unblacklist_from joe@example.com fred@example.com
268 unblacklist_from *@spammer.com
269 whitelist_to user@example.com
271 If the given address appears as a recipient in the message headers
272 (Resent-To, To, Cc, obvious envelope recipient, etc.) the mail will
273 be whitelisted. Useful if you're deploying SpamAssassin system-
274 wide, and don't want some users to have their mail filtered. Same
275 format as "whitelist_from".
276 There are three levels of To-whitelisting, "whitelist_to",
278 "more_spam_to" and "all_spam_to". Users in the first level may
279 still get some spammish mails blocked, but users in "all_spam_to"
280 should never get mail blocked.
281 The headers checked for whitelist addresses are as follows: if
283 "Resent-To" or "Resent-Cc" are set, use those; otherwise check all
284 addresses taken from the following set of headers:
285 To
287 Cc
288 Apparently-To
289 Delivered-To
290 Envelope-Recipients
291 Apparently-Resent-To
292 X-Envelope-To
293 Envelope-To
294 X-Delivered-To
295 X-Original-To
296 X-Rcpt-To
297 X-Real-To
298 more_spam_to user@example.com
300 See above.
301 all_spam_to user@example.com
303 See above.
304 blacklist_to user@example.com
306 If the given address appears as a recipient in the message headers
307 (Resent-To, To, Cc, obvious envelope recipient, etc.) the mail will
308 be blacklisted. Same format as "blacklist_from".
309 whitelist_auth user@example.com
311 Used to specify addresses which send mail that is often tagged
312 (incorrectly) as spam. This is different from "whitelist_from" and
313 "whitelist_from_rcvd" in that it first verifies that the message
314 was sent by an authorized sender for the address, before
315 whitelisting.
316 Authorization is performed using one of the installed sender-
318 authorization schemes: SPF (using
319 "Mail::SpamAssassin::Plugin::SPF"), or DKIM (using
320 "Mail::SpamAssassin::Plugin::DKIM"). Note that those plugins must
321 be active, and working, for this to operate.
322 Using "whitelist_auth" is roughly equivalent to specifying
324 duplicate "whitelist_from_spf", "whitelist_from_dk", and
325 "whitelist_from_dkim" lines for each of the addresses specified.
326 e.g.
328 whitelist_auth joe@example.com fred@example.com
330 whitelist_auth *@example.com
331 def_whitelist_auth user@example.com
333 Same as "whitelist_auth", but used for the default whitelist
334 entries in the SpamAssassin distribution. The whitelist score is
335 lower, because these are often targets for spammer spoofing.
336 unwhitelist_auth user@example.com
338 Used to override a "whitelist_auth" entry. The specified email
339 address has to match exactly the address previously used in a
340 "whitelist_auth" line.
341 e.g.
343 unwhitelist_auth joe@example.com fred@example.com
345 unwhitelist_auth *@example.com
346 enlist_uri_host (listname) host ...
348 Adds one or more host names or domain names to a named list of URI
349 domains. The named list can then be consulted through a
350 check_uri_host_listed() eval rule implemented by the WLBLEval
351 plugin, which takes the list name as an argument. Parenthesis
352 around a list name are literal - a required syntax.
353 Host names may optionally be prefixed by an exclamantion mark '!',
355 which produces false as a result if this entry matches. This makes
356 it easier to exclude some subdomains when their superdomain is
357 listed, for example:
358 enlist_uri_host (MYLIST) !sub1.example.com !sub2.example.com example.com
360 No wildcards are supported, but subdomains do match implicitly.
362 Lists are independent. Search for each named list starts by looking
363 up the full hostname first, then leading fields are progressively
364 stripped off (e.g.: sub.example.com, example.com, com) until a
365 match is found or we run out of fields. The first matching entry
366 (the most specific) determines if a lookup yielded a true (no '!'
367 prefix) or a false (with a '!' prefix) result.
368 If an URL found in a message contains an IP address in place of a
370 host name, the given list must specify the exact same IP address
371 (instead of a host name) in order to match.
372 Use the delist_uri_host directive to neutralize previous
374 enlist_uri_host settings.
375 Enlisting to lists named 'BLACK' and 'WHITE' have their shorthand
377 directives blacklist_uri_host and whitelist_uri_host and
378 corresponding default rules, but the names 'BLACK' and 'WHITE' are
379 otherwise not special or reserved.
380 delist_uri_host [ (listname) ] host ...
382 Removes one or more specified host names from a named list of URI
383 domains. Removing an unlisted name is ignored (is not an error).
384 Listname is optional, if specified then just the named list is
385 affected, otherwise hosts are removed from all URI host lists
386 created so far. Parenthesis around a list name are a required
387 syntax.
388 Note that directives in configuration files are processed in
390 sequence, the delist_uri_host only applies to previously listed
391 entries and has no effect on enlisted entries in yet-to-be-
392 processed directives.
393 For convenience (similarity to the enlist_uri_host directive)
395 hostnames may be prefixed by a an exclamation mark, which is
396 stripped off from each name and has no meaning here.
397 enlist_addrlist (listname) user@example.com
399 Adds one or more addresses to a named list of addresses. The named
400 list can then be consulted through a check_from_in_list() or a
401 check_to_in_list() eval rule implemented by the WLBLEval plugin,
402 which takes the list name as an argument. Parenthesis around a list
403 name are literal - a required syntax.
404 Listed addresses are file-glob-style patterns, so
406 "friend@somewhere.com", "*@isp.com", or "*.domain.net" will all
407 work. Specifically, "*" and "?" are allowed, but all other
408 metacharacters are not. Regular expressions are not used for
409 security reasons. Matching is case-insensitive.
410 Multiple addresses per line, separated by spaces, is OK. Multiple
412 "enlist_addrlist" lines are also OK.
413 Enlisting an address to the list named blacklist_to is synonymous
415 to using the directive blacklist_to
416 Enlisting an address to the list named blacklist_from is synonymous
418 to using the directive blacklist_from
419 Enlisting an address to the list named whitelist_to is synonymous
421 to using the directive whitelist_to
422 Enlisting an address to the list named whitelist_from is synonymous
424 to using the directive whitelist_from
425 e.g.
427 enlist_addrlist (PAYPAL_ADDRESS) service@paypal.com
429 enlist_addrlist (PAYPAL_ADDRESS) *@paypal.co.uk
430 blacklist_uri_host host-or-domain ...
432 Is a shorthand for a directive: enlist_uri_host (BLACK) host ...
433 Please see directives enlist_uri_host and delist_uri_host for
435 details.
436 whitelist_uri_host host-or-domain ...
438 Is a shorthand for a directive: enlist_uri_host (BLACK) host ...
439 Please see directives enlist_uri_host and delist_uri_host for
441 details.
442 BASIC MESSAGE TAGGING OPTIONS
444 rewrite_header { subject | from | to } STRING
445 By default, suspected spam messages will not have the "Subject",
446 "From" or "To" lines tagged to indicate spam. By setting this
447 option, the header will be tagged with "STRING" to indicate that a
448 message is spam. For the From or To headers, this will take the
449 form of an RFC 2822 comment following the address in parantheses.
450 For the Subject header, this will be prepended to the original
451 subject. Note that you should only use the _REQD_ and _SCORE_ tags
452 when rewriting the Subject header if "report_safe" is 0. Otherwise,
453 you may not be able to remove the SpamAssassin markup via the
454 normal methods. More information about tags is explained below in
455 the TEMPLATE TAGS section.
456 Parentheses are not permitted in STRING if rewriting the From or To
458 headers. (They will be converted to square brackets.)
459 If "rewrite_header subject" is used, but the message being
461 rewritten does not already contain a "Subject" header, one will be
462 created.
463 A null value for "STRING" will remove any existing rewrite for the
465 specified header.
466 add_header { spam | ham | all } header_name string
468 Customized headers can be added to the specified type of messages
469 (spam, ham, or "all" to add to either). All headers begin with
470 "X-Spam-" (so a "header_name" Foo will generate a header called
471 X-Spam-Foo). header_name is restricted to the character set
472 [A-Za-z0-9_-].
473 The order of "add_header" configuration options is preserved,
475 inserted headers will follow this order of declarations. When
476 combining "add_header" with "clear_headers" and "remove_header",
477 keep in mind that "add_header" appends a new header to the current
478 list, after first removing any existing header fields of the same
479 name. Note also that "add_header", "clear_headers" and
480 "remove_header" may appear in multiple .cf files, which are
481 interpreted in alphabetic order.
482 "string" can contain tags as explained below in the TEMPLATE TAGS
484 section. You can also use "\n" and "\t" in the header to add
485 newlines and tabulators as desired. A backslash has to be written
486 as \\, any other escaped chars will be silently removed.
487 All headers will be folded if fold_headers is set to 1. Note:
489 Manually adding newlines via "\n" disables any further automatic
490 wrapping (ie: long header lines are possible). The lines will still
491 be properly folded (marked as continuing) though.
492 You can customize existing headers with add_header (only the
494 specified subset of messages will be changed).
495 See also "clear_headers" and "remove_header" for removing headers.
497 Here are some examples (these are the defaults, note that Checker-
499 Version can not be changed or removed):
500 add_header spam Flag _YESNOCAPS_
502 add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ tests=_TESTS_ autolearn=_AUTOLEARN_ version=_VERSION_
503 add_header all Level _STARS(*)_
504 add_header all Checker-Version SpamAssassin _VERSION_ (_SUBVERSION_) on _HOSTNAME_
505 remove_header { spam | ham | all } header_name
507 Headers can be removed from the specified type of messages (spam,
508 ham, or "all" to remove from either). All headers begin with
509 "X-Spam-" (so "header_name" will be appended to "X-Spam-").
510 See also "clear_headers" for removing all the headers at once.
512 Note that X-Spam-Checker-Version is not removable because the
514 version information is needed by mail administrators and developers
515 to debug problems. Without at least one header, it might not even
516 be possible to determine that SpamAssassin is running.
517 clear_headers
519 Clear the list of headers to be added to messages. You may use
520 this before any add_header options to prevent the default headers
521 from being added to the message.
522 "add_header", "clear_headers" and "remove_header" may appear in
524 multiple .cf files, which are interpreted in alphabetic order, so
525 "clear_headers" in a later file will remove all added headers from
526 previously interpreted configuration files, which may or may not be
527 desired.
528 Note that X-Spam-Checker-Version is not removable because the
530 version information is needed by mail administrators and developers
531 to debug problems. Without at least one header, it might not even
532 be possible to determine that SpamAssassin is running.
533 report_safe ( 0 | 1 | 2 ) (default: 1)
535 if this option is set to 1, if an incoming message is tagged as
536 spam, instead of modifying the original message, SpamAssassin will
537 create a new report message and attach the original message as a
538 message/rfc822 MIME part (ensuring the original message is
539 completely preserved, not easily opened, and easier to recover).
540 If this option is set to 2, then original messages will be attached
542 with a content type of text/plain instead of message/rfc822. This
543 setting may be required for safety reasons on certain broken mail
544 clients that automatically load attachments without any action by
545 the user. This setting may also make it somewhat more difficult to
546 extract or view the original message.
547 If this option is set to 0, incoming spam is only modified by
549 adding some "X-Spam-" headers and no changes will be made to the
550 body. In addition, a header named X-Spam-Report will be added to
551 spam. You can use the remove_header option to remove that header
552 after setting report_safe to 0.
553 See report_safe_copy_headers if you want to copy headers from the
555 original mail into tagged messages.
556 report_wrap_width (default: 70)
558 This option sets the wrap width for description lines in the
559 X-Spam-Report header, not accounting for tab width.
560 LANGUAGE OPTIONS
562 ok_locales xx [ yy zz ... ] (default: all)
563 This option is used to specify which locales are considered OK for
564 incoming mail. Mail using the character sets that are allowed by
565 this option will not be marked as possibly being spam in a foreign
566 language.
567 If you receive lots of spam in foreign languages, and never get any
569 non-spam in these languages, this may help. Note that all
570 ISO-8859-* character sets, and Windows code page character sets,
571 are always permitted by default.
572 Set this to "all" to allow all character sets. This is the
574 default.
575 The rules "CHARSET_FARAWAY", "CHARSET_FARAWAY_BODY", and
577 "CHARSET_FARAWAY_HEADERS" are triggered based on how this is set.
578 Examples:
580 ok_locales all (allow all locales)
582 ok_locales en (only allow English)
583 ok_locales en ja zh (allow English, Japanese, and Chinese)
584 Note: if there are multiple ok_locales lines, only the last one is
586 used.
587 Select the locales to allow from the list below:
589 en - Western character sets in general
591 ja - Japanese character sets
592 ko - Korean character sets
593 ru - Cyrillic character sets
594 th - Thai character sets
595 zh - Chinese (both simplified and traditional) character sets
596 normalize_charset ( 0 | 1) (default: 0)
597 Whether to decode non- UTF-8 and non-ASCII textual parts and recode
598 them to UTF-8 before the text is given over to rules processing.
599 The character set used for attempted decoding is primarily based on
600 a declared character set in a Content-Type header, but if the
601 decoding attempt fails a module Encode::Detect::Detector is
602 consulted (if available) to provide a guess based on the actual
603 text, and decoding is re-attempted. Even if the option is enabled
604 no unnecessary decoding and re-encoding work is done when possible
605 (like with an all-ASCII text with a US-ASCII or extended ASCII
606 character set declaration, e.g. UTF-8 or ISO-8859-nn or Windows-
607 nnnn).
608 Unicode support in old versions of perl or in a core module Encode
610 is likely to be buggy in places, so if the normalize_charset
611 function is enabled it is advised to stick to more recent versions
612 of perl (preferably 5.12 or later). The module
613 Encode::Detect::Detector is optional, when necessary it will be
614 used if it is available.
615 NETWORK TEST OPTIONS
617 trusted_networks IPaddress[/masklen] ... (default: none)
618 What networks or hosts are 'trusted' in your setup. Trusted in
619 this case means that relay hosts on these networks are considered
620 to not be potentially operated by spammers, open relays, or open
621 proxies. A trusted host could conceivably relay spam, but will not
622 originate it, and will not forge header data. DNS blacklist checks
623 will never query for hosts on these networks.
624 See "http://wiki.apache.org/spamassassin/TrustPath" for more
626 information.
627 MXes for your domain(s) and internal relays should also be
629 specified using the "internal_networks" setting. When there are
630 'trusted' hosts that are not MXes or internal relays for your
631 domain(s) they should only be specified in "trusted_networks".
632 The "IPaddress" can be an IPv4 address (in a dot-quad form), or an
634 IPv6 address optionally enclosed in square brackets. Scoped link-
635 local IPv6 addresses are syntactically recognized but the interface
636 scope is currently ignored (e.g. [fe80::1234%eth0] ) and should be
637 avoided.
638 If a "/masklen" is specified, it is considered a CIDR-style
640 'netmask' length, specified in bits. If it is not specified, but
641 less than 4 octets of an IPv4 address are specified with a trailing
642 dot, an implied netmask length covers all addresses in remaining
643 octets (i.e. implied masklen is /8 or /16 or /24). If masklen is
644 not specified, and there is not trailing dot, then just a single IP
645 address specified is used, as if the masklen were "/32" with an
646 IPv4 address, or "/128" in case of an IPv6 address.
647 If a network or host address is prefaced by a "!" the matching
649 network or host will be excluded from the list even if a less
650 specific (shorter netmask length) subnet is later specified in the
651 list. This allows a subset of a wider network to be exempt. In case
652 of specifying overlapping subnets, specify more specific subnets
653 first (tighter matching, i.e. with a longer netmask length),
654 followed by less specific (shorter netmask length) subnets to get
655 predictable results regarless of the search algorithm used - when
656 Net::Patricia module is installed the search finds the tightest
657 matching entry in the list, while a sequential search as used in
658 absence of the module Net::Patricia will find the first matching
659 entry in the list.
660 Note: 127.0.0.0/8 and ::1 are always included in trusted_networks,
662 regardless of your config.
663 Examples:
665 trusted_networks 192.168.0.0/16 # all in 192.168.*.*
667 trusted_networks 192.168. # all in 192.168.*.*
668 trusted_networks 212.17.35.15 # just that host
669 trusted_networks !10.0.1.5 10.0.1/24 # all in 10.0.1.* but not 10.0.1.5
670 trusted_networks 2001:db8:1::1 !2001:db8:1::/64 2001:db8::/32
671 # 2001:db8::/32 and 2001:db8:1::1/128, except the rest of 2001:db8:1::/64
672 This operates additively, so a "trusted_networks" line after
674 another one will append new entries to the list of trusted
675 networks. To clear out the existing entries, use
676 "clear_trusted_networks".
677 If "trusted_networks" is not set and "internal_networks" is, the
679 value of "internal_networks" will be used for this parameter.
680 If neither "trusted_networks" or "internal_networks" is set, a
682 basic inference algorithm is applied. This works as follows:
683 · If the 'from' host has an IP address in a private (RFC 1918)
685 network range, then it's trusted
686 · If there are authentication tokens in the received header, and
688 the previous host was trusted, then this host is also trusted
689 · Otherwise this host, and all further hosts, are consider
691 untrusted.
692 clear_trusted_networks
694 Empty the list of trusted networks.
695 internal_networks IPaddress[/masklen] ... (default: none)
697 What networks or hosts are 'internal' in your setup. Internal
698 means that relay hosts on these networks are considered to be MXes
699 for your domain(s), or internal relays. This uses the same syntax
700 as "trusted_networks", above - see there for details.
701 This value is used when checking 'dial-up' or dynamic IP address
703 blocklists, in order to detect direct-to-MX spamming.
704 Trusted relays that accept mail directly from dial-up connections
706 (i.e. are also performing a role of mail submission agents - MSA)
707 should not be listed in "internal_networks". List them only in
708 "trusted_networks".
709 If "trusted_networks" is set and "internal_networks" is not, the
711 value of "trusted_networks" will be used for this parameter.
712 If neither "trusted_networks" nor "internal_networks" is set, no
714 addresses will be considered local; in other words, any relays past
715 the machine where SpamAssassin is running will be considered
716 external.
717 Every entry in "internal_networks" must appear in
719 "trusted_networks"; in other words, "internal_networks" is always a
720 subset of the trusted set.
721 Note: 127/8 and ::1 are always included in internal_networks,
723 regardless of your config.
724 clear_internal_networks
726 Empty the list of internal networks.
727 msa_networks IPaddress[/masklen] ... (default: none)
729 The networks or hosts which are acting as MSAs in your setup (but
730 not also as MX relays). This uses the same syntax as
731 "trusted_networks", above - see there for details.
732 MSA means that the relay hosts on these networks accept mail from
734 your own users and authenticates them appropriately. These relays
735 will never accept mail from hosts that aren't authenticated in some
736 way. Examples of authentication include, IP lists, SMTP AUTH, POP-
737 before-SMTP, etc.
738 All relays found in the message headers after the MSA relay will
740 take on the same trusted and internal classifications as the MSA
741 relay itself, as defined by your trusted_networks and
742 internal_networks configuration.
743 For example, if the MSA relay is trusted and internal so will all
745 of the relays that precede it.
746 When using msa_networks to identify an MSA it is recommended that
748 you treat that MSA as both trusted and internal. When an MSA is
749 not included in msa_networks you should treat the MSA as trusted
750 but not internal, however if the MSA is also acting as an MX or
751 intermediate relay you must always treat it as both trusted and
752 internal and ensure that the MSA includes visible auth tokens in
753 its Received header to identify submission clients.
754 Warning: Never include an MSA that also acts as an MX (or is also
756 an intermediate relay for an MX) or otherwise accepts mail from
757 non-authenticated users in msa_networks. Doing so will result in
758 unknown external relays being trusted.
759 clear_msa_networks
761 Empty the list of msa networks.
762 originating_ip_headers header ... (default: X-Yahoo-Post-IP
764 X-Originating-IP X-Apparently-From X-SenderIP)
765 A list of header field names from which an originating IP address
766 can be obtained. For example, webmail servers may record a client
767 IP address in X-Originating-IP.
768 These IP addresses are virtually appended into the Received: chain,
770 so they are used in RBL checks where appropriate.
771 Currently the IP addresses are not added into X-Spam-Relays-*
773 header fields, but they may be in the future.
774 clear_originating_ip_headers
776 Empty the list of 'originating IP address' header field names.
777 always_trust_envelope_sender ( 0 | 1 ) (default: 0)
779 Trust the envelope sender even if the message has been passed
780 through one or more trusted relays. See also
781 "envelope_sender_header".
782 skip_rbl_checks ( 0 | 1 ) (default: 0)
784 Turning on the skip_rbl_checks setting will disable the DNSEval
785 plugin, which implements Real-time Block List (or: Blackhole List)
786 (RBL) lookups.
787 By default, SpamAssassin will run RBL checks. Individual blocklists
789 may be disabled selectively by setting a score of a corresponding
790 rule to 0.
791 See also a related configuration parameter skip_uribl_checks, which
793 controls the URIDNSBL plugin (documented in the URIDNSBL man page).
794 dns_available { yes | no | test[: domain1 domain2...] } (default:
796 yes)
797 Tells SpamAssassin whether DNS resolving is available or not. A
798 value yes indicates DNS resolving is available, a value no
799 indicates DNS resolving is not available - both of these values
800 apply unconditionally and skip initial DNS tests, which can be slow
801 or unreliable.
802 When the option value is a test (with or without arguments),
804 SpamAssassin will query some domain names on the internet during
805 initialization, attempting to determine if DNS resolving is working
806 or not. A space-separated list of domain names may be specified
807 explicitly, or left to a built-in default of a dozen or so domain
808 names. From an explicit or a default list a subset of three domain
809 names is picked randomly for checking. The test queries for NS
810 records of these domain: if at least one query returns a success
811 then SpamAssassin considers DNS resolving as available, otherwise
812 not.
813 The problem is that the test can introduce some startup delay if a
815 network connection is down, and in some cases it can wrongly guess
816 that DNS is unavailable because a test connection failed, what
817 causes disabling several DNS-dependent tests.
818 Please note, the DNS test queries for NS records, so specify domain
820 names, not host names.
821 Since version 3.4.0 of SpamAssassin a default setting for option
823 dns_available is yes. A default in older versions was test.
824 dns_server ip-addr-port (default: entries provided by Net::DNS)
826 Specifies an IP address of a DNS server, and optionally its port
827 number. The dns_server directive may be specified multiple times,
828 each entry adding to a list of available resolving name servers.
829 The ip-addr-port argument can either be an IPv4 or IPv6 address,
830 optionally enclosed in brackets, and optionally followed by a colon
831 and a port number. In absence of a port number a standard port
832 number 53 is assumed. When an IPv6 address is specified along with
833 a port number, the address must be enclosed in brackets to avoid
834 parsing ambiguity regarding a colon separator. A scoped link-local
835 IP address is allowed (assuming underlying modules allow it).
836 Examples :
838 dns_server 127.0.0.1
839 dns_server 127.0.0.1:53
840 dns_server [127.0.0.1]:53
841 dns_server [::1]:53
842 dns_server fe80::1%lo0
843 dns_server [fe80::1%lo0]:53
844 In absence of dns_server directives, the list of name servers is
846 provided by Net::DNS module, which typically obtains the list from
847 /etc/resolv.conf, but this may be platform dependent. Please
848 consult the Net::DNS::Resolver documentation for details.
849 clear_dns_servers
851 Empty the list of explicitly configured DNS servers through a
852 dns_server directive, falling back to Net::DNS -supplied defaults.
853 dns_local_ports_permit ranges...
855 Add the specified ports or ports ranges to the set of allowed port
856 numbers that can be used as local port numbers when sending DNS
857 queries to a resolver.
858 The argument is a whitespace-separated or a comma-separated list of
860 single port numbers n, or port number pairs (i.e. m-n) delimited by
861 a '-', representing a range. Allowed port numbers are between 1 and
862 65535.
863 Directives dns_local_ports_permit and dns_local_ports_avoid are
865 processed in order in which they appear in configuration files.
866 Each directive adds (or subtracts) its subsets of ports to a
867 current set of available ports. Whatever is left in the set by the
868 end of configuration processing is made available to a DNS
869 resolving client code.
870 If the resulting set of port numbers is empty (see also the
872 directive dns_local_ports_none), then SpamAssassin does not apply
873 its ports randomization logic, but instead leaves the operating
874 system to choose a suitable free local port number.
875 The initial set consists of all port numbers in the range
877 1024-65535. Note that system config files already modify the set
878 and remove all the IANA registered port numbers and some other
879 ranges, so there is rarely a need to adjust the ranges by site-
880 specific directives.
881 See also directives dns_local_ports_permit and
883 dns_local_ports_none.
884 dns_local_ports_avoid ranges...
886 Remove specified ports or ports ranges from the set of allowed port
887 numbers that can be used as local port numbers when sending DNS
888 queries to a resolver.
889 Please see directive dns_local_ports_permit for details.
891 dns_local_ports_none
893 Is a fast shorthand for:
894 dns_local_ports_avoid 1-65535
896 leaving the set of available DNS query local port numbers empty. In
898 all respects (apart from speed) it is equivalent to the shown
899 directive, and can be freely mixed with dns_local_ports_permit and
900 dns_local_ports_avoid.
901 If the resulting set of port numbers is empty, then SpamAssassin
903 does not apply its ports randomization logic, but instead leaves
904 the operating system to choose a suitable free local port number.
905 See also directives dns_local_ports_permit and
907 dns_local_ports_avoid.
908 dns_test_interval n (default: 600 seconds)
910 If dns_available is set to test, the dns_test_interval time in
911 number of seconds will tell SpamAssassin how often to retest for
912 working DNS. A numeric value is optionally suffixed by a time unit
913 (s, m, h, d, w, indicating seconds (default), minutes, hours, days,
914 weeks).
915 dns_options opts (default: norotate, nodns0x20, edns=4096)
917 Provides a (whitespace or comma -separated) list of options
918 applying to DNS resolving. Available options are: rotate, dns0x20
919 and edns (or edns0). Option name may be negated by prepending a no
920 (e.g. norotate, NoEDNS) to counteract a previously enabled option.
921 Option names are not case-sensitive. The dns_options directive may
922 appear in configuration files multiple times, the last setting
923 prevails.
924 Option edns (or edsn0) may take a value which specifies a
926 requestor's acceptable UDP payload size according to EDNS0
927 specifications (RFC 6891, ex RFC 2671) e.g. edns=4096. When EDNS0
928 is off (noedns or edns=512) a traditional implied UDP payload size
929 is 512 bytes, which is also a minimum allowed value for this
930 option. When the option is specified but a value is not provided, a
931 conservative default of 1220 bytes is implied. It is recommended to
932 keep edns enabled when using a local recursive DNS server which
933 supports EDNS0 (like most modern DNS servers do), a suitable
934 setting in this case is edns=4096, which is also a default.
935 Allowing UDP payload size larger than 512 bytes can avoid
936 truncation of resource records in large DNS responses (like in TXT
937 records of some SPF and DKIM responses, or when an unreasonable
938 number of A records is published by some domain). The option should
939 be disabled when a recursive DNS server is only reachable through
940 non- RFC 6891 compliant middleboxes (such as some old-fashioned
941 firewall) which bans DNS UDP payload sizes larger than 512 bytes. A
942 suitable value when a non-local recursive DNS server is used and a
943 middlebox does allow EDNS0 but blocks fragmented IP packets is
944 perhaps 1220 bytes, allowing a DNS UDP packet to fit within a
945 single IP packet in most cases (a slightly less conservative range
946 would be 1280-1410 bytes).
947 Option rotate causes SpamAssassin to choose a DNS server at random
949 from all servers listed in "/etc/resolv.conf" every
950 dns_test_interval seconds, effectively spreading the load over all
951 currently available DNS servers when there are many spamd workers.
952 Option dns0x20 enables randomization of letters in a DNS query
954 label according to draft-vixie-dnsext-dns0x20, decreasing a chance
955 of collisions of responses (by chance or by a malicious intent) by
956 increasing spread as provided by a 16-bit query ID and up to 16
957 bits of a port number, with additional bits as encoded by flipping
958 case (upper/lower) of letters in a query. The number of additional
959 random bits corresponds to the number of letters in a query label.
960 Should work reliably with all mainstream DNS servers - do not turn
961 on if you see frequent info messages "dns: no callback for id:" in
962 the log, or if RBL or URIDNS lookups do not work for no apparent
963 reason.
964 dns_query_restriction (allow|deny) domain1 domain2 ...
966 Option allows disabling of rules which would result in a DNS query
967 to one of the listed domains. The first argument must be a literal
968 "allow" or "deny", remaining arguments are domains names.
969 Most DNS queries (with some exceptions) are subject to
971 dns_query_restriction. A domain to be queried is successively
972 stripped-off of its leading labels (thus yielding a series of its
973 parent domains), and on each iteration a check is made against an
974 associative array generated by dns_query_restriction options.
975 Search stops at the first match (i.e. the tightest match), and the
976 matching entry with its "allow" or "deny" value then controls
977 whether a DNS query is allowed to be launched.
978 If no match is found an implicit default is to allow a query. The
980 purpose of an explicit "allow" entry is to be able to override a
981 previously configured "deny" on the same domain or to override an
982 entry (possibly yet to be configured in subsequent config
983 directives) on one of its parent domains. Thus an 'allow
984 zen.spamhaus.org' with a 'deny spamhaus.org' would permit DNS
985 queries on a specific DNS BL zone but deny queries to other zones
986 under the same parent domain.
987 Domains are matched case-insensitively, no wildcards are
989 recognized, there should be no leading or trailing dot.
990 Specifying a block on querying a domain name has a similar effect
992 as setting a score of corresponding DNSBL and URIBL rules to zero,
993 and can be a handy alternative to hunting for such rules when a
994 site policy does not allow certain DNS block lists to be queried.
995 Example:
997 dns_query_restriction deny dnswl.org surbl.org
998 dns_query_restriction allow zen.spamhaus.org
999 dns_query_restriction deny spamhaus.org mailspike.net
1000 spamcop.net
1001 clear_dns_query_restriction
1003 The option removes any entries entered by previous
1004 'dns_query_restriction' options, leaving the list empty, i.e.
1005 allowing DNS queries for any domain (including any DNS BL zone).
1006 LEARNING OPTIONS
1008 use_learner ( 0 | 1 ) (default: 1)
1009 Whether to use any machine-learning classifiers with SpamAssassin,
1010 such as the default 'BAYES_*' rules. Setting this to 0 will
1011 disable use of any and all human-trained classifiers.
1012 use_bayes ( 0 | 1 ) (default: 1)
1014 Whether to use the naive-Bayesian-style classifier built into
1015 SpamAssassin. This is a master on/off switch for all Bayes-related
1016 operations.
1017 use_bayes_rules ( 0 | 1 ) (default: 1)
1019 Whether to use rules using the naive-Bayesian-style classifier
1020 built into SpamAssassin. This allows you to disable the rules
1021 while leaving auto and manual learning enabled.
1022 bayes_auto_learn ( 0 | 1 ) (default: 1)
1024 Whether SpamAssassin should automatically feed high-scoring mails
1025 (or low-scoring mails, for non-spam) into its learning systems.
1026 The only learning system supported currently is a naive-Bayesian-
1027 style classifier.
1028 See the documentation for the
1030 "Mail::SpamAssassin::Plugin::AutoLearnThreshold" plugin module for
1031 details on how Bayes auto-learning is implemented by default.
1032 bayes_token_sources (default: header visible invisible uri)
1034 Controls which sources in a mail message can contribute tokens
1035 (e.g. words, phrases, etc.) to a Bayes classifier. The argument is
1036 a space-separated list of keywords: header, visible, invisible,
1037 uri, mimepart), each of which may be prefixed by a no to indicate
1038 its exclusion. Additionally two reserved keywords are allowed: all
1039 and none (or: noall). The list of keywords is processed
1040 sequentially: a keyword all adds all available keywords to a set
1041 being built, a none or noall clears the set, other non-negated
1042 keywords are added to the set, and negated keywords are removed
1043 from the set. Keywords are case-insensitive.
1044 The default set is: header visible invisible uri, which is
1046 equivalent for example to: All NoMIMEpart. The reason why mimepart
1047 is not currently in a default set is that it is a newer source
1048 (introduced with SpamAssassin version 3.4.1) and not much
1049 experience has yet been gathered regarding its usefulness.
1050 See also option "bayes_ignore_header" for a fine-grained control on
1052 individual header fields under the umbrella of a more general
1053 keyword header here.
1054 Keywords imply the following data sources:
1056 header - tokens collected from a message header section
1058 visible - words from visible text (plain or HTML) in a message body
1059 invisible - hidden/invisible text in HTML parts of a message body
1060 uri - URIs collected from a message body
1061 mimepart - digests (hashes) of all MIME parts (textual or non-
1062 textual) of a message, computed after Base64 and quoted-printable
1063 decoding, suffixed by their Content-Type
1064 all - adds all the above keywords to the set being assembled
1065 none or noall - removes all keywords from the set
1066 The "bayes_token_sources" directive may appear multiple times, its
1068 keywords are interpreted sequentially, adding or removing items
1069 from the final set as they appear in their order in
1070 "bayes_token_sources" directive(s).
1071 bayes_ignore_header header_name
1073 If you receive mail filtered by upstream mail systems, like a spam-
1074 filtering ISP or mailing list, and that service adds new headers
1075 (as most of them do), these headers may provide inappropriate cues
1076 to the Bayesian classifier, allowing it to take a "short cut". To
1077 avoid this, list the headers using this setting. Example:
1078 bayes_ignore_header X-Upstream-Spamfilter
1080 bayes_ignore_header X-Upstream-SomethingElse
1081 bayes_ignore_from user@example.com
1083 Bayesian classification and autolearning will not be performed on
1084 mail from the listed addresses. Program "sa-learn" will also
1085 ignore the listed addresses if it is invoked using the
1086 "--use-ignores" option. One or more addresses can be listed, see
1087 "whitelist_from".
1088 Spam messages from certain senders may contain many words that
1090 frequently occur in ham. For example, one might read messages from
1091 a preferred bookstore but also get unwanted spam messages from
1092 other bookstores. If the unwanted messages are learned as spam
1093 then any messages discussing books, including the preferred
1094 bookstore and antiquarian messages would be in danger of being
1095 marked as spam. The addresses of the annoying bookstores would be
1096 listed. (Assuming they were halfway legitimate and didn't send you
1097 mail through myriad affiliates.)
1098 Those who have pieces of spam in legitimate messages or otherwise
1100 receive ham messages containing potentially spammy words might fear
1101 that some spam messages might be in danger of being marked as ham.
1102 The addresses of the spam mailing lists, correspondents, etc.
1103 would be listed.
1104 bayes_ignore_to user@example.com
1106 Bayesian classification and autolearning will not be performed on
1107 mail to the listed addresses. See "bayes_ignore_from" for details.
1108 bayes_min_ham_num (Default: 200)
1110 bayes_min_spam_num (Default: 200)
1111 To be accurate, the Bayes system does not activate until a certain
1112 number of ham (non-spam) and spam have been learned. The default
1113 is 200 of each ham and spam, but you can tune these up or down with
1114 these two settings.
1115 bayes_learn_during_report (Default: 1)
1117 The Bayes system will, by default, learn any reported messages
1118 ("spamassassin -r") as spam. If you do not want this to happen,
1119 set this option to 0.
1120 bayes_sql_override_username
1122 Used by BayesStore::SQL storage implementation.
1123 If this options is set the BayesStore::SQL module will override the
1125 set username with the value given. This could be useful for
1126 implementing global or group bayes databases.
1127 bayes_use_hapaxes (default: 1)
1129 Should the Bayesian classifier use hapaxes (words/tokens that occur
1130 only once) when classifying? This produces significantly better
1131 hit-rates.
1132 bayes_journal_max_size (default: 102400)
1134 SpamAssassin will opportunistically sync the journal and the
1135 database. It will do so once a day, but will sync more often if
1136 the journal file size goes above this setting, in bytes. If set to
1137 0, opportunistic syncing will not occur.
1138 bayes_expiry_max_db_size (default: 150000)
1140 What should be the maximum size of the Bayes tokens database? When
1141 expiry occurs, the Bayes system will keep either 75% of the maximum
1142 value, or 100,000 tokens, whichever has a larger value. 150,000
1143 tokens is roughly equivalent to a 8Mb database file.
1144 bayes_auto_expire (default: 1)
1146 If enabled, the Bayes system will try to automatically expire old
1147 tokens from the database. Auto-expiry occurs when the number of
1148 tokens in the database surpasses the bayes_expiry_max_db_size
1149 value. If a bayes datastore backend does not implement individual
1150 key/value expirations, the setting is silently ignored.
1151 bayes_token_ttl (default: 3w, i.e. 3 weeks)
1153 Time-to-live / expiration time in seconds for tokens kept in a
1154 Bayes database. A numeric value is optionally suffixed by a time
1155 unit (s, m, h, d, w, indicating seconds (default), minutes, hours,
1156 days, weeks).
1157 If bayes_auto_expire is true and a Bayes datastore backend supports
1159 it (currently only Redis), this setting controls deletion of
1160 expired tokens from a bayes database. The value is observed on a
1161 best-effort basis, exact timing promises are not necessarily kept.
1162 If a bayes datastore backend does not implement individual
1163 key/value expirations, the setting is silently ignored.
1164 bayes_seen_ttl (default: 8d, i.e. 8 days)
1166 Time-to-live / expiration time in seconds for 'seen' entries (i.e.
1167 mail message digests with their status) kept in a Bayes database.
1168 A numeric value is optionally suffixed by a time unit (s, m, h, d,
1169 w, indicating seconds (default), minutes, hours, days, weeks).
1170 If bayes_auto_expire is true and a Bayes datastore backend supports
1172 it (currently only Redis), this setting controls deletion of
1173 expired 'seen' entries from a bayes database. The value is observed
1174 on a best-effort basis, exact timing promises are not necessarily
1175 kept. If a bayes datastore backend does not implement individual
1176 key/value expirations, the setting is silently ignored.
1177 bayes_learn_to_journal (default: 0)
1179 If this option is set, whenever SpamAssassin does Bayes learning,
1180 it will put the information into the journal instead of directly
1181 into the database. This lowers contention for locking the database
1182 to execute an update, but will also cause more access to the
1183 journal and cause a delay before the updates are actually committed
1184 to the Bayes database.
1185 MISCELLANEOUS OPTIONS
1187 time_limit n (default: 300)
1188 Specifies a limit on elapsed time in seconds that SpamAssassin is
1189 allowed to spend before providing a result. The value may be
1190 fractional and must not be negative, zero is interpreted as
1191 unlimited. The default is 300 seconds for consistency with the
1192 spamd default setting of --timeout-child .
1193 This is a best-effort advisory setting, processing will not be
1195 abruptly aborted at an arbitrary point in processing when the time
1196 limit is exceeded, but only on reaching one of locations in the
1197 program flow equipped with a time test. Currently equipped with the
1198 test are the main checking loop, asynchronous DNS lookups, plugins
1199 which are calling external programs. Rule evaluation is guarded by
1200 starting a timer (alarm) on each set of compiled rules.
1201 When a message is passed to Mail::SpamAssassin::parse, a deadline
1203 time is established as a sum of current time and the "time_limit"
1204 setting.
1205 This deadline may also be specified by a caller through an option
1207 'master_deadline' in $suppl_attrib on a call to parse(), possibly
1208 providing a more accurate deadline taking into account past and
1209 expected future processing of a message in a mail filtering setup.
1210 If both the config option as well as a 'master_deadline' option in
1211 a call are provided, the shorter time limit of the two is used
1212 (since version 3.3.2). Note that spamd (and possibly third-party
1213 callers of SpamAssassin) will supply the 'master_deadline' option
1214 in a call based on its --timeout-child option (or equivalent),
1215 unlike the command line "spamassassin", which has no such command
1216 line option.
1217 When a time limit is exceeded, most of the remaining tests will be
1219 skipped, as well as auto-learning. Whatever tests fired so far will
1220 determine the final score. The behaviour is similar to short-
1221 circuiting with attribute 'on', as implemented by a Shortcircuit
1222 plugin. A synthetic hit on a rule named TIME_LIMIT_EXCEEDED with a
1223 near-zero default score is generated, so that the report will
1224 reflect the event. A score for TIME_LIMIT_EXCEEDED may be provided
1225 explicitly in a configuration file, for example to achieve
1226 whitelisting or blacklisting effect for messages with long
1227 processing times.
1228 The "time_limit" option is a useful protection against excessive
1230 processing time on certain degenerate or unusually long or complex
1231 mail messages, as well as against some DoS attacks. It is also
1232 needed in time-critical pre-queue filtering setups (e.g. milter,
1233 proxy, integration with MTA), where message processing must finish
1234 before a SMTP client times out. RFC 5321 prescribes in section
1235 4.5.3.2.6 the 'DATA Termination' time limit of 10 minutes, although
1236 it is not unusual to see some SMTP clients abort sooner on waiting
1237 for a response. A sensible "time_limit" for a pre-queue filtering
1238 setup is maybe 50 seconds, assuming that clients are willing to
1239 wait at least a minute.
1240 lock_method type
1242 Select the file-locking method used to protect database files on-
1243 disk. By default, SpamAssassin uses an NFS-safe locking method on
1244 UNIX; however, if you are sure that the database files you'll be
1245 using for Bayes and AWL storage will never be accessed over NFS, a
1246 non-NFS-safe locking system can be selected.
1247 This will be quite a bit faster, but may risk file corruption if
1249 the files are ever accessed by multiple clients at once, and one or
1250 more of them is accessing them through an NFS filesystem.
1251 Note that different platforms require different locking systems.
1253 The supported locking systems for "type" are as follows:
1255 nfssafe - an NFS-safe locking system
1257 flock - simple UNIX "flock()" locking
1258 win32 - Win32 locking using "sysopen (..., O_CREAT|O_EXCL)".
1259 nfssafe and flock are only available on UNIX, and win32 is only
1261 available on Windows. By default, SpamAssassin will choose either
1262 nfssafe or win32 depending on the platform in use.
1263 fold_headers ( 0 | 1 ) (default: 1)
1265 By default, headers added by SpamAssassin will be whitespace
1266 folded. In other words, they will be broken up into multiple lines
1267 instead of one very long one and each continuation line will have a
1268 tabulator prepended to mark it as a continuation of the preceding
1269 one.
1270 The automatic wrapping can be disabled here. Note that this can
1272 generate very long lines. RFC 2822 required that header lines do
1273 not exceed 998 characters (not counting the final CRLF).
1274 report_safe_copy_headers header_name ...
1276 If using "report_safe", a few of the headers from the original
1277 message are copied into the wrapper header (From, To, Cc, Subject,
1278 Date, etc.) If you want to have other headers copied as well, you
1279 can add them using this option. You can specify multiple headers
1280 on the same line, separated by spaces, or you can just use multiple
1281 lines.
1282 envelope_sender_header Name-Of-Header
1284 SpamAssassin will attempt to discover the address used in the 'MAIL
1285 FROM:' phase of the SMTP transaction that delivered this message,
1286 if this data has been made available by the SMTP server. This is
1287 used in the "EnvelopeFrom" pseudo-header, and for various rules
1288 such as SPF checking.
1289 By default, various MTAs will use different headers, such as the
1291 following:
1292 X-Envelope-From
1294 Envelope-Sender
1295 X-Sender
1296 Return-Path
1297 SpamAssassin will attempt to use these, if some heuristics (such as
1299 the header placement in the message, or the absence of fetchmail
1300 signatures) appear to indicate that they are safe to use. However,
1301 it may choose the wrong headers in some mailserver configurations.
1302 (More discussion of this can be found in bug 2142 and bug 4747 in
1303 the SpamAssassin BugZilla.)
1304 To avoid this heuristic failure, the "envelope_sender_header"
1306 setting may be helpful. Name the header that your MTA or MDA adds
1307 to messages containing the address used at the MAIL FROM step of
1308 the SMTP transaction.
1309 If the header in question contains "<" or ">" characters at the
1311 start and end of the email address in the right-hand side, as in
1312 the SMTP transaction, these will be stripped.
1313 If the header is not found in a message, or if it's value does not
1315 contain an "@" sign, SpamAssassin will issue a warning in the logs
1316 and fall back to its default heuristics.
1317 (Note for MTA developers: we would prefer if the use of a single
1319 header be avoided in future, since that precludes 'downstream' spam
1320 scanning.
1321 "http://wiki.apache.org/spamassassin/EnvelopeSenderInReceived"
1322 details a better proposal, storing the envelope sender at each hop
1323 in the "Received" header.)
1324 example:
1326 envelope_sender_header X-SA-Exim-Mail-From
1328 describe SYMBOLIC_TEST_NAME description ...
1330 Used to describe a test. This text is shown to users in the
1331 detailed report.
1332 Note that test names which begin with '__' are reserved for meta-
1334 match sub-rules, and are not scored or listed in the 'tests hit'
1335 reports.
1336 Also note that by convention, rule descriptions should be limited
1338 in length to no more than 50 characters.
1339 report_charset CHARSET (default: unset)
1341 Set the MIME Content-Type charset used for the text/plain report
1342 which is attached to spam mail messages.
1343 report ...some text for a report...
1345 Set the report template which is attached to spam mail messages.
1346 See the "10_default_prefs.cf" configuration file in
1347 "/usr/share/spamassassin" for an example.
1348 If you change this, try to keep it under 78 columns. Each "report"
1350 line appends to the existing template, so use
1351 "clear_report_template" to restart.
1352 Tags can be included as explained above.
1354 clear_report_template
1356 Clear the report template.
1357 report_contact ...text of contact address...
1359 Set what _CONTACTADDRESS_ is replaced with in the above report
1360 text. By default, this is 'the administrator of that system',
1361 since the hostname of the system the scanner is running on is also
1362 included.
1363 report_hostname ...hostname to use...
1365 Set what _HOSTNAME_ is replaced with in the above report text. By
1366 default, this is determined dynamically as whatever the host
1367 running SpamAssassin calls itself.
1368 unsafe_report ...some text for a report...
1370 Set the report template which is attached to spam mail messages
1371 which contain a non-text/plain part. See the "10_default_prefs.cf"
1372 configuration file in "/usr/share/spamassassin" for an example.
1373 Each "unsafe-report" line appends to the existing template, so use
1375 "clear_unsafe_report_template" to restart.
1376 Tags can be used in this template (see above for details).
1378 clear_unsafe_report_template
1380 Clear the unsafe_report template.
1381 mbox_format_from_regex
1383 Set a specific regular expression to be used for mbox file From
1384 separators.
1385 For example, this setting will allow sa-learn to process emails
1387 stored in a kmail 2 mbox:
1388 mbox_format_from_regex /^From \S+ ?[[:upper:]][[:lower:]]{2}(?:,
1390 \d\d [[:upper:]][[:lower:]]{2} \d{4} [0-2]\d:\d\d:\d\d [+-]\d{4}|
1391 [[:upper:]][[:lower:]]{2} [ 1-3]\d [ 0-2]\d:\d\d:\d\d \d{4})/
1392 parse_dkim_uris ( 0 | 1 ) (default: 1)
1394 If this option is set to 1 and the message contains DKIM headers,
1395 the headers will be parsed for URIs to process alongside URIs found
1396 in the body with some rules and modules (ex. URIDNSBL)
1397
1399 These settings differ from the ones above, in that they are considered
1400 'privileged'. Only users running "spamassassin" from their
1401 procmailrc's or forward files, or sysadmins editing a file in
1402 "/etc/mail/spamassassin", can use them. "spamd" users cannot use them
1403 in their "user_prefs" files, for security and efficiency reasons,
1404 unless "allow_user_rules" is enabled (and then, they may only add rules
1405 from below).
1406 allow_user_rules ( 0 | 1 ) (default: 0)
1408 This setting allows users to create rules (and only rules) in their
1409 "user_prefs" files for use with "spamd". It defaults to off,
1410 because this could be a severe security hole. It may be possible
1411 for users to gain root level access if "spamd" is run as root. It
1412 is NOT a good idea, unless you have some other way of ensuring that
1413 users' tests are safe. Don't use this unless you are certain you
1414 know what you are doing. Furthermore, this option causes
1415 spamassassin to recompile all the tests each time it processes a
1416 message for a user with a rule in his/her "user_prefs" file, which
1417 could have a significant effect on server load. It is not
1418 recommended.
1419 Note that it is not currently possible to use "allow_user_rules" to
1421 modify an existing system rule from a "user_prefs" file with
1422 "spamd".
1423 redirector_pattern /pattern/modifiers
1425 A regex pattern that matches both the redirector site portion, and
1426 the target site portion of a URI.
1427 Note: The target URI portion must be surrounded in parentheses and
1429 no other part of the pattern may create a backreference.
1430 Example:
1432 http://chkpt.zdnet.com/chkpt/whatever/spammer.domain/yo/dude
1433 redirector_pattern /^https?:\/\/(?:opt\.)?chkpt\.zdnet\.com\/chkpt\/\w+\/(.*)$/i
1435 header SYMBOLIC_TEST_NAME header op /pattern/modifiers [if-unset:
1437 STRING]
1438 Define a test. "SYMBOLIC_TEST_NAME" is a symbolic test name, such
1439 as 'FROM_ENDS_IN_NUMS'. "header" is the name of a mail header
1440 field, such as 'Subject', 'To', 'From', etc. Header field names
1441 are matched case-insensitively (conforming to RFC 5322 section
1442 1.2.2), except for all-capitals metaheader fields such as ALL,
1443 MESSAGEID, ALL-TRUSTED.
1444 Appending a modifier ":raw" to a header field name will inhibit
1446 decoding of quoted-printable or base-64 encoded strings, and will
1447 preserve all whitespace inside the header string. The ":raw" may
1448 also be applied to pseudo-headers e.g. "ALL:raw" will return a
1449 pristine (unmodified) header section.
1450 Appending a modifier ":addr" to a header field name will cause
1452 everything except the first email address to be removed from the
1453 header field. It is mainly applicable to header fields 'From',
1454 'Sender', 'To', 'Cc' along with their 'Resent-*' counterparts, and
1455 the 'Return-Path'.
1456 Appending a modifier ":name" to a header field name will cause
1458 everything except the first display name to be removed from the
1459 header field. It is mainly applicable to header fields containing a
1460 single mail address: 'From', 'Sender', along with their
1461 'Resent-From' and 'Resent-Sender' counterparts.
1462 It is syntactically permitted to append more than one modifier to a
1464 header field name, although currently most combinations achieve no
1465 additional effect, for example "From:addr:raw" or "From:raw:addr"
1466 is currently the same as "From:addr" .
1467 For example, appending ":addr" to a header name will result in
1469 example@foo in all of the following cases:
1470 example@foo
1472 example@foo (Foo Blah)
1473 example@foo, example@bar
1474 display: example@foo (Foo Blah), example@bar ;
1475 Foo Blah <example@foo>
1476 "Foo Blah" <example@foo>
1477 "'Foo Blah'" <example@foo>
1478 For example, appending ":name" to a header name will result in "Foo
1480 Blah" (without quotes) in all of the following cases:
1481 example@foo (Foo Blah)
1483 example@foo (Foo Blah), example@bar
1484 display: example@foo (Foo Blah), example@bar ;
1485 Foo Blah <example@foo>
1486 "Foo Blah" <example@foo>
1487 "'Foo Blah'" <example@foo>
1488 There are several special pseudo-headers that can be specified:
1490 "ALL" can be used to mean the text of all the message's headers.
1492 Note that all whitespace inside the headers, at line folds, is
1493 currently compressed into a single space (' ') character. To obtain
1494 a pristine (unmodified) header section, use "ALL:raw" - the :raw
1495 modifier is documented above.
1496 "ToCc" can be used to mean the contents of both the 'To' and 'Cc'
1497 headers.
1498 "EnvelopeFrom" is the address used in the 'MAIL FROM:' phase of the
1499 SMTP transaction that delivered this message, if this data has been
1500 made available by the SMTP server. See "envelope_sender_header"
1501 for more information on how to set this.
1502 "MESSAGEID" is a symbol meaning all Message-Id's found in the
1503 message; some mailing list software moves the real 'Message-Id' to
1504 'Resent-Message-Id' or to 'X-Message-Id', then uses its own one in
1505 the 'Message-Id' header. The value returned for this symbol is the
1506 text from all 3 headers, separated by newlines.
1507 "X-Spam-Relays-Untrusted", "X-Spam-Relays-Trusted",
1508 "X-Spam-Relays-Internal" and "X-Spam-Relays-External" represent a
1509 portable, pre-parsed representation of the message's network path,
1510 as recorded in the Received headers, divided into 'trusted' vs
1511 'untrusted' and 'internal' vs 'external' sets. See
1512 "http://wiki.apache.org/spamassassin/TrustedRelays" for more
1513 details.
1514 "op" is either "=~" (contains regular expression) or "!~" (does not
1516 contain regular expression), and "pattern" is a valid Perl regular
1517 expression, with "modifiers" as regexp modifiers in the usual
1518 style. Note that multi-line rules are not supported, even if you
1519 use "x" as a modifier. Also note that the "#" character must be
1520 escaped ("\#") or else it will be considered to be the start of a
1521 comment and not part of the regexp.
1522 If the "[if-unset: STRING]" tag is present, then "STRING" will be
1524 used if the header is not found in the mail message.
1525 Test names must not start with a number, and must contain only
1527 alphanumerics and underscores. It is suggested that lower-case
1528 characters not be used, and names have a length of no more than 22
1529 characters, as an informal convention. Dashes are not allowed.
1530 Note that test names which begin with '__' are reserved for meta-
1532 match sub-rules, and are not scored or listed in the 'tests hit'
1533 reports. Test names which begin with 'T_' are reserved for tests
1534 which are undergoing QA, and these are given a very low score.
1535 If you add or modify a test, please be sure to run a sanity check
1537 afterwards by running "spamassassin --lint". This will avoid
1538 confusing error messages, or other tests being skipped as a side-
1539 effect.
1540 header SYMBOLIC_TEST_NAME exists:header_field_name
1542 Define a header field existence test. "header_field_name" is the
1543 name of a header field to test for existence. Not to be confused
1544 with a test for a nonempty header field body, which can be
1545 implemented by a "header SYMBOLIC_TEST_NAME header =~ /\S/" rule as
1546 described above.
1547 header SYMBOLIC_TEST_NAME eval:name_of_eval_method([arguments])
1549 Define a header eval test. "name_of_eval_method" is the name of a
1550 method registered by a "Mail::SpamAssassin::Plugin" object.
1551 "arguments" are optional arguments to the function call.
1552 header SYMBOLIC_TEST_NAME eval:check_rbl('set', 'zone' [, 'sub-test'])
1554 Check a DNSBL (a DNS blacklist or whitelist). This will retrieve
1555 Received: headers from the message, extract the IP addresses,
1556 select which ones are 'untrusted' based on the "trusted_networks"
1557 logic, and query that DNSBL zone. There's a few things to note:
1558 duplicated or private IPs
1560 Duplicated IPs are only queried once and reserved IPs are not
1561 queried. Private IPs are those listed in
1562 <http://www.iana.org/assignments/ipv4-address-space>,
1563 <http://duxcw.com/faq/network/privip.htm>,
1564 <http://duxcw.com/faq/network/autoip.htm>, or
1565 <http://tools.ietf.org/html/rfc5735> as private.
1566 the 'set' argument
1568 This is used as a 'zone ID'. If you want to look up a
1569 multiple-meaning zone like SORBS, you can then query the
1570 results from that zone using it; but all check_rbl_sub() calls
1571 must use that zone ID.
1572 Also, if more than one IP address gets a DNSBL hit for a
1574 particular rule, it does not affect the score because rules
1575 only trigger once per message.
1576 the 'zone' argument
1578 This is the root zone of the DNSBL.
1579 The domain name is considered to be a fully qualified domain
1581 name (i.e. not subject to DNS resolver's search or default
1582 domain options). No trailing period is needed, and will be
1583 removed if specified.
1584 the 'sub-test' argument
1586 This optional argument behaves the same as the sub-test
1587 argument in "check_rbl_sub()" below.
1588 selecting all IPs except for the originating one
1590 This is accomplished by placing '-notfirsthop' at the end of
1591 the set name. This is useful for querying against DNS lists
1592 which list dialup IP addresses; the first hop may be a dialup,
1593 but as long as there is at least one more hop, via their
1594 outgoing SMTP server, that's legitimate, and so should not gain
1595 points. If there is only one hop, that will be queried anyway,
1596 as it should be relaying via its outgoing SMTP server instead
1597 of sending directly to your MX (mail exchange).
1598 selecting IPs by whether they are trusted
1600 When checking a 'nice' DNSBL (a DNS whitelist), you cannot
1601 trust the IP addresses in Received headers that were not added
1602 by trusted relays. To test the first IP address that can be
1603 trusted, place '-firsttrusted' at the end of the set name.
1604 That should test the IP address of the relay that connected to
1605 the most remote trusted relay.
1606 Note that this requires that SpamAssassin know which relays are
1608 trusted. For simple cases, SpamAssassin can make a good
1609 estimate. For complex cases, you may get better results by
1610 setting "trusted_networks" manually.
1611 In addition, you can test all untrusted IP addresses by placing
1613 '-untrusted' at the end of the set name. Important note --
1614 this does NOT include the IP address from the most recent
1615 'untrusted line', as used in '-firsttrusted' above. That's
1616 because we're talking about the trustworthiness of the IP
1617 address data, not the source header line, here; and in the case
1618 of the most recent header (the 'firsttrusted'), that data can
1619 be trusted. See the Wiki page at
1620 "http://wiki.apache.org/spamassassin/TrustedRelays" for more
1621 information on this.
1622 Selecting just the last external IP
1624 By using '-lastexternal' at the end of the set name, you can
1625 select only the external host that connected to your internal
1626 network, or at least the last external host with a public IP.
1627 header SYMBOLIC_TEST_NAME eval:check_rbl_txt('set', 'zone')
1629 Same as check_rbl(), except querying using IN TXT instead of IN A
1630 records. If the zone supports it, it will result in a line of text
1631 describing why the IP is listed, typically a hyperlink to a
1632 database entry.
1633 header SYMBOLIC_TEST_NAME eval:check_rbl_sub('set', 'sub-test')
1635 Create a sub-test for 'set'. If you want to look up a multi-
1636 meaning zone like relays.osirusoft.com, you can then query the
1637 results from that zone using the zone ID from the original query.
1638 The sub-test may either be an IPv4 dotted address for RBLs that
1639 return multiple A records or a non-negative decimal number to
1640 specify a bitmask for RBLs that return a single A record containing
1641 a bitmask of results, a SenderBase test beginning with "sb:", or
1642 (if none of the preceding options seem to fit) a regular
1643 expression.
1644 Note: the set name must be exactly the same for as the main query
1646 rule, including selections like '-notfirsthop' appearing at the end
1647 of the set name.
1648 body SYMBOLIC_TEST_NAME /pattern/modifiers
1650 Define a body pattern test. "pattern" is a Perl regular
1651 expression. Note: as per the header tests, "#" must be escaped
1652 ("\#") or else it is considered the beginning of a comment.
1653 The 'body' in this case is the textual parts of the message body;
1655 any non-text MIME parts are stripped, and the message decoded from
1656 Quoted-Printable or Base-64-encoded format if necessary. Parts
1657 declared as text/html will be rendered from HTML to text.
1658 All body paragraphs (double-newline-separated blocks text) are
1660 turned into a line breaks removed, whitespace normalized single
1661 line. Any lines longer than 2kB are split into shorter separate
1662 lines (from a boundary when possible), this may unexpectedly
1663 prevent pattern from matching. Patterns are matched independently
1664 against each of these lines.
1665 Note that the message Subject header is considered part of the body
1667 and becomes the first line when running the rules.
1668 body SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])
1670 Define a body eval test. See above.
1671 uri SYMBOLIC_TEST_NAME /pattern/modifiers
1673 Define a uri pattern test. "pattern" is a Perl regular expression.
1674 Note: as per the header tests, "#" must be escaped ("\#") or else
1675 it is considered the beginning of a comment.
1676 The 'uri' in this case is a list of all the URIs in the body of the
1678 email, and the test will be run on each and every one of those
1679 URIs, adjusting the score if a match is found. Use this test
1680 instead of one of the body tests when you need to match a URI, as
1681 it is more accurately bound to the start/end points of the URI, and
1682 will also be faster.
1683 rawbody SYMBOLIC_TEST_NAME /pattern/modifiers
1685 Define a raw-body pattern test. "pattern" is a Perl regular
1686 expression. Note: as per the header tests, "#" must be escaped
1687 ("\#") or else it is considered the beginning of a comment.
1688 The 'raw body' of a message is the raw data inside all textual
1690 parts. The text will be decoded from base64 or quoted-printable
1691 encoding, but HTML tags and line breaks will still be present.
1692 Multiline expressions will need to be used to match strings that
1693 are broken by line breaks.
1694 Note that the text is split into 2-4kB chunks (from a word boundary
1696 when possible), this may unexpectedly prevent pattern from
1697 matching. Patterns are matched independently against each of these
1698 chunks.
1699 rawbody SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])
1701 Define a raw-body eval test. See above.
1702 full SYMBOLIC_TEST_NAME /pattern/modifiers
1704 Define a full message pattern test. "pattern" is a Perl regular
1705 expression. Note: as per the header tests, "#" must be escaped
1706 ("\#") or else it is considered the beginning of a comment.
1707 The full message is the pristine message headers plus the pristine
1709 message body, including all MIME data such as images, other
1710 attachments, MIME boundaries, etc.
1711 full SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])
1713 Define a full message eval test. See above.
1714 meta SYMBOLIC_TEST_NAME boolean expression
1716 Define a boolean expression test in terms of other tests that have
1717 been hit or not hit. For example:
1718 meta META1 TEST1 && !(TEST2 || TEST3)
1720 Note that English language operators ("and", "or") will be treated
1722 as rule names, and that there is no "XOR" operator.
1723 meta SYMBOLIC_TEST_NAME boolean arithmetic expression
1725 Can also define an arithmetic expression in terms of other tests,
1726 with an unhit test having the value "0" and a hit test having a
1727 nonzero value. The value of a hit meta test is that of its
1728 arithmetic expression. The value of a hit eval test is that
1729 returned by its method. The value of a hit header, body, rawbody,
1730 uri, or full test which has the "multiple" tflag is the number of
1731 times the test hit. The value of any other type of hit test is
1732 "1".
1733 For example:
1735 meta META2 (3 * TEST1 - 2 * TEST2) > 0
1737 Note that Perl builtins and functions, like "abs()", can't be used,
1739 and will be treated as rule names.
1740 If you want to define a meta-rule, but do not want its individual
1742 sub-rules to count towards the final score unless the entire meta-
1743 rule matches, give the sub-rules names that start with '__' (two
1744 underscores). SpamAssassin will ignore these for scoring.
1745 reuse SYMBOLIC_TEST_NAME [ OLD_SYMBOLIC_TEST_NAME_1 ... ]
1747 Defines the name of a test that should be "reused" during the
1748 scoring process. If a message has an X-Spam-Status header that
1749 shows a hit for this rule or any of the old rule names given, a hit
1750 will be added for this rule when mass-check --reuse is used.
1751 Examples:
1752 "reuse SPF_PASS"
1754 "reuse MY_NET_RULE_V2 MY_NET_RULE_V1"
1756 The actual logic for reuse tests is done by
1758 Mail::SpamAssassin::Plugin::Reuse.
1759 tflags SYMBOLIC_TEST_NAME flags
1761 Used to set flags on a test. Parameter is a space-separated list of
1762 flag names or flag name = value pairs. These flags are used in the
1763 score-determination back end system for details of the test's
1764 behaviour. Please see "bayes_auto_learn" for more information
1765 about tflag interaction with those systems. The following flags can
1766 be set:
1767 net The test is a network test, and will not be run in the mass
1769 checking system or if -L is used, therefore its score should
1770 not be modified.
1771 nice
1773 The test is intended to compensate for common false positives,
1774 and should be assigned a negative score.
1775 userconf
1777 The test requires user configuration before it can be used
1778 (like language-specific tests).
1779 learn
1781 The test requires training before it can be used.
1782 noautolearn
1784 The test will explicitly be ignored when calculating the score
1785 for learning systems.
1786 autolearn_force
1788 The test will be subject to less stringent autolearn
1789 thresholds.
1790 Normally, SpamAssassin will require 3 points from the header
1792 and 3 points from the body to be auto-learned as spam. This
1793 option keeps the threshold at 6 points total but changes it to
1794 have no regard to the source of the points.
1795 noawl
1797 This flag is specific when using AWL plugin.
1798 Normally, AWL plugin normalizes scores via auto-whitelist. In
1800 some scenarios it works against the system administrator when
1801 trying to add some rules to correct miss-classified email. When
1802 AWL plugin searches the email and finds the noawl flag it will
1803 exit without normalizing the score nor storing the value in db.
1804 multiple
1806 The test will be evaluated multiple times, for use with meta
1807 rules. Only affects header, body, rawbody, uri, and full
1808 tests.
1809 maxhits=N
1811 If multiple is specified, limit the number of hits found to N.
1812 If the rule is used in a meta that counts the hits (e.g.
1813 __RULENAME > 5), this is a way to avoid wasted extra work (use
1814 "tflags multiple maxhits=6").
1815 For example:
1817 uri __KAM_COUNT_URIS /^./
1819 tflags __KAM_COUNT_URIS multiple maxhits=16
1820 describe __KAM_COUNT_URIS A multiple match used to count URIs in a message
1821 meta __KAM_HAS_0_URIS (__KAM_COUNT_URIS == 0)
1823 meta __KAM_HAS_1_URIS (__KAM_COUNT_URIS >= 1)
1824 meta __KAM_HAS_2_URIS (__KAM_COUNT_URIS >= 2)
1825 meta __KAM_HAS_3_URIS (__KAM_COUNT_URIS >= 3)
1826 meta __KAM_HAS_4_URIS (__KAM_COUNT_URIS >= 4)
1827 meta __KAM_HAS_5_URIS (__KAM_COUNT_URIS >= 5)
1828 meta __KAM_HAS_10_URIS (__KAM_COUNT_URIS >= 10)
1829 meta __KAM_HAS_15_URIS (__KAM_COUNT_URIS >= 15)
1830 ips_only
1832 This flag is specific to rules invoking an URIDNSBL plugin, it
1833 is documented there.
1834 domains_only
1836 This flag is specific to rules invoking an URIDNSBL plugin, it
1837 is documented there.
1838 ns This flag is specific to rules invoking an URIDNSBL plugin, it
1840 is documented there.
1841 a This flag is specific to rules invoking an URIDNSBL plugin, it
1843 is documented there.
1844 priority SYMBOLIC_TEST_NAME n
1846 Assign a specific priority to a test. All tests, except for DNS
1847 and Meta tests, are run in increasing priority value order
1848 (negative priority values are run before positive priority values).
1849 The default test priority is 0 (zero).
1850 The values <-99999999999999> and <-99999999999998> have a special
1852 meaning internally, and should not be used.
1853
1855 These settings differ from the ones above, in that they are considered
1856 'more privileged' -- even more than the ones in the PRIVILEGED SETTINGS
1857 section. No matter what "allow_user_rules" is set to, these can never
1858 be set from a user's "user_prefs" file when spamc/spamd is being used.
1859 However, all settings can be used by local programs run directly by the
1860 user.
1861 version_tag string
1863 This tag is appended to the SA version in the X-Spam-Status header.
1864 You should include it when you modify your ruleset, especially if
1865 you plan to distribute it. A good choice for string is your last
1866 name or your initials followed by a number which you increase with
1867 each change.
1868 The version_tag will be lowercased, and any non-alphanumeric or
1870 period character will be replaced by an underscore.
1871 e.g.
1873 version_tag myrules1 # version=2.41-myrules1
1875 test SYMBOLIC_TEST_NAME (ok|fail) Some string to test against
1877 Define a regression testing string. You can have more than one
1878 regression test string per symbolic test name. Simply specify a
1879 string that you wish the test to match.
1880 These tests are only run as part of the test suite - they should
1882 not affect the general running of SpamAssassin.
1883 rbl_timeout t [t_min] [zone] (default: 15 3)
1885 All DNS queries are made at the beginning of a check and we try to
1886 read the results at the end. This value specifies the maximum
1887 period of time (in seconds) to wait for a DNS query. If most of
1888 the DNS queries have succeeded for a particular message, then
1889 SpamAssassin will not wait for the full period to avoid wasting
1890 time on unresponsive server(s), but will shrink the timeout
1891 according to a percentage of queries already completed. As the
1892 number of queries remaining approaches 0, the timeout value will
1893 gradually approach a t_min value, which is an optional second
1894 parameter and defaults to 0.2 * t. If t is smaller than t_min, the
1895 initial timeout is set to t_min. Here is a chart of queries
1896 remaining versus the timeout in seconds, for the default 15 second
1897 / 3 second timeout setting:
1898 queries left 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0%
1900 timeout 15 14.9 14.5 13.9 13.1 12.0 10.7 9.1 7.3 5.3 3
1901 For example, if 20 queries are made at the beginning of a message
1903 check and 16 queries have returned (leaving 20%), the remaining 4
1904 queries should finish within 7.3 seconds since their query started
1905 or they will be timed out. Note that timed out queries are only
1906 aborted when there is nothing else left for SpamAssassin to do -
1907 long evaluation of other rules may grant queries additional time.
1908 If a parameter 'zone' is specified (it must end with a letter,
1910 which distinguishes it from other numeric parametrs), then the
1911 setting only applies to DNS queries against the specified DNS
1912 domain (host, domain or RBL (sub)zone). Matching is case-
1913 insensitive, the actual domain may be a subdomain of the specified
1914 zone.
1915 util_rb_tld tld1 tld2 ...
1917 This option maintains list of valid TLDs in the RegistryBoundaries
1918 code. TLDs include things like com, net, org, etc.
1919 util_rb_2tld 2tld-1.tld 2tld-2.tld ...
1921 This option maintains list of valid 2nd-level TLDs in the
1922 RegistryBoundaries code. 2TLDs include things like co.uk, fed.us,
1923 etc.
1924 util_rb_3tld 3tld1.some.tld 3tld2.other.tld ...
1926 This option maintains list of valid 3rd-level TLDs in the
1927 RegistryBoundaries code. 3TLDs include things like demon.co.uk,
1928 plc.co.im, etc.
1929 clear_util_rb
1931 Empty internal list of valid TLDs (including 2nd and 3rd level)
1932 which RegistryBoundaries code uses. Only useful if you want to
1933 override the standard lists supplied by sa-update.
1934 bayes_path /path/filename (default: ~/.spamassassin/bayes)
1936 This is the directory and filename for Bayes databases. Several
1937 databases will be created, with this as the base directory and
1938 filename, with "_toks", "_seen", etc. appended to the base. The
1939 default setting results in files called
1940 "~/.spamassassin/bayes_seen", "~/.spamassassin/bayes_toks", etc.
1941 By default, each user has their own in their "~/.spamassassin"
1943 directory with mode 0700/0600. For system-wide SpamAssassin use,
1944 you may want to reduce disk space usage by sharing this across all
1945 users. However, Bayes appears to be more effective with individual
1946 user databases.
1947 bayes_file_mode (default: 0700)
1949 The file mode bits used for the Bayesian filtering database files.
1950 Make sure you specify this using the 'x' mode bits set, as it may
1952 also be used to create directories. However, if a file is created,
1953 the resulting file will not have any execute bits set (the umask is
1954 set to 111). The argument is a string of octal digits, it is
1955 converted to a numeric value internally.
1956 bayes_store_module Name::Of::BayesStore::Module
1958 If this option is set, the module given will be used as an
1959 alternate to the default bayes storage mechanism. It must conform
1960 to the published storage specification (see
1961 Mail::SpamAssassin::BayesStore). For example, set this to
1962 Mail::SpamAssassin::BayesStore::SQL to use the generic SQL storage
1963 module.
1964 bayes_sql_dsn DBI::databasetype:databasename:hostname:port
1966 Used for BayesStore::SQL storage implementation.
1967 This option give the connect string used to connect to the SQL
1969 based Bayes storage.
1970 bayes_sql_username
1972 Used by BayesStore::SQL storage implementation.
1973 This option gives the username used by the above DSN.
1975 bayes_sql_password
1977 Used by BayesStore::SQL storage implementation.
1978 This option gives the password used by the above DSN.
1980 bayes_sql_username_authorized ( 0 | 1 ) (default: 0)
1982 Whether to call the services_authorized_for_username plugin hook in
1983 BayesSQL. If the hook does not determine that the user is allowed
1984 to use bayes or is invalid then then database will not be
1985 initialized.
1986 NOTE: By default the user is considered invalid until a plugin
1988 returns a true value. If you enable this, but do not have a proper
1989 plugin loaded, all users will turn up as invalid.
1990 The username passed into the plugin can be affected by the
1992 bayes_sql_override_username config option.
1993 user_scores_dsn DBI:databasetype:databasename:hostname:port
1995 If you load user scores from an SQL database, this will set the DSN
1996 used to connect. Example: "DBI:mysql:spamassassin:localhost"
1997 If you load user scores from an LDAP directory, this will set the
1999 DSN used to connect. You have to write the DSN as an LDAP URL, the
2000 components being the host and port to connect to, the base DN for
2001 the search, the scope of the search (base, one or sub), the single
2002 attribute being the multivalued attribute used to hold the
2003 configuration data (space separated pairs of key and value, just as
2004 in a file) and finally the filter being the expression used to
2005 filter out the wanted username. Note that the filter expression is
2006 being used in a sprintf statement with the username as the only
2007 parameter, thus is can hold a single __USERNAME__ expression. This
2008 will be replaced with the username.
2009 Example:
2011 "ldap://localhost:389/dc=koehntopp,dc=de?saconfig?uid=__USERNAME__"
2012 user_scores_sql_username username
2014 The authorized username to connect to the above DSN.
2015 user_scores_sql_password password
2017 The password for the database username, for the above DSN.
2018 user_scores_sql_custom_query query
2020 This option gives you the ability to create a custom SQL query to
2021 retrieve user scores and preferences. In order to work correctly
2022 your query should return two values, the preference name and value,
2023 in that order. In addition, there are several "variables" that you
2024 can use as part of your query, these variables will be substituted
2025 for the current values right before the query is run. The current
2026 allowed variables are:
2027 _TABLE_
2029 The name of the table where user scores and preferences are
2030 stored. Currently hardcoded to userpref, to change this value
2031 you need to create a new custom query with the new table name.
2032 _USERNAME_
2034 The current user's username.
2035 _MAILBOX_
2037 The portion before the @ as derived from the current user's
2038 username.
2039 _DOMAIN_
2041 The portion after the @ as derived from the current user's
2042 username, this value may be null.
2043 The query must be one continuous line in order to parse correctly.
2045 Here are several example queries, please note that these are broken
2047 up for easy reading, in your config it should be one continuous
2048 line.
2049 Current default query:
2051 "SELECT preference, value FROM _TABLE_ WHERE username =
2052 _USERNAME_ OR username = '@GLOBAL' ORDER BY username ASC"
2053 Use global and then domain level defaults:
2055 "SELECT preference, value FROM _TABLE_ WHERE username =
2056 _USERNAME_ OR username = '@GLOBAL' OR username = '@~'||_DOMAIN_
2057 ORDER BY username ASC"
2058 Maybe global prefs should override user prefs:
2060 "SELECT preference, value FROM _TABLE_ WHERE username =
2061 _USERNAME_ OR username = '@GLOBAL' ORDER BY username DESC"
2062 user_scores_ldap_username
2064 This is the Bind DN used to connect to the LDAP server. It
2065 defaults to the empty string (""), allowing anonymous binding to
2066 work.
2067 Example: "cn=master,dc=koehntopp,dc=de"
2069 user_scores_ldap_password
2071 This is the password used to connect to the LDAP server. It
2072 defaults to the empty string ("").
2073 user_scores_fallback_to_global (default: 1)
2075 Fall back to global scores and settings if userprefs can't be
2076 loaded from SQL or LDAP, instead of passing the message through
2077 unprocessed.
2078 loadplugin PluginModuleName [/path/module.pm]
2080 Load a SpamAssassin plugin module. The "PluginModuleName" is the
2081 perl module name, used to create the plugin object itself.
2082 "/path/to/module.pm" is the file to load, containing the module's
2084 perl code; if it's specified as a relative path, it's considered to
2085 be relative to the current configuration file. If it is omitted,
2086 the module will be loaded using perl's search path (the @INC
2087 array).
2088 See "Mail::SpamAssassin::Plugin" for more details on writing
2090 plugins.
2091 tryplugin PluginModuleName [/path/module.pm]
2093 Same as "loadplugin", but silently ignored if the .pm file cannot
2094 be found in the filesystem.
2095 ignore_always_matching_regexps (Default: 0)
2097 Ignore any rule which contains a regexp which always matches.
2098 Currently only catches regexps which contain '||', or which begin
2099 or end with a '|'. Also ignore rules with "some" combinatorial
2100 explosions.
2101
2103 include filename
2104 Include configuration lines from "filename". Relative paths are
2105 considered relative to the current configuration file or user
2106 preferences file.
2107 if (boolean perl expression)
2109 Used to support conditional interpretation of the configuration
2110 file. Lines between this and a corresponding "else" or "endif" line
2111 will be ignored unless the expression evaluates as true (in the
2112 perl sense; that is, defined and non-0 and non-empty string).
2113 The conditional accepts a limited subset of perl for security --
2115 just enough to perform basic arithmetic comparisons. The following
2116 input is accepted:
2117 numbers, whitespace, arithmetic operations and grouping
2119 Namely these characters and ranges:
2120 ( ) - + * / _ . , < = > ! ~ 0-9 whitespace
2122 version
2124 This will be replaced with the version number of the currently-
2125 running SpamAssassin engine. Note: The version used is in the
2126 internal SpamAssassin version format which is "x.yyyzzz", where
2127 x is major version, y is minor version, and z is maintenance
2128 version. So 3.0.0 is 3.000000, and 3.4.80 is 3.004080.
2129 perl_version
2131 (Introduced in 3.4.1) This will be replaced with the version
2132 number of the currently-running perl engine. Note: The version
2133 used is in the $] version format which is "x.yyyzzz", where x
2134 is major version, y is minor version, and z is maintenance
2135 version. So 5.8.8 is 5.008008, and 5.10.0 is 5.010000. Use to
2136 protect rules that incorporate RE syntax elements introduced in
2137 later versions of perl, such as the "++" non-backtracking match
2138 introduced in perl 5.10. For example:
2139 # Avoid lint error on older perl installs
2141 # Check SA version first to avoid warnings on checking perl_version on older SA
2142 if version > 3.004001 && perl_version >= 5.018000
2143 body INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18 /(?[ \p{Thai} & \p{Digit} ])/
2144 endif
2145 Note that the above will still generate a warning on perl older
2147 than 5.10.0; to avoid that warning do this instead:
2148 # Avoid lint error on older perl installs
2150 if can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
2151 body INVALID_RE_SYNTAX_IN_PERL_5_8 /\w++/
2152 endif
2153 Warning: a can() test is only defined for perl 5.10.0!
2155 plugin(Name::Of::Plugin)
2157 This is a function call that returns 1 if the plugin named
2158 "Name::Of::Plugin" is loaded, or "undef" otherwise.
2159 has(Name::Of::Package::function_name)
2161 This is a function call that returns 1 if the perl package
2162 named "Name::Of::Package" includes a function called
2163 "function_name", or "undef" otherwise. Note that packages can
2164 be SpamAssassin plugins or built-in classes, there's no
2165 difference in this respect. Internally this invokes
2166 UNIVERSAL::can.
2167 can(Name::Of::Package::function_name)
2169 This is a function call that returns 1 if the perl package
2170 named "Name::Of::Package" includes a function called
2171 "function_name" and that function returns a true value when
2172 called with no arguments, otherwise "undef" is returned.
2173 Is similar to "has", except that it also calls the named
2175 function, testing its return value (unlike the perl function
2176 UNIVERSAL::can). This makes it possible for a 'feature'
2177 function to determine its result value at run time.
2178 If the end of a configuration file is reached while still inside a
2180 "if" scope, a warning will be issued, but parsing will restart on
2181 the next file.
2182 For example:
2184 if (version > 3.000000)
2186 header MY_FOO ...
2187 endif
2188 loadplugin MyPlugin plugintest.pm
2190 if plugin (MyPlugin)
2192 header MY_PLUGIN_FOO eval:check_for_foo()
2193 score MY_PLUGIN_FOO 0.1
2194 endif
2195 ifplugin PluginModuleName
2197 An alias for "if plugin(PluginModuleName)".
2198 else
2200 Used to support conditional interpretation of the configuration
2201 file. Lines between this and a corresponding "endif" line, will be
2202 ignored unless the conditional expression evaluates as false (in
2203 the perl sense; that is, not defined and not 0 and non-empty
2204 string).
2205 require_version n.nnnnnn
2207 Indicates that the entire file, from this line on, requires a
2208 certain version of SpamAssassin to run. If a different (older or
2209 newer) version of SpamAssassin tries to read the configuration from
2210 this file, it will output a warning instead, and ignore it.
2211 Note: The version used is in the internal SpamAssassin version
2213 format which is "x.yyyzzz", where x is major version, y is minor
2214 version, and z is maintenance version. So 3.0.0 is 3.000000, and
2215 3.4.80 is 3.004080.
2216
2218 The following "tags" can be used as placeholders in certain options.
2219 They will be replaced by the corresponding value when they are used.
2220 Some tags can take an argument (in parentheses). The argument is
2222 optional, and the default is shown below.
2223 _YESNO_ "Yes" for spam, "No" for nonspam (=ham)
2225 _YESNO(spam_str,ham_str)_ returns the first argument ("Yes" if missing)
2226 for spam, and the second argument ("No" if missing) for ham
2227 _YESNOCAPS_ "YES" for spam, "NO" for nonspam (=ham)
2228 _YESNOCAPS(spam_str,ham_str)_ same as _YESNO(...)_, but uppercased
2229 _SCORE(PAD)_ message score, if PAD is included and is either spaces or
2230 zeroes, then pad scores with that many spaces or zeroes
2231 (default, none) ie: _SCORE(0)_ makes 2.4 become 02.4,
2232 _SCORE(00)_ is 002.4. 12.3 would be 12.3 and 012.3
2233 respectively.
2234 _REQD_ message threshold
2235 _VERSION_ version (eg. 3.0.0 or 3.1.0-r26142-foo1)
2236 _SUBVERSION_ sub-version/code revision date (eg. 2004-01-10)
2237 _RULESVERSION_ comma-separated list of rules versions, retrieved from
2238 an '# UPDATE version' comment in rules files; if there is
2239 more than one set of rules (update channels) the order
2240 is unspecified (currently sorted by names of files);
2241 _HOSTNAME_ hostname of the machine the mail was processed on
2242 _REMOTEHOSTNAME_ hostname of the machine the mail was sent from, only
2243 available with spamd
2244 _REMOTEHOSTADDR_ ip address of the machine the mail was sent from, only
2245 available with spamd
2246 _BAYES_ bayes score
2247 _TOKENSUMMARY_ number of new, neutral, spammy, and hammy tokens found
2248 _BAYESTC_ number of new tokens found
2249 _BAYESTCLEARNED_ number of seen tokens found
2250 _BAYESTCSPAMMY_ number of spammy tokens found
2251 _BAYESTCHAMMY_ number of hammy tokens found
2252 _HAMMYTOKENS(N)_ the N most significant hammy tokens (default, 5)
2253 _SPAMMYTOKENS(N)_ the N most significant spammy tokens (default, 5)
2254 _DATE_ rfc-2822 date of scan
2255 _STARS(*)_ one "*" (use any character) for each full score point
2256 (note: limited to 50 'stars')
2257 _SENDERDOMAIN_ a domain name of the envelope sender address, lowercased
2258 _AUTHORDOMAIN_ a domain name of the author address (the From header
2259 field), lowercased; note that RFC 5322 allows a mail
2260 message to have multiple authors - currently only the
2261 domain name of the first email address is returned
2262 _RELAYSTRUSTED_ relays used and deemed to be trusted (see the
2263 'X-Spam-Relays-Trusted' pseudo-header)
2264 _RELAYSUNTRUSTED_ relays used that can not be trusted (see the
2265 'X-Spam-Relays-Untrusted' pseudo-header)
2266 _RELAYSINTERNAL_ relays used and deemed to be internal (see the
2267 'X-Spam-Relays-Internal' pseudo-header)
2268 _RELAYSEXTERNAL_ relays used and deemed to be external (see the
2269 'X-Spam-Relays-External' pseudo-header)
2270 _LASTEXTERNALIP_ IP address of client in the external-to-internal
2271 SMTP handover
2272 _LASTEXTERNALRDNS_ reverse-DNS of client in the external-to-internal
2273 SMTP handover
2274 _LASTEXTERNALHELO_ HELO string used by client in the external-to-internal
2275 SMTP handover
2276 _AUTOLEARN_ autolearn status ("ham", "no", "spam", "disabled",
2277 "failed", "unavailable")
2278 _AUTOLEARNSCORE_ portion of message score used by autolearn
2279 _TESTS(,)_ tests hit separated by "," (or other separator)
2280 _TESTSSCORES(,)_ as above, except with scores appended (eg. AWL=-3.0,...)
2281 _SUBTESTS(,)_ subtests (start with "__") hit separated by ","
2282 (or other separator)
2283 _DCCB_ DCC's "Brand"
2284 _DCCR_ DCC's results
2285 _PYZOR_ Pyzor results
2286 _RBL_ full results for positive RBL queries in DNS URI format
2287 _LANGUAGES_ possible languages of mail
2288 _PREVIEW_ content preview
2289 _REPORT_ terse report of tests hit (for header reports)
2290 _SUMMARY_ summary of tests hit for standard report (for body reports)
2291 _CONTACTADDRESS_ contents of the 'report_contact' setting
2292 _HEADER(NAME)_ includes the value of a message header. value is the same
2293 as is found for header rules (see elsewhere in this doc)
2294 _TIMING_ timing breakdown report
2295 _ADDEDHEADERHAM_ resulting header fields as requested by add_header for spam
2296 _ADDEDHEADERSPAM_ resulting header fields as requested by add_header for ham
2297 _ADDEDHEADER_ same as ADDEDHEADERHAM for ham or ADDEDHEADERSPAM for spam
2298 If a tag reference uses the name of a tag which is not in this list or
2300 defined by a loaded plugin, the reference will be left intact and not
2301 replaced by any value.
2302 Additional, plugin specific, template tags can be found in the
2304 documentation for the following plugins:
2305 L<Mail::SpamAssassin::Plugin::ASN>
2307 L<Mail::SpamAssassin::Plugin::AWL>
2308 L<Mail::SpamAssassin::Plugin::TxRep>
2309 The "HAMMYTOKENS" and "SPAMMYTOKENS" tags have an optional second
2311 argument which specifies a format. See the HAMMYTOKENS/SPAMMYTOKENS
2312 TAG FORMAT section, below, for details.
2313 HAMMYTOKENS/SPAMMYTOKENS TAG FORMAT
2315 The "HAMMYTOKENS" and "SPAMMYTOKENS" tags have an optional second
2316 argument which specifies a format: "_SPAMMYTOKENS(N,FMT)_",
2317 "_HAMMYTOKENS(N,FMT)_" The following formats are available:
2318 short
2320 Only the tokens themselves are listed. For example, preference
2321 file entry:
2322 "add_header all Spammy _SPAMMYTOKENS(2,short)_"
2324 Results in message header:
2326 "X-Spam-Spammy: remove.php, UD:jpg"
2328 Indicating that the top two spammy tokens found are "remove.php"
2330 and "UD:jpg". (The token itself follows the last colon, the text
2331 before the colon indicates something about the token. "UD" means
2332 the token looks like it might be part of a domain name.)
2333 compact
2335 The token probability, an abbreviated declassification distance
2336 (see example), and the token are listed. For example, preference
2337 file entry:
2338 "add_header all Spammy _SPAMMYTOKENS(2,compact)_"
2340 Results in message header:
2342 "0.989-6--remove.php, 0.988-+--UD:jpg"
2344 Indicating that the probabilities of the top two tokens are 0.989
2346 and 0.988, respectively. The first token has a declassification
2347 distance of 6, meaning that if the token had appeared in at least 6
2348 more ham messages it would not be considered spammy. The "+" for
2349 the second token indicates a declassification distance greater than
2350 9.
2351 long
2353 Probability, declassification distance, number of times seen in a
2354 ham message, number of times seen in a spam message, age and the
2355 token are listed.
2356 For example, preference file entry:
2358 "add_header all Spammy _SPAMMYTOKENS(2,long)_"
2360 Results in message header:
2362 "X-Spam-Spammy: 0.989-6--0h-4s--4d--remove.php,
2364 0.988-33--2h-25s--1d--UD:jpg"
2365 In addition to the information provided by the compact option, the
2367 long option shows that the first token appeared in zero ham
2368 messages and four spam messages, and that it was last seen four
2369 days ago. The second token appeared in two ham messages, 25 spam
2370 messages and was last seen one day ago. (Unlike the "compact"
2371 option, the long option shows declassification distances that are
2372 greater than 9.)
2373
2375 A line starting with the text "lang xx" will only be interpreted if the
2376 user is in that locale, allowing test descriptions and templates to be
2377 set for that language.
2378 The locales string should specify either both the language and country,
2380 e.g. "lang pt_BR", or just the language, e.g. "lang de".
2381
2383 "Mail::SpamAssassin" "spamassassin" "spamd"
2384perl v5.30.0 2019-10-01 Mail::SpamAssassin::Conf(3)