Spamfilter MTA options

From Messaging Server Technical Reference Wiki
Jump to: navigation, search

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 ldap_optinN, ldap_source_optinN, and ldap_domain_attr_optinN MTA options.

For each virus/spam filtering package used, typically at a minimum a pair of options spamfilterN_library and spamfilterN_config_file 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 spamfilter* MTA options may be used to further fine-tune the MTA'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's choice). In MS 6.2, use of up to four spam/virus filter packages callouts was supported (via spamfilter1_* through spamfilter4_* options). New in MS 6.3, up to eight spam/virus filter package callouts are supported (via spamfilter1_* through spamfilter8_* 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's spamfilterN_verdict_M, spamfilterN_action_M option pairs as well as the default cases controlled via the spamfilterN_null_action and spamfilterN_string_action 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 spamfilter*_action MTA options and then have the MTA's systemfilter 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 imexpire, 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 spamfilterN_final, spamfilterN_includeheaders, spamfilterN_received, and spamfilterN_returnpath MTA options.

See also: