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 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
The current version of Messaging Server only supports the SAVSE scan function. It does not support the repair or delete functions.
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.
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.
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 Table 14–2Specifying Actions to Perform on Spam Messages
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 the next step. The name used here is SAVSE.opt. An example of this file is shown below:
host=127.0.0.1 port=1344 mode=0 verdict=virus debug=1 |
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 SAVSE Options for a description of the ICAP configuration parameters.
Create an option.dat file. Example:
! for Symantex Anti-virus Scan Engine spamfilter1_config_file=/opt/SUNWmsgsr/config/SAVSE.opt spamfilter1_library=/opt/SUNWmsgsr/lib/libicap.so spamfilter1_optional=1 spamfilter1_string_action=data:,discard |
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
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"
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 |
---|---|---|
Enables or disables debug output from the ICAP interface module. 0 or 1. |
0 |
|
Specifies the prefix for the ICAP result. SAVSE result strings look like this: Virus-Test: False Virus-Test: True; W32.Mydoom.A@mm.enc This 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 |
|
The name of the system where the ICAP filtering server is running |
localhost |
|
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: FALSEVIRUS-TEST: TRUE; W32.Mydoom.A@mm.enc 2 - 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 |
|
Specifies the port number on which the ICAP server is running. |
1344 |
|
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. |
"" |
|
Integer. Specifies the port on which the intermediate SOCKS server is running. |
1080 |
|
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. |
"" |
|
String. Specifies a username to use in establishing the connection through the SOCKS server. |
"" |
|
Specifies the verdict string used for MODE 0 and 3. |
"" |
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!