Spam and virus filtering

The MTA supports calling out to up to eight spam/virus filter packages while processing incoming messages. The configuration of how the MTA should locate and communicate with such spam/virus filter packages is controlled via spamfilter MTA options; the configuration of which routes of messages traffic receive which spam/virus filtering may be controlled via spamfilter channel options;  in addition to, or instead of, channel-level control, the MTA also supports per address (either sender or receiver) opt-in to spam/virus filtering  via various  user-level or  domain-level LDAP attributes, and via    alias options.

When use of multiple spam/virus filter package "slots" is configured, the MTA calls all the configured spam/virus filter packages as messages are being received (enqueued). Thus the spam/virus filter package processing of messages is essentially in parallel with each other (and with the MTA&#x27;s own inherent processing). The MTA then uses (applies) the spam/virus filter package results -- their respective verdicts -- in the order of the configured spam/virus filter package "slots": , before  , before  , etc.

Generally, spam/virus filter package verdicts regarding specific messages are interpreted by the MTA as requesting correspondingly configured Sieve filter actions. Via the interaction of various types and levels of Sieve filters in the MTA&#x27;s Sieve hierarchy, complex logic weighting or comparing verdicts from multiple spam/virus filter packages can be achieved. The Sieve  and   extensions can be particularly useful in the context of consulting multiple spam/virus filter packages.

With those spam/virus filter packages that support connection-based "early verdicts",  the MTA can also make use of such information as a special application of its general Mail filtering and access control functionality. See also the topics of Defending against denial of service attacks and Triggering effects from transaction logging with LOG_ACTION.

Note that many spam/virus filter packages do not themselves support returning different verdicts for different recipients of a single message. However, Brightmail does; and as of Messaging Server 7.0.5.33, Oracle&#x27;s  milter implementation supports a single recipient extension to effect different milter actions for different recipients. Furthermore, note that even with a spam/virus filter package that does not itself support returning different verdicts for different recipients, different per-recipient eventual effects can be achieved (at the cost of some additional configuration complexity) in a couple of ways. One way to achieve different effects for different users even with a spam/virus filter package that does not support per-recipient verdicts is to have the spam/virus filter package result "mark up" a message in one way or another (e.g., by adding a header line, or setting a spam level)  and then make use of the MTA&#x27;s Sieve hierarchy to take individualized actions in user-level Sieve filters. Another way to achieve individualized effects even with a spam/virus filter package that has no such inbuilt support is to assign different MTA spamfilter "slots" (that is, different   in the      MTA options) to different configurations of a single spam/virus filter package, and then "opt in" users to the appropriate "package" configurations, either at the domain level or at the individual user level; see the    and     MTA options.

Integrating spam/virus filter package use as a "call-out" via spamfilter MTA options is generally much preferable in functionality to use of an "in front" or "on the side" separate, dedicated spam/virus filter SMTP host, or even site or third-party written filtering MTA channel, for reasons including:



 the call-out approach permits "up front" address validation by the MTA, thus avoiding wasting time on invalid (perhaps dictionary attack generated) recipient addresses; 

 the call-out approach preserves SMTP responsibility and full SMTP features (e.g., message size limits, message notification handling requests, message authentication data, etc.) for incoming messages with the MTA whose primary function that is; 

 the call-out approach tends to maximize performance and throughput of messages; in particular, it avoids the overhead of additional full transfers of the messages and avoids SMTP performance bottlenecks or message buildups on third-party SMTP implementations; 

 the call-out approach permits the use of multiple spam/virus filter packages "in parallel", which for sites that like to use (or compare) different spam/virus packages has benefits including: 

 higher throughput due to the parallelization of the MTA calling all the spam/virus filter packages in parallel while messages are being enqueued, 

 convenient comparison of and swapping between different spam/virus filter packages at site convenience, 

 the potential for complex combining and weighting of verdicts from different spam/virus filter packages, 

 provisioning of user use of email spam/virus services that is integrated with the provisioning of user email addresses, routing, and other email services. </li>

</ol>

</li>

</ul>

However, the MTA does also support hooking in site or third-party written MTA channels via the alternate conversion channel approach.

The Message Store&#x27;s  utility also supports operating in a mode where it calls out to spam/virus filter packages "as if" it were an MTA channel, applying a subset of Sieve filter actions corresponding to the  spam/virus filter package verdicts again "as if" it were an MTA channel. This feature thus permits post-delivery scanning of  messages for spam/virus, and removal from the Message Store of such messages determined (post-delivery) to be spam or virus-contaminated.

See also:
 * Brightmail spamfilterN_config_file
 * ClamAV spamfilterN_config_file
 * ICAP spamfilterN_config_file
 * Milter spamfilterN_config_file
 * SpamAssassin spamfilterN_config_file
 * Archive spamfilterN_config_file
 * Sieve spamfilterN_config_file
 * Spamfilter channel options
 * Spamfilter MTA options
 * ldap_optin1 MTA Option
 * ldap_optout1 MTA Option
 * ldap_domain_attr_optin1 MTA Option
 * alias_optin1 Option
 * alias_optout1 Option
 * Sieve filters
 * Sieve hierarchy
 * Sieve spamtest and virustest extensions
 * Spamfilter early verdicts
 * Mail filtering and access control
 * Alternate channel routing via the CONVERSIONS mapping
 * Defending against denial of service attacks
 * Triggering effects from transaction logging with LOG_ACTION
 * Brightmail spamfilterN_config_file
 * Milter implementation
 * Milter single recipient extension
 * Sieve hierarchy
 * imexpire invoking spamfilter packages
 * The MTA