Deploying and Configuring Third Party Spam Filtering Programs

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.

Loading and Configuring the Spam Filtering Software Client Library

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)

Specifying the Spam Filtering Software Library Paths

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.

Specifying the Messages to Be Filtered

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:

• Specifying the Messages to Be Filtered

• User-level Filtering Example

• Domain-level Filtering Example

The expression optin means that a user, domain or channel is selected to receive mail filtering.

To Specify User-level 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:

Steps

1. 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

2. 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

User-level Filtering Example

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.

Example 14–1 Example LDAP User Entry for Brightmail

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)

To Specify Domain-level Filtering

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:

Steps

1. 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

2. 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

Domain-level Filtering Example

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.

Example 14–2 Example LDAP Domain Entry for Brightmail

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.

To Specify Channel-level Filtering

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.

Steps

1. 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

2. 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

Channel-level Filtering Examples

These examples assume a filtering program specified by the number 1. They use the keywords in the table below.

Example 1. Filter all mail for spam and viruses from an MTA relay to a backend message store called msg_store1.siroe.com

To Filter from an MTA Relay to a Backend Message Store

Steps

1. 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

2. 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

Specifying Actions to Perform on Spam Messages

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.

spamfilter1_verdict_0=reject
spamfilter1_action_0=data:,require "reject";
reject "Rejected by spam filter";