|
| |
| Sun Java System Messaging Server 6 2005Q1 Administration Guide | |
Chapter 14
Integrating Spam and Virus Filtering Programs Into Messaging ServerThis chapter describes how to integrate and configure spam and virus filtering software with Messaging Server. The spam/virus filtering technology described in this chapter is more powerful than the technology provided by the conversion channel (see The Conversion Channel). Messaging Server supports Symantec Brightmail AntiSpam, SpamAssassin, and anti-spam/anti-virus programs which support Internet Content Adaptation Protocol (ICAP, RFC 3507), specifically Symantec AntiVirus Scan Engine.
This chapter is divided into the following sections:
Integrating Spam Filtering Programs Into Messaging Server—Theory of OperationsFrom the perspective of Messaging Server, anti-spam solutions operate in much the same way:
- Messaging Server sends a copy of a message to the spam filtering software.
- The spam filtering software analyzes the message and returns a verdict of spam or not spam. Some programs, like SpamAssassin may also return a spam score, which is a numerical rating of the probability of the message being spam.
- Messaging Server reads the verdict and takes a Sieve action on the message (see Specifying Actions to Perform on Spam Messages).
Spam filtering programs interact with the MTA through a protocol. The protocol may be a standard as in ICAP-based programs such as Symantec AntiVirus Scan Engine, proprietary as in Brightmail, or simply non-standard as in SpamAssassin. Each protocol requires software hooks to interface with the MTA. Brightmail and SpamAssassin were the first two spam filtering programs that could be integrated with messaging server. The MTA now supports the programs that use ICAP.
Deploying and Configuring Third Party Spam Filtering ProgramsThere 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.
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 or Using SpamAssassin, 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_FileWhen 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:
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:
- 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: spamFor 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: virusUser-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. Code Example 14-1 shows the Brightmail user entry for Otis Fanning.
If Symantec AntiVirus Scan Engine and SpamAssassin were used, the entry would look like this:
SymantecAV: virus
SpamAssassin: spamSee Using Symantec Brightmail Anti-Spam, Using SpamAssassin or Using Symantec Anti-Virus Scanning Engine (SAVSE) for more examples and details.
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:
- 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: spamFor 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: virusDomain-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. Code Example 14-2 shows the domain entry.
Code 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: spamSee 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:
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
Table 14-1 MTA Channel Keywords for Spam Filters
Channel Keyword
Description
destinationspamfilterXoptin
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. . .
sourcespamfilterXoptin
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.
Channel-level Filtering Examples
These example assume a filtering program specified by the number 1.
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 \
destinationspamfilter1optin spam,virus
msg_store1.siroe.comExample 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-daemonExample 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-daemonExample 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-daemonExample 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-daemonExample 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-daemonSpecifying Actions to Perform on Spam Messages
Spam filtering programs analyze messages and return a verdict of spam or not spam to 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.
Note
Refer to the Sieve specification 3028 for the complete Sieve syntax. Also see http://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:,discardRefer 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
SpamfilterX_config_file
Specifies the full file path and name of the filtering software X configuration file.
Default: noneSpamfilterX_library
Specifies the full file path and name of the filtering software X shared library.
Default: noneSpamfilterX_optional
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
LDAP_optinX
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
LDAP_domain_attr_optinX
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
SpamfilterX_null_optin
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 for usage details.
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.)
SpamfilterX_null_action
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;SpamfilterX_string_action
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.
spamfilterX_verdict_n
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:
spamfilter1_verdict_0=reject
spamfilter1_action_0=data:,require "reject"; reject "Rejected by spam filter";The default values for all the spamfilterX_verdict_n options and the corresponding action options are empty strings.
Default: none
spamfilterX_action_n
See spamfilterX_verdict_n. Default: none
spamfilterX_final
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
optin_user_carryover
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.)
Using Symantec Brightmail Anti-SpamThe Brightmail solution consists of the Brightmail server along with realtime anti-spam and anti-virus rule updates downloaded to email servers.
How Brightmail Works
The Brightmail server is deployed at a customer site. Brightmail has email probes set around the Internet for detection of new spam. Brightmail technicians create custom rules to block this spam in realtime. These rules are downloaded to Brightmail servers, also in realtime. The Brightmail database is updated and Brightmail server runs this database filter against the email for the specified users or domains.
Brightmail Architecture
Figure 14-1 depicts the Brightmail architecture.
Figure 14-1
Brightmail and Messaging Server Architecture
When the Brightmail Logistics and Operations Center (BLOC) receives spam from email probes, operators immediately create appropriate spam filtering rules, which are downloaded to Brightmail customer machines. Similarly, the Symantec Security Response realtime virus rules are also sent from Brightmail. These rules are used by customer’s Brightmail servers to catch spam and viruses.
The MTA uses the Brightmail SDK to communicate with the Brightmail Server. The MTA dispatches messages based on the response from Brightmail. After the mail (1a) or (1b) is received by the MTA, the MTA sends the message to the Brightmail server (2). The Brightmail server uses its rules and data to determine if the message is a spam or virus (3), and returns a verdict to the MTA. Based on the verdict, the MTA either (4a) discards the message or files the message into a folder, or (4b) delivers it normally to the destination.
Since the Brightmail SDK is third party software, we do not include it in our installation kit. The Brightmail SDK and server software must be obtained from Brightmail Inc. The MTA has configuration settings to tell it whether and where to load the Brightmail SDK to enable Brightmail integration.
Once the SDK is loaded, Brightmail message processing is determined by several factors and levels of granularity (the term used by Brightmail to specify active processing is optin). This is specified by the following criteria:
For any particular message recipient, the optins and defaults above are combined, which means, if the channel default is already specified for both spam and virus, then there is no reason to bother with per-user optin. That is, if the system administrator decides to do spam and virus filtering for everyone, then there is no reason to expose to the user the ability to optin for spam or virus. There is no way to opt out of processing, that is, you can not say you do not want the service if a user is already optin via a system or domain optin. This also means that if you are optin for a service, and you have forwarded your mail to another address, that address would get the mail after the filtering has been performed on your behalf.
There are only two services offered, virus or spam detection. Brightmail also provides “content-filtering” service, but this functionality is provided using Sieve, so there is no added value to have Brightmail do the Sieve filtering.
When a message is determined to contain a virus, the Brightmail server can be configured to clean the virus and resubmit the cleaned message back to the MTA. (Due to some undesirable side effects caused by loss of information about the original message in a resubmitted cleaned message, we recommend you do not configure Brightmail to resubmit the cleaned message back to the MTA.) When the message is spam, the verdict back from the Brightmail along with the configuration in Brightmail allows the MTA to determine what happens to the message. The message can be discarded, filed into a folder, tagged as spam or virus on the subject line, passed to a Sieve rule, delivered normally in the INBOX, and so on.
The Brightmail servers can be located on the same system as the MTA, or it can be on a separate system. In fact, you can have a farm of Brightmail servers serving one or more MTAs. The Brightmail SDK uses the Brightmail configuration file to determine which Brightmail servers to use.
Brightmail Requirements and Performance Considerations
- Brightmail servers must run on the Solaris Operating System.
- If Brightmail does spam and virus checking, MTA message throughput can be reduced by as much 50%. To keep up with MTA throughput, you may need two Brightmail servers for each MTA.
- While SpamAssassin has the ability to perform different sorts of filtering on a user basis, it is unable to apply two different sets of filtering criteria to the same message at the same time. Thus, SpamAssassin only allows system-wide filtering. Customized filtering for individual users is not possible.
Deploying Brightmail
Perform the following steps to deploy Brightmail.
- Install and Configure Brightmail. Refer to the Brightmail software documentation or representative for installation and configuration information. Selected Brightmail configuration options are shown in Brightmail Configuration Options, however the most complete and up-to-date information is in the Brightmail documentation.
- Load and Configure the Brightmail Client Library. This involves specifying the Brightmail client library, libbmiclient.so, and configuration, config, file to the MTA. See Loading and Configuring the Spam Filtering Software Client Library.
- Specify what messages to filter for spam. Messages can be filtered by user, domain, or channel. See Specifying the Messages to Be Filtered
- Specify what actions to take on spam messages. Spam can be discarded, filed into a folder, tagged on the subject line, and so on. See Specifying Actions to Perform on Spam Messages.
- Set miscellaneous MTA filter configuration parameters as desired. See MTA Spam Filter Options (option.dat).
Brightmail Configuration Options
Selected Brightmail configuration file options are shown in Table 14-3. The most complete listing of Brightmail configuration file options can be obtained from Brightmail. Options and values are not case-sensitive.
Table 14-3 Selected Brightmail Configuration File Options
Brightmail Option
Description
blSWPrecedence
A given message can have multiple verdicts. This specifies the precedence order. So if a message is processed for virus first, then for spam if you specified this option as virus-spam the verdicts are separated by hyphens (-). This is the recommended setting when using Brightmail with Sun Java System Messaging Server.
blSWClientDestinationDefault
Specifies how to deliver normal messages, that is, not a spam or virus, and thus have no verdict. Usually you want to deliver this message normally, so you would specify inbox as the value. There is no default.
blSWLocalDomain
This attribute specifies what domain(s) are considered to be local. There can be multiple lines of this attribute specifying several domains which are all considered local. Local versus foreign domain is used to specify two different handling for a verdict.
See below blSWClientDestinationLocal and blSWClientDestinationForeign. For example, you can specify
blSWLocalDomain=siroe.com
blSWClientDestinationLocal
This specifies the verdict and action pair for the local domain. You would normally have two lines for this, one for spam and one for virus. The value is of the form verdict|action, For example,
blSWClientDestinationLocal=spam|spambox
blSWClientDestinationLocal=virus|
The default Brightmail interpretation for the “null” action, meaning nothing to the right of the |, is to discard the message. So the example above discards the message if it has a verdict of virus. And if the verdict is spam, the above example files the message into the folder called spambox. If the message is not spam or virus, then the verdicts do not match, and the mail is delivered normally based on what’s set in the blSWClientDestinationDefault setting above.
When using a separate Brightmail server or servers from the MTA, you can customize the actions taken by each MTA by using the Brightmail_verdict_n/Brightmail_action_n/Brightmail_null_action/Brightmail_string_action MTA options to override the actions and verdicts returned by the Brightmail server. In this example, you can use different Brightmail_null_action on the MTA to override the Virus action (which would be to discard it) or to use Brightmail_verdict_0=spambox, and Brightmail_action_0=data:,require "fileinto";fileinto "Junk"; to file into a folder called Junk instead of spambox.
blSWClientDesintationForeign
Same format and interpretation as blSWClientDestinationLocal above, except this applies to users in the domain which are NOT local.
blSWUseClientOptin
Always set this to TRUE when used with Sun Java System Messaging Server.
blswcServerAddress
Is of the form ip:port[,ip:port,...] to specify one or more Brightmail server’s IP address and port numbers
Using SpamAssassinThis section consists of the following subsections:
SpamAssassin Overview
Messaging Server supports the use of SpamAssassin, a freeware mail filter used to identify spam. SpamAssassin consists of a library written in Perl and a set of applications and utilities that can be used to integrate SpamAssassin into messaging systems.
SpamAssassin calculates a score for every message by performing a series of tests on the message header and body information. Each test succeeds or fails, and a verdict of true (spam) or false (not spam) is rendered. Scores are real numbers that can be positive or negative. Scores that exceed a specified threshold, typically 5.0, are considered to be spam. An example of a SpamAssassin result string is:
True ; 18.3 / 5.0
True indicates the message is spam. 18.3 is the SpamAssassin score. 5.0 is the threshold.
SpamAssassin is highly configurable. Tests may be added or removed at any time, and the scores of existing tests can be adjusted. This is all done through various configuration files. Further information on SpamAssassin can be found on the SpamAssassin web site.
The same mechanism used for calling out to the Brightmail spam and virus scanning library can be used to connect to the SpamAssassin spamd server. The module provided in Messaging Server is called libspamass.so.
SpamAssassin/Messaging Server Theory of Operations
spamd is the daemon version of SpamAssassin and can be invoked from the MTA. spamd listens on a socket for requests and spawns a child process to test the message. The child process dies after processing the message and sending back a result. In theory, the forking should be an efficient process because the code itself is shared among the children processes.
The client portion, spamc from the SpamAssassin installation, is not used. Instead, its function is done by a shared library called libspamass.so, which is part of the Messaging Server. libspamass.so is loaded the same way that the Brightmail SDK is loaded.
From the MTA’s point of view, you can almost transparently switch between SpamAssassin and Brightmail for spam filtering. It’s not completely transparent, because they do not have same functions. For example, Brightmail can also filter for viruses, but SpamAssassin is only used to filter for spam. The result, or verdict, returned by the two software packages are also different. SpamAssassin provides a score, while Brightmail provides just the verdict name, so the configuration would also have some differences.
When using SpamAssassin with the MTA, only a score and verdict is returned from SpamAssassin. The message itself is not modified. That is, options such as adding headers and modifying subject lines must be done by Sieve scripts. In addition, the mode option allows you to specify the string that is returned to indicate the verdict. The string choices are null, default, SpamAssassin result string, or a verdict string. See Table 14-4 for details.
SpamAssassin Requirements and Usage Considerations
- SpamAssassin is free. Go to http://www.spamassassin.org for software and documentation.
- SpamAssassin can be tuned and configured to provide very accurate detection of spam. The tuning is up to you and the SpamAssassin community. Messaging Server does not provide or enhance what SpamAssassin can do.
- While no specific numbers are available, SpamAssassin seems to reduce throughput more than Brightmail.
- SpamAssassin integrated with the MTA can be enabled for a user, a domain, or a channel.
- SpamAssassin can be configured to use other online databases such as Vipul Razor or Distributed checksum clearinghouse (DCC).
- Messaging Server does not supply an Secure Socket Layer (SSL) version of libspamass.so, however, it is possible to build SpamAssassin to use openSSL.
- Perl 5.6 or later is required.
Where Should You Run SpamAssassin?
SpamAssassin can run on a separate system of its own, on the same system as the Messaging Server in a single system deployment, or on the same system as the MTA in a two-tier deployment. If Local Mail Transfer Protocol (LMTP) is used between the MTA and the message store, the filtering must be invoked from the MTA. It cannot be invoked from the message store. When SMTP is used between the MTA and the message store, it can be invoked from either one, and it can run on either system or a separate third system.
If you want to use a farm of servers running SpamAssassin, you would have to use a load balancer in front of them. The MTA is configured with only one address for the SpamAssassin server.
Deploying SpamAssassin
Perform the following steps to deploy SpamAssassin:
- Install and configure SpamAssassin. Refer to the SpamAssassin software documentation for installation and configuration information. See also SpamAssassin Options.
- Load and configure the SpamAssassin client library. This involves specifying the client library, libspamass.so, and configuration file to the MTA (you must create this file). See Loading and Configuring the Spam Filtering Software Client Library.
- Specify what messages to filter for spam. Messages can be filtered by user, domain, or channel. See Specifying the Messages to Be Filtered
- Specify what actions to take on spam messages. Spam can be discarded, filed into a folder, tagged on the subject line, and so on. See Specifying Actions to Perform on Spam Messages.
- Set miscellaneous filter configuration parameters as desired. See MTA Spam Filter Options (option.dat).
SpamAssassin Configuration Examples
This section describes some common SpamAssassin configuration examples:
- To Add the SpamAssassin Result String to the Subject Line
Note
These examples use a number of options and keywords. Refer to "MTA Channel Keywords for Spam Filters" on page 449 and "MTA Spam Filter Options (option.dat)" on page 452 for details.
To File Spam to a Separate Folder
This example tests messages arriving at the local message store and files spam into a folder called spam. The first three steps can be done in any order.
- Create the SpamAssassin configuration file.
The name and location of this file is specified in Step 2. A good name is spamassassin.opt. This file contains the following lines:
host and port specify the name of the system where spamd is running and the port on which spamd listens for incoming requests. mode=0 specifies that a string, specified by verdict, is returned if the message is perceived as spam. debug=1 turns on debugging in the SpamAssassin library. See Table 14-4 for a description of the SpamAssassin configuration parameters.
- Add the following lines to the option.dat file:
spamfilter1_config_files specifies the SpamAssassin configuration file.
spamfilter1_library specifies the SpamAssassin shared library.
spamfilter1_optional=1 specifies that the MTA continue operation if there is a failure by spamd.
spamfilter1_string_action specifies the Sieve action to take for a spam messages.
In this example, spamfilter1_string_action is not necessary because the default value already is data:,require "fileinto"; fileinto "$U;. This line specifies that spam messages are sent to a folder. The name of the folder is the spam verdict value returned by SpamAssassin. The value returned by SpamAssassin is specified by the verdict option in spamassassin.opt. (See Step 1.) In this case, the folder name is spam.
- Specify the messages to be filtered.
To filter all messages coming into the local message store, change the imta.cnf file by adding the destinationspamfilterXoptin spam keywords on the ims-ms channel:
!
! ims-ms
ims-ms defragment subdirs 20 notices 1 7 14 21 28 backoff "pt5m" "pt10m" "pt30m" "pt1h" "pt2h" "pt4h" maxjobs 4 pool IMS_POOL fileinto
$U+$S@$D destinationspamfilter1optin spam
ims-ms-daemon- Recompile the configuration and restart the server. Only the MTA needs to be restarted. You do not need to execute stop-msg.
# imsimta cnbuild
# imsimta restart- Start the spamd daemon. This is normally done with a command of the form:
spamd -d
spamd defaults to only accepting connections from the local system. If SpamAssassin and Messaging Server are running on different systems, this syntax is required:
spamd -d -i listen_ip_address -A allowed_hosts
where listen_ip_address is the address on which to listen and allowed_hosts is a list of authorized hosts or networks (using IP addresses) which can connect to this spamd instance.
To Add a Header Containing SpamAssassin Score to Spam Messages
This example adds the header Spam-test: result string to messages determined to be spam by SpamAssassin. An example header might be:
Spam-test: True ; 7.3 / 5.0
where Spam-test: is a literal and everything after that is the result string. True means that it is spam (false would be not spam). 7.3 is the SpamAssassin score. 5.0 is the threshold. This result is useful for setting up a Sieve filter that can file or discard mail above or between a certain score.
In addition, setting USE_CHECK to 0 returns the list of SpamAssassin tests that matched along with the verdict string. See USE_CHECK in Table 14-4.
- Specify the messages to be filtered. This is described in Step 3 in To File Spam to a Separate Folder.
- Create the SpamAssassin configuration file.
The name and location of this file is specified with spamfilter_configX_file (sse next step). It consists of the following lines:
host and port specify the name of the system where spamd is running and the port on which spamd listens for incoming requests. mode=1 specifies that the SpamAssassin result string is returned if the message is found to be spam. field= specifies a string prefix for the SpamAssasin result string. In this example, a prefix is not desired because we are specifying it in the Sieve script. debug=1 turns on debugging in the SpamAssassin library.
- Add the following lines to the option.dat file:
As in previous examples, the first three options specify the SpamAssassin configuration file, shared library, and to continue MTA operation if there is a failure by the shared library. The following line:
spamfilter1_string_action=data:,require ["addheader"];addheader "Spam-test: $U";
specifies that a header is added to spam messages. The header has the literal prefix Spam-text: followed by the string returned by SpamAssassin. Because mode=1 was specified in Step 2, the SpamAssassin result string is returned. For example: True; 7.3/5.0
- Recompile the configuration, restart the server and start the spamd daemon.
To Add the SpamAssassin Result String to the Subject Line
By adding the SpamAssassin result string to the Subject line, users can determine whether they wish to read a message with a SpamAssassin score. For example:
Subject: [SPAM True ; 99.3 / 5.0] Free Money At Home with Prescription Xanirex!
Note that setting USE_CHECK to 0 returns the list of SpamAssassin tests that matched along with the verdict string (see USE_CHECK in Table 14-4). This list can be very long, so it is best to set USE_CHECK to 1.
- Specify the messages to be filtered. See Step 3 in "To File Spam to a Separate Folder" on page 463.
- Create the SpamAssassin configuration file.
This step is described in To File Spam to a Separate Folder. mode=1 specifies that the SpamAssassin result string is returned if the message is found to be spam.
host and port specify the name of the system where spamd is running and the port on which spamd listens for incoming requests. mode=1 specifies that the SpamAssassin result string is returned if the message is spam. debug=1 turns on debugging in the SpamAssassin library.
- Add the following lines to the option.dat file:
As in previous examples, the first three options specify the SpamAssassin configuration file, shared library, and to continue MTA operation if there is a failure by the shared library. The following line
spamfilter1_string_action=data:,addtag “[SPAM detected $U]”;
specifies that a tag be added to the Subject: line. It has the literal prefix SPAM detected followed by the field string (default: Spam-Test) followed by “[result string]” returned by SpamAssassin. Because mode=1 was specified in Step 2, the SpamAssassin result string is returned. Thus, a subject line looks something like this:
Subject: [SPAM detected Spam-Test: True ; 11.3 / 5.0] Make Money!
You can also use addheader and addtag together:
spamfilter1_string_action=data:,require ["addheader"];addtag "[SPAM detected $U]";addheader "Spamscore: $U";
to get a message like this:
Subject: [SPAM detected Spam-Test: True ; 12.3 / 5.0] Vigaro Now!
Spamscore: Spam-Test: True ; 12.3 / 5.0Set field= in spamassassin.opt to remove the default value of Spam-Test. A cleaner message is returned:
Subject: [SPAM True ; 91.3 / 5.0] Vigaro Now!
Spamscore: True ; 91.3 / 5.0- Recompile the configuration, restart the server and start the spamd daemon.
Testing SpamAssassin
To test SpamAssassin, first set debug=1 in the spamassassion.opt file. You do not have to turn on the channel-specific master_debug or slave_debug in the imta.cnf. Then send a test message to a test user. The msg_svr_base/data/tcp_local_slave.log* file should have lines similar to these:
15:15:45.44: SpamAssassin callout debugging enabled; config /opt/SUNWmsgsr/config/spamassassin.opt
15:15:45.44: IP address 127.0.0.1 specified
15:15:45.44: Port 2000 selected
15:15:45.44: Mode 0 selected
15:15:45.44: Field "Spam-Test: " selected
15:15:45.44: Verdict "spam" selected
15:15:45.44: Using CHECK rather than SYMBOLS
15:15:45.44: Initializing SpamAssassin message context
...
15:15:51.42: Creating socket to connect to SpamAssassin
15:15:51.42: Binding SpamAssassin socket
15:15:51.42: Connecting to SpamAssassin
15:15:51.42: Sending SpamAssassin announcement
15:15:51.42: Sending SpamAssassin the message
15:15:51.42: Performing SpamAssassin half close
15:15:51.42: Reading SpamAssassin status
15:15:51.67: Status line: SPAMD/1.1 0 EX_OK
15:15:51.67: Reading SpamAssassin result
15:15:51.67: Result line: Spam: False ; 1.3 / 5.0
15:15:51.67: Verdict line: Spam-Test: False ; 1.3 / 5.0
15:15:51.67: Closing connection to SpamAssassin
15:15:51.73: Freeing SpamAssassin message context
If your log file does not contain lines similar to these, or if spamd is not running, the following error message is returned in your SMTP dialog after the last period (.) is sent to the SMTP server.
452 4.4.5 Error writing message temporaries - Temporary scan failure: End message status = -1
In addition, if spamfilter1_optional=1 (highly recommended) is set in option.dat, the message is accepted, but not filtered. It is as if spam filtering was not enabled, and the following lines appear in tcp_local_slave.log*:
15:35:15.69: Creating socket to connect to SpamAssassin
15:35:15.69: Binding SpamAssassin socket
15:35:15.69: Connecting to SpamAssassin
15:35:15.69: Error connecting socket: Connection refused
15:35:15.72: Freeing SpamAssassin message context
The call to SpamAssassin happens after the SMTP server received the entire message (that is, after the last “.” is sent to the SMTP server), but before the SMTP server acknowledges to the sender that it accepted the message.
Another test is to send a sample spam message using sample-spam.txt from, for example, the Mail-SpamAssassin-2.60 directory. This message has the following special text string in it:
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X
The corresponding tcp_local_slave.log* contains something like this:
16:00:08.15: Creating socket to connect to SpamAssassin
16:00:08.15: Binding SpamAssassin socket
16:00:08.15: Connecting to SpamAssassin
16:00:08.15: Sending SpamAssassin announcement
16:00:08.15: Sending SpamAssassin the message
16:00:08.15: Performing SpamAssassin half close
16:00:08.15: Reading SpamAssassin status
16:00:08.43: Status line: SPAMD/1.1 0 EX_OK
16:00:08.43: Reading SpamAssassin result
16:00:08.43: Result line: Spam: True ; 1002.9 / 5.0
16:00:08.43: Verdict line: Spam-Test: True ; 1002.9 / 5.0
16:00:08.43: Closing connection to SpamAssassin
16:00:08.43: Mode 0 verdict of spam
16:00:08.43: Mode 0 verdict of spam
16:00:08.47: Freeing SpamAssassin message context
A corresponding entry in the mail.log_current file would look as follows. Note the +spam part of the destination address, which means the message is filed in the folder called spam:
15-Dec-2003 15:32:17.44 tcp_intranet ims-ms E 1 morchia@siroe.com rfc822;morchia
morchia+spam@ims-ms-daemon
15-Dec-2003 15:32:18.53 ims-ms D 1 morchia@siroe.com rfc822;morchia morchia+spam@ims-ms-daemon
SpamAssassin Options
This section contains the SpamAssassin option table.
Table 14-4 SpamAssassin Options (spamassassin.opt)
Options
Description
Default
debug
Specifies whether to turn on debugging in the libspamass.so. Debugging of spamd itself is controlled by the command line invoking spamd. Set to 0 or 1.
0
field
Specifies the string prefix for the SpamAssasin result. SpamAssassin results look like this:
Spam-Test: False ; 0.0 / 5.0
Spam-Test: True ; 27.7 / 5.0The field option provides the means for changing the Spam-Test: part of the result. Note that the “: “ is removed if an empty field value is specified.
If USE_CHECK is set to 0, the result string will look similar to this:
Spam-test: False ; 0.3 / 4.5 ; HTML_MESSAGE,NO_REAL_NAME
Spam-test: True ; 8.8 / 4.5 ; NIGERIAN_BODY, NO_REAL_NAME,PLING_PLING,RCVD_IN_SBL,SUBJ_ALL_CAPS
“Spam-test”
host
The name of the system where spamd is running.
localhost
mode
Controls the translation of SpamAssassin filter results to verdict information.That is, it specifies what verdict information is returned after a message is processed. Four modes are available. See The SpamAssassin mode Option for further explanation.
0 - Return a verdict string (specified by the verdict option), if the message is spam. The MTA option spamfilterX_string_action can be used to specify what to do if a verdict string is returned. If the verdict option (defined below) is empty or unspecified, and message is spam, a null verdict is returned. The MTA option spamfilterX_null_action can be used to specify what to do if a null verdict is returned.
Returns a SpamAssassin default result string if it is not spam. (A default verdict always means to take no action and deliver as normal.)
1 - Returns the SpamAssassin result string if the message is found to be spam. Returns a SpamAssassin default result string if it is not spam. (Again, a default verdict always means to take no action and deliver as normal.) A SpamAssassin result string looks something like this: True; 6.5 / 7.3
2 - Same as mode 1 except that the SpamAssassin result string is returned regardless of whether the message is spam or not spam. No default or null verdict is ever returned and the verdict option is never used.
3 - Return the SpamAssassin result string if the message is found to be spam; return the verdict string specified by the verdict option if it is not. You can control the action for the SpamAssassin result string by using the spamfilterX_verdict_n and spamfilterX_action_n matched pair. You can control the action for the verdict string by using spamfilterX_string_action.
0
port
Specifies the port number where spamd listens for incoming requests.
783
USE_CHECK
1 - The spamd CHECK command is used to return the SpamAssassin score.
0 - Enables use of the SYMBOLS command which returns a score and a list of the SpamAssassin tests that matched. The system may hang or have other problems with this option in pre-2.55 versions of SpamAssassin. See field above.
SOCKS_HOST
String. Specifies the name of an intermediate SOCKS server. If this option is specified the ICAP connection is made through the specified SOCKS server and not directly.
""
SOCKS_PORT
Specifies the port that the intermediate SOCKS server is running on.
1080
SOCKS_PASSWORD
Specifies a password (string) use in establishing the connection through the SOCKS server. Whether a username/password is required depends on the SOCKS server configuration.
""
SOCKS_USERNAME
Specifies a username (string) to use in establishing the connection through the SOCKS server.
""
verdict
Specifies the verdict string used for MODE 0.
“”
The SpamAssassin mode Option
After processing a message, SpamAssassin determines whether a message is spam or not. mode allows you to specify the string that is returned to indicate the verdict. The string choices are null, default, SpamAssassin result string, or a verdict string specified with the verdict option. (Note that default is neither null, the SpamAssassin result string, nor the string specified by verdict, but some other non-configurable result string.) The mode operations are outlined in the table below.
Table 14-5 Returned String for the SpamAssassin mode Option
verdict Setting
Spam?
mode=0
mode=1
mode=2
mode=3
verdict="" (not set)
yes
null
SpamAssassin result
SpamAssassin result
SpamAssassin result
no
default
default
SpamAssassin result
default
verdict=string
yes
verdict string
SpamAssassin result
SpamAssassin result
SpamAssassin result
no
default
default
SpamAssassin result
verdict string
The first column indicates whether the verdict option is set or not set. The second column indicates whether the message is spam or not. The mode columns indicate the string returned for the various modes. For example, if verdict is not set and mode is set to 0 and a message is not spam, a default string is returned. If the verdict is set to YO SPAM! and mode is set to 0 and a message is spam, the string YO SPAM! is returned.
Using Symantec Anti-Virus Scanning Engine (SAVSE)In addition to describing how to deploy SAVSE this section can also be useful in deploying other ICAP-supported anti-spam/anti-virus programs. This section consists of the following subsections:
SAVSE Overview
SAVSE is a TCP/IP server application and communication Application Programming Interface (API) that provides virus scanning services. Designed specifically to protect traffic served through, or stored on, network infrastructure devices, it detects and protects against viruses, worms, and Trojan horses in all major file types, including mobile code and compressed file formats. Refer to the Symantec website for detailed information
Note
Messaging Server only supports the SAVSE scan function. It does not support the repair or delete functions.
SAVSE Requirements and Usage Considerations
This is a separately licensed product from Symantec.
Only the scan mode is supported, not the scan and repair or scan and delete mode in the SAVSE configuration.
Where Should You Run SAVSE?
SAVSE or another server that supports ICAP can run on a separate system of its own, on the same system as the Messaging Server in a single system deployment, or in a two-tier deployment on the same system as the MTA. If Local Mail Transfer Protocol (LMTP) is used between the MTA and the message store, the filtering must be invoked from the MTA. It cannot be invoked from the message store. When SMTP is used between the MTA and the message store, it can be invoked from either one, and it can run on either system or a separate third system.
If you want to use a farm of servers running SAVSE, you would have to use a load balancer in front of them. The MTA is configured with only one address for the SpamAssassin server.
Deploying SAVSE
Perform the following steps to deploy SAVSE.
- Install and configure the SAVSE. Refer to the Symantec software documentation for installation and configuration information. See also SAVSE Options.
- Load and configure the SAVSE client library. This involves specifying the client library libicap.so and configuration file to the MTA (you must to create this file). See Loading and Configuring the Spam Filtering Software Client Library.
- Specify what messages to filter for viruses. Messages can be filtered by user, domain, or channel. See Specifying the Messages to Be Filtered
- Specify what actions to take on virus messages. Viruses can be discarded, filed into a folder, tagged on the subject line, and so on. See Specifying Actions to Perform on Spam Messages.
- Set miscellaneous filter configuration parameters as desired. See MTA Spam Filter Options (option.dat).
SAVSE Configuration Example
The following example tests messages arriving at the local message store and discards messages with attached viruses. The first three steps can be done in any order.
- Create the SAVSE configuration file.
The name and location of this file is specified in Step 2. The name used here is SAVSE.opt. An example of this file is shown below:
host and port specify the name of the system where the SAVSE program is running and the port (1344 is the default for SAVSE) on which it listens for incoming requests. mode=0 specifies that a string, specified by verdict (in this case the word virus), will be returned if the message is perceived to contain a virus. debug=1 turns on debugging. See Table 14-6 for a description of the ICAP configuration parameters.
- Create an option.dat file. Example:
spamfilter1_config_files specifies the SAVSE configuration file.
spamfilter1_library specifies the location of the SAVSE shared library.
spamfilter1_optional=1 specifies that the MTA continue operation if there is a failure by the SAVSE program.
spamfilter1_string_action specifies the Sieve action to take for a spam messages. This value specifies that messages with viruses are discarded. Since this is the default value, you don’t have to specify it unless you are changing the value.
- Specify the messages to be filtered.
To filter all messages coming into the local message store, change the imta.cnf file by adding the destinationspamfilter1optin spam keywords on the ims-ms channel:
!
! ims-ms
ims-ms defragment subdirs 20 notices 1 7 14 21 28 backoff "pt5m" "pt10m" "pt30m" "pt1h" "pt2h" "pt4h" maxjobs 4 pool IMS_POOL fileinto
$U+$S@$D destinationspamfilter1optin virus
ims-ms-daemon- Recompile the configuration and restart the server. Only the MTA needs to be restarted. You do not need to execute stop-msg.
# imsimta cnbuild
# imsimta restart- Make sure SAVSE is started.
It should have started automatically, but if not, the start command might looks something like this: /etc/init.d/symcscna start
Other Possible Configurations
Setting mode to 0 can be used with a spamfilterX_null_option to take some other action, such as filing messages in a particular folder when they are determined to be spam. For example:
spamfilter1_null_option=data:,require "fileinto"; fileinto "VIRUS";
Note that filing infected messages into a folder is not a good idea in most cases.
Setting mode to 1 can be used to start an action. For example, the spam result could be included in the reject message by setting mode to 1 and the spamfilterX_string_action option in the MTA to something like:
spamfilter1_string_action=data:,require "reject"; reject "Message contained a virus [$U]";
Like fileinto, using the reject action to deal with viruses is rarely a good idea because it sends the virus back to the sender.
You could also add a tag to the spam message header by adding a line to the option.dat file. Example:
spamfilter1_string_action=data:,addtag “[SPAM detected!]”;
Setting mode to 2 can be used where an action needs to be taken regardless of whether or not the message was determined to contain a virus. The addition of a header field that can subsequently be tested is an obvious application for mode 2:
spamfilterX_string_action=data:,require ["addheader"];addheader "$U"
SAVSE Options
The SAVSE option file is really a more generic ICAP option file. Its name and location is set by spamfilterX_config_file in option.dat. It consists of lines of the form option=value. The one required option is HOST. It must be set to the name of system where the ICAP filtering server is running. This option must be set even if the ICAP server is running on the local host. The option file is shown below.
Table 14-6 ICAP Options
Options
Description
Default
debug
Enables or disables debug output from the ICAP interface module. 0 or 1.
0
field
Specifies the prefix for the ICAP result. SAVSE result strings look like this:
Virus-Test: False
Virus-Test: True; W32.Mydoom.A@mm.encThis option provides a way to change the Virus-Test: part of the result. Note that the “: “ is removed if an empty field value is specified.
Virus-test
host
The name of the system where the ICAP filtering server is running
localhost
mode
Controls the translation of ICAP filter results to verdict information.That is, it specifies the string information returned after a message is processed. Four modes are available. See The ICAP mode Option for further explanation
0 - Returns a verdict string (specified by the verdict option), if the message contains a virus. The MTA option spamfilterX_string_action can be used to specify what to do if a verdict string is returned. If the verdict option is empty or not set, a null verdict is returned. The MTA option spamfilterX_null_action can be used to specify what to do if a null verdict is returned and if you want to override the default action, which is to discard the message.
If the message does not contain a virus, a default string is returned. A default string is unconfigurable and always means to take no action and deliver as normal.
1 - Return the ICAP result string if the message is found to contain a virus. If the message does not contain a virus, a default string is returned. A default string always means to take no action and deliver as normal. Below are two examples of a ICAP result string:
VIRUS TEST: FALSE
VIRUS-TEST: TRUE; W32.Mydoom.A@mm.enc2 - Return an ICAP result string unconditionally; no default or null verdict is ever returned and the verdict option is never used. This setting is intended for cases in which an action needs to be taken regardless of whether or not the message was determined to contain a virus. The addition of a header field that can subsequently be tested is an obvious application for mode 2:
spamfilterX_string_action=data:,require ["addheader"];addheader "$U"
3 - Return the ICAP result string if the message is found to contain a virus; return the verdict string specified by the verdict option if it does not. This setting is intended for cases in which one action needs to be taken if a virus is found and another taken if one is not. You can control the action for the ICAP result string by using the spamfilterX_verdict_n and spamfilterX_action_n matched pair. You can control the action for the verdict string by using spamfilterX_string_action.
0
port
Specifies the port number on which the ICAP server is running.
1344
SOCKS_HOST
String. Specifies the name of an intermediate SOCKS server. If this option is specified, the ICAP connection is made through the specified SOCKS server and not directly.
""
SOCKS_PORT
Integer. Specifies the port on which the intermediate SOCKS server is running.
1080
SOCKS_PASSWORD
String. Specifies a password to use in establishing the connection through the SOCKS server. Whether or not a username/password is required depends on the SOCKS server configuration.
""
SOCKS_USERNAME
String. Specifies a username to use in establishing the connection through the SOCKS server.
""
verdict
Specifies the verdict string used for MODE 0 and 3.
""
The ICAP mode Option
After processing a message, ICAP anti-virus programs like SASVE determines whether a message has a virus or not. mode allows you to specify the string returned by the ICAP program indicating this verdict. The string choices are null, default, ICAP result string, or a verdict string (specified with the verdict option). Note that default is not null, the ICAP result string, nor the string specified by verdict, but some other non-configurable string returned by the program. The mode operations are outlined in the table below.
Table 14-7 Returned Verdict String for the ICAP mode Option
verdict Setting
Virus?
mode=0
mode=1
mode=2
mode=3
verdict="" (not set)
yes
null
ICAP result
ICAP result
ICAP result
no
default
default
ICAP result
default
verdict=string
yes
verdict string
ICAP result
ICAP result
ICAP result
no
default
default
ICAP result
verdict string
The first column indicates whether the verdict option is set or not set. The second column indicates whether the message contains a virus or not. The mode columns indicate the string returned for the various modes. For example, if verdict is not set and mode is set to 0 and a message does not have a virus, the ICAP program returns a default. If the verdict is set to WARNING VIRUS! and mode is set to 0 and a message does have a virus, the ICAP program returns the string WARNING VIRUS!
Support for Sieve ExtensionsIn addition to the standard Sieve functions, Messaging Server provides support for a number extensions including addheader, addtag, spamtest and spamadjust. addheader and addtag are described in To Add a Header Containing SpamAssassin Score to Spam Messages), and To Add the SpamAssassin Result String to the Subject Line. spamtest and spamadjust are describe here
These extensions gives administrators the ability to set different threshold values as well as the ability to set up white lists that override SpamAssassin verdicts. The two can even be combined to have different thresholds depending on who sent a particular message. spamadjust is a non-standard action. spamtest is described in ftp://ftp.isi.edu/in-notes/rfc3685.txt.
spamtest can be used to compare SpamAssassin scores to specific values using the Sieve [RELATIONAL] extension with the "i;ascii-numeric" comparator. The SpamAssassin score is typically a real number, but spamtest forces the score into an integer value between 0 an 10 by first rounding the score to the nearest integer. Values below 0 are forced up to 0 while values above 10 are forced down to 10. Finally, the text string maintained by Messaging Server is appended to produce the test string that the spamtest test sees.
spamadjust is used to adjust the current spam score. This action takes a single string argument which is scanned for a real numeric value. This value is used to adjust the current spam score. The entire string is also appended to the current score text string. In the example shown below, the string would be “undisclosed recipients.”
Multiple spamadjust actions are allowed; each one is added to the current score. Again, the score value always starts at 0. Signed numeric values are allowed, making it possible to lower the current score as well as raise it. There is no require clause for spamadjust; the spamtest extension should be listed instead.
For example, a possible use of spamadjust with a SpamAssassin MODE setting of 2 might be:
spamfilterX_string_action=data:,require ["spamtest"];spamadjust "$U";
A system-level Sieve filter could then modify the SpamAssassin score by checking for a particular type of header and, if found, adding 5 to the SpamAssassin score:
spamfilter1_string_action=require "spamtest"; \
if header :contains ["to", "cc", "bcc", "resent-to", "resent-cc", "resent-bcc"] \
["<undisclosed recipients>", "undisclosed.recipients"] \
{spamadjust "+5 undisclosed recipients";}
Finally, a user-level Sieve script could test the resulting value, discard messages certain to be spam, file messages likely to be spam, and allow messages from addresses in the local domain to pass through:
spamfilter1_string_action=require ["spamtest", "relational", \
"comparator-i;ascii-numeric", "fileinto"]; \
if anyof (address :matches "from" ["*@siroe.com", \
"*@*.siroe.com"]) \
{keep;} \
elsif spamtest :value "ge" :comparator "i;ascii-numeric" "8" \
{discard;} \
elsif spamtest :value "ge" :comparator "i;ascii-numeric" "5" \
{fileinfo "spam-likely";} \
else \
{keep;}
