There are five actions required to deploy third-party filtering software on Messaging Server:
Determine which spam filtering programs you wish to deploy, and how many servers on which to deploy them. Messaging Server allows you to filter incoming messages with up to four different spam/virus programs. These programs can be run on separate systems, on the same system as Messaging Server in a single system deployment, or on the same system as the MTA in a two-tier deployment. The number of servers required depends on the message load, the hardware performance, and other factors. Refer to your spam filtering software documentation or representative for guidelines on determining the hardware requirements at your site.
Install and configure the spam filtering software. Refer to your spam filtering software documentation or representative for this information.
Load and configure the filtering client library. This involves specifying the client library and configuration file in the MTA option.dat file, and also setting the desired options in the filtering software’s configuration file. Loading and Configuring the Spam Filtering Software Client Library
Specify what messages get filtered. Messages can be filtered by user, domain, or channel. Specifying the Messages to Be Filtered.
Specify what happens to Spam. Spam can be discarded, filed into a folder, tagged on the subject line, and so on. Specifying Actions to Perform on Spam Messages
Previous versions of Messaging Server only supported the Brightmail filtering technology and so keywords and options had names, such as sourcebrightmail or Brightmail_config_file. These keywords and options have been changed to more generic names such as sourcespamfilter or spamfilter_config_file. The previous Brightmail names are retained for compatibility.
Each spam filtering program is expected to provide a client library file and configuration file for Messaging Server. Loading and configuring the client library involves two things:
Specifying the spam filtering software library paths (spamfilterX_library) and configuration files (spamfilterX_config_file) in the option.dat file. In addition to these options, there are a number of others used to specify spam filtering LDAP attributes, as well as the Sieve actions to use on spam messages.
Specifying the desired options in the spam filtering software configuration files. Each spam filtering program has a different configuration file and configuration options. These are described in the spam filtering software sections, as well as in the filtering software documentation. See Using Symantec Brightmail Anti-Spam and Using Symantec Anti-Virus Scanning Engine (SAVSE)
Messaging Server can call up to four different filtering systems for your messages. For example, you can run your messages through both the Symantec AntiVirus Scan Engine and SpamAssassin. Each filtering software is identified by a number from 1 to 4. These numbers appear as part of the various spam filter options, LDAP attributes, and channel keywords; an X is used as a filter identification number. For example, sourcespamfilterXoptin or spamfilterX_config_file. If the identifying number is omitted from the keyword or option name it defaults to 1.
The following option.dat settings specify Messaging Server to filter messages through both Symantec AntiVirus Scan Engine and SpamAssassin:
spamfilter1_library=Symantec_Library_File spamfilter1_config_file=Symantec_Config_File spamfilter2_library=SpamAssassin_Library_File spamfilter2_config_file=SpamAssassin_Config_File |
When using other options or keywords to configure the system, use the corresponding number at the end of the option or keyword. For example, sourcespamfilter2optin would refer to SpamAssassin. sourcespamfilter1optin would refer to Symantec AntiVirus Scan Engine. It is not necessary to use numbers sequentially. For example, if you want to temporarily disable the Symantec AntiVirus Scan Engine, you can just comment out the spamfilter1_library configuration file.
Once the spam filtering software is installed and ready to run with Messaging Server, you need to specify what messages to filter. Messaging Server can be configured to filter messages by user, domain, or channel. Each of these scenarios is described in the following sections:
The expression optin means that a user, domain or channel is selected to receive mail filtering.
It may be desirable to specify filtering on a per-user basis. For example, if spam or virus filtering is offered as a premium service to ISP customers, you can specify which users receive this and which don’t. The general steps for user filtering are as follows:
Specify the user LDAP attributes that activate the spam filtering software.
Set the LDAP_OPTINX options in option.dat. Example:
LDAP_OPTIN1=SymantecAV LDAP_OPTIN2=SpamAssassin |
Set filter attributes in the user entries that receive spam filtering.
The values for the filter attributes are multi-valued and depend on the server. Using the example shown in Step 1, the entries are:
SymantecAV: virus SpamAssassin: spam |
For a program like Brightmail, which can filter both viruses and spam, the valid values are spam and virus. When used as a multi-valued attribute, each value requires a separate attribute entry. For example, if the filter attribute for Brightmail was set to Brightmail, the entries are:
Brightmail: spam Brightmail: virus |
This example assumes that Brightmail is used. It also assumes that LDAP_OPTIN1 was set to Brightmail in the option.dat file. The user, Otis Fanning, has the Brightmail attribute set to spam and virus in his user entry. His mail is filtered by Brightmail for spam and viruses. User-level Filtering Example shows the Brightmail user entry for Otis Fanning.
dn: uid=fanning,ou=people,o=sesta.com,o=ISP objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: inetUser objectClass: ipUser objectClass: inetMailUser objectClass: inetLocalMailRecipient objectClass: nsManagedPerson objectClass: userPresenceProfile cn: Otis Fanning sn: fanning initials: OTF givenName: Otis pabURI: ldap://ldap.siroe.com:389/ou=fanning,ou=people,o=sesta.com,o=isp,o=pab mail: Otis.Fanning@sesta.com mailAlternateAddress: ofanning@sesta.com mailDeliveryOption: mailbox mailHost: manatee.siroe.com uid: fanning dataSource: iMS 5.0 @(#)ims50users.sh 1.5a 02/3/00 userPassword: password inetUserStatus: active mailUserStatus: active mailQuota: -1 mailMsgQuota: 100 Brightmail: virus Brightmail: spam |
If Symantec AntiVirus Scan Engine and SpamAssassin were used, the entry would look like this:
SymantecAV: virus SpamAssassin: spam |
See Using Symantec Brightmail Anti-Spam, Using SpamAssassin or Using Symantec Anti-Virus Scanning Engine (SAVSE)
You can specify which domains receive filtering. An example of this feature would be if anti-spam or anti-virus filtering were offered as a premium service to ISP domain customers. The general steps for specifying domain filtering is as follows:
Specify the domain LDAP attributes that activates the filtering software.
Set the LDAP_DOMAIN_ATTR_OPTINX options in option.dat. Example:
LDAP_DOMAIN_ATTR_OPTIN1=SymantecAV LDAP_DOMAIN_ATTR_OPTIN2=SpamAssassin |
Set filter attributes in the domain entries that receive spam filtering.
The values for the filter attributes are multi-valued and depend on the server. Using the example shown in Step 1, the entries would be as follows:
SymantecAV: virus SpamAssassin: spam |
For a program like Brightmail which can filter both viruses and spam, the valid values are spam and virus. When used as a multi-valued attribute, each value requires a separate attribute value entry. For example, if LDAP_DOMAIN_ATTR_OPTIN1 was set to Brightmail, the entries would be:
Brightmail: spam Brightmail: virus |
This example assumes that Brightmail is used. It also assumes that LDAP_DOMAIN_ATTR_OPTIN1 was set to Brightmail in the option.dat file. The Brightmail attribute is set to spam and virus in the sesta.com domain entry in the DC tree for Sun LDAP Schema 1. For Sun LDAP Schema 2 you also set Brightmail in the domain entries that receive spam filtering.
All mail sent to sesta.com is filtered for spam and viruses by Brightmail. A Domain-level Filtering Example is shown below.
dn: dc=sesta,dc=com,o=internet objectClass: domain objectClass: inetDomain objectClass: mailDomain objectClass: nsManagedDomain objectClass: icsCalendarDomain description: DC node for sesta.com hosted domain dc: sesta inetDomainBaseDN: o=sesta.com,o=isp inetDomainStatus: active mailDomainStatus: active mailDomainAllowedServiceAccess: +imap, pop3, http:* mailRoutingHosts: manatee.siroe.com preferredMailHost: manatee.siroe.com mailDomainDiskQuota: 100000000 mailDomainMsgQuota: -1 mailClientAttachmentQuota: 5 Brightmail: spam Brightmail: virus |
If Symantec AntiVirus Scan Engine and SpamAssassin were used, the entry would look similar to like this:
SymantecAV: virus SpamAssassin: spam |
See Using Symantec Brightmail Anti-Spam, Using SpamAssassin or Using Symantec Anti-Virus Scanning Engine (SAVSE) for more examples and details.
Filtering by source or destination channel provides greater flexibility and granularity for spam filtering. For example, you may wish to filter in these ways:
Only messages from a specific MTA relay to a backend message store
All incoming mail from a specific MTA.
All outgoing mail from a specific MTA.
Incoming and outgoing mail from a specific MTA.
Messaging Server allows you to specify filtering by source or destination channel. The mechanism for doing this are the channel keywords described in Table 14–1. The following example demonstrates how to set up channel-level filtering.
Add a rewrite rule in the imta.cnf file for all inbound SMTP servers that send messages to a backend message store host. Example:
msg_store1.siroe.com $U@msg_store1.siroe.com
Add a channel corresponding to the rewrite rule with the destinationspamfilterXoptin keyword. Example:
tcp_msg_store1 smtp subdirs 20 backoff "pt5m" "pt10" "pt30" \ "pt1h" “pt2h” “pt4h” maxjobs 1 pool IMS_POOL \ fileinto $U+$S@$D destinationspamfilter1optin spam msg_store1.siroe.com |
These examples assume a filtering program specified by the number 1. They use the keywords in the table below.
Table 14–1 MTA Channel Keywords for Spam Filters
Channel Keyword |
Description |
---|---|
Specifies that all messages destined to this channel are filtered by anti-spam software X even if those services are not specified by user or domain with the LDAP_OPTIN LDAP attribute. (Filtering software X is defined by spamfilterX_library in option.dat.) The filter parameters depend on the filtering program and follow the keyword. For example, Brightmail parameters are normally spam or virus or spam,virus. The SpamAssassin parameter is spam. In this example, all mail destined for the message store is scanned for spam: ims-ms destinationspamfilter1optin spam,virus. . . |
|
Specifies that all messages originating from this channel are filtered by anti-spam software X even if those services are not specified by user or domain with the LDAP_OPTIN LDAP attribute. The system-wide default parameters follow the keyword, and the available parameters depend on the filtering program. For example, for Brightmail parameters are spam or virus or spam,virus. For SpamAssassin, the parameter is spam. If switchchannel is in effect, this keyword is placed on the switched-to channel. |
Example 1. Filter all mail for spam and viruses from an MTA relay to a backend message store called msg_store1.siroe.com
Add a rewrite rule in the imta.cnf file that sends messages to a backend message store host. Example:
msg_store1.siroe.com $U@msg_store1.siroe.com
Add a channel corresponding to that rewrite rule with the destinationspamfilterXoptin keyword. Example:
tcp_msg_store1 smtp subdirs 20 backoff “pt5m” “pt10” “pt30” “pt1h” \ “pt2h” “pt4h” maxjobs 1 pool IMS_POOL fileinto $U+$S@$D \ destinationspamfilter 1optin spam,virus msg_store1.siroe.com
Example 2. Filter for spam all incoming mail passing through your MTA (Typically, all incoming messages pass through the tcp_local channel):
tcp_local smtp mx single_sys remotehost inner switchchannel \ identnonelimited subdirs 20 maxjobs 7 pool SMTP_POOL \ maytlsserver maysaslserver saslswitchchannel tcp_auth \ sourcespamfilter1optin spam tcp-daemon
Example 3. Filter all outgoing mail to the Internet passing through your MTA. (Typically, all messages going out to the Internet pass through the tcp_local channel.)
tcp_local smtp mx single_sys remotehost inner switchchannel \ identnonelimited subdirs 20 maxjobs 7 pool SMTP_POOL \ maytlsserver maysaslserver saslswitchchannel tcp_auth \ destinationspamfilter1optin spam tcp-daemon
Example 4. Filter all incoming and outgoing mail passing through your MTA:
tcp_local smtp mx single_sys remotehost inner switchchannel \ identnonelimited subdirs 20 maxjobs 7 pool SMTP_POOL \ maytlsserver maysaslserver saslswitchchannel tcp_auth \ sourcespamfilter1optin spam destinationspamfilter1optin spam tcp-daemon
Example 5. Filter all mail destined to the local message store in a two-tiered system without using user optin:
ims-ms smtp mx single_sys remotehost inner switchchannel \ identnonelimited subdirs 20 maxjobs 7 pool SMTP_POOL \ maytlsserver maysaslserver saslswitchchannel tcp_auth \ destinationspamfilter1optin spam tcp-daemon
Example 6. Filter all incoming and outgoing mail for spam and viruses (this presumes that your software filters both spam and viruses):
tcp_local smtp mx single_sys remotehost inner switchchannel \ identnonelimited subdirs 20 maxjobs 7 pool SMTP_POOL \ maytlsserver maysaslserver saslswitchchannel tcp_auth \ destinationspamfilter1optin spam,virus sourcespamfilter1optin \ spam,virus tcp-daemon
Spam filtering programs analyze messages and return a verdict of spam or not spam to current version of Messaging Server. Messaging Server then takes action on the message. Actions are specified using the Sieve mail filtering language. Possible actions are to discard the message, file it into a folder, add a header, add a tag to the subject line, and so on. Complex Sieve scripts with if-then-else statements are also possible.
Refer to the Sieve specification 3028 for the complete Sieve syntax. Also see http//www.cyrusoft.com/sievettp://www.cyrusoft.com/sieve/
Sieve scripts are specified with the MTA spam filter options (option.dat) described in Table 14–2. The primary spam filter action options are SpamfilterX_null_action, which specifies the Sieve rule to execute when a null value is returned as the spam verdict value, and SpamfilterX_string_action, which specifies the Sieve rule to execute when a string is returned as the spam verdict.
Spam filtering programs typically return a string or a null value to the MTA to indicate that message is spam. Some programs also return a spam score—a number rating the probability of the message being spam or not. This score can be used as part of the action sequence. The following examples show how to specify actions on filtered messages. Each example assumes a filtering program specified by the number 1.
Example 1: File spam messages with a null verdict value to the file SPAM_CAN.
spamfilter1_null_action=data:,require "fileinto"; fileinto "SPAM_CAN”;
The same action can be performed on a spam message that returns a string:
spamfilter1_string_action=data:,require "fileinto"; fileinto "SPAM_CAN”;
Example 2: File spam messages with a returned verdict string into a file named after the returned verdict string (this is what $U does). That is, if the verdict string returned is spam, the message is stored in a file called spam.
spamfilter1_null_action=data:,require "fileinto"; fileinto "$U”;
Example 3: Discard spam messages with a string verdict value.
spamfilter1_string_action=data:,discard
The same action can be performed on a spam message that returns a null value:
spamfilter1_null_action=data:,require "fileinto"; fileinto "SPAM_CAN”;
Example 4. This line adds the header Spam-test: FAIL to each message determined to be spam by a string verdict value:
spamfilter1_string_action=data:,require ["addheader"];addheader "Spam-test: FAIL”;
Example 5. This line adds the string [PROBABLE SPAM] to the subject line of the spam messages returning a string:
spamfilter1_string_action=data:,addtag “[PROBABLE SPAM]”;
Example 6. This line assumes a string verdict value and files a spam message in the mailbox testspam if the header contains resent-from and User-1. If the message does not have that header, it files the message into spam.
spamfilter1_string_action=data:,require "fileinto"; \ if header :contains ["resent-from"] ["User-1"] { \ fileinto "testspam"; \ } else { \ fileinto "spam";};
Because verdict strings are configurable with most spam filter software, you can specify different actions depending on the returned string. This can be done with the matched pairs spamfilterX_verdict_n and spamfilterX_action_n options.
Example 7. These matched pair options discard spam messages with the returned verdict string of remove.
spamfilter1_verdict_0=remove spamfilter1_action_0=data:,discard |
Refer to the specific spam filtering software sections for instructions on how to specify the spam verdict string.
Table 14–2 MTA Spam Filter Options (option.dat)
MTA Options for Spam Assassin |
Description |
|
---|---|---|
Specifies the full file path and name of the filtering software X configuration file. Default: none |
||
Specifies the full file path and name of the filtering software X shared library. Default: none |
||
Controls whether certain failures reported by the filtering library X are treated as a temporary processing failure or ignored. The default value of 0 specifies that spam filtering problems cause a temporary processing failure. Changing the value to 1 causes spam filter processing to be skipped in the event of some, but possibly not all, filtering library failures. In particular, if the system gets stuck without a return in the library code, some portion of the MTA may also get stuck. -2 and 2 can also be set. The are the same as 0 and 1 respectively except that they also cause a syslog message to be sent in the event of a problem reported by the spam filter plugin. Default: 0 |
||
Specifies the name of the LDAP attribute used to activate filtering software X on a user basis. This should be an attribute in the inetMailUser objectclass. The attribute itself can take multiple values and is case-sensitive. For SpamAssassin, its value should be spam in lowercase. Default: none |
||
Specifies the name of the LDAP attribute used to activate filtering software X on a domain basis. It applies to the destination domain. It is just like LDAP_optin, except it should be in the objectclass mailDomain. Default: none |
||
Specifies a string which, if found, as a value of the attribute defined by LDAP_optinX or LDAP_domain_attr_optinX, causes the MTA to act as if the attribute wasn’t there. That is, it disables filtering for that entry. See Specifying the Messages to Be Filtered Default: The empty string. Empty optin attributes are ignored by default. (This is a change from iPlanet Messaging Server 5.2, where empty optin attributes triggered filtering with an empty optin list. The 5.2 behavior can be restored by setting spamfilterX_null_optin to a string that never occurs in practice.) |
||
Defines a Sieve rule specifying what to do with the message when the filtering software X verdict returns as null. Sieve expressions can be stored externally using a file URL. For example: file:///var/opt/SUNWmsgsr/config/null_action.sieve. Also, do not reject spam using the Sieve reject action, as it tends to deliver a nondelivery notification to the innocent party whose address was used to send the spam. Default: data:,discard; |
||
Defines Sieve rule specifying what to do with the message if the verdict is a string. Sieve expressions can be stored externally using a file URL. For example: file:///var/opt/SUNWmsgsr/config/null_action.sieve. Also, do not reject spam using the Sieve reject action, as it tends to deliver a nondelivery notification to the innocent party whose server was used to send the spam. Default: data:,require "fileinto"; fileinto "$U; where $U is the string that verdict returned. |
||
The options spamfilterX_verdict_n and spamfilterX_action_n are matched pairs, where n is a number from 0 to 9. These options allow you to specify Sieve filters for arbitrary verdict strings. This is done by setting spamfilterX_verdict_n and spamfilterX_action_n to the verdict string and sieve filter, respectively, where n is an integer from 0 to 9. For example, a site could have the “reject” verdict cause a sieve reject action by specifying:
The default values for all the spamfilterX_verdict_n options and the corresponding action options are empty strings. Default: none |
||
See spamfilterX_verdict_n. Default: none |
||
Some filtering libraries have the ability to perform a set of actions based on recipient addresses. spamfilterX_final specifies the sort of recipient address passed to the filtering library. A value of 0 results in an intermediate address being used; 1 sends the final form of the recipient address. Default: 0 |
||
Forwarding is a challenge for spam filter processing. Consider a user entry that specifies the forward delivery option and specifies the forwarding address of another user. Additionally, the user entry is set to opt in to some specific sort of filtering. Should the filtering be applied to the forwarded message or not? On the one hand, the correct filtering choice for one particular user may not be the correct choice for another. On the other hand, eliminating a filtering operation might be used as means of violating a site’s security policy. No single answer is correct in all cases so OPTIN_USER_CARRYOVER controls how the spam filtering optin list is carried from one user or alias entry to another when forwarding occurs. This is a bit-encoded value. The various bit values have the following meanings: bit 0 (value 1). Each LDAP user entry overrides any previously active user/domain optins unconditionally. bit 1 (value 2). If a user’s domain has an optin attribute, it overrides any previous user/domain/alias optins that were active. bit 2 (value 4). If a user has an optin attribute, it overrides any previous user/domain/alias optins that were active. bit 3 (value 8). An optin specified by an [optin] non-positional parameter overrides any previous user/domain/alias optins that were active. Default: 0 (optins accumulate if one user has a delivery option that forwards to another. The default insures that site security policies are effective when forwarding; other settings may not.) |