Spamfilter MTA options

The MTA has a number of options affecting Brightmail, ClamAV, Cloudmark, ICAP, Milter (as of MS 6.3), SpamAssassin, Symantec SAVSE or similar  virus/spam filtering plug-in facilities. These options are also used to integrate with AXS:One archiving. Most of these options affect the operation of the spam/virus filter package or archive package itself; however, there are also options that affect which  user(s) and domains(s) get such filtering or archiving applied, such as the    ,   , and      MTA options.

For each virus/spam filtering package used, typically at a minimum a pair of options       and      must be specified, telling the MTA the  location of a library of callable routines for that virus/spam filter  package and providing the location of a configuration file containing  some configuration information specific to that virus/spam filter  package. Additional   MTA options may be used to further  fine-tune the MTA&#x27;s utilization of the virus/spam filter package.

Prior to MS 6.2, the MTA supported use of one spam/virus filter package callout (of the site&#x27;s choice). In MS 6.2, use of up to four spam/virus filter packages callouts was supported (via    through   options). New in MS 6.3, up to eight spam/virus filter package callouts are supported (via   through   options).

The spam/virus filter packages get called asynchronously, being passed the original1 (not yet processed by the MTA) message; thus multiple spam/filter packages may be working on the same message in parallel. The spam/filter packages report their verdicts back to the MTA on their own timelines, as they respectively finish their work. The verdicts from the spam/virus filter packages are converted by the MTA into Sieve scriptlets, per the MTA&#x27;s   ,      option pairs as well as the default cases controlled via the     and      MTA options. The MTA then evaluates these Sieve scriptlets in order from spam/filter package 1  to spam/filter package 8; this in particular means that higher numbered, "later" spam/filter packages can see the results, such as added headers, from  lower numbered, "earlier" spam/filter packages and potentially  override them, if desired, although in regards to combining/weighting/overriding the  verdicts-and-effects of multiple spam/virus filter packages, a flexible and perhaps more straightforward approach is to convert the spam/virus filter package verdicts into various added header lines via configuration of the above mentioned    MTA options  and then have the MTA&#x27;s   see, consider, and make decisions based upon all the results (all the added header lines).

For spam/virus filter package invocation by external (external-to-the-MTA) components such as, see also the External filtering context MTA options.

 1Regarding the passing of the "original" (as received) message to the spam/virus filter packages, a few modifications are configurable via the   ,    ,    , and     MTA options.

See also:
 * optin_user_carryover MTA Option
 * scan_channel MTA Option
 * scan_originator MTA Option
 * scan_recipient MTA Option
 * spamfilter1_library MTA Option
 * spamfilter1_config_file MTA Option
 * spamfilter1_name MTA Option
 * spamfilter1_received MTA Option
 * spamfilter1_null_optin MTA Option
 * spamfilter1_action_0 MTA Option
 * spamfilter1_final MTA Option
 * spamfilter1_includeheaders MTA Option
 * spamfilter1_null_action MTA Option
 * spamfilter1_optional MTA Option
 * spamfilter1_received MTA Option
 * spamfilter1_returnpath MTA Option
 * spamfilter1_string_action MTA Option
 * spamfilter1_verdict_0 MTA Option
 * access_errors MTA Option
 * error_text_spamfilter1_error MTA Option
 * ldap_optin1 MTA Option
 * ldap_optout1 MTA Option
 * ldap_source_optin1 MTA Option
 * ldap_domain_attr_optin1 MTA Option
 * systemfilter MTA Option
 * Sieve hierarchy
 * Sieve filters
 * Spamfilter early verdicts
 * Spam and virus filtering
 * imexpire invoking spamfilter packages
 * External filtering context MTA options
 * MTA options