NAME
    Mail::SpamAssassin::Conf - SpamAssassin configuration file

SYNOPSIS
      # a comment

      rewrite_subject                 1

      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

DESCRIPTION
    SpamAssassin is configured using some traditional UNIX-style
    configuration files, loaded from the /usr/share/spamassassin and
    /etc/mail/spamassassin directories.

    The "#" character starts a comment, which continues until end of line.

    Whitespace in the files is not significant, but please note that
    starting a line with whitespace is deprecated, as we reserve its use for
    multi-line rule definitions, at some point in the future.

    Paths can use "~" to refer to the user's home directory.

    Where appropriate, default values are listed in parentheses.

USER PREFERENCES
    require_version n.nn
        Indicates that the entire file, from this line on, requires a
        certain version of SpamAssassin to run. If an older or newer version
        of SpamAssassin tries to read configuration from this file, it will
        output a warning instead, and ignore it.

    version_tag string
        This tag is appended to the SA version in the X-Spam-Status header.
        You should include it when 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.

        e.g.

          version_tag myrules1    # version=2.41-myrules1

    whitelist_from add@ress.com
        Used to specify addresses which send mail that is often tagged
        (incorrectly) as spam; it also helps if they are addresses of big
        companies with lots of lawyers. This way, if spammers impersonate
        them, they'll get into big trouble, so it doesn't provide a shortcut
        around SpamAssassin.

        Whitelist and blacklist addresses are now file-glob-style patterns,
        so "friend@somewhere.com", "*@isp.com", or "*.domain.net" will all
        work. Regular expressions are not used for security reasons.

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

        e.g.

          whitelist_from joe@example.com fred@example.com
          whitelist_from simon@example.com

    whitelist_from_rcvd lists.sourceforge.net sourceforge.net
        Use this to supplement the whitelist_from addresses with a check
        against the Received headers. The first parameter is the address to
        whitelist, and the second is a domain to match in the received
        headers.

        e.g.

          whitelist_from_rcvd joe@example.com  example.com
          whitelist_from_rcvd axkit.org        sergeant.org

    unwhitelist_from add@ress.com
        Used to override a default whitelist_from entry, so for example a
        distribution whitelist_from can be overriden in a local.cf file, or
        an individual user can override a whitelist_from entry in their own
        "user_prefs" file.

        e.g.

          unwhitelist_from joe@example.com fred@example.com
          unwhitelist_from *@amazon.com

    blacklist_from add@ress.com
        Used to specify addresses which send mail that is often tagged
        (incorrectly) as non-spam, but which the user doesn't want. Same
        format as "whitelist_from".

    unblacklist_from add@ress.com
        Used to override a default blacklist_from entry, so for example a
        distribution blacklist_from can be overriden in a local.cf file, or
        an individual user can override a blacklist_from entry in their own
        "user_prefs" file.

        e.g.

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

    whitelist_to add@ress.com
        If the given address appears in the "To:" or "Cc:" headers, mail
        will be whitelisted. Useful if you're deploying SpamAssassin
        system-wide, and don't want some users to have their mail filtered.
        Same format as "whitelist_from".

        There are three levels of To-whitelisting, "whitelist_to",
        "more_spam_to" and "all_spam_to". Users in the first level may still
        get some spammish mails blocked, but users in "all_spam_to" should
        never get mail blocked.

    more_spam_to add@ress.com
        See above.

    all_spam_to add@ress.com
        See above.

    required_hits n.nn (default: 5)
        Set the number of hits required before a mail is considered spam.
        "n.nn" can be an integer or a real number. 5.0 is the default
        setting, and is quite aggressive; it would be suitable for a
        single-user setup, but if you're an ISP installing SpamAssassin, you
        should probably set the default to be something much more
        conservative, like 8.0 or 10.0. Experience has shown that you will
        get plenty of user complaints otherwise!

    score SYMBOLIC_TEST_NAME n.nn
        Assign a score to a given test. Scores can be positive or negative
        real numbers or integers. "SYMBOLIC_TEST_NAME" is the symbolic name
        used by SpamAssassin as a handle for that test; for example,
        'FROM_ENDS_IN_NUMS'.

        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.

    detailed_phrase_score { 0 | 1 } (default: 0)
        This option displays all matches for "contains phrases frequently
        found in spam" Note that this is disabled by default because it can
        output huge headers (800 words and more than 8KB in some cases)

    rewrite_subject { 0 | 1 } (default: 1)
        By default, the subject lines of suspected spam will be tagged. This
        can be disabled here.

    fold_headers { 0 | 1 } (default: 1)
        By default, the X-Spam-Status header will be whitespace folded, in
        other words, it will be broken up into multiple lines instead of one
        very long one. This can be disabled here.

    spam_level_stars { 0 | 1 } (default: 1)
        By default, a header field called "X-Spam-Level" will be added to
        the message, with its value set to a number of asterisks equal to
        the score of the message. In other words, for a message scoring 7.2
        points:

        X-Spam-Level: *******

        This can be useful for MUA rule creation.

    spam_level_char { x (some character, unquoted) } (default: *)
        By default, the "X-Spam-Level" header will use a '*' character with
        its length equal to the score of the message. Some people don't like
        escaping *s though, so you can set the character to anything with
        this option.

        In other words, for a message scoring 7.2 points with this option
        set to .

        X-Spam-Level: .......

    subject_tag STRING ... (default: *****SPAM*****)
        Text added to the "Subject:" line of mails that are considered spam,
        if "rewrite_subject" is 1. _HITS_ in the tag will be replace with
        the calculated score for this message. _REQD_ will be replaced with
        the threshold.

    report_header { 0 | 1 } (default: 0)
        By default, SpamAssassin will include its report in the body of
        suspected spam. Enabling this causes the report to go in the headers
        instead. Using 'use_terse_report' with this is recommended.

    use_terse_report { 0 | 1 } (default: 0)
        By default, SpamAssassin uses a fairly long report format. Enabling
        this uses a shorter format which includes all the information in the
        normal one, but without the superfluous explanations.

    defang_mime { 0 | 1 } (default: 1)
        By default, SpamAssassin will change the Content-type: header of
        suspected spam to "text/plain". This is a safety feature. If you
        prefer to leave the Content-type header alone, set this to 0.

    dns_available { yes | test[: name1 name2...] | no } (default: test)
        By default, SpamAssassin will query some default hosts on the
        internet to attempt to check if DNS is working on not. The problem
        is that it can introduce some delay if your network connection is
        down, and in some cases it can wrongly guess that DNS is unavailable
        because the test connections failed. SpamAssassin includes a default
        set of 13 servers, among which 3 are picked randomly.

        You can however specify your own list by specifying

        dns_available test: server1.tld server2.tld server3.tld

    skip_rbl_checks { 0 | 1 } (default: 0)
        By default, SpamAssassin will run RBL checks. If your ISP already
        does this for you, set this to 1.

    check_mx_attempts n (default: 2)
        By default, SpamAssassin checks the From: address for a valid MX
        this many times, waiting 5 seconds each time.

    check_mx_delay n (default 5)
        How many seconds to wait before retrying an MX check.

    ok_languages xx [ yy zz ... ] (default: all)
        Which languages are considered OK to receive mail from. Mail using
        character sets used by these languages will not be marked as
        possibly being spam in an undesired language.

        The following languages are recognized. In your configuration, you
        must use the language specifier located in the first column, not the
        English name for the language. You may also specify "all" if your
        language is not listed or if you want to allow any language.

        af afrikaans
        am amharic
        ar arabic
        be byelorussian
        bg bulgarian
        bs bosnian
        ca catalan
        cs czech
        cy welsh
        da danish
        de german
        el greek
        en english
        eo esperanto
        es spanish
        et estonian
        eu basque
        fa persian
        fi finnish
        fr french
        fy frisian
        ga irish
        gd scots
        he hebrew
        hi hindi
        hr croatian
        hu hungarian
        hy armenian
        id indonesian
        is icelandic
        it italian
        ja japanese
        ka georgian
        ko korean
        la latin
        lt lithuanian
        lv latvian
        mr marathi
        ms malay
        ne nepali
        nl dutch
        no norwegian
        pl polish
        pt portuguese
        qu quechua
        rm rhaeto-romance
        ro romanian
        ru russian
        sa sanskrit
        sco scots
        sk slovak
        sl slovenian
        sq albanian
        sr serbian
        sv swedish
        sw swahili
        ta tamil
        th thai
        tl tagalog
        tr turkish
        uk ukrainian
        vi vietnamese
        yi yiddish
        zh chinese

        Note that the language cannot always be recognized. In that case, no
        points will be assigned.

    rbl_timeout n (default 30)
        All RBL queries are started at the beginning and we try to read the
        results at the end. In case some of them are hanging or not
        returning, you can specify here how long you're willing to wait for
        them before deciding that they timed out

    ok_locales xx [ yy zz ... ] (default: all)
        Which locales (country codes) are considered OK to receive mail
        from. Mail using character sets used by languages in these
        countries, will not be marked as possibly being spam in a foreign
        language.

        Note that all ISO-8859-* character sets, and Windows code page
        character sets, are always permitted by default anyway.

        If you wish SpamAssassin to block spam in foreign languages, set
        this to the locale which matches your preference, from the list
        below:

        ja  Japanese

        ko  Korea

        ru  Cyrillic charsets

        th  Thai

        zh  Chinese (both simplified and traditional)

    auto_whitelist_factor n (default: 0.5, range [0..1])
        How much towards the long-term mean for the sender to regress a
        message. Basically, the algorithm is to track the long-term mean
        score of messages for the sender ("mean"), and then once we have
        otherwise fully calculated the score for this message ("score"), we
        calculate the final score for the message as:

        "finalscore" = "score" + ("mean" - "score") * "factor"

        So if "factor" = 0.5, then we'll move to half way between the
        calculated score and the mean. If "factor" = 0.3, then we'll move
        about 1/3 of the way from the score toward the mean. "factor" = 1
        means just use the long-term mean; "factor" = 0 mean just use the
        calculated score.

    describe SYMBOLIC_TEST_NAME description ...
        Used to describe a test. This text is shown to users in the detailed
        report.

        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.

    tflags SYMBOLIC_TEST_NAME [ { net | nice } ... ]
        Used to set flags on a test. These flags are used in the
        score-determination back end system for details of the test's
        behaviour. The following flags can be 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 intended to compensate for common false positives,
            and should be assigned a negative score.

    report ...some text for a report...
        Set the report template which is attached to spam mail messages. See
        the "10_misc.cf" configuration file in "/usr/share/spamassassin" for
        an example.

        If you change this, try to keep it under 76 columns (inside the the
        dots below). Bear in mind that EVERY line will be prefixed with
        "SPAM: " in order to make it clear what's been added, and allow
        other filters to remove spamfilter modifications, so you lose 6
        columns right there. Also note that the first line of the report
        must start with 4 dashes, for the same reason. Each "report" line
        appends to the existing template, so use "clear-report-template" to
        restart.

        The following template items are supported, and will be filled out
        by SpamAssassin:

        _HITS_: the number of hits the message triggered
        _REQD_: the required hits to be considered spam
        _SUMMARY_: the full details of what hits were triggered
        _VER_: SpamAssassin version
        _HOME_: SpamAssassin home URL

    clear_report_template
        Clear the report template.

    terse_report ...some text for a report...
        Set the report template which is attached to spam mail messages, for
        the terse-report format. See the "10_misc.cf" configuration file in
        "/usr/share/spamassassin" for an example.

    clear-terse-report-template
        Clear the terse-report template.

    spamtrap ...some text for spamtrap reply mail...
        A template for spam-trap responses. If the first few lines begin
        with "Xxxxxx: yyy" where Xxxxxx is a header and yyy is some text,
        they'll be used as headers. See the "10_misc.cf" configuration file
        in "/usr/share/spamassassin" for an example.

    clear_spamtrap_template
        Clear the spamtrap template.

    dcc_path STRING
        This option tells SpamAssassin specifically where to find the pyzor
        client instead of relying on SpamAssassin to find it in the current
        PATH.

    dcc_body_max NUMBER
    dcc_fuz1_max NUMBER
    dcc_fuz2_max NUMBER
        DCC (Distributed Checksum Clearinghouse) is a system similar to
        Razor. This option sets how often a message's body/fuz1/fuz2
        checksum must have been reported to the DCC server before
        SpamAssassin will consider the DCC check as matched.

        As nearly all DCC clients are auto-reporting these checksums you
        should set this to a relatively high value, e.g. 999999 (this is
        DCC's MANY count).

        The default is 999999 for all these options.

    dcc_add_header { 0 | 1 } (default: 0)
        DCC processing creates a message header containing the statistics
        for the message. This option sets whether SpamAssassin will add the
        heading to messages it processes.

        The default is to not add the header.

    dcc_timeout n (default: 10)
        How many seconds you wait for dcc to complete before you go on
        without the results

    pyzor_path STRING
        This option tells SpamAssassin specifically where to find the pyzor
        client instead of relying on SpamAssassin to find it in the current
        PATH.

    pyzor_max NUMBER
        Pyzor is a system similar to Razor. This option sets how often a
        message's body checksum must have been reported to the Pyzor server
        before SpamAssassin will consider the Pyzor check as matched.

        The default is 5.

    pyzor_add_header { 0 | 1 } (default: 0)
        Pyzor processing creates a message header containing the statistics
        for the message. This option sets whether SpamAssassin will add the
        heading to messages it processes.

        The default is to not add the header.

    pyzor_timeout n (default: 10)
        How many seconds you wait for pyzor to complete before you go on
        without the results

    razor_timeout n (default 10)
        How many seconds you wait for razor to complete before you go on
        without the results

    num_check_received { integer } (default: 2)
        How many received lines from and including the original mail relay
        do we check in RBLs (you'd want at least 1 or 2). Note that for
        checking against dialup lists, you can call check_rbl with a special
        set name of "set-firsthop" and this rule will only be matched
        against the first hop if there is more than one hop, so that you can
        set a negative score to not penalize people who properly relayed
        through their ISP. See dialup_codes for more details and an example

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

    allow_user_rules { 0 | 1 } (default: 0)
        This setting allows users to 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.

    dialup_codes { "domain1" => "127.0.x.y", "domain2" => "127.0.a.b" }
        Default: { "dialups.mail-abuse.org." => "127.0.0.3", # For DUL +
        other codes, we ignore that it's on DUL "rbl-plus.mail-abuse.org."
        => "127.0.0.2", "relays.osirusoft.com." => "127.0.0.3" };

        WARNING!!! When passing a reference to a hash, you need to put the
        whole hash in one line for the parser to read it correctly (you can
        check with "spamassassin -D < mesg")

        Set this to what your RBLs return for dialup IPs It is used by
        dialup-firsthop and relay-firsthop rules so that you can match DUL
        codes and compensate DUL checks with a negative score if the IP is a
        dialup IP the mail originated from and it was properly relayed by a
        hop before reaching you (hopefully not your secondary MX :-) The
        trailing "-firsthop" is magic, it's what triggers the RBL to only be
        run on the originating hop The idea is to not penalize (or penalize
        less) people who properly relayed through their ISP's mail server

        Here's an example showing the use of Osirusoft and MAPS DUL, as well
        as the use of check_two_rbl_results to compensate for a match in
        both RBLs

        header RCVD_IN_DUL rbleval:check_rbl('dialup',
        'dialups.mail-abuse.org.') describe RCVD_IN_DUL Received from
        dialup, see http://www.mail-abuse.org/dul/ score RCVD_IN_DUL 4

        header X_RCVD_IN_DUL_FH rbleval:check_rbl('dialup-firsthop',
        'dialups.mail-abuse.org.') describe X_RCVD_IN_DUL_FH Received from
        first hop dialup, see http://www.mail-abuse.org/dul/ score
        X_RCVD_IN_DUL_FH -3

        header RCVD_IN_OSIRUSOFT_COM rbleval:check_rbl('osirusoft',
        'relays.osirusoft.com.') describe RCVD_IN_OSIRUSOFT_COM Received via
        an IP flagged in relays.osirusoft.com

        header X_OSIRU_SPAM_SRC rbleval:check_rbl_results_for('osirusoft',
        '127.0.0.4') describe X_OSIRU_SPAM_SRC DNSBL: sender is Confirmed
        Spam Source, penalizing further score X_OSIRU_SPAM_SRC 3.0

        header X_OSIRU_SPAMWARE_SITE
        rbleval:check_rbl_results_for('osirusoft', '127.0.0.6') describe
        X_OSIRU_SPAMWARE_SITE DNSBL: sender is a Spamware site or vendor,
        penalizing further score X_OSIRU_SPAMWARE_SITE 5.0

        header X_OSIRU_DUL_FH rbleval:check_rbl('osirusoft-dul-firsthop',
        'relays.osirusoft.com.') describe X_OSIRU_DUL_FH Received from first
        hop dialup listed in relays.osirusoft.com score X_OSIRU_DUL_FH -1.5

        header Z_FUDGE_DUL_MAPS_OSIRU
        rblreseval:check_two_rbl_results('osirusoft', "127.0.0.3", 'dialup',
        "127.0.0.3") describe Z_FUDGE_DUL_MAPS_OSIRU Do not double penalize
        for MAPS DUL and Osirusoft DUL score Z_FUDGE_DUL_MAPS_OSIRU -2

        header Z_FUDGE_RELAY_OSIRU
        rblreseval:check_two_rbl_results('osirusoft', "127.0.0.2", 'relay',
        "127.0.0.2") describe Z_FUDGE_RELAY_OSIRU Do not double penalize for
        being an open relay on Osirusoft and another DNSBL score
        Z_FUDGE_RELAY_OSIRU -2

        header Z_FUDGE_DUL_OSIRU_FH
        rblreseval:check_two_rbl_results('osirusoft-dul-firsthop',
        "127.0.0.3", 'dialup-firsthop', "127.0.0.3") describe
        Z_FUDGE_DUL_OSIRU_FH Do not double compensate for MAPS DUL and
        Osirusoft DUL first hop dialup score Z_FUDGE_DUL_OSIRU_FH 1.5

    header SYMBOLIC_TEST_NAME header op /pattern/modifiers [if-unset:
    STRING]
        Define a test. "SYMBOLIC_TEST_NAME" is a symbolic test name, such as
        'FROM_ENDS_IN_NUMS'. "header" is the name of a mail header, such as
        'Subject', 'To', etc.

        'ALL' can be used to mean the text of all the message's headers.
        'ToCc' can be used to mean the contents of both the 'To' and 'Cc'
        headers.

        "op" is either "=~" (contains regular expression) or "!~" (does not
        contain regular expression), and "pattern" is a valid Perl regular
        expression, with "modifiers" as regexp modifiers in the usual style.

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

        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.

    header SYMBOLIC_TEST_NAME exists:name_of_header
        Define a header existence test. "name_of_header" is the name of a
        header to test for existence. This is just a very simple version of
        the above header tests.

    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 on the "Mail::SpamAssassin::EvalTests" object. "arguments"
        are optional arguments to the function call.

    body SYMBOLIC_TEST_NAME /pattern/modifiers
        Define a body pattern test. "pattern" is a Perl regular expression.

        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. All HTML
        tags and line breaks will be removed before matching.

    body SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])
        Define a body eval test. See above.

    uri SYMBOLIC_TEST_NAME /pattern/modifiers
        Define a uri pattern test. "pattern" is a Perl regular expression.

        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.

    rawbody SYMBOLIC_TEST_NAME /pattern/modifiers
        Define a raw-body pattern test. "pattern" is a Perl regular
        expression.

        The 'raw body' of a message is the text, including all textual
        parts. The text will be decoded from base64 or quoted-printable
        encoding, but HTML tags and line breaks will still be present.

    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-body pattern test. "pattern" is a Perl regular
        expression.

        The 'full body' of a message is the un-decoded text, including all
        parts (including images or other attachments). SpamAssassin no
        longer tests full tests against decoded text; use "rawbody" for
        that.

    full SYMBOLIC_TEST_NAME eval:name_of_eval_method([args])
        Define a full-body eval test. See above.

    meta SYMBOLIC_TEST_NAME boolean expression
        Define a boolean expression test in terms of other tests that have
        been hit or not hit. For example:

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

        Note that English language operators ("and", "or") will be treated
        as rule names, and that there is no XOR operator.

        If you want to define a meta-rule, but do not want its individual
        sub-rules to count towards the final score unless the entire
        meta-rule matches, give the sub-rules names that start with '__'
        (two underscores). SpamAssassin will ignore these for scoring.

PRIVILEGED SETTINGS
    These settings differ from the ones above, in that they are considered
    'more privileged' -- even more than the ones in the SETTINGS section. No
    matter what "allow_user_rules" is set to, these can never be set from a
    user's "user_prefs" file.

    test SYMBOLIC_TEST_NAME (ok|fail) Some string to test against
        Define a regression testing string. You can have more than one
        regression test string per symbolic test name. Simply 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.

    razor_config filename
        Define the filename used to store Razor's configuration settings.
        Currently this is the same value Razor itself uses: "~/razor.conf".

    dcc_options options
        Specify additional options to the dccproc(8) command. Please note
        that only [A-Z -] is allowed (security).

        The default is "-R"

    auto_whitelist_path /path/to/file (default:
    ~/.spamassassin/auto-whitelist)
        Automatic-whitelist directory or file. By default, each user has
        their own, in their "~/.spamassassin" directory with mode 0700, but
        for system-wide SpamAssassin use, you may want to share this across
        all users.

    timelog_path /path/to/dir (default: NULL)
        If you set this value, razor will try to create logfiles for each
        message I processes and dump information on how fast it ran, and in
        which parts of the code the time was spent. The files will be named:
        unixdate_mesgid (i.e 1023257504_chuvn31gdu@4ax.com)

        Make sure SA can write the log file, if you're not sure what
        permissions needed, make the log directory chmod'ed 1777, and adjust
        later.

    auto_whitelist_file_mode (default: 0700)
        The file mode bits used for the automatic-whitelist directory or
        file. Make sure this has the relevant execute-bits set (--x),
        otherwise things will go wrong.

    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"

    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_table tablename
        The table user preferences are stored in, for the above DSN.

    spamphrase score phrase ...
        A 2-word spam phrase, for the FREQ_SPAM_PHRASE test.

    spamphrase-highest-score nnnnn
        The highest score of any of the spamphrases. Used for scaling.

LOCALI[SZ]ATION
    A line starting with the text "lang xx" will only be interpreted if the
    user is in that locale, allowing test descriptions and templates to be
    set for that language.

SEE ALSO
    "Mail::SpamAssassin" "spamassassin" "spamd"

