Mail::...::Conf(3pm)

📦

version 4.0.2+svn1935691 · 17 versions

4.0.2+svn1935691 · ubuntu stonking (latest)
4.0.1 · opensuse-leap 16.0
4.0.1 · epel 10
3.4.6 · centos-stream 9
4.0.1 · alpine 3.22
4.0.2 · alpine 3.23
4.0.2 · alpine 3.24
4.0.2 · arch rolling
4.0.2~rc2 · ubuntu questing
3.4.6 · ubuntu jammy
3.4.6 · ubuntu jammy
4.0.1 · fedora 43
4.0.2 · fedora 44
4.0.0 · ubuntu noble
4.0.1 · debian bookworm
4.0.2 · ubuntu resolute
4.0.1 · debian trixie

✨ NAME ✨

Mail::SpamAssassin::Conf — okay so this page (...::Conf(3pm), yes) is literally the SpamAssassin configuration file. Everything about configuring SpamAssassin lives right here. 💖

🎀 SYNOPSIS 🎀

# a comment

rewrite_header Subject          *****SPAM*****

full PARA_A_2_C_OF_1618         /Paragraph .a.{0,10}2.{0,10}C. of S. 1618/i
describe PARA_A_2_C_OF_1618     Claims compliance with senate bill 1618

header FROM_HAS_MIXED_NUMS      From =~ /\d+[a-z]+\d+\S*@/i
describe FROM_HAS_MIXED_NUMS    From: contains numbers mixed in with letters

score A_HREF_TO_REMOVE          2.0

lang es describe FROM_FORGED_HOTMAIL Forzado From: simula ser de hotmail.com

lang pt_BR report O programa detetor de Spam ZOE [...]

🌈 DESCRIPTION 🌈

SpamAssassin gets configured using traditional UNIX-style configuration files, and they're loaded from the /usr/share/spamassassin and /etc/spamassassin directories. 🗂️

There's a web page that lists the most important configuration settings used to configure SpamAssassin, and if you're a novice you're encouraged to read it first (no gatekeeping here, bestie 🫶):

https://wiki.apache.org/spamassassin/ImportantInitialConfigItems

🦋 FILE FORMAT 🦋

The # character starts a comment, which continues until the end of the line. NOTE: if you wanna use the # character as part of a rule or configuration option, it has to be escaped with a backslash. Like: \# 💅
Whitespace in the files is not significant, but please note: starting a line with whitespace is deprecated, because its use is reserved for multi-line rule definitions at some point in the future. 🔮
Currently, each rule or configuration setting must fit on one line; multi-line settings are not supported yet. 😭
File and directory paths can use ~ to refer to the user's home directory, but no other shell-style path extensions such as globing or ~user/ are supported. Nope nope. 🙅
Where appropriate below, default values are listed in parentheses.
Test names (SYMBOLIC_TEST_NAME) can only contain alphanumerics/underscores, can not start with a digit, and must be less than 128 characters. That's the whole law. 👑

👑 USER PREFERENCES 👑

These options work in both site-wide (local.cf) and user-specific (user_prefs) configuration files, to customize how SpamAssassin handles incoming email messages. 📬

🔥 SCORING OPTIONS 🔥

required_score n.nn (default: 5)

Sets the score required before a mail is considered spam. n.nn can be an integer or a real number. 5.0 is the default setting, and honestly it's quite aggressive; it would be suitable for a single-user setup, but if you're an ISP installing SpamAssassin, you should probably set the default to be more conservative, like 8.0 or 10.0.

It is not recommended to automatically delete or discard messages marked as spam, because your users will complain. But if you choose to do that anyway, only delete messages with an exceptionally high score such as 15.0 or higher. ⚠️

This option was previously known as required_hits, and that name is still accepted, but it is deprecated. 💀

score SYMBOLIC_TEST_NAME n.nn [ n.nn n.nn n.nn ]

Assign scores (the number of points for a hit) to a given test. Scores can be positive or negative real numbers or integers. SYMBOLIC_TEST_NAME is the symbolic name used by SpamAssassin for that test; for example, FROM_ENDS_IN_NUMS.

If only one valid score is listed, then that score is always used for a test.

If four valid scores are listed, then the score that is used depends on how SpamAssassin is being used:

The first score is used when both Bayes and network tests are disabled (score set 0).
The second score is used when Bayes is disabled, but network tests are enabled (score set 1).
The third score is used when Bayes is enabled and network tests are disabled (score set 2).
The fourth score is used when Bayes is enabled and network tests are enabled (score set 3).

Setting a rule's score to 0 will disable that rule from running.

If any of the score values are surrounded by parenthesis (), then all of the scores in the line are considered to be relative to the already set score. i.e. (3) means increase the score for this rule by 3 points in all score sets. (3) (0) (3) (0) means increase the score for this rule by 3 in score sets 0 and 2 only. 🧮

If no score is given for a test by the end of the configuration, a default score is assigned: a score of 1.0 is used for all tests, except those whose names begin with T_ (this is used to indicate a rule in testing) which receive 0.01.

Note that test names which begin with __ are indirect rules used to compose meta-match rules and can also act as prerequisites to other rules. They are not scored or listed in the 'tests hit' reports, but assigning a score of 0 to an indirect rule will disable it from running.

💖 WELCOMELIST AND BLOCKLIST OPTIONS 💖

welcomelist_from user@example.com

Previously whitelist_from which will work interchangeably until 4.1.

Used to welcomelist sender addresses which send mail that is often tagged (incorrectly) as spam.

Use of this setting is not recommended, since it blindly trusts the message, which is routinely and easily forged by spammers and phish senders. The recommended solution is to instead use welcomelist_auth or other authenticated welcomelisting methods, or welcomelist_from_rcvd. 🎣

Welcomelist and blocklist addresses are now file-glob-style patterns, so friend@somewhere.com, *@isp.com, or *.domain.net will all work. Specifically, * and ? are allowed, but all other metacharacters are not. Regular expressions are not used, for security reasons. Matching is case-insensitive.

Multiple addresses per line, separated by spaces, is OK. Multiple welcomelist_from lines are also OK.

The headers checked for welcomelist addresses are as follows: if Resent-From is set, use that; otherwise check all addresses taken from the following set of headers:

Envelope-Sender
Resent-Sender
X-Envelope-From
From

In addition, the envelope sender data, taken from the SMTP envelope data where this is available, is looked up. See envelope_sender_header.

e.g.

welcomelist_from joe@example.com fred@example.com
welcomelist_from *@example.com

unwelcomelist_from user@example.com

Previously unwelcomelist_from which will work interchangeably until 4.1.

Used to remove a default welcomelist_from entry, so for example a distribution welcomelist_from can be overridden in a local.cf file, or an individual user can override a welcomelist_from entry in their own user_prefs file. The specified email address has to match exactly (although case-insensitively) the address previously used in a welcomelist_from line, which implies that a wildcard only matches literally the same wildcard (not 'any' address).

e.g.

unwelcomelist_from joe@example.com fred@example.com
unwelcomelist_from *@example.com

welcomelist_from_rcvd addr@lists.sourceforge.net sourceforge.net

Previously whitelist_from_rcvd which will work interchangeably until 4.1.

Works similarly to welcomelist_from, except that in addition to matching a sender address, a relay's rDNS name or its IP address must match too for the welcomelisting rule to fire. The first parameter is a sender's e-mail address to welcomelist, and the second is a string to match the relay's rDNS, or its IP address. Matching is case-insensitive. 🔍

This second parameter is matched against a TCP-info information field as provided in a FROM clause of a trace information (i.e. in a Received header field, see RFC 5321). Only the Received header fields inserted by trusted hosts are considered. This parameter can either be a full hostname, or a domain component of that hostname, or an IP address (optionally followed by a slash and a prefix length) in square brackets. The address prefix (mask) length with a slash may stand within brackets along with an address, or may follow the bracketed address. Reverse DNS lookup is done by an MTA, not by SpamAssassin.

For backward compatibility as an alternative to a CIDR notation, an IPv4 address in brackets may be truncated on classful boundaries to cover whole subnets, e.g. [10.1.2.3], [10.1.2], [10.1], [10].

In other words, if the host that connected to your MX had an IP address 192.0.2.123 that mapped to sendinghost.example.org, you should specify sendinghost.example.org, or example.org, or [192.0.2.123], or [192.0.2.0/24], or [192.0.2] here. 🌐

Note that this requires that internal_networks be correct. For simple cases, it will be, but for a complex network you may get better results by setting that parameter.

It also requires that your mail exchangers be configured to perform DNS reverse lookups on the connecting host's IP address, and to record the result in the generated Received header field according to RFC 5321.

e.g.

welcomelist_from_rcvd joe@example.com  example.com
welcomelist_from_rcvd *@*              mail.example.org
welcomelist_from_rcvd *@axkit.org      [192.0.2.123]
welcomelist_from_rcvd *@axkit.org      [192.0.2.0/24]
welcomelist_from_rcvd *@axkit.org      [192.0.2.0]/24
welcomelist_from_rcvd *@axkit.org      [2001:db8:1234::/48]
welcomelist_from_rcvd *@axkit.org      [2001:db8:1234::]/48

def_welcomelist_from_rcvd addr@lists.sourceforge.net sourceforge.net

Previously def_whitelist_from_rcvd which will work interchangeably until 4.1.

Same as welcomelist_from_rcvd, but used for the default welcomelist entries in the SpamAssassin distribution. The welcomelist score is lower, because these are often targets for spammer spoofing. 👀

welcomelist_allows_relays user@example.com

Previously whitelist_allows_relays which will work interchangeably until 4.1.

Specify addresses which are in welcomelist_from_rcvd that sometimes send through a mail relay other than the listed ones. By default mail with a From address that is in welcomelist_from_rcvd that does not match the relay will trigger a forgery rule. Including the address in welcomelist_allows_relay prevents that.

Multiple addresses per line, separated by spaces, is OK. Multiple welcomelist_allows_relays lines are also OK. 💖

The address you write down doesn't have to match the address that was used earlier in a welcomelist_from_rcvd line exactly — bestie, it gets compared against the address in the header, okay? Not the one from before. It's giving "close enough is literally not a thing here, but also kind of is."

e.g.

welcomelist_allows_relays joe@example.com fred@example.com
welcomelist_allows_relays *@example.com

unwelcomelist_from_rcvd user@example.com — bestie this used to be called unwhitelist_from_rcvd, and that old name still works, interchangeably, all the way until 4.1. ✨

What it does: it rips out a default welcomelist_from_rcvd or def_welcomelist_from_rcvd entry. So like, a distribution's welcomelist_from_rcvd can get overridden in a local.cf file, or one individual user can override a welcomelist_from_rcvd entry inside their own "user_prefs" file. 💅

⚠️ The email address you specify has to match exactly the address that was previously used in a welcomelist_from_rcvd line. Exact. No vibes-based matching. No cap.

e.g.

unwelcomelist_from_rcvd joe@example.com fred@example.com
unwelcomelist_from_rcvd *@axkit.org

blocklist_from user@example.com — you use this to name addresses that send mail which keeps getting tagged (wrongly!) as non-spam, but which the user genuinely does not want. Same format as "welcomelist_from". 🚫

unblocklist_from user@example.com — previously unblacklist_from, which will work interchangeably until 4.1. 🦋

It removes a default blocklist_from entry — so a distribution's blocklist_from can be overridden in a local.cf file, or an individual user can override a blocklist_from entry in their own "user_prefs" file. And yeah, the email address you specify has to match exactly the address previously used in a blocklist_from line. 🙈

e.g.

unblocklist_from joe@example.com fred@example.com
unblocklist_from *@spammer.com

welcomelist_to user@example.com — previously whitelist_to, works interchangeably until 4.1. 💖

If the address you give shows up as a recipient somewhere in the message headers (Resent-To, To, Cc, the obvious envelope recipient, etc. etc.), the mail gets listed as allowed. Super useful if you're deploying SpamAssassin system-wide and you do not want some users to have their mail filtered. Same format as "welcomelist_from".

There are three levels of To-welcomelisting: "welcomelist_to", "more_spam_to" and "all_spam_to". Users sitting in that first level may still get some spammish mails blocked, but users in "all_spam_to" should never get mail blocked. 👑

The headers it checks for welcomelist addresses go like this: if "Resent-To" or "Resent-Cc" are set, use those; otherwise it checks all addresses taken from this exact set of headers:

To
Cc
Apparently-To
Delivered-To
Envelope-Recipients
Apparently-Resent-To
X-Envelope-To
Envelope-To
X-Delivered-To
X-Original-To
X-Rcpt-To
X-Real-To

more_spam_to user@example.com — see above. 👆

all_spam_to user@example.com — see above. 👆

blocklist_to user@example.com — previously blacklist_to, which will work interchangeably until 4.1.

If the given address appears as a recipient in the message headers (Resent-To, To, Cc, obvious envelope recipient, etc.), the mail gets blocklisted. Same format as "blocklist_from". 🚫

welcomelist_auth user@example.com — previously whitelist_auth, works interchangeably until 4.1. ✨

This one names addresses that send mail which often gets tagged (incorrectly!) as spam. But it's different from "welcomelist_from" and "welcomelist_from_rcvd", because it first verifies that the message was actually sent by an authorized sender for that address before it does any welcomelisting. Verification first, trust second. Periodt.

Authorization goes through one of the installed sender-authorization schemes: SPF (using "Mail::SpamAssassin::Plugin::SPF"), or DKIM (using "Mail::SpamAssassin::Plugin::DKIM").

🌸 Heads up, bestie: those plugins must be active, and working, for any of this to operate. No plugin, no party.

Using "welcomelist_auth" is roughly equivalent to writing duplicate "welcomelist_from_spf", "welcomelist_from_dk", and "welcomelist_from_dkim" lines for every address you specified.

e.g.

welcomelist_auth joe@example.com fred@example.com
welcomelist_auth *@example.com

def_welcomelist_auth user@example.com — previously def_whitelist_auth, works interchangeably until 4.1.

Same as "welcomelist_auth", except it's for the default welcomelist entries in the SpamAssassin distribution. The welcomelist score is lower, because these are often targets for spammer spoofing. 💀

unwelcomelist_auth user@example.com — previously unwhitelist_auth, works interchangeably until 4.1.

Used to remove a "welcomelist_auth" or "def_welcomelist_auth" entry. The specified email address has to match exactly the address previously used. exact. match. only. 🫶

e.g.

unwelcomelist_auth joe@example.com fred@example.com
unwelcomelist_auth *@example.com

enlist_uri_host (listname) host ... — adds one or more host names or domain names to a named list of URI domains. That named list can then be consulted through a check_uri_host_listed() eval rule implemented by the WLBLEval plugin, which takes the list name as an argument. 🌈

🎀 The parentheses around a list name are literal — it's a required syntax, not a lil decoration.

Host names may optionally be prefixed by an exclamation mark '!', which produces false as a result if that entry matches. This makes it way easier to exclude some subdomains when their superdomain is listed, for example:

enlist_uri_host (MYLIST) !sub1.example.com !sub2.example.com example.com

No wildcards are supported, but subdomains do match implicitly. Lists are independent of each other. Searching a named list starts by looking up the full hostname first, then leading fields get progressively stripped off (e.g.: sub.example.com, example.com, com) until a match is found or we run out of fields. The first matching entry — the most specific one — decides whether a lookup yielded a true (no '!' prefix) or a false (with a '!' prefix) result.

If a URL found in a message contains an IP address where a host name should be, the given list has to specify the exact same IP address (instead of a host name) in order to match. 🦋

Use the delist_uri_host directive to neutralize previous enlist_uri_host settings.

Enlisting to lists named 'BLOCK' and 'WELCOME' have their shorthand directives blocklist_uri_host and welcomelist_uri_host plus corresponding default rules — but the names 'BLOCK' and 'WELCOME' are otherwise not special or reserved. 💅

delist_uri_host [ (listname) ] host ... — removes one or more specified host names from a named list of URI domains. Removing an unlisted name is ignored (it is not an error, breathe). Listname is optional: if you specify it, then just the named list is affected; otherwise hosts get removed from all URI host lists created so far. Parentheses around a list name are a required syntax. 🧚

⚠️ Real talk: directives in configuration files are processed in sequence. So delist_uri_host only applies to previously listed entries and has no effect on enlisted entries in directives that haven't been processed yet.

For convenience (and similarity to the enlist_uri_host directive), hostnames may be prefixed by an exclamation mark — which gets stripped off from each name and has no meaning here. 🙈

enlist_addrlist (listname) user@example.com — adds one or more addresses to a named list of addresses. The named list can then be consulted through a check_from_in_list() or a check_to_in_list() eval rule implemented by the WLBLEval plugin, which takes the list name as an argument. Parenthesis around a list name are literal — a required syntax. 💖

Listed addresses are file-glob-style patterns, so "friend@somewhere.com", "*@isp.com", or "*.domain.net" will all work. Specifically, "*" and "?" are allowed, but all other metacharacters are not. Regular expressions are not used here, for security reasons. Matching is case-insensitive. 🔥

Multiple addresses per line, separated by spaces, is OK. Multiple "enlist_addrlist" lines are also OK.

Enlisting an address to the list named blocklist_to is synonymous to using the directive blocklist_to.

Enlisting an address to the list named blocklist_from is synonymous to using the directive blocklist_from.

Enlisting an address to the list named welcomelist_to is synonymous to using the directive welcomelist_to.

Enlisting an address to the list named welcomelist_from is synonymous to using the directive welcomelist_from.

e.g.

enlist_addrlist (PAYPAL_ADDRESS) service@paypal.com
enlist_addrlist (PAYPAL_ADDRESS) *@paypal.co.uk

blocklist_uri_host host-or-domain ... — previously blacklist_uri_host, which will work interchangeably until 4.1. 🚫

It's a shorthand for a directive: enlist_uri_host (BLOCK) host ...

Please see directives enlist_uri_host and delist_uri_host for details. 👀

welcomelist_uri_host host-or-domain ... — previously whitelist_uri_host, which will work interchangeably until 4.1. ✨

It's a shorthand for a directive: enlist_uri_host (WELCOME) host ...

Please see directives enlist_uri_host and delist_uri_host for details. 👀

🏷️ BASIC MESSAGE TAGGING OPTIONS 🏷️

rewrite_header { subject | from | to } STRING — okay so by default, suspected spam messages do not have their Subject, From or To lines tagged to say "hey this is spam." But if you set this option, that header gets tagged with STRING to indicate the message is spam. 🎀

For the From or To headers, it takes the form of an RFC 2822 comment following the address in parentheses. For the Subject header, it gets prepended to the original subject. 💅

⚠️ Careful bestie: you should only use the _REQD_ and _SCORE_ tags when rewriting the Subject header, and only if "report_safe" is 0. Otherwise you may not be able to remove the SpamAssassin markup via the normal methods. Not a vibe.

More info about tags is explained below in the TEMPLATE TAGS section.

🙈 Parentheses are not permitted in STRING if you're rewriting the From or To headers. (They will be converted to square brackets.)

If "rewrite_header subject" is used, but the message being rewritten does not already contain a "Subject" header, one will be created. New header, who dis. 👑

oh and heads up: a null value for STRING will straight-up remove any existing rewrite for that header. like, gone. poof. 💅
subjprefix — this one slaps a prefix onto the Subject line of an email whenever a rule matches. but — and this is the important bit — for it to do literally anything, the rewrite_header Subject config option has to be enabled too. they're a package deal, bestie. 🫶

to keep older SpamAssassin versions from chewing you out with warnings, use the check if can(Mail::SpamAssassin::Conf::feature_subjprefix).

and ngl, to actually get this feature working you might need an add_header all Subjprefix _SUBJPREFIX_ config line — that's the case when the glue between your MTA and SpamAssassin is out here rewriting the email content. 🙈

here's the example, verbatim, no cap:

rewrite_header Subject *****SPAM*****
add_header all Subjprefix _SUBJPREFIX_
body     OLEMACRO_MALICE eval:check_olemacro_malice()
describe OLEMACRO_MALICE Dangerous Office Macro
score    OLEMACRO_MALICE 5.0
if can(Mail::SpamAssassin::Conf::feature_subjprefix)
  subjprefix OLEMACRO_MALICE [VIRUS]
endif

add_header { spam | ham | all } header_name string — this is how you add your own little customized headers to whichever kind of message you want: spam, ham, or all (which means both, bestie, not just one). every single one of these headers starts with X-Spam-, so if your header_name is Foo you're getting a header called X-Spam-Foo. and header_name is only allowed to use the character set [A-Za-z0-9_-]. stay in your lane, characters. ⭐

the order of your add_header config options is preserved — inserted headers follow the order you declared them in. and when you're mixing add_header with clear_headers and remove_header, keep this in mind: add_header appends a new header to the current list, but only after first removing any existing header fields with the same name. also, add_header, clear_headers and remove_header can show up in multiple .cf files, and those get interpreted in alphabetic order. 👑

your string can contain tags, and those are explained down in the TEMPLATE TAGS section. you can also use \n and \t in the header to add newlines and tabulators however you like. one gotcha tho: a backslash has to be written as \\, and any other escaped chars will be silently removed. silently. rude but okay. 💀

all headers get folded if fold_headers is set to 1. Note: manually adding newlines via \n disables any further automatic wrapping (translation: yes, long header lines are possible). the lines will still be properly folded (marked as continuing) though, so don't stress.

you can also customize existing headers with add_header — when you do, only the subset of messages you specified gets changed. 🎀

see also clear_headers and remove_header if removing headers is more your vibe.

here are some examples — and these are literally the defaults, so note well that Checker-Version can not be changed or removed:

add_header spam Flag _YESNOCAPS_
add_header all Status _YESNO_, score=_SCORE_ required=_REQD_ tests=_TESTS_ autolearn=_AUTOLEARN_ version=_VERSION_
add_header all Level _STARS(*)_
add_header all Checker-Version SpamAssassin _VERSION_ (_SUBVERSION_) on _HOSTNAME_

remove_header { spam | ham | all } header_name — yeet headers off of whichever kind of message you pick (spam, ham, or all to remove from either). all headers begin with X-Spam-, so your header_name gets appended onto X-Spam-. bye felicia. 🦋

see also clear_headers if you wanna nuke all the headers at once instead.

Note: X-Spam-Checker-Version is not removable, because the version info is needed by mail administrators and developers to debug problems. and honestly? without at least one header it might not even be possible to determine that SpamAssassin is running at all. main character energy, that header. 👑

clear_headers — wipes the list of headers that get added to messages. use this before any add_header options if you want to stop the default headers from being added to the message. clean slate, fresh start, icon behavior. ✨

add_header, clear_headers and remove_header may appear in multiple .cf files, which get interpreted in alphabetic order — so a clear_headers in a later file will remove all added headers from previously interpreted configuration files. which may or may not be what you wanted. check yourself before you wreck yourself. 😭

Note: X-Spam-Checker-Version is not removable, because the version information is needed by mail administrators and developers to debug problems. without at least one header, it might not even be possible to determine that SpamAssassin is running. (yes we said it twice, it's that serious.)

report_safe ( 0 | 1 | 2 ) — (default: 1) — okay so if you set this to 1, and an incoming message gets tagged as spam, SpamAssassin will not modify the original message. instead it creates a brand new report message and attaches the original message as a message/rfc822 MIME part — which ensures the original message is completely preserved, not easily opened, and easier to recover. protective queen. 💖

set it to 2 and the original messages get attached with a content type of text/plain instead of message/rfc822. why would you want that? safety reasons, bestie — certain broken mail clients will automatically load attachments without any action from the user, and that's a whole vibe killer. fair warning though: this setting may also make it somewhat more difficult to extract or view the original message. trade-offs. ⚖️

set it to 0 and incoming spam only gets modified by adding some X-Spam- headers — no changes at all to the body. in addition, a header named X-Spam-Report will be added to spam. you can use the remove_header option to remove that header after setting report_safe to 0. 🙈

see report_safe_copy_headers if you want to copy headers from the original mail into the tagged messages. 💌

report_wrap_width — (default: 75) — sets the wrap width for description lines in the X-Spam-Report header. and no, it does not account for tab width. it is what it is. 💅

🌸 LANGUAGE OPTIONS 🌸

ok_locales xx [ yy zz ... ] — (default: all) — this one tells SpamAssassin which locales are considered OK for incoming mail. mail that uses the character sets allowed by this option will not be marked as possibly being spam in a foreign language. 🧚

if you get a ton of spam in foreign languages and literally never get any non-spam in those languages, this can help you out. Note that all ISO-8859-* character sets, and Windows code page character sets, are always permitted by default. always. no matter what.

set this to all to allow all character sets — and that is the default, so if you do nothing, congrats, you already did it. ⭐

the rules CHARSET_FARAWAY, CHARSET_FARAWAY_BODY, and CHARSET_FARAWAY_HEADERS get triggered based on how this is set.

examples, exact as written:

ok_locales all         (allow all locales)
ok_locales en          (only allow English)
ok_locales en ja zh    (allow English, Japanese, and Chinese)

Note: if there are multiple ok_locales lines, only the last one is used. the rest? ignored. sorry to those lines.

pick the locales you wanna allow from this list, bestie:

en — Western character sets in general
ja — Japanese character sets
ko — Korean character sets
ru — Cyrillic character sets
th — Thai character sets
zh — Chinese (both simplified and traditional) character sets

normalize_charset ( 0 | 1 ) — (default: 1) — this decides whether to decode non-UTF-8 and non-ASCII textual parts and recode them to UTF-8 before the text gets handed over to rules processing. 🌈

how does it guess the character set? primarily based on a declared character set in a Content-Type header. but if that decoding attempt fails, a module called Encode::Detect::Detector gets consulted (if it's available, that is) to provide a guess based on the actual text, and then decoding is re-attempted. detective work, honestly. 🔍

even if the option is enabled, no unnecessary decoding and re-encoding work gets done when it can be avoided — like with an all-ASCII text that has a US-ASCII or extended ASCII character set declaration, e.g. UTF-8, ISO-8859-nn or Windows-nnnn. efficient queen. 👑

Warning tho: Unicode support in old versions of perl, or in the core module Encode, is likely to be buggy in places. so if the normalize_charset function is enabled, it is advised to stick to more recent versions of perl (preferably 5.12 or later). the module Encode::Detect::Detector is optional — when it's necessary, it will be used if it is available. 🫶

💜 NETWORK TEST OPTIONS 💜

trusted_networks IPaddress[/masklen] ... — (default: none) — what networks or hosts are 'trusted' in your setup. 🌐

and what does "trusted" actually mean here? it means relay hosts on these networks are considered to not be potentially operated by spammers, open relays, or open proxies. a trusted host could conceivably relay spam, but it will not originate it, and it will not forge header data. also: DNS blocklist checks will never query for hosts on these networks. never. periodt. 💅

see https://wiki.apache.org/spamassassin/TrustPath for more information.

MXes for your domain(s) and internal relays should also be specified using the internal_networks setting. and when you've got 'trusted' hosts that are not MXes or internal relays for your domain(s), those should only be specified in trusted_networks. don't mix it up bestie, the vibes depend on it. 🦋

the IPaddress can be an IPv4 address (in the dot-quad form), or an IPv6 address optionally enclosed in square brackets. scoped link-local IPv6 addresses are syntactically recognized, but the interface scope is currently ignored (e.g. [fe80::1234%eth0]) and should be avoided. lowkey a trap. 🙈

if a /masklen is specified, it's considered a CIDR-style 'netmask' length, specified in bits. if it's not specified, but less than 4 octets of an IPv4 address are given with a trailing dot, then an implied netmask length covers all addresses in the remaining octets (so the implied masklen is /8 or /16 or /24). and if masklen isn't specified and there's no trailing dot, then you just get that single IP address you specified, as if the masklen were "/32" with an IPv4 address, or "/128" in the case of an IPv6 address. math is math. ✨

if the module Net::CIDR::Lite is installed, it's also possible to use the dash separated IP range format (e.g. 192.168.1.1-192.168.255.255). fun little bonus, iykyk.

if a network or host address is prefaced by a !, then the matching network or host gets excluded from the list — even if a less specific (shorter netmask length) subnet is later specified in the list. this is how you let a subset of a wider network be exempt. and in the case of overlapping subnets, you should specify the more specific subnets first (tighter matching, i.e. with a longer netmask length), followed by the less specific ones (shorter netmask length) — that way you get predictable results regardless of which search algorithm is being used. why does it matter? because when the Net::Patricia module is installed, the search finds the tightest matching entry in the list, while a sequential search as used in the absence of the module Net::Patricia will find the first matching entry in the list. two algorithms, one list, don't get caught slipping. 😭

okay before we get into ANY of this — a lil heads up that's honestly the most important thing on this whole page: 127.0.0.0/8 and ::1 are ALWAYS in trusted_networks, periodt. Doesn't matter what you write in your config, they're grandfathered in. no cap 💅

Examples, because seeing it makes it click way better:

trusted_networks 192.168.0.0/16        # all in 192.168.*.*
trusted_networks 192.168.              # all in 192.168.*.*
trusted_networks 212.17.35.15          # just that host
trusted_networks !10.0.1.5 10.0.1/24   # all in 10.0.1.* but not 10.0.1.5
trusted_networks 2001:db8:1::1 !2001:db8:1::/64 2001:db8::/32
  # 2001:db8::/32 and 2001:db8:1::1/128, except the rest of 2001:db8:1::/64

This one works additively, bestie — like, it's giving "yes and". Drop another trusted_networks line after your first one and it just appends new entries onto the list of trusted networks. It does NOT reset anything. If you wanna wipe the slate clean and start over, that's what clear_trusted_networks is for.

If trusted_networks isn't set but internal_networks is, then whatever you put in internal_networks gets used for this parameter instead. They share ✨

And if neither trusted_networks nor internal_networks is set, SpamAssassin runs a basic inference algorithm. The way that works is:

If the 'from' host has an IP address in a private (RFC 1918) network range, then it's trusted
If there are authentication tokens in the received header, and the previous host was trusted, then this host is also trusted
Otherwise this host, and all further hosts, are consider untrusted.

`clear_trusted_networks`

Empty the list of trusted networks. That's it, that's the whole vibe — releasing the trust 🕊️

`internal_networks` `IPaddress[/masklen] ...` (default: none)

Which networks or hosts are 'internal' in your setup. "Internal" means relay hosts on these networks count as MXes for your domain(s), or as internal relays. Same syntax as trusted_networks up above — go look there, it's all the same tea 🫖

This value gets used when checking 'dial-up' or dynamic IP address blocklists, so we can catch direct-to-MX spamming.

Real talk: trusted relays that accept mail directly from dial-up connections (like, ones also doing the whole mail submission agent — MSA — thing) should NOT be listed in internal_networks. List them only in trusted_networks. Just in trusted. Not both. I'm serious 🙈

If trusted_networks is set and internal_networks isn't, the value of trusted_networks gets used for this parameter.

If neither trusted_networks nor internal_networks is set, then no addresses will be considered local; in other words, any relays past the machine where SpamAssassin is running will be considered external.

Every single entry in internal_networks must also appear in trusted_networks — in other words, internal_networks is always a subset of the trusted set. Always. It's giving "you can't be internal without being trusted first" ✨

Note: 127/8 and ::1 are always included in internal_networks, regardless of your config. Same energy as before, they're simply not leaving 💖

`clear_internal_networks`

Empty the list of internal networks. ~poof~ 🦋

`msa_networks` `IPaddress[/masklen] ...` (default: none)

The networks or hosts acting as MSAs in your setup — but not ones that are also acting as MX relays, okay? Same syntax as trusted_networks above, go peek. 👀

MSA means the relay hosts on these networks accept mail from your own users and authenticate them properly. These relays will never accept mail from hosts that aren't authenticated in some way. Examples of authentication include: IP lists, SMTP AUTH, POP-before-SMTP, etc.

Here's the slay part: every relay found in the message headers after the MSA relay takes on the same trusted and internal classifications as the MSA relay itself, as defined by your trusted_networks and internal_networks configuration. So like, if the MSA relay is trusted and internal, all the relays that precede it will be too. Inheritance, but make it mail headers 🧬

When you use msa_networks to identify an MSA, it's recommended you treat that MSA as both trusted and internal. When an MSA is not included in msa_networks you should treat the MSA as trusted but not internal — however, if the MSA is also acting as an MX or intermediate relay you must always treat it as both trusted and internal, and make sure the MSA includes visible auth tokens in its Received header to identify submission clients. No shortcuts bestie.

Warning: Never include an MSA that also acts as an MX (or is also an intermediate relay for an MX) or otherwise accepts mail from non-authenticated users in msa_networks. Doing so will result in unknown external relays being trusted. That is a 🚨bad time🚨 and you will be sad.

`clear_msa_networks`

Empty the list of msa networks. Bye bye 👋

`originating_ip_headers` `header ...` (default: none)

A list of header field names you can pull an originating IP address out of. For example, webmail servers may record a client IP address in X-Originating-IP. Very "found you" energy 🔍

These IP addresses are virtually appended into the Received: chain, so they get used in RBL checks where appropriate.

Currently the IP addresses are not added into X-Spam-Relays-* header fields, but they may be in the future. So like, don't count on it yet, but also don't be shocked if it happens.

A default list may be supplied via sa-update — use clear_originating_ip_headers to clear and override the settings if you need to.

`clear_originating_ip_headers`

Empty the list of 'originating IP address' header field names. Useful if you want to override the standard list supplied by sa-update. It's giving "I got this myself, thanks" 💅

`always_trust_envelope_sender` `( 0 | 1 )` (default: `0`)

Trust the envelope sender even if the message has been passed through one or more trusted relays. See also envelope_sender_header. 🤝

`skip_rbl_checks` `( 0 | 1 )` (default: `0`)

Turning this on will disable the DNSEval plugin, which is the one that implements Real-time Block List (or: Blockhole List) (RBL) lookups.

By default, SpamAssassin will run RBL checks. Individual blocklists may be disabled selectively by setting a score of a corresponding rule to 0. So you don't have to nuke the whole thing to sideline one list 🎯

See also a related configuration parameter skip_uribl_checks, which controls the URIDNSBL plugin (documented in the URIDNSBL man page).

`dns_available` `{ yes | no | test[: domain1 domain2...] }` (default: `yes`)

Tells SpamAssassin whether DNS resolving is available or not. A value yes indicates DNS resolving is available, a value no indicates DNS resolving is not available — and both of these values apply unconditionally and skip the initial DNS tests, which can be slow or unreliable. Sometimes you just know, you know? 💅

When the option value is a test (with or without arguments), SpamAssassin will query some domain names on the internet during initialization, attempting to determine if DNS resolving is working or not. A space-separated list of domain names may be specified explicitly, or left to a built-in default of a dozen or so domain names. From an explicit or a default list, a subset of three domain names is picked randomly for checking. The test queries for NS records of these domains: if at least one query returns a success, then SpamAssassin considers DNS resolving as available, otherwise not.

Here's the catch though, and I'm telling you because I care: the test can introduce some startup delay if a network connection is down, and in some cases it can wrongly guess that DNS is unavailable because a test connection failed — which then causes disabling several DNS-dependent tests. So a network hiccup = a bunch of tests just ✨not running✨. Not the vibe. 😭

Please note: the DNS test queries for NS records, so specify domain names, not host names.

Since version 3.4.0 of SpamAssassin a default setting for option dns_available is yes. A default in older versions was test.

`dns_server` `ip-addr-port` (default: entries provided by `Net::DNS`)

Specifies an IP address of a DNS server, and optionally its port number. The dns_server directive may be specified multiple times — each entry adds to a list of available resolving name servers. Stack 'em up 🥞

The ip-addr-port argument can either be an IPv4 or IPv6 address, optionally enclosed in brackets, and optionally followed by a colon and a port number. In absence of a port number a standard port number 53 is assumed. When an IPv6 address is specified along with a port number, the address must be enclosed in brackets to avoid parsing ambiguity regarding a colon separator. A scoped link-local IP address is allowed (assuming underlying modules allow it).

Examples :

dns_server 127.0.0.1
dns_server 127.0.0.1:53
dns_server [127.0.0.1]:53
dns_server [::1]:53
dns_server fe80::1%lo0
dns_server [fe80::1%lo0]:53

In absence of dns_server directives, the list of name servers is provided by the Net::DNS module, which typically obtains the list from /etc/resolv.conf, but this may be platform dependent. Please consult the Net::DNS::Resolver documentation for details.

`clear_dns_servers`

Empty the list of explicitly configured DNS servers through a dns_server directive, falling back to Net::DNS-supplied defaults. Back to factory settings, but for DNS 🏭✨

`dns_local_ports_permit` `ranges...`

Add the specified ports or ports ranges to the set of allowed port numbers that can be used as local port numbers when sending DNS queries to a resolver.

The argument is a whitespace-separated or a comma-separated list of single port numbers n, or port number pairs (i.e. m-n) delimited by a -, representing a range. Allowed port numbers are between 1 and 65535.

Directives dns_local_ports_permit and dns_local_ports_avoid are processed in order in which they appear in configuration files. Each directive adds (or subtracts) its subsets of ports to a current set of available ports. Whatever is left in the set by the end of configuration processing is made available to a DNS resolving client code. Order matters bestie, don't shuffle them 🙈

If the resulting set of port numbers is empty (see also the directive dns_local_ports_none), then SpamAssassin does not apply its ports randomization logic, but instead leaves the operating system to choose a suitable free local port number. Let the OS cook 👑

The initial set consists of all port numbers in the range 1024-65535. Note that system config files already modify the set and remove all the IANA registered port numbers and some other ranges, so there is rarely a need to adjust the ranges by site-specific directives.

See also directives dns_local_ports_permit and dns_local_ports_none. (yes it really does reference itself like that, iconic honestly 💅)

`dns_local_ports_avoid` `ranges...`

Remove specified ports or ports ranges from the set of allowed port numbers that can be used as local port numbers when sending DNS queries to a resolver.

Please see directive dns_local_ports_permit for details. Same rules, opposite direction 🔄

`dns_local_ports_none`

Is a fast shorthand for:

dns_local_ports_avoid 1-65535

Nothing left, no ports, no problem — the OS picks. 🫶

…and that means the set of available DNS query local port numbers is left empty. In literally every respect (except speed fr fr) it's exactly equivalent to the directive shown up there ☝️, and you can mix it freely with dns_local_ports_permit and dns_local_ports_avoid — no drama.

But okay bestie, plot twist 🫢 if the resulting set of port numbers ends up empty, then SpamAssassin does not do its ports randomization thing at all. Instead it just hands the whole vibe over to the operating system and lets it pick a suitable free local port number. Iconic delegation tbh 👑

See also the directives dns_local_ports_permit and dns_local_ports_avoid. iykyk 💅

dns_test_interval n — (default: 600 seconds) 🌸 If dns_available is set to test, then dns_test_interval — a number of seconds — tells SpamAssassin how often to retest for working DNS. A numeric value can optionally get a time-unit suffix (s, m, h, d, w, meaning seconds (that's the default), minutes, hours, days, weeks). Pick your unit, queen ⏰
dns_options opts — (default: v4, v6, norotate, nodns0x20, edns=4096) ✨ Gives a list (whitespace or comma-separated, either is fine) of options that apply to DNS resolving. The available options are: v4, v6, rotate, dns0x20 and edns (or edns0). Any option name can be negated by slapping a no in front of it (e.g. norotate, NoEDNS) to counteract an option that was enabled earlier. Option names are not case-sensitive 💖. And the dns_options directive can show up in config files multiple times — the last setting prevails, periodt.

Option v4 declares the resolver capable of returning IPv4 (A) records. Option v6 declares the resolver capable of returning IPv6 (AAAA) records. You'd set nov6 if your resolver is out here filtering AAAA responses 🙈 NOTE: these options only refer to resolving capabilies — there is no other meaning, like whether the IP address of the resolver itself is IPv4 or IPv6. Don't read into it, it's not that deep.

Option edns (or edns0) may take a value that specifies a requestor's acceptable UDP payload size according to EDNS0 specifications (RFC 6891, ex RFC 2671) e.g. edns=4096. When EDNS0 is off (noedns or edns=512) a traditional implied UDP payload size is 512 bytes, which is also a minimum allowed value for this option. When the option is specified but a value is not provided, a conservative default of 1220 bytes is implied. It is recommended to keep edns enabled when using a local recursive DNS server which supports EDNS0 (like most modern DNS servers do) — a suitable setting in this case is edns=4096, which is also a default 💅. Allowing UDP payload size larger than 512 bytes can avoid truncation of resource records in large DNS responses (like in TXT records of some SPF and DKIM responses, or when an unreasonable number of A records is published by some domain 😭). The option should be disabled when a recursive DNS server is only reachable through non-RFC 6891 compliant middleboxes (such as some old-fashioned firewall) which bans DNS UDP payload sizes larger than 512 bytes. A suitable value when a non-local recursive DNS server is used and a middlebox does allow EDNS0 but blocks fragmented IP packets is perhaps 1220 bytes, allowing a DNS UDP packet to fit within a single IP packet in most cases (a slightly less conservative range would be 1280-1410 bytes).

Option rotate causes SpamAssassin to choose a DNS server at random from all servers listed in /etc/resolv.conf every dns_test_interval seconds — effectively spreading the load over all currently available DNS servers when there are many spamd workers. Load balancing era 🌀

Option dns0x20 enables randomization of letters in a DNS query label according to draft-vixie-dnsext-dns0x20, decreasing a chance of collisions of responses (by chance or by a malicious intent) by increasing spread as provided by a 16-bit query ID and up to 16 bits of a port number, with additional bits as encoded by flipping case (upper/lower) of letters in a query. The number of additional random bits corresponds to the number of letters in a query label. Should work reliably with all mainstream DNS servers — do not turn on if you see frequent info messages dns: no callback for id: in the log, or if RBL or URIDNS lookups do not work for no apparent reason. Not me warning you twice 💀

dns_query_restriction (allow|deny) domain1 domain2 ... — Okay so this one lets you disable rules which would result in a DNS query to one of the listed domains 🚫. The first argument must be a literal allow or deny, and the remaining arguments are domains names.

Most DNS queries (with some exceptions) are subject to dns_query_restriction. A domain to be queried is successively stripped-off of its leading labels (thus yielding a series of its parent domains), and on each iteration a check is made against an associative array generated by dns_query_restriction options. Search stops at the first match (i.e. the tightest match), and the matching entry with its allow or deny value then controls whether a DNS query is allowed to be launched.

If no match is found, an implicit default is to allow a query 💚. The purpose of an explicit allow entry is to be able to override a previously configured deny on the same domain, or to override an entry (possibly yet to be configured in subsequent config directives) on one of its parent domains. Thus an allow zen.spamhaus.org with a deny spamhaus.org would permit DNS queries on a specific DNS BL zone but deny queries to other zones under the same parent domain. So specific, so iconic 🎀

Domains are matched case-insensitively, no wildcards are recognized, and there should be no leading or trailing dot. Read that again bestie, no trailing dot 🫶

Specifying a block on querying a domain name has a similar effect as setting a score of corresponding DNSBL and URIBL rules to zero, and it can be a handy alternative to hunting for such rules when a site policy does not allow certain DNS block lists to be queried. Effortless 😌

Special wildcard dns_query_restriction deny * is supported to block all queries except allowed ones 🌈

Example:

dns_query_restriction deny  dnswl.org surbl.org
dns_query_restriction allow zen.spamhaus.org
dns_query_restriction deny  spamhaus.org mailspike.net spamcop.net

clear_dns_query_restriction — The option removes any entries entered by previous dns_query_restriction options, leaving the list empty, i.e. allowing DNS queries for any domain (including any DNS BL zone). Fresh start, clean slate, slay 🧚
dns_block_rule RULE domain — If rule named RULE is hit, DNS queries to specified domain are temporarily blocked 🔥. Intended to be used with rules that check RBL return codes for specific blocked status. For example:

urirhssub URIBL_BLOCKED multi.uribl.com. A 1
dns_block_rule URIBL_BLOCKED multi.uribl.com

Block status is maintained across all processes by an empty statefile named dnsblock_multi.uribl.com in global state dir: home_dir_for_helpers/.spamassassin, $HOME/.spamassassin, /var/lib/spamassassin (localstate), depending which is found and writable. It'll find its lil home somewhere 💜

dns_block_time — (default: 300) ⏳ dns_block_rule query blockage will last this many seconds.
dns_max_cname_cache n — (default: 10 entries) When we find CNAMEs of uris, limit the cache to 10 entries and stop processing CNAMEs to limit resource usage. Protect the resources bestie, we're not made of RAM 💀

🎀 LEARNING OPTIONS 🎀

use_learner ( 0 | 1 ) — (default: 1) Whether to use any machine-learning classifiers with SpamAssassin, such as the default 'BAYES_*' rules. Setting this to 0 will disable use of any and all human-trained classifiers. All of them. Gone. Periodt 🌸
use_bayes ( 0 | 1 ) — (default: 1) Whether to use the naive-Bayesian-style classifier built into SpamAssassin. This is a master on/off switch for all Bayes-related operations 👑
use_bayes_rules ( 0 | 1 ) — (default: 1) Whether to use rules using the naive-Bayesian-style classifier built into SpamAssassin. This lets you disable the rules while leaving auto and manual learning enabled. Rules off, learning on, a whole vibe ✨
bayes_auto_learn ( 0 | 1 ) — (default: 1) Whether SpamAssassin should automatically feed high-scoring mails (or low-scoring mails, for non-spam) into its learning systems. The only learning system supported currently is a naive-Bayesian-style classifier.

See the documentation for the Mail::SpamAssassin::Plugin::AutoLearnThreshold plugin module for details on how Bayes auto-learning is implemented by default. Go read it, it's giving thorough 📚

bayes_token_sources — (default: header visible invisible uri) Controls which sources in a mail message can contribute tokens (e.g. words, phrases, etc.) to a Bayes classifier. The argument is a space-separated list of keywords: header, visible, invisible, uri, mimepart), each of which may be prefixed by a no to indicate its exclusion. Additionally two reserved keywords are allowed: all and none (or: noall). The list of keywords is processed sequentially: a keyword all adds all available keywords to a set being built, a none or noall clears the set, other non-negated keywords are added to the set, and negated keywords are removed from the set. Keywords are case-insensitive 💖

The default set is: header visible invisible uri, which is equivalent for example to: All NoMIMEpart. The reason why mimepart is not currently in a default set is that it is a newer source (introduced with SpamAssassin version 3.4.1) and not much experience has yet been gathered regarding its usefulness. It's new here, be nice to it 🦋

See also option bayes_ignore_header for a fine-grained control on individual header fields under the umbrella of a more general keyword header here.

Keywords imply the following data sources:

header - tokens collected from a message header section
visible - words from visible text (plain or HTML) in a message body
invisible - hidden/invisible text in HTML parts of a message body
uri - URIs collected from a message body
mimepart - digests (hashes) of all MIME parts (textual or non-textual) of a message, computed after Base64 and quoted-printable decoding, suffixed by their Content-Type
all - adds all the above keywords to the set being assembled
none or noall - removes all keywords from the set

The bayes_token_sources directive may appear multiple times, its keywords are interpreted sequentially, adding or removing items from the final set as they appear in their order in bayes_token_sources directive(s). Order matters bestie, don't forget 💅

bayes_ignore_header header_name — so if your mail gets filtered upstream (think spam-filtering ISP, mailing list, all of them basically) and that service slaps new headers on your messages — which they always do — those headers can feed the Bayesian classifier some seriously inappropriate cues and let it take a "short cut". 💀 To stop that, just list the headers with this setting. Header matching is case-insensitive. Example:

bayes_ignore_header X-Upstream-Spamfilter
bayes_ignore_header X-Upstream-SomethingElse

bayes_ignore_from user@example.com — Bayesian classification and autolearning will not be performed on mail from the listed addresses. The program sa-learn will also ignore the listed addresses if it is invoked using the --use-ignores option. One or more addresses can be listed, see welcomelist_from.

Okay so here's the tea: spam messages from certain senders may contain many words that frequently occur in ham. For example, one might read messages from a preferred bookstore but also get unwanted spam messages from other bookstores. If the unwanted messages are learned as spam then any messages discussing books — including the preferred bookstore and antiquarian messages — would be in danger of being marked as spam. 😭 The addresses of the annoying bookstores would be listed. (Assuming they were halfway legitimate and didn't send you mail through myriad affiliates.)

And then those who have pieces of spam in legitimate messages, or otherwise receive ham messages containing potentially spammy words, might fear that some spam messages might be in danger of being marked as ham. The addresses of the spam mailing lists, correspondents, etc. would be listed.

bayes_ignore_to user@example.com — Bayesian classification and autolearning will not be performed on mail to the listed addresses. See bayes_ignore_from for details. 👀
bayes_min_ham_num (Default: 200)
bayes_min_spam_num (Default: 200) — To be accurate, the Bayes system does not activate until a certain number of ham (non-spam) and spam have been learned. The default is 200 of each ham and spam, but you can tune these up or down with these two settings. 📈📉
bayes_learn_during_report (Default: 1) — The Bayes system will, by default, learn any reported messages (spamassassin -r) as spam. If you do not want this to happen, set this option to 0. periodt.
bayes_sql_override_username — Used by BayesStore::SQL storage implementation.

If this options is set the BayesStore::SQL module will override the set username with the value given. This could be useful for implementing global or group bayes databases. 👑

bayes_use_hapaxes (default: 1) — Should the Bayesian classifier use hapaxes (words/tokens that occur only once) when classifying? This produces significantly better hit-rates. slay. ✨
bayes_journal_max_size (default: 102400) — SpamAssassin will opportunistically sync the journal and the database. It will do so once a day, but will sync more often if the journal file size goes above this setting, in bytes. If set to 0, opportunistic syncing will not occur.
bayes_expiry_max_db_size (default: 150000) — What should be the maximum size of the Bayes tokens database? When expiry occurs, the Bayes system will keep either 75% of the maximum value, or 100,000 tokens, whichever has a larger value. 150,000 tokens is roughly equivalent to a 8Mb database file.
bayes_auto_expire (default: 1) — If enabled, the Bayes system will try to automatically expire old tokens from the database. Auto-expiry occurs when the number of tokens in the database surpasses the bayes_expiry_max_db_size value. If a bayes datastore backend does not implement individual key/value expirations, the setting is silently ignored. 🙈
bayes_token_ttl (default: 3w, i.e. 3 weeks) — Time-to-live / expiration time in seconds for tokens kept in a Bayes database. A numeric value is optionally suffixed by a time unit (s, m, h, d, w, indicating seconds (default), minutes, hours, days, weeks).

If bayes_auto_expire is true and a Bayes datastore backend supports it (currently only Redis), this setting controls deletion of expired tokens from a bayes database. The value is observed on a best-effort basis, exact timing promises are not necessarily kept. If a bayes datastore backend does not implement individual key/value expirations, the setting is silently ignored.

bayes_seen_ttl (default: 8d, i.e. 8 days) — Time-to-live / expiration time in seconds for 'seen' entries (i.e. mail message digests with their status) kept in a Bayes database. A numeric value is optionally suffixed by a time unit (s, m, h, d, w, indicating seconds (default), minutes, hours, days, weeks).

If bayes_auto_expire is true and a Bayes datastore backend supports it (currently only Redis), this setting controls deletion of expired 'seen' entries from a bayes database. The value is observed on a best-effort basis, exact timing promises are not necessarily kept. If a bayes datastore backend does not implement individual key/value expirations, the setting is silently ignored.

bayes_learn_to_journal (default: 0) — If this option is set, whenever SpamAssassin does Bayes learning, it will put the information into the journal instead of directly into the database. This lowers contention for locking the database to execute an update, but will also cause more access to the journal and cause a delay before the updates are actually committed to the Bayes database. 🎀

🌈 MISCELLANEOUS OPTIONS 🌈

time_limit n (default: 300) — Specifies a limit on elapsed time in seconds that SpamAssassin is allowed to spend before providing a result. The value may be fractional and must not be negative, zero is interpreted as unlimited. The default is 300 seconds for consistency with the spamd default setting of --timeout-child . ⏰

This is a best-effort advisory setting — processing will not be abruptly aborted at an arbitrary point in processing when the time limit is exceeded, but only on reaching one of locations in the program flow equipped with a time test. Currently equipped with the test are the main checking loop, asynchronous DNS lookups, plugins which are calling external programs. Rule evaluation is guarded by starting a timer (alarm) on each set of compiled rules.

When a message is passed to Mail::SpamAssassin::parse, a deadline time is established as a sum of current time and the time_limit setting.

This deadline may also be specified by a caller through an option master_deadline in $suppl_attrib on a call to parse(), possibly providing a more accurate deadline taking into account past and expected future processing of a message in a mail filtering setup. If both the config option as well as a master_deadline option in a call are provided, the shorter time limit of the two is used (since version 3.3.2). Note that spamd (and possibly third-party callers of SpamAssassin) will supply the master_deadline option in a call based on its --timeout-child option (or equivalent), unlike the command line spamassassin, which has no such command line option.

When a time limit is exceeded, most of the remaining tests will be skipped, as well as auto-learning. Whatever tests fired so far will determine the final score. The behaviour is similar to short-circuiting with attribute on, as implemented by a Shortcircuit plugin. A synthetic hit on a rule named TIME_LIMIT_EXCEEDED with a near-zero default score is generated, so that the report will reflect the event. A score for TIME_LIMIT_EXCEEDED may be provided explicitly in a configuration file, for example to achieve welcomelisting or blocklisting effect for messages with long processing times.

The time_limit option is a useful protection against excessive processing time on certain degenerate or unusually long or complex mail messages, as well as against some DoS attacks. It is also needed in time-critical pre-queue filtering setups (e.g. milter, proxy, integration with MTA), where message processing must finish before a SMTP client times out. RFC 5321 prescribes in section 4.5.3.2.6 the 'DATA Termination' time limit of 10 minutes, although it is not unusual to see some SMTP clients abort sooner on waiting for a response. A sensible time_limit for a pre-queue filtering setup is maybe 50 seconds, assuming that clients are willing to wait at least a minute. 💅

lock_method type — Select the file-locking method used to protect database files on-disk. By default, SpamAssassin uses an NFS-safe locking method on UNIX; however, if you are sure that the database files you'll be using for Bayes and AWL storage will never be accessed over NFS, a non-NFS-safe locking system can be selected.

This will be quite a bit faster, but may risk file corruption if the files are ever accessed by multiple clients at once, and one or more of them is accessing them through an NFS filesystem. ⚠️

Note that different platforms require different locking systems.

The supported locking systems for type are as follows:

nfssafe - an NFS-safe locking system
flock - simple UNIX flock() locking
win32 - Win32 locking using sysopen (..., O_CREAT|O_EXCL).

nfssafe and flock are only available on UNIX, and win32 is only available on Windows. By default, SpamAssassin will choose either nfssafe or win32 depending on the platform in use.

fold_headers ( 0 | 1 ) (default: 1) — By default, headers added by SpamAssassin will be whitespace folded. In other words, they will be broken up into multiple lines instead of one very long one and each continuation line will have a tabulator prepended to mark it as a continuation of the preceding one. 🦋

The automatic wrapping can be disabled here. Note that this can generate very long lines. RFC 2822 required that header lines do not exceed 998 characters (not counting the final CRLF).

report_safe_copy_headers header_name ... — okay so when report_safe is on, a lil handful of headers from the original message get copied into the wrapper header (From, To, Cc, Subject, Date, etc.). Want more than that? Add them here bestie 💅. You can list multiple headers on the same line separated by spaces, or just do multiple lines — dealer's choice. ✨
envelope_sender_header Name-Of-Header — SpamAssassin is gonna try to sniff out the address used in the MAIL FROM: phase of the SMTP transaction that delivered this message, if the SMTP server actually handed that data over. It's used in the EnvelopeFrom pseudo-header and for a bunch of rules like SPF checking 🕵️♀️.

By default, different MTAs use different headers, like these faves:

X-Envelope-From
Envelope-Sender
X-Sender
Return-Path

SpamAssassin will try to use these, but only if some heuristics seem to say they're safe (like where the header sits in the message, or whether there's an absence of fetchmail signatures). However, it can lowkey pick the wrong headers in some mailserver setups. (More tea on this lives in bug 2142 and bug 4747 over in the SpamAssassin BugZilla.)

To dodge that heuristic fail, the envelope_sender_header setting is your bestie. Just name the header that your MTA or MDA adds to messages containing the address used at the MAIL FROM step of the SMTP transaction. 🫶

If the header in question has < or > characters at the start and end of the email address on the right-hand side, like in the SMTP transaction, those get stripped.

If the header isn't found in a message, or if its value doesn't contain an @ sign, SpamAssassin will throw a warning in the logs and fall back to its default heuristics. 😭

(Note for MTA developers: we'd prefer it if using a single header were avoided in future, since that precludes 'downstream' spam scanning. "https://wiki.apache.org/spamassassin/EnvelopeSenderInReceived" details a better proposal, storing the envelope sender at each hop in the Received header.)

example:

envelope_sender_header X-SA-Exim-Mail-From

describe SYMBOLIC_TEST_NAME description ... — used to describe a test. This text gets shown to users in the detailed report. 📝 Test names that start with '__' are reserved for meta-match sub-rules, and they're not scored or listed in the 'tests hit' reports. Also, by convention, keep rule descriptions to no more than 50 characters. Periodt.
report_charset CHARSET (default: UTF-8) — sets the MIME Content-Type charset used for the text/plain report that gets attached to spam mail messages. 🌈
report ...some text for a report... — sets the report template that's attached to spam mail messages. Peep the 10_default_prefs.cf configuration file in /usr/share/spamassassin for an example. 👀

If you change this, try to keep it under 78 columns. Each report line appends to the existing template, so use clear_report_template to restart. Tags can be included as explained above. 💖

clear_report_template — clears the report template. Clean slate, bestie. 🧹
report_contact ...text of contact address... — sets what _CONTACTADDRESS_ gets replaced with in the above report text. By default this is 'the administrator of that system', since the hostname of the system the scanner is running on is also included. 🏠
report_hostname ...hostname to use... — sets what _HOSTNAME_ gets replaced with in the above report text. By default it's figured out dynamically as whatever the host running SpamAssassin calls itself. 🦋
unsafe_report ...some text for a report... — sets the report template that's attached to spam mail messages which contain a non-text/plain part. See the 10_default_prefs.cf configuration file in /usr/share/spamassassin for an example. 💀

Each unsafe-report line appends to the existing template, so use clear_unsafe_report_template to restart. Tags can be used in this template (see above for details). ✨

clear_unsafe_report_template — clears the unsafe_report template. bye bye 👋
mbox_format_from_regex — sets a specific regular expression to be used for mbox file From separators.

For example, this setting will let sa-learn process emails stored in a kmail 2 mbox:

mbox_format_from_regex /^From \S+  ?[[:upper:]][[:lower:]]{2}(?:,
   \d\d [[:upper:]][[:lower:]]{2} \d{4} [0-2]\d:\d\d:\d\d [+-]\d{4}|
   [[:upper:]][[:lower:]]{2} [ 1-3]\d [ 0-2]\d:\d\d:\d\d \d{4})/

parse_dkim_uris ( 0 | 1 ) (default: 1) — if this is set to 1 and the message contains DKIM headers, the headers will be parsed for URIs to process alongside URIs found in the body with some rules and modules (ex. URIDNSBL). 🔍

🎀 RULE DEFINITIONS AND PRIVILEGED SETTINGS 🎀

okay so these settings are different from the ones above, in that they're considered 'privileged'. Only users running spamassassin from their procmailrc's or forward files, or sysadmins editing a file in /etc/spamassassin, can use them. spamd users cannot use them in their user_prefs files, for security and efficiency reasons, unless allow_user_rules is enabled (and then, they may only add rules from below). 👑

allow_user_rules ( 0 | 1 ) (default: 0) — this setting lets users create rules (and only rules) in their user_prefs files for use with spamd. It defaults to off, because this could be a severe security hole. It may be possible for users to gain root level access if spamd is run as root. It is NOT a good idea, unless you have some other way of ensuring that users' tests are safe. Don't use this unless you are certain you know what you are doing. 😭 Furthermore, this option causes spamassassin to recompile all the tests each time it processes a message for a user with a rule in his/her user_prefs file, which could have a significant effect on server load. It is not recommended. 🚨

Note that it is not currently possible to use allow_user_rules to modify an existing system rule from a user_prefs file with spamd.

redirector_pattern /pattern/modifiers — a regex pattern that matches both the redirector site portion, and the target site portion of a URI.

Note: The target URI portion must be surrounded in parentheses and no other part of the pattern may create a backreference. ⚠️

Example: http://chkpt.zdnet.com/chkpt/whatever/spammer.domain/yo/dude

redirector_pattern    /^https?:\/\/(?:opt\.)?chkpt\.zdnet\.com\/chkpt\/\w+\/(.*)$/i

header SYMBOLIC_TEST_NAME header op /pattern/modifiers [if-unset: STRING] — defines a test. 🧪 SYMBOLIC_TEST_NAME is a symbolic test name, such as 'FROM_ENDS_IN_NUMS'. header is the name of a mail header field, such as 'Subject', 'To', 'From', etc. Header field names are matched case-insensitively (conforming to RFC 5322 section 1.2.2), except for all-capitals metaheader fields such as ALL, MESSAGEID, ALL-TRUSTED.

Appending a modifier :raw to a header field name will inhibit decoding of quoted-printable or base-64 encoded strings, and will preserve all whitespace inside the header string. The :raw may also be applied to pseudo-headers e.g. ALL:raw will return a pristine (unmodified) header section. 💅

Appending a modifier :addr to a header field name will cause everything except the first email address to be removed from the header field. It's mainly applicable to header fields 'From', 'Sender', 'To', 'Cc' along with their 'Resent-*' counterparts, and the 'Return-Path'. 📬

Appending a modifier :name to a header field name will cause everything except the first display name to be removed from the header field. It's mainly applicable to header fields containing a single mail address: 'From', 'Sender', along with their 'Resent-From' and 'Resent-Sender' counterparts. ✨

It is syntactically permitted to append more than one modifier to a header field name, although currently most combinations achieve no additional effect, for example From:addr:raw or From:raw:addr is currently the same as From:addr.

For example, appending :addr to a header name will result in example@foo in all of the following cases:

example@foo
example@foo (Foo Blah)
example@foo, example@bar
display: example@foo (Foo Blah), example@bar ;
Foo Blah <example@foo>
"Foo Blah" <example@foo>
"'Foo Blah'" <example@foo>

For example, appending :name to a header name will result in "Foo Blah" (without quotes) in all of the following cases:

example@foo (Foo Blah)
example@foo (Foo Blah), example@bar
display: example@foo (Foo Blah), example@bar ;
Foo Blah <example@foo>
"Foo Blah" <example@foo>
"'Foo Blah'" <example@foo>

There are several special pseudo-headers that can be specified:

ALL can be used to mean the text of all the message's headers. Note that all whitespace inside the headers, at line folds, is currently compressed into a single space (' ') character. To obtain a pristine (unmodified) header section, use ALL:raw — the :raw modifier is documented above. Also similar that return headers added by specific relays: ALL-TRUSTED, ALL-INTERNAL, ALL-UNTRUSTED, ALL-EXTERNAL.
ToCc can be used to mean the contents of both the 'To' and 'Cc' headers.
EnvelopeFrom is the address used in the 'MAIL FROM:' phase of the SMTP transaction that delivered this message, if this data has been made available by the SMTP server. See envelope_sender_header for more information on how to set this.
MESSAGEID is a symbol meaning all Message-Id's found in the message; some mailing list software moves the real 'Message-Id' to 'Resent-Message-Id' or to 'X-Message-Id', then uses its own one in the 'Message-Id' header. The value returned for this symbol is the text from all 3 headers, separated by newlines. 📨
X-Spam-Relays-Untrusted, X-Spam-Relays-Trusted, X-Spam-Relays-Internal and X-Spam-Relays-External represent a portable, pre-parsed representation of the message's network path, as recorded in the Received headers, divided into 'trusted' vs 'untrusted' and 'internal' vs 'external' sets. See "https://wiki.apache.org/spamassassin/TrustedRelays" for more details. 🌐

"op" — it's either "=~" (contains regular expression, i.e. yay it matches) or "!~" (does not contain regular expression, i.e. nope). And "pattern" is a valid Perl regular expression, with "modifiers" as regexp modifiers in the usual style. 💅

Heads up bestie: multi-line rules are not supported, even if you use "x" as a modifier. Not a vibe. Also the "#" character must be escaped ("\#") or else it'll be treated as the start of a comment and not part of the regexp. So yeah, escape it, periodt.

If the header specified matches multiple headers, their text will be concatenated with embedded \n's. Therefore you may wish to use /m if you use ^ or $ in your regular expression. 🧚

If the [if-unset: STRING] tag is present, then "STRING" will be used if the header is not found in the mail message. Iconic fallback behaviour, lowkey.

Test names must not start with a number, and must contain only alphanumerics and underscores. It is suggested that lower-case characters not be used, and names have a length of no more than 22 characters, as an informal convention. Dashes are not allowed — sorry, they're just not invited. 🙈

Note that test names which begin with '__' are reserved for meta-match sub-rules, and are not scored or listed in the 'tests hit' reports. Test names which begin with 'T_' are reserved for tests which are undergoing QA, and these are given a very low score.

If you add or modify a test, please be sure to run a sanity check afterwards by running spamassassin --lint. This will avoid confusing error messages, or other tests being skipped as a side-effect. Do it bestie, it's for your own good 🫶

header `SYMBOLIC_TEST_NAME` exists:header_field_name

Define a header field existence test. "header_field_name" is the name of a header field to test for existence. Not to be confused with a test for a nonempty header field body, which can be implemented by a header SYMBOLIC_TEST_NAME header =~ /\S/ rule as described above. Two totally different vibes, don't mix them up 💫

header `SYMBOLIC_TEST_NAME` eval:name_of_eval_method([arguments])

Define a header eval test. "name_of_eval_method" is the name of a method registered by a Mail::SpamAssassin::Plugin object. "arguments" are optional arguments to the function call. 🌸

header `SYMBOLIC_TEST_NAME` eval:check_rbl('set', 'zone' [, 'sub-test'])

Check a DNSBL (a DNS blocklist or welcomelist). This will retrieve Received: headers from the message, extract the IP addresses, select which ones are 'untrusted' based on the "trusted_networks" logic, and query that DNSBL zone. There's a few things to note: 👀

duplicated or private IPs

Duplicated IPs are only queried once and reserved IPs are not queried. Private IPs are those listed in https://www.iana.org/assignments/ipv4-address-space, or https://www.rfc-editor.org/rfc/rfc5735 as private. We're not wasting queries on those, no ma'am 💅

the 'set' argument

This is used as a 'zone ID'. If you want to look up a multiple-meaning zone like Spamhaus Zen, you can then query the results from that zone using it; but all check_rbl_sub() calls must use that zone ID. 🌈

Also, if more than one IP address gets a DNSBL hit for a particular rule, it does not affect the score because rules only trigger once per message. One and done, fr fr.

the 'zone' argument

This is the root zone of the DNSBL. 🍓

The domain name is considered to be a fully qualified domain name (i.e. not subject to DNS resolver's search or default domain options). No trailing period is needed, and will be removed if specified. Clean.

the 'sub-test' argument

This optional argument behaves the same as the sub-test argument in check_rbl_sub() below. ✨

selecting all IPs except for the originating one

This is accomplished by placing -notfirsthop at the end of the set name. This is useful for querying against DNS lists which list dialup IP addresses; the first hop may be a dialup, but as long as there is at least one more hop, via their outgoing SMTP server, that's legitimate, and so should not gain points. If there is only one hop, that will be queried anyway, as it should be relaying via its outgoing SMTP server instead of sending directly to your MX (mail exchange). 💀 protected fr

selecting IPs by whether they are trusted

When checking a 'nice' DNSBL (a DNS welcomelist), you cannot trust the IP addresses in Received headers that were not added by trusted relays. To test the first IP address that can be trusted, place -firsttrusted at the end of the set name. That should test the IP address of the relay that connected to the most remote trusted relay. 👑

Note that this requires that SpamAssassin know which relays are trusted. For simple cases, SpamAssassin can make a good estimate. For complex cases, you may get better results by setting "trusted_networks" manually. 🎀

In addition, you can test all untrusted IP addresses by placing -untrusted at the end of the set name.

Important note — this does NOT include the IP address from the most recent 'untrusted line', as used in -firsttrusted above. That's because we're talking about the trustworthiness of the IP address data, not the source header line, here; and in the case of the most recent header (the 'firsttrusted'), that data can be trusted. See the Wiki page at https://wiki.apache.org/spamassassin/TrustedRelays for more information on this. Read it bestie, iykyk 📖

Selecting just the last external IP

By using -lastexternal at the end of the set name, you can select only the external host that connected to your internal network, or at least the last external host with a public IP. 🌐

header `SYMBOLIC_TEST_NAME` eval:check_rbl_txt('set', 'zone')

Same as check_rbl(), except querying using IN TXT instead of IN A records. If the zone supports it, it will result in a line of text describing why the IP is listed, typically a hyperlink to a database entry. Receipts and everything 🔥

header `SYMBOLIC_TEST_NAME` eval:check_rbl_sub('set', 'sub-test')

Create a sub-test for 'set'. If you want to look up a multi-meaning zone like relays.osirusoft.com, you can then query the results from that zone using the zone ID from the original query. The sub-test may either be an IPv4 dotted address for RBLs that return multiple A records, or a non-negative decimal number to specify a bitmask for RBLs that return a single A record containing a bitmask of results, or a regular expression. 🦋

Note: the set name must be exactly the same for as the main query rule, including selections like -notfirsthop appearing at the end of the set name. Exact same means exact same, no improvising 💅

body `SYMBOLIC_TEST_NAME` /pattern/modifiers

Define a body pattern test. "pattern" is a Perl regular expression. Note: as per the header tests, "#" must be escaped ("\#") or else it is considered the beginning of a comment. 😭 the # really does be starting comments everywhere

The 'body' in this case is the textual parts of the message body; any non-text MIME parts are stripped, and the message decoded from Quoted-Printable or Base-64-encoded format if necessary. Parts declared as text/html will be rendered from HTML to text. Yasss it's all getting cleaned up for you 🧼

Body is processed as a raw byte string, which means Unicode-specific regex features like \p{} can NOT be used for matching. The normalize_charset setting will also affect how raw bytes are presented. Rules in .cf files should be written portably — to match "a with umlaut" character, look for both LATIN1 and UTF8 raw byte variants: /(?:\xE4|\xC3\xA4)/

All body paragraphs (double-newline-separated blocks text) are turned into a linebreaks-removed, whitespace-normalized, single line. Any lines longer than 2kB are split into shorter separate lines (from a boundary when possible), this may unexpectedly prevent pattern from matching. Patterns are matched independently against each of these lines. 💀 sneaky

Note that by default the message Subject header is considered part of the body and becomes the first line when running the rules. If you don't want to match Subject along with body text, use tflags RULENAME nosubject. 🌸

See https://wiki.apache.org/SpamAssassin/WritingRules for more information.

body `SYMBOLIC_TEST_NAME` eval:name_of_eval_method([args])

Define a body eval test. See above. Same energy, different target ✨

uri `SYMBOLIC_TEST_NAME` /pattern/modifiers

Define a uri pattern test. "pattern" is a Perl regular expression. Note: as per the header tests, "#" must be escaped ("\#") or else it is considered the beginning of a comment. Yeah, you know the drill by now 🎀

The 'uri' in this case is a list of all the URIs in the body of the email, and the test will be run on each and every one of those URIs, adjusting the score if a match is found. Use this test instead of one of the body tests when you need to match a URI, as it is more accurately bound to the start/end points of the URI, and will also be faster. Faster and more accurate?? main character energy fr 👑

rawbody `SYMBOLIC_TEST_NAME` /pattern/modifiers

Define a raw-body pattern test. "pattern" is a Perl regular expression. Note: as per the header tests, "#" must be escaped ("\#") or else it is considered the beginning of a comment. 🌈

The 'raw body' of a message is the raw data inside all textual parts. The text will be decoded from base64 or quoted-printable encoding, but HTML tags and line breaks will still be present. Multiline expressions will need to be used to match strings that are broken by line breaks. Raw and unfiltered, just how we like it 💅

Note that the text is split into 2-4kB chunks (from a word boundary when possible), this may unexpectedly prevent pattern from matching. Patterns are matched independently against each of these chunks. Another sneaky one, keep an eye out 😭

rawbody `SYMBOLIC_TEST_NAME` eval:name_of_eval_method([args])

Define a raw-body eval test. See above. 🦋

full `SYMBOLIC_TEST_NAME` /pattern/modifiers

Define a full message pattern test. "pattern" is a Perl regular expression. Note: as per the header tests, "#" must be escaped ("\#") or else it is considered the beginning of a comment. 🍓

The full message is the pristine message headers plus the pristine message body, including all MIME data such as images, other attachments, MIME boundaries, etc. Everything, the whole thing, no skips 🌟

Note that CRLF/LF line endings are matched as the original message has them. For any full rules that match newlines, it's recommended to use \r?$ instead of plain $, so it works on all systems. Portability queen behaviour 👑

full `SYMBOLIC_TEST_NAME` eval:name_of_eval_method([args])

Define a full message eval test. See above. And that's the whole set of rule types, bestie 💖

`meta SYMBOLIC_TEST_NAME boolean expression`

okay so this is where you build a whole new test out of tests you already have 😌 you're literally saying "this one hits if these other ones hit (or didn't hit)". Obsessed. Example:

meta META1        TEST1 && !(TEST2 || TEST3)

⚠️ real talk bestie: English-language operators ("and", "or") get treated as rule names, not operators. And there is no XOR operator. Don't come for me, that's just how it is 💀

`meta SYMBOLIC_TEST_NAME boolean arithmetic expression`

you can also do straight-up math with your tests, which is giving calculator energy 🔥 here's the deal:

an unhit test is worth 0
a hit test is worth a nonzero value
a hit meta test's value is whatever its arithmetic expression evaluates to
a hit eval test's value is whatever its method returned
a hit header, body, rawbody, uri, or full test with the multiple tflag is worth the number of times it hit 👑
any other type of hit test is worth 1

Like, for example:

meta META2        (3 * TEST1 - 2 * TEST2) > 0

but ngl, Perl builtins and functions like abs() can't be used — they'll just be treated as rule names. so don't try it 🙈

✨ pro tip: if you wanna define a meta-rule but you don't want its individual sub-rules counting toward the final score unless the entire meta-rule matches, name those sub-rules starting with __ (two underscores). SpamAssassin will ignore those for scoring. sneaky, iconic, slay.

`meta SYMBOLIC_TEST_NAME ... rules_matching(RULEGLOB) ...`

this one's a special function that expands into a list of matching rulenames 🧚 and you can drop it anywhere in expressions. The argument supports glob-style rulename matching: * = anything, ? = one character. Matching is case-sensitive, bestie, keep that in mind.

so this example will hit if at least two __FOO_* rule hits:

 body __FOO_1  /xxx/
 body __FOO_2  /yyy/
 body __FOO_3  /zzz/
 meta FOO_META  rules_matching(__FOO_*) >= 2

which is literally the same as:

 meta FOO_META  (__FOO_1 + __FOO_2 + __FOO_3) >= 2

`reuse SYMBOLIC_TEST_NAME [ OLD_SYMBOLIC_TEST_NAME_1 ... ]`

defines a test name that should be "reused" during scoring. So if a message has an X-Spam-Status header showing a hit for this rule or any of the old rule names you listed, a hit gets added for this rule when mass-check --reuse is used. Examples:

"reuse SPF_PASS"

"reuse MY_NET_RULE_V2 MY_NET_RULE_V1"

the actual logic for reuse tests is handled by Mail::SpamAssassin::Plugin::Reuse. 🫶

`tflags SYMBOLIC_TEST_NAME flags`

sets flags on a test. The parameter is a space-separated list of flag names, or flag name = value pairs. These flags get used in the score-determination back end system for details of the test's behaviour. For more on how tflags interact with those systems, go peep "bayes_auto_learn". Here's every flag you can set:

net — the test is a network test and will not be run in the mass checking system or if -L is used, therefore its score should not be modified.
nice — the test is meant to compensate for common false positives, and should be assigned a negative score.
userconf — the test requires user configuration before it can be used (like language-specific tests).
learn — the test requires training before it can be used.
noautolearn — the test will explicitly be ignored when calculating the score for learning systems.
autolearn_force — the test will be subject to less stringent autolearn thresholds.

normally, SpamAssassin requires 3 points from the header and 3 points from the body to be auto-learned as spam. This option keeps the threshold at 6 points total but changes it so it has no regard to the source of the points. 💅

noawl — this flag is specific when using the AWL plugin.

normally, the AWL plugin normalizes scores via auto-welcomelist. In some scenarios it works against the system administrator when they're trying to add rules to correct mis-classified email. When the AWL plugin searches the email and finds the noawl flag, it will exit without normalizing the score nor storing the value in db. no cap.

multiple — the test will be evaluated multiple times, for use with meta rules. Only affects header, body, rawbody, uri, and full tests.
maxhits=N — if multiple is specified, limit the number of hits found to N. If the rule is used in a meta that counts the hits (e.g. __RULENAME > 5), this is a way to avoid wasted extra work (use "tflags multiple maxhits=6").

For example:

  uri      __KAM_COUNT_URIS /^./
  tflags   __KAM_COUNT_URIS multiple maxhits=16
  describe __KAM_COUNT_URIS A multiple match used to count URIs in a message

  meta __KAM_HAS_0_URIS (__KAM_COUNT_URIS == 0)
  meta __KAM_HAS_1_URIS (__KAM_COUNT_URIS >= 1)
  meta __KAM_HAS_2_URIS (__KAM_COUNT_URIS >= 2)
  meta __KAM_HAS_3_URIS (__KAM_COUNT_URIS >= 3)
  meta __KAM_HAS_4_URIS (__KAM_COUNT_URIS >= 4)
  meta __KAM_HAS_5_URIS (__KAM_COUNT_URIS >= 5)
  meta __KAM_HAS_10_URIS (__KAM_COUNT_URIS >= 10)
  meta __KAM_HAS_15_URIS (__KAM_COUNT_URIS >= 15)

nosubject — used only for body rules. If specified, the Subject header will not be part of the matched body text. See body for more info.
ips_only — this flag is specific to rules invoking an URIDNSBL plugin, it is documented there.
domains_only — this flag is specific to rules invoking an URIDNSBL plugin, it is documented there.
ns — this flag is specific to rules invoking an URIDNSBL plugin, it is documented there.
a — this flag is specific to rules invoking an URIDNSBL plugin, it is documented there.
notrim — this flag is specific to rules invoking an URIDNSBL plugin, it is documented there.
nolog — this flag will hide (sensitive) rule information from reports. 🙈

`priority SYMBOLIC_TEST_NAME n`

gives a test a specific priority 🎯 All tests — except for DNS and Meta tests — are run in increasing priority value order (so negative priority values run before positive ones). The default test priority is 0 (zero).

⚠️ heads up: the values -99999999999999 and -99999999999998 have a special meaning internally, and should not be used. don't touch them bestie.

CAPTURING TAGS USING REGEX NAMED CAPTURE GROUPS

SpamAssassin 4.0 supports capturing template tags from regex rules 🎀 The captured tags, along with other standard template tags, can be used in other rules as a matching string. Peep the TEMPLATE TAGS section for more info on tags.

Capturing can be done in any body/rawbody/header/uri/full rule that uses a regex for matching (not eval rules). You have to use the standard Perl named capture group format (?<NAME>pattern), like it says over at <https://perldoc.perl.org/perlre#(?%3CNAME%3Epattern)>.

Example — capturing a tag named "BODY_HELLO_NAME":

 body __HELLO_NAME /\bHello, (?<BODY_HELLO_NAME>\w+)\b/

and then that tag can be used in another rule for matching, using a %{TAGNAME} template. This one would search the captured name in the From header:

 header HELLO_NAME_IN_FROM From =~ /\b%{BODY_HELLO_NAME}\b/i

if any tag that a rule depends on is not found, then the rule is not run at all. 😭 and btw, to stop a literal %{NAME} string from being parsed as a template, you can escape it with a backslash: \%{NAME}.

Captured tags can also be used in reports and in other plugins like AskDNS, with the standard "_BODY_HELLO_NAME_" notation. 💖

ngl there's currently no automatic dependency tracking for rule running order. All rules that use named capture groups are automatically set to priority -10000, so the tags should always be ready for any normal rules to use. When a rule depends on a tag that might be set at a later stage by a plugin, for example, its priority should be set manually to a higher value. 👑

ADMINISTRATOR SETTINGS

these settings are different from the ones above because they're considered 'more privileged' — even more privileged than the ones in the PRIVILEGED SETTINGS section 👑 No matter what "allow_user_rules" is set to, these can never be set from a user's "user_prefs" file when spamc/spamd is being used. However, all of these settings can be used by local programs run directly by the user. periodt.

`version_tag string`

this tag gets appended to the SA version in the X-Spam-Status header. You should include it when you modify your ruleset, especially if you plan to distribute it. A good choice for string is your last name or your initials followed by a number which you increase with each change. 📈

the version_tag will be lowercased, and any non-alphanumeric or period character will be replaced by an underscore.

e.g.

 version_tag myrules1    # version=2.41-myrules1

`empty_tags string`

this is a list of tags that might be undefined because they're set by 3rd party plugins. Setting this configuration will prevent those tags from being set with an invalid value if they are not defined. 🦋

e.g.

 empty_tags mytag1 mytag2

`test SYMBOLIC_TEST_NAME (ok|fail) Some string to test against`

defines a regression testing string. You can have more than one regression test string per symbolic test name — just specify a string that you wish the test to match. ✨

these tests are only run as part of the test suite — they should not affect the general running of SpamAssassin. iykyk.

`body_part_scan_size` (default: 50000)

per mime-part scan size limit, in bytes, for "body" type rules. The decoded/stripped mime-part gets truncated approx to this size. Helps scanning large messages safely, so it's not necessary to skip them completely. Disabled with 0. 🫶

`rawbody_part_scan_size` (default: 500000)

like body_part_scan_size, but for "rawbody" type rules.

`multipart_alternative_preferred_part` (default: empty)

specifies which part of a multipart/alternative section to prefer for rendered body text. Valid values are "text/html" and "text/plain". When set, only the preferred part type will be used from multipart/alternative sections, skipping the other alternative. When empty (the default), all parts are included as before. 🧚

rbl_timeout t [t_min] [zone] — (default: 15 3)

okay so every DNS query gets fired off at the start of a check and then we come back for the receipts at the end. This value is the max stretch of time (in seconds) to wait for a DNS query. But lowkey the smart part is: if most of the DNS queries already came back for a particular message, SpamAssassin will NOT wait out the full period (why waste time on unresponsive server(s)?? 💀), it shrinks the timeout according to a percentage of queries already completed. As the number of queries remaining approaches 0, the timeout value gradually approaches a t_min value, which is an optional second parameter and defaults to 0.2 * t. If t is smaller than t_min, the initial timeout is set to t_min. Here's the chart of queries remaining versus the timeout in seconds, for the default 15 second / 3 second timeout setting:

  queries left  100%  90%  80%  70%  60%  50%  40%  30%  20%  10%   0%
  timeout        15   14.9 14.5 13.9 13.1 12.0 10.7  9.1  7.3  5.3  3

bestie, a whole example: say 20 queries are made at the beginning of a message check and 16 queries have returned (leaving 20%), the remaining 4 queries should finish within 7.3 seconds since their query started or they will be timed out ⏰. And note that timed out queries are only aborted when there is nothing else left for SpamAssassin to do — long evaluation of other rules may grant queries additional time. icon behaviour honestly.

If a parameter zone is specified (it must end with a letter, which distinguishes it from other numeric parametrs), then the setting only applies to DNS queries against the specified DNS domain (host, domain or RBL (sub)zone). Matching is case-insensitive, and the actual domain may be a subdomain of the specified zone. 💅

util_rb_tld tld1 tld2 ... — this one maintains a list of valid TLDs in the RegistryBoundaries code. Top level domains (TLD) include things like com, net, org, xn--p1ai, рф, ... 🌈 International domain names may be specified in ASCII-compatible encoding (ACE), e.g. xn--p1ai, xn--qxam, or with Unicode labels encoded as UTF-8 octets, e.g. рф, ελ.
util_rb_2tld 2tld-1.tld 2tld-2.tld ... — maintains list of valid 2nd-level TLDs in the RegistryBoundaries code. 2TLDs include things like co.uk, fed.us, etc. International domain names may be specified in ASCII-compatible encoding (ACE), or with Unicode labels encoded as UTF-8 octets.
util_rb_3tld 3tld1.some.tld 3tld2.other.tld ... — maintains list of valid 3rd-level TLDs in the RegistryBoundaries code. 3TLDs include things like demon.co.uk, plc.co.im, etc. International domain names may be specified in ASCII-compatible encoding (ACE), or with Unicode labels encoded as UTF-8 octets.
util_rb_4tld 4tld1.some.other.tld 4tld2.another.other.tld ... — maintains list of valid 4th-level TLDs in the RegistryBoundaries code. 4TLDs can include things like domain.s3.us-east-2.amazonaws.com, etc. International domain names may be specified in ASCII-compatible encoding (ACE), or with Unicode labels encoded as UTF-8 octets.
clear_util_rb — empties the internal list of valid TLDs (including 2nd and 3rd level) which the RegistryBoundaries code uses. Only useful if you want to override the standard lists supplied by sa-update. 🧚

bayes_path /path/filename — (default: ~/.spamassassin/bayes)

this is the directory and filename for Bayes databases. Several databases will be created, with this as the base directory and filename, with "_toks", "_seen", etc. appended to the base. The default setting results in files called "~/.spamassassin/bayes_seen", "~/.spamassassin/bayes_toks", etc.

By default, each user has their own in their "~/.spamassassin" directory with mode 0700/0600. For system-wide SpamAssassin use, you may want to reduce disk space usage by sharing this across all users. However, Bayes appears to be more effective with individual user databases. (yeah, main character energy per user, sorry 🫶)

bayes_file_mode — (default: 0700)

the file mode bits used for the Bayesian filtering database files.

Make sure you specify this using the 'x' mode bits set, as it may also be used to create directories. However, if a file is created, the resulting file will not have any execute bits set (the umask is set to 111). The argument is a string of octal digits, it is converted to a numeric value internally. no notes, just octal ✨

bayes_store_module Name::Of::BayesStore::Module — if this option is set, the module given will be used as an alternate to the default bayes storage mechanism. It must conform to the published storage specification (see Mail::SpamAssassin::BayesStore). For example, set this to Mail::SpamAssassin::BayesStore::SQL to use the generic SQL storage module.
bayes_sql_dsn DBI::databasetype:databasename:hostname:port — used for BayesStore::SQL storage implementation.

This option give the connect string used to connect to the SQL based Bayes storage.

bayes_sql_username — used by BayesStore::SQL storage implementation.

This option gives the username used by the above DSN.

bayes_sql_password — used by BayesStore::SQL storage implementation.

This option gives the password used by the above DSN. 🔐

bayes_sql_username_authorized ( 0 | 1 ) — (default: 0)

whether to call the services_authorized_for_username plugin hook in BayesSQL. If the hook does not determine that the user is allowed to use bayes or is invalid then the database will not be initialized.

NOTE: By default the user is considered invalid until a plugin returns a true value. If you enable this, but do not have a proper plugin loaded, all users will turn up as invalid. 💀 do not do this casually bestie.

The username passed into the plugin can be affected by the bayes_sql_override_username config option.

bayes_redis_read_servers host=hostname1;port=port1,host=hostname2;port=port2,... — used for BayesStore::Redis storage implementation. Specifies a comma-separated list of Redis servers to use for read operations. Each server can have its own connection parameters specified with semicolon-separated key=value pairs. Multiple read servers provide high availability through automatic failover. Example: host=redis1.example.com;port=6379,host=redis2.example.com;port=6379
bayes_redis_write_server host=hostname;port=port;... — used for BayesStore::Redis storage implementation. Specifies the Redis server to use for write operations with semicolon-separated key=value connection parameters. Only a single write server is supported to ensure data consistency. Example: host=master.example.com;port=6379 👑
bayes_redis_database n — used for BayesStore::Redis storage implementation. Specifies the Redis database number to use (default: 0).
bayes_redis_password password — used for BayesStore::Redis storage implementation. Specifies the password to use for Redis authentication.
bayes_redis_prefix prefix — used for BayesStore::Redis storage implementation. Specifies a prefix to use for all Redis keys. This allows multiple SpamAssassin instances to share the same Redis database without key collisions. Example: bayes:user1:

user_scores_dsn DBI:databasetype:databasename:hostname:port — if you load user scores from an SQL database, this will set the DSN used to connect. Example: "DBI:mysql:spamassassin:localhost"

If you load user scores from an LDAP directory, this will set the DSN used to connect. You have to write the DSN as an LDAP URL, the components being the host and port to connect to, the base DN for the search, the scope of the search (base, one or sub), the single attribute being the multivalued attribute used to hold the configuration data (space separated pairs of key and value, just as in a file) and finally the filter being the expression used to filter out the wanted username. Note that the filter expression is being used in a sprintf statement with the username as the only parameter, thus is can hold a single __USERNAME__ expression. This will be replaced with the username.

Example: "ldap://localhost:389/dc=koehntopp,dc=de?saconfig?uid=__USERNAME__"

user_scores_sql_username username — the authorized username to connect to the above DSN.
user_scores_sql_password password — the password for the database username, for the above DSN.
user_scores_sql_custom_query query — this option gives you the ability to create a custom SQL query to retrieve user scores and preferences. In order to work correctly your query should return two values, the preference name and value, in that order. In addition, there are several "variables" that you can use as part of your query, these variables will be substituted for the current values right before the query is run. The current allowed variables are:
- _TABLE_ — the name of the table where user scores and preferences are stored. Currently hardcoded to userpref, to change this value you need to create a new custom query with the new table name.
- _USERNAME_ — the current user's username.
- _MAILBOX_ — the portion before the @ as derived from the current user's username.
- _DOMAIN_ — the portion after the @ as derived from the current user's username, this value may be null.

The query must be one continuous line in order to parse correctly. 🚨

Here are several example queries, please note that these are broken up for easy reading, in your config it should be one continuous line.

Current default query:

"SELECT preference, value FROM _TABLE_ WHERE username = _USERNAME_ OR username = '@GLOBAL' ORDER BY username ASC"

Use global and then domain level defaults:

"SELECT preference, value FROM _TABLE_ WHERE username = _USERNAME_ OR username = '@GLOBAL' OR username = '@~'||_DOMAIN_ ORDER BY username ASC"

Maybe global prefs should override user prefs:

"SELECT preference, value FROM _TABLE_ WHERE username = _USERNAME_ OR username = '@GLOBAL' ORDER BY username DESC"

user_scores_ldap_username — this is the Bind DN used to connect to the LDAP server. It defaults to the empty string (""), allowing anonymous binding to work.

Example: "cn=master,dc=koehntopp,dc=de"

user_scores_ldap_password — this is the password used to connect to the LDAP server. It defaults to the empty string (""). 🎀
user_scores_fallback_to_global (default: 1) — if the userprefs just will not load from SQL or LDAP, do we just yeet the message through untouched? No bestie, not on this setting's watch 💅 when it's on, we fall back to the global scores and settings instead. Much better vibe.
loadplugin [Mail::SpamAssassin::Plugin::]ModuleName [/path/module.pm] — load a SpamAssassin plugin module 🧚 the ModuleName is the perl module name, and it's the thing used to create the plugin object itself.

Module naming is strict, ok? The name can only contain alphanumeric characters or underscores. And the file has to have a .pm extension, periodt.

/path/module.pm is the file to load, and it's the one holding the module's perl code 🫶 if you give it as a relative path, it counts as relative to the current configuration file. And if you just... don't give it? Then the module gets loaded using perl's search path (the @INC array) ✨

Peep Mail::SpamAssassin::Plugin for more deets on writing plugins 👑

tryplugin ModuleName [/path/module.pm] — literally the same as loadplugin, except if the .pm file can't be found in the filesystem it just gets silently ignored 🙈 no drama, no error.
loadhandler Mail::SpamAssassin::Handler::ModuleName [/path/module.pm] — load a SpamAssassin MIME-part handler module 🌸 a handler is a subclass of Mail::SpamAssassin::Handler that registers itself for one or more content types with register_handler, and it gets invoked once per matching MIME part.

Important: the module name has to be given in full — unlike a bare word, it does not get prefixed automatically. ModuleName and the optional /path/module.pm are otherwise interpreted exactly the same way as for loadplugin 💖

tryhandler Mail::SpamAssassin::Handler::ModuleName [/path/module.pm] — same as loadhandler, but if the .pm file can't be found in the filesystem it's silently ignored 🦋
handler_max_depth n (default: 8) — max handler chain depth, aka the guard rail against deeply nested archives 😮‍💨
handler_max_parts n (default: 1000) — max total synthetic parts produced per message.
handler_max_bytes n (default: 50000000) — the total extracted-bytes budget across the handler chain for one message.
handler_time_limit n (default: 10) — per-invocation timeout, in seconds, for a single handler running on a single part ⏳ heads up: the whole-pass budget is the existing scan-wide time limit, not a separate setting.
ignore_always_matching_regexps (Default: 0) — ignore any rule that contains a regexp which always matches 🙅‍♀️ right now it only catches regexps containing '||', or ones that begin or end with a '|'. It also ignores rules with "some" combinatorial explosions 💀
geodb_module STRING — tells SpamAssassin which geolocation module to use 🌍 if you don't specify one, all the supported ones get tried in this order:
- MaxMind::DB::Reader (same as GeoIP2::Database::Reader)
- IP::Geolocation::MMDB
- Geo::IP
- IP::Country::DB_File (not used unless geodb_options path set)
- IP::Country::Fast

Plugins can override this internally if required 👑

geodb_options dbtype:/path/to/db ... — supported dbtypes:
- city — use City database
- country — use Country database
- isp — try loading ISP database
- asn — try loading ASN database

Append the full database path with a colon, like this for example:

isp:/opt/geoip/isp.mmdb

Plugins can internally request all the types they require, so geodb_options is only needed if the default location search (described below) doesn't work 🫶

GeoIP/GeoIP2 searches these files/directories:

 country:
   GeoIP2-Country.mmdb, GeoLite2-Country.mmdb
   GeoIP.dat (and v6 version)
 city:
   GeoIP2-City.mmdb, GeoLite2-City.mmdb
   GeoIPCity.dat, GeoLiteCity.dat (and v6 versions)
 isp:
   GeoIP2-ISP.mmdb
   GeoIPISP.dat, GeoLiteISP.dat (and v6 versions)
 directories:
   /usr/local/share/GeoIP
   /usr/share/GeoIP
   /var/lib/GeoIP
   /opt/share/GeoIP

geodb_search_path /path/to/GeoIP ... — an alternative to geodb_options ✨ it overrides the default list of directories to search for default filenames.

✨ PREPROCESSING OPTIONS ✨

include filename — include configuration lines from filename 💖 relative paths are considered relative to the current configuration file or user preferences file.
if (boolean perl expression) — this exists to support conditional interpretation of the configuration file 🧚 lines between this and a corresponding else or endif line get ignored unless the expression evaluates as true (in the perl sense, that is: defined and non-0 and non-empty string).

The conditional accepts a limited subset of perl for security — just enough to do basic arithmetic comparisons 🔒 the following input is accepted:

numbers, whitespace, arithmetic operations and grouping — namely these characters and ranges:

  ( ) - + * / _ . , < = > ! ~ 0-9 whitespace

version — this gets replaced with the version number of the currently-running SpamAssassin engine 📌 Note: the version used is in the internal SpamAssassin version format, which is "x.yyyzzz", where x is major version, y is minor version, and z is maintenance version. So 3.0.0 is 3.000000, and 3.4.80 is 3.004080.
perl_version — (Introduced in 3.4.1) this gets replaced with the version number of the currently-running perl engine 🌸 Note: the version used is in the $] version format which is "x.yyyzzz", where x is major version, y is minor version, and z is maintenance version. So 5.8.8 is 5.008008, and 5.10.0 is 5.010000. Use it to protect rules that incorporate RE syntax elements introduced in later versions of perl, such as the "++" non-backtracking match introduced in perl 5.10. For example:

# Avoid lint error on older perl installs
# Check SA version first to avoid warnings on checking perl_version on older SA
if version > 3.004001 && perl_version >= 5.018000
  body  INVALID_RE_SYNTAX_IN_PERL_BEFORE_5_18  /(?[ \p{Thai} & \p{Digit} ])/
endif

Heads up: the above will still generate a warning on perl older than 5.10.0 😭 to dodge that warning, do this instead:

# Avoid lint error on older perl installs
if can(Mail::SpamAssassin::Conf::perl_min_version_5010000)
  body  INVALID_RE_SYNTAX_IN_PERL_5_8  /\w++/
endif

Warning: a can() test is only defined for perl 5.10.0! 💀

plugin(Name::Of::Plugin) — this is a function call that returns 1 if the plugin named "Name::Of::Plugin" is loaded, or "undef" otherwise.
has(Name::Of::Package::function_name) — a function call that returns 1 if the perl package named "Name::Of::Package" includes a function called "function_name", or "undef" otherwise 🦋 note that packages can be SpamAssassin plugins or built-in classes, there's no difference in this respect. Internally this invokes UNIVERSAL::can.
can(Name::Of::Package::function_name) — a function call that returns 1 if the perl package named "Name::Of::Package" includes a function called "function_name" and that function returns a true value when called with no arguments, otherwise "undef" is returned.

It's similar to "has", except that it also calls the named function, testing its return value (unlike the perl function UNIVERSAL::can) 🫶 this makes it possible for a 'feature' function to determine its result value at run time. Iconic behavior honestly.

If the end of a configuration file is reached while still inside an if scope, a warning will be issued, but parsing will restart on the next file ⚠️

For example:

if (version > 3.000000)
  header MY_FOO ...
endif

loadplugin MyPlugin plugintest.pm

if plugin (MyPlugin)
  header MY_PLUGIN_FOO  eval:check_for_foo()
  score  MY_PLUGIN_FOO  0.1
endif

ifplugin PluginModuleName — an alias for if plugin(PluginModuleName) 💅
ifhandler HandlerModuleName — include the configuration up to the matching endif only if the named handler module has been loaded 🌈 it's the counterpart of ifplugin, but for handlers loaded with loadhandler.
else — supports conditional interpretation of the configuration file 🎀 lines between this and a corresponding endif line get ignored unless the conditional expression evaluates as false (in the perl sense, that is: not defined and not 0 and non-empty string).
require_version n.nnnnnn — says that the entire file, from this line on, requires a certain version of SpamAssassin to run 🔥 if a different (older or newer) version of SpamAssassin tries to read the configuration from this file, it will output a warning instead, and ignore it.

Note: the version used is in the internal SpamAssassin version format which is "x.yyyzzz", where x is major version, y is minor version, and z is maintenance version. So 3.0.0 is 3.000000, and 3.4.80 is 3.004080 ⭐

enable_compat xxxxxx — define a version compatibility flag 💜

This creates a function named Mail::SpamAssassin::Conf::compat_xxxxxx, which returns true. You can use it for example in cf-files, similarly as existing feature_ checks:

if can(Mail::SpamAssassin::Conf::compat_xxxxxx)

The name can only consist of [a-zA-Z0-9_] characters ✨

It's mainly used by the SpamAssassin distribution to handle backwards compatibility issues 🫡

✨ TEMPLATE TAGS ✨

okay bestie, these are the little glow-up placeholders 💅 you can drop into certain options, and when they get used they get swapped out for the actual value. it's giving mad-libs but for spam.

Some tags can take an argument (in parentheses). The argument is optional, and the default is shown below. 🙈

_YESNO_ — "Yes" for spam, "No" for nonspam (=ham)
_YESNO(spam_str,ham_str)_ — returns the first argument ("Yes" if missing) for spam, and the second argument ("No" if missing) for ham
_YESNOCAPS_ — "YES" for spam, "NO" for nonspam (=ham)
_YESNOCAPS(spam_str,ham_str)_ — same as _YESNO(...)_, but uppercased
_SCORE(PAD)_ — message score, if PAD is included and is either spaces or zeroes, then pad scores with that many spaces or zeroes (default, none) ie: _SCORE(0)_ makes 2.4 become 02.4, _SCORE(00)_ is 002.4. 12.3 would be 12.3 and 012.3 respectively.
_REQD_ — message threshold
_VERSION_ — version (eg. 3.0.0 or 3.1.0-r26142-foo1)
_SUBVERSION_ — sub-version/code revision date (eg. 2004-01-10)
_RULESVERSION_ — comma-separated list of rules versions, retrieved from an '# UPDATE version' comment in rules files; if there is more than one set of rules (update channels) the order is unspecified (currently sorted by names of files);
_HOSTNAME_ — hostname of the machine the mail was processed on
_REMOTEHOSTNAME_ — hostname of the machine the mail was sent from, only available with spamd
_REMOTEHOSTADDR_ — ip address of the machine the mail was sent from, only available with spamd
_BAYES_ — bayes score
_TOKENSUMMARY_ — number of new, neutral, spammy, and hammy tokens found
_BAYESTC_ — number of new tokens found
_BAYESTCLEARNED_ — number of seen tokens found
_BAYESTCSPAMMY_ — number of spammy tokens found
_BAYESTCHAMMY_ — number of hammy tokens found
_HAMMYTOKENS(N)_ — the N most significant hammy tokens (default, 5)
_SPAMMYTOKENS(N)_ — the N most significant spammy tokens (default, 5)
_DATE_ — rfc-2822 date of scan
_STARS(*)_ — one "*" (use any character) for each full score point (note: limited to 50 'stars')
_SENDERDOMAIN_ — a domain name of the envelope sender address, lowercased
_AUTHORDOMAIN_ — a domain name of the author address (the From header field), lowercased; note that RFC 5322 allows a mail message to have multiple authors - currently only the domain name of the first email address is returned
_RELAYSTRUSTED_ — relays used and deemed to be trusted (see the 'X-Spam-Relays-Trusted' pseudo-header)
_RELAYSUNTRUSTED_ — relays used that can not be trusted (see the 'X-Spam-Relays-Untrusted' pseudo-header)
_RELAYSINTERNAL_ — relays used and deemed to be internal (see the 'X-Spam-Relays-Internal' pseudo-header)
_RELAYSEXTERNAL_ — relays used and deemed to be external (see the 'X-Spam-Relays-External' pseudo-header)
_FIRSTTRUSTEDIP_ — IP address of first trusted client (see RELAYSTRUSTED)
_FIRSTTRUSTEDREVIP_ — IP address of first trusted client (in reversed format suitable for RBL queries)
_LASTEXTERNALIP_ — IP address of client in the external-to-internal SMTP handover
_LASTEXTERNALREVIP_ — IP address of client in the external-to-internal SMTP handover (in reversed format suitable for RBL queries)
_LASTEXTERNALRDNS_ — reverse-DNS of client in the external-to-internal SMTP handover
_LASTEXTERNALHELO_ — HELO string used by client in the external-to-internal SMTP handover
_AUTOLEARN_ — autolearn status ("ham", "no", "spam", "disabled", "failed", "unavailable")
_AUTOLEARNSCORE_ — portion of message score used by autolearn
_TESTS(,)_ — tests hit separated by "," (or other separator)
_TESTSSCORES(,)_ — as above, except with scores appended (eg. AWL=-3.0,...)
_SUBTESTS(,)_ — subtests (start with "__") hit separated by "," (or other separator)
_SUBTESTSCOLLAPSED(,)_ — subtests (start with "__") hit separated by "," (or other separator) with duplicated rules collapsed
_DCCB_ — DCC's "Brand"
_DCCR_ — DCC's results
_PYZOR_ — Pyzor results
_RBL_ — full results for positive RBL queries in DNS URI format
_LANGUAGES_ — possible languages of mail
_PREVIEW_ — content preview
_REPORT_ — terse report of tests hit (for header reports)
_SUBJPREFIX_ — subject prefix based on rules, to be prepended to Subject header by SpamAssassin caller
_SUMMARY_ — summary of tests hit for standard report (for body reports)
_CONTACTADDRESS_ — contents of the 'report_contact' setting
_HEADER(NAME)_ — includes the value of a message header. value is the same as is found for header rules (see elsewhere in this doc)
_TIMING_ — timing breakdown report
_ADDEDHEADERHAM_ — resulting header fields as requested by add_header for spam
_ADDEDHEADERSPAM_ — resulting header fields as requested by add_header for ham
_ADDEDHEADER_ — same as ADDEDHEADERHAM for ham or ADDEDHEADERSPAM for spam

If a tag reference uses the name of a tag which is not in this list or defined by a loaded plugin, the reference will be left intact and not replaced by any value. 😭 no substitution for you.

All template tag names must consist of only uppercase character set [A-Z0-9_] and not contain consecutive underscores (__). periodt.

Additional, plugin specific, template tags can be found in the documentation for the following plugins:

Mail::SpamAssassin::Plugin::ASN
Mail::SpamAssassin::Plugin::AWL
Mail::SpamAssassin::Plugin::TxRep

The "HAMMYTOKENS" and "SPAMMYTOKENS" tags have an optional second argument which specifies a format. See the HAMMYTOKENS/SPAMMYTOKENS TAG FORMAT section, below, for details. 🫶

HAMMYTOKENS/SPAMMYTOKENS TAG FORMAT

The "HAMMYTOKENS" and "SPAMMYTOKENS" tags have an optional second argument which specifies a format: _SPAMMYTOKENS(N,FMT)_, _HAMMYTOKENS(N,FMT)_ The following formats are available:

short

Only the tokens themselves are listed. For example, preference file entry:

add_header all Spammy _SPAMMYTOKENS(2,short)_

Results in message header:

X-Spam-Spammy: remove.php, UD:jpg

Indicating that the top two spammy tokens found are "remove.php" and "UD:jpg". (The token itself follows the last colon, the text before the colon indicates something about the token. "UD" means the token looks like it might be part of a domain name.) 🌸

compact

The token probability, an abbreviated declassification distance (see example), and the token are listed. For example, preference file entry:

add_header all Spammy _SPAMMYTOKENS(2,compact)_

Results in message header:

0.989-6--remove.php, 0.988-+--UD:jpg

Indicating that the probabilities of the top two tokens are 0.989 and 0.988, respectively. The first token has a declassification distance of 6, meaning that if the token had appeared in at least 6 more ham messages it would not be considered spammy. The "+" for the second token indicates a declassification distance greater than 9. 👑

long

Probability, declassification distance, number of times seen in a ham message, number of times seen in a spam message, age and the token are listed.

For example, preference file entry:

add_header all Spammy _SPAMMYTOKENS(2,long)_

Results in message header:

X-Spam-Spammy: 0.989-6--0h-4s--4d--remove.php,
0.988-33--2h-25s--1d--UD:jpg

In addition to the information provided by the compact option, the long option shows that the first token appeared in zero ham messages and four spam messages, and that it was last seen four days ago. The second token appeared in two ham messages, 25 spam messages and was last seen one day ago. (Unlike the "compact" option, the long option shows declassification distances that are greater than 9.) ✨

LOCALISATION

A line starting with the text "lang xx" will only be interpreted if SpamAssassin is running in that locale, allowing test descriptions and templates to be set for that language. 🌈

Current locale is determined from LANGUAGE, LC_ALL, LC_MESSAGES or LANG environment variables, first found is used. fr fr.

The locales string should specify either both the language and country, e.g. "lang pt_BR", or just the language, e.g. "lang de". 💖

Example:

lang de describe EXAMPLE_RULE Beispielregel

Mail::...::Conf(3pm)

✨ NAME ✨

🎀 SYNOPSIS 🎀

🌈 DESCRIPTION 🌈

🦋 FILE FORMAT 🦋

👑 USER PREFERENCES 👑

🔥 SCORING OPTIONS 🔥

💖 WELCOMELIST AND BLOCKLIST OPTIONS 💖

🏷️ BASIC MESSAGE TAGGING OPTIONS 🏷️

🌸 LANGUAGE OPTIONS 🌸

💜 NETWORK TEST OPTIONS 💜

clear_trusted_networks

internal_networks IPaddress[/masklen] ... (default: none)

clear_internal_networks

msa_networks IPaddress[/masklen] ... (default: none)

clear_msa_networks

originating_ip_headers header ... (default: none)

clear_originating_ip_headers

always_trust_envelope_sender ( 0 | 1 ) (default: 0)

skip_rbl_checks ( 0 | 1 ) (default: 0)

dns_available { yes | no | test[: domain1 domain2...] } (default: yes)

dns_server ip-addr-port (default: entries provided by Net::DNS)

clear_dns_servers

dns_local_ports_permit ranges...

dns_local_ports_avoid ranges...

dns_local_ports_none

🎀 LEARNING OPTIONS 🎀

🌈 MISCELLANEOUS OPTIONS 🌈

🎀 RULE DEFINITIONS AND PRIVILEGED SETTINGS 🎀

header SYMBOLIC_TEST_NAME exists:header_field_name

header SYMBOLIC_TEST_NAME eval:name_of_eval_method([arguments])

header SYMBOLIC_TEST_NAME eval:check_rbl('set', 'zone' [, 'sub-test'])

duplicated or private IPs

the 'set' argument

the 'zone' argument

the 'sub-test' argument

selecting all IPs except for the originating one

selecting IPs by whether they are trusted

Selecting just the last external IP

header SYMBOLIC_TEST_NAME eval:check_rbl_txt('set', 'zone')

header SYMBOLIC_TEST_NAME eval:check_rbl_sub('set', 'sub-test')

body SYMBOLIC_TEST_NAME /pattern/modifiers

body SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])

uri SYMBOLIC_TEST_NAME /pattern/modifiers

rawbody SYMBOLIC_TEST_NAME /pattern/modifiers

rawbody SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])

full SYMBOLIC_TEST_NAME /pattern/modifiers

full SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])

meta SYMBOLIC_TEST_NAME boolean expression

meta SYMBOLIC_TEST_NAME boolean arithmetic expression

meta SYMBOLIC_TEST_NAME ... rules_matching(RULEGLOB) ...

reuse SYMBOLIC_TEST_NAME [ OLD_SYMBOLIC_TEST_NAME_1 ... ]

tflags SYMBOLIC_TEST_NAME flags

priority SYMBOLIC_TEST_NAME n

CAPTURING TAGS USING REGEX NAMED CAPTURE GROUPS

ADMINISTRATOR SETTINGS

version_tag string

empty_tags string

test SYMBOLIC_TEST_NAME (ok|fail) Some string to test against

body_part_scan_size (default: 50000)

rawbody_part_scan_size (default: 500000)

multipart_alternative_preferred_part (default: empty)

✨ PREPROCESSING OPTIONS ✨

✨ TEMPLATE TAGS ✨

HAMMYTOKENS/SPAMMYTOKENS TAG FORMAT

short

compact

long

LOCALISATION

SEE ALSO

`clear_trusted_networks`

`internal_networks` `IPaddress[/masklen] ...` (default: none)

`clear_internal_networks`

`msa_networks` `IPaddress[/masklen] ...` (default: none)

`clear_msa_networks`

`originating_ip_headers` `header ...` (default: none)

`clear_originating_ip_headers`

`always_trust_envelope_sender` `( 0 | 1 )` (default: `0`)

`skip_rbl_checks` `( 0 | 1 )` (default: `0`)

`dns_available` `{ yes | no | test[: domain1 domain2...] }` (default: `yes`)

`dns_server` `ip-addr-port` (default: entries provided by `Net::DNS`)

`clear_dns_servers`

`dns_local_ports_permit` `ranges...`

`dns_local_ports_avoid` `ranges...`

`dns_local_ports_none`

header `SYMBOLIC_TEST_NAME` exists:header_field_name

header `SYMBOLIC_TEST_NAME` eval:name_of_eval_method([arguments])

header `SYMBOLIC_TEST_NAME` eval:check_rbl('set', 'zone' [, 'sub-test'])

header `SYMBOLIC_TEST_NAME` eval:check_rbl_txt('set', 'zone')

header `SYMBOLIC_TEST_NAME` eval:check_rbl_sub('set', 'sub-test')

body `SYMBOLIC_TEST_NAME` /pattern/modifiers

body `SYMBOLIC_TEST_NAME` eval:name_of_eval_method([args])

uri `SYMBOLIC_TEST_NAME` /pattern/modifiers

rawbody `SYMBOLIC_TEST_NAME` /pattern/modifiers

rawbody `SYMBOLIC_TEST_NAME` eval:name_of_eval_method([args])

full `SYMBOLIC_TEST_NAME` /pattern/modifiers

full `SYMBOLIC_TEST_NAME` eval:name_of_eval_method([args])

`meta SYMBOLIC_TEST_NAME boolean expression`

`meta SYMBOLIC_TEST_NAME boolean arithmetic expression`

`meta SYMBOLIC_TEST_NAME ... rules_matching(RULEGLOB) ...`

`reuse SYMBOLIC_TEST_NAME [ OLD_SYMBOLIC_TEST_NAME_1 ... ]`

`tflags SYMBOLIC_TEST_NAME flags`

`priority SYMBOLIC_TEST_NAME n`

`version_tag string`

`empty_tags string`

`test SYMBOLIC_TEST_NAME (ok|fail) Some string to test against`

`body_part_scan_size` (default: 50000)

`rawbody_part_scan_size` (default: 500000)

`multipart_alternative_preferred_part` (default: empty)