Installation

Installation & Administration Guide

Cloudmark Immunity Installation and Administration Guide

Copyright © 2003-2004, Cloudmark, Inc.All rights reserved.

Cloudmark Immunity Version 1.0

This document may not, in whole or in part, be copied, photocopied, reproduced, trans-lated or reduced to any electronic medium or machine readable form without prior con-sent in writing from:

Cloudmark, Inc.128 King Street, Second FloorSan Francisco, CA 94107

ALL EXAMPLES WITH NAMES, COMPANY NAMES OR COMPANIES THAT APPEAR IN THIS GUIDE ARE FICTITIOUS AND DO NOT REFER TO, OR PORTRAY, IN NAME OR SUB-STANCE, ANY ACTUAL NAMES, ORGANIZATIONS, ENTITIES OR INSTITUTIONS. ANY RESEMBLANCE TO ANY REAL PERSON, ORGANIZATION, ENTITY OR INSTITUTION IS PURELY COINCIDENTAL.

While every effort has been made to ensure technical accuracy, information in this doc-ument is subject to change without notice and does not represent a commitment on the part of Cloudmark, Inc. Cloudmark makes no warranties with respect to this documen-tation and disclaims any implied warranties of merchantability and fitness for a partic-ular purpose. Cloudmark shall be liable for any errors or for incidental or consequential damages in connection with the furnishing, performance or use of this manual or examples herein.

Copyright i


ii
Copyright

CO

NTE

NTS

Contents

Chapter 1 1 Introduction1 Required knowledge2 Notational conventions2 Typographical conventions2 Support resources

Chapter 2 3 Immunity Functional Overview3 Spam defined3 How Immunity identifies spam4 Handling spam with Immunity4 Running Immunity on Linux with sendmail

4 Immunity in distributed environments5 Ensuring proper detection5 Interoperability

Chapter 3 7 Installing Immunity7 Installing sendmail

7 Building sendmail from the source8 Configuring the new sendmail installation9 Creating the sendmail-required databases10 Verifying installation of procmail11 Testing the new sendmail installation

11 Configuring or upgrading sendmail12 Installing the Immunity software

13 Upgrading Immunity from a previous version13 Setting up the database

14 Running the database setup script with SQLite14 Creating a user in MySQL for Immunity14 Creating the Immunity database in MySQL

Chapter 4 17 Configuring Immunity17 Configuration settings

18 Automatic spam filtering and user validation19 Detained messages reports20 Administration Dashboard access settings21 Statistics calculation variables

iii


iv

22 Database connection properties22 Immunity event logging22 A note about configuration in multiple server environments

22 Starting and stopping Immunity23 Accessing the Administration Dashboard23 Creating policies

25 Determining threshold25 Configuring action attributes27 Editing (or deleting) action policies

27 Whitelisting29 Blacklisting29 Micro-updates settings29 Updating the EGM30 Verifying operation and configuration

30 Checking operational status30 Testing spam classification functionality

Chapter 5 33 Working with Immunity33 Managing detained messages

34 An important note about narrowing search parameters34 Detention Center search results

35 Managing administrative and end-user feedback36 Feedback search results36 Submitting feedback using the cm_add_feedback utility38 Using the nD Visualizer to View Feedback and Classificaton

38 Generating statistical reports39 Managing users

40 Searching for specific users40 Adding new users40 Setting the Detained Messages Report header file

41 End-user interaction with detained messages41 Detained Messages Report41 Detained Messages Folder

Appendix A 43 Linux Library Compatibility43 Required Linux libraries

Appendix B 45 Testing Immunity45 Creating test sets of email

45 Stability testing45 Accuracy testing

Appendix C 47 nD Visualizer47 Message clusters

48 Viewing cluster details48 Highlighting clusters by feedback scope

Contents


48 Highlighting clusters by message traffic48 Highlighting clusters by keywords

49 Viewing message details

51 Index

Contents v


vi
Contents

1

Introduction

The Cloudmark Immunity Installation and Administration Guide shows network administrators how to add spam-filtering functionality to their email infrastructure.This chapter describes the knowledge administrators must possess to use Immu-nity effectively. It also explains the conventions used in the guide, as well as the support options available to Immunity customers.Following is an overview of the remaining chapters:Chapter 2, Immunity Overview, describes how Immunity filters spam and how administrators configure policies to handle it. In addition, it illustrates how Immu-nity is installed in the enterprise, as well as its interoperability with various network components.Chapter 3, Installing Immunity, describes the process of configuring sendmail to work with Immunity, and then provides installation instructions for Immunity on Linux. Following are instructions for configuring a database to work with Immunity.Chapter 4, Configuring Immunity, lists all configurable properties for Immu-nity. Specifically, it shows how to create spam handling policies, update Immunity’s spam-filtering capabilities, take advantage of your MTA’s blacklisting functionality, and use whitelists to bypass spam-filtering from trusted recipients.Chapter 5, Working with Immunity, shows how administrators use Immunity’s web-based interface to provide and manage feedback on misclassified messages and how end-users provide feedback from their desktops. Instructions for manag-ing users of your Immunity-enabled mail server and viewing statistics generated by Immunity and mail server operation are provided, as well.

Required knowledgeAdministrators of Immunity and mail servers in the enterprise should possess a strong working knowledge of the MTA and database software used with Immunity. The MTA used with Immunity is sendmail. Administrators should know how to install sendmail in a networked environment and configure it to send and receive mail. Additional knowledge is required in order to use certain sendmail-specific features that Immunity takes advantage of or compliments with added functional-ity, such as blacklisting.Although Immunity is designed to quickly and easily configure and use a database for spam-filtering operations, installation and basic administration skills for a data-base software package are helpful in optimizing your anti-spam solution. The abil-

1


2

ity to evaluate databases and choose one that is best suited for your environment will help you create an ideal mail server setup.You should be familiar with basic Linux system administration and commonly used Linux command line instructions (such as decompressing packages with tar or building configuration files), as well as working with various Unix-based utilties (such as text editors).

Notational conventionsThere are two notational conventions:NOTE A note highlights or adds information to relevant to the surrounding

topic.

WARNING A warning advises you that failure to take or avoid a specific action could result in failure to complete a task or cause undes-ired results in the use of the software.

Typographical conventionsThe following typographic conventions are used:

• Courier indicates text that is either typed by the user on the command line in Linux or script output to the command line. For example:“To create a user with the appropriate permissions, log on to MySQL and select the mysql database with the use command (use mysql).”In this example, you would only type, “use mysql,” and not the surrounding text.

• Bolded text in the Courier typeface and surrounded by brackets [ ] indicatesinformation that varies depending on any given circumstance. The text describes the information needed. For example:tar -xzvf [sendmail source]

The sendmail source text will vary depending on the version of sendmail you downloaded, as well as the naming method applied to the package. In this case, you would type “tar -xzvf ” and then type the name of the sendmail source package as it appears on your computer; you would not type the text, “[sendmail source].”

Support resourcesSupport for Immunity is found at www.cloudmark.com/support/immunity/.

Chapter 1 Introduction

2
Immunity Functional Overview
This chapter describes how Immunity identifies spam, as well as how administra-tors can configure Immunity to handle it. In addition, it provides an overview of Immunity in a sendmail environment.

Spam definedSpam is generally considered to be unsolicited commercial email sent to a large amount of email addresses which all have nearly identical content. As the adminis-trator of Immunity, your ultimate goal is to halt the flood of spam that is threaten-ing to overwhelm your enterprise, while at the same time allowing all legitimate email to reach its intended recipients.

How Immunity identifies spamImmunity analyzes the underlying structure of incoming email to detect spam by employing nearly 300 advanced algorithms called spamGenes. Each spamGene identifies a single characteristic of a message that, when combined with other char-acteristics, classifies a message as legitimate or spam. Such characteristics may include matching headers and properly formatted mail relay ID numbers for legiti-mate messages or forged headers and character histograms for spam, for example.Cloudmark creates an n-dimensional data structure called an Email Genetic Map (EGM), which contains messages grouped by their genetic similarity (i.e., defined by the spamGenes that apply to the message). Immunity evaluates the similarity of new messages to those in the EGM. New messages are then classified based on their proximity—or genetic similarity—to the existing messages in the EGM.Administrators and end-users can submit feedback on messages that are misclassi-fied. Immunity uses this feedback to tailor spam filtering to the individual prefer-ences of your organization and each employee within it. When an individual user submits feedback, Immunity determines whether the feedback applies to the entire organization or just the individual based on feedback that has been submitted for other messages in the EGM.The EGM continuously evolves by learning from administrator and end-user feed-back within your organization. Additionally, Cloudmark sends out an updated EGM update every 30 to 60 days based on feedback collected by Cloudmark’s community of over 1 million users.Using a web interface provided by Immunity, administrators can correct or remove end-user feedback, as well as change the scope applied to a message, to optimize

3


4

Immunity’s message classification capabilities. Administrators can also view the feedback using the nD Visualizer, a tool that displays a graphical representation of the n-dimensional data structure with genetically similar messages clustered in groups (see Appendix C, nD Visualizer (pg. 47)).

Handling spam with ImmunityWhen Immunity scans a message, it applies a confidence level (as a percentage) to indicate the likelihood that the message is spam. For example, if Immunity assigns a message a confidence level of 99.4, it means Immunity is 99.4% certain the mes-sage is spam; a confidence level of .15% means Immunity is almost certain the message is legitimate.You can configure Immunity to take action on a message based on its confidence level. Such actions include storing spam in a designated spam folder, tagging or deleting it and even sending it back to the original sender. As a result, you must establish policies for handling spam (and suspected spam), which determine the actions taken on a message with any given confidence level, and then add those policies to Immunity’s configuration.

Running Immunity on Linux with sendmailImmunity is a standalone server application that runs on Linux servers with send-mail installed on the gateway MTA.

Figure 2-1 Immunity in a typical Linux sendmail environment

The sendmail MTA that Immunity is installed on (or next to) can be configured to relay messages from a variety of firewalls, border systems, email management tools, anti-virus filters and other SMTP message processors.NOTE Optionally, you can control whether Immunity communicates with any

external sources outside your firewall.Incoming SMTP mail traffic is routed to Immunity using the sendmail Milter inter-face. The sendmail Milter Content Management API is the standard interface for connecting all message filters.

Immunity in distributed environmentsYou can install multiple instances of Immunity, with each sharing a single database and serving a specific role. For example, you can install one Immunity server to provide spam-filtering functionality only and install a second Immunity server ded-icated to administration and other tasks.

Corporate Mail ServersGateway MTAFirewallInternet

MS Exchange, Lotus Notes, sendmail, etc.

sendmail & Immunity

Chapter 2 Immunity Functional Overview


It is recommended in large environments to install separate instances of Immunity for its web-based administration interface, detained messages reports and spam-fil-tering for optimal performance.

Ensuring proper detectionIn order for Immunity to properly classify email messages, the message must be as close to its original form as possible. Since Immunity looks at the structure of spam messages and constantly scans for new gene mutations, changes made to the routing of a message or other properties of the message can affect whether or not Immunity classifies the message as spam or legitimate. For example, forwarding messages or changes to the header of messages may cause messages to look more or less like spam. To avoid this, as well as complex message routing, install Immu-nity on the gateway MTA (or close to as possible).

InteroperabilityImmunity works with any device or process that sends and receives an SMTP mail stream. Immunity’s approach to blocking spam is simple: it receives a stream of SMTP messages from an SMTP source and then passes the filtered stream back to the same source. The sendmail MTA that Immunity is installed with can be config-ured to relay messages from a variety of firewalls, border systems, email manage-ment tools, anti-virus filters and other SMTP message processors.

Interoperabilitywith firewalls

Immunity can be placed either inside an existing firewall (towards the company) or outside (towards the Internet). Although Immunity potentially reduces the load on your firewall, it should not be placed in front of your servers because it does not protect against denial of service and other low-level attacks. For this reason, place Immunity inside your firewall.

Interoperabilitywith email border

managers

Immunity works well with compliance and anti-virus solutions and mail delivery appliances from other vendors. In general, if a device provides border security, place Immunity inside of this border. If the device provides compliance, anti-virus, manageability or throughput services, place Immunity outside of that border ser-vice.

Interoperabilitywith email sys-

tems

Enterprise email servers view Immunity as a typical SMTP mail relay. As a result, Immunity interoperates seamlessly with existing commercial email systems such as Microsoft Exchange, Lotus Domino and Novell GroupWise; however, it does not integrate directly into their proprietary environments, but it is easy to configure Immunity to tag suspected spam with a header or subject field tag that can then be interpreted and manipulated by other email systems. One common integration is to use Immunity to tag suspected spam and then set up a centrally-managed server side rule that automatically moves each user’s suspected spam in a folder desig-nated for spam.

Chapter 2 Immunity Functional Overview 5


6
Chapter 2 Immunity Functional Overview

3
Installing Immunity
Immunity is installed in the following steps:• Install a new sendmail configuration or configure an existing installation of send-

mail to work with Immunity• Install the Immunity software or upgrade existing software• Link to an Immunity-configured database

Installing sendmailThis section provides instructions for building sendmail from the source and con-figuring it to use the Immunity mail filter via the Milter interface.

Building sendmail from the sourceTo build sendmail with the Milter interface, download the latest version from www.sendmail.org and follow the instructions below.To build sendmail with the Milter interface

1 Log on as root and move the downloaded file to the /usr/local/srv directory.2 Untar the sendmail source code using the x, z, v and f switches:

tar -xzvf [sendmail source]3 In the sendmail source tree, create (or append) the m4 build configuration file dev-

tools/Site/site.config.m4 and add the following directive:APPENDDEF(`conf_sendmail_ENVDEF', `-DMILTER')

WARNING Do not use the sample m4 build configuration file; it contains directives and commands that are incompatible with Immunity.

This command instructs the compiler to build sendmail with the Milter interface.4 Enter the following commands to set up (and create, if necessary) the required

sendmail directories:groupadd smmspmount -o rw,remount /usrmkdir -p /usr/man/man1mkdir -p /usr/man/man5mkdir -p /usr/man/man8mkdir -m 755 -p /var/spool/mqueuechown root:mail /var/spool/mqueue

5 Go back to root level of the sendmail source and then build and install sendmail:sh ./Build

7

www.sendmail.org


8

sh ./Build install6 To run sendmail as a set-user-id root program:

sh ./Build install-set-user-id

NOTE When using the Build install-set-user-id command, some targets may not compile; however, this does not necessarily indicate a build fail-ure.

Configuring the new sendmail installationTo use the Immunity mail filter with sendmail, you must add commands to the macro configuration file config.mc and then build a new sendmail configuration file (sendmail.cf).To add the Immunity mail filter to sendmail and other configuration options using the config.mc file

1 In the sendmail source tree, go to the cf/cf directory and locate the generic macro configuration file for your operating system (e.g., generic-linux.mc). Rename the macro configuration file to config.mc.

2 Add the following define statements to the config.mc file (immediately following the OSTYPE command, but before the Domain command):define(`confSERVICE_SWITCH_FILE', `/etc/mail/service.switch')dnldefine(`confHOSTS_FILE', `/etc/hosts')dnldefine(`confTO_IDENT', `0s')dnldefine(`confCW_FILE', `/etc/mail/localhosts')dnldefine(`confCR_FILE', `-o /etc/mail/relays')dnldefine(ÀLIAS_FILE', `/etc/mail/aliases')dnldefine(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail')dnl

3 If your MTA serves a large number of users, it is possible sendmail will create more sendmail processes than can be handled by the available resources. As a result, Immunity may stop running.By default, no limit is placed on the number of queues that can be simultaneously run. To limit the number of sendmail child processes that are processing queues, add the following define statement:define(`confMAX_QUEUE_CHILDREN',`[number]')

You must supply the number of concurrent processes your system resources can support, which varies from system to system; Cloudmark testing suggests that 50 child processes are reasonable for some systems.

4 Add the following Feature commands after the define commands you added in the previous two steps:FEATURE(`local_procmail')dnlFEATURE(`redirect')dnlFEATURE(ùse_cw_file')dnlFEATURE(`no_default_msa',`dnl')dnlFEATURE(`nocanonify')dnlFEATURE(àccept_unresolvable_domains')dnl

Chapter 3 Installing Immunity


FEATURE(`relay_entire_domain')dnlFEATURE(`smrsh',`/usr/sbin/smrsh')dnlFEATURE(àccess_db', `hash -T<TMPF> /etc/mail/access')dnlFEATURE(`virtusertable', `hash /etc/mail/virtuals')dnl

5 If sendmail will relay messages on a per-domain basis, add this Feature command:FEATURE(`mailertable', `hash /etc/mail/mailers')dnl

See Creating the sendmail-required databases, page 9 for further instructions on the mailertable feature.

6 After the Feature commands—but before the mailer commands—add the follow-ing InputMailFilter command:INPUT_MAIL_FILTER(ìmmunity', `S=local:/var/run/smf.immunity')dnl

This option adds the Immunity mail filter to sendmail.NOTE Immunity does not use the ordering flags in the INPUT_MAIL_FILTER

macro. To define the order in which the Immunity mail filter loads, add Immunity to the confINPUT_MAIL_FILTERS macro (if used).

7 While still in the cf/cf directory of the sendmail source, build the sendmail config-uration file:sh ./Build config.cf

8 Delete the old sendmail configuration files from /etc/mail and then copy the new ones to it:rm /etc/mail/*cp config.cf /etc/mail/sendmail.cfcp config.mc /etc/mail/sendmail.mc

NOTE Evaluate the impact of the commands added to the config.mc file to determine whether they are appropriate for your environment.

Configuringsendmail without

DNS service

If your server will run without DNS service, you must make additional changes to three configuration files.To make the necessary changes to the configuration files

1 Create a file named service.switch in the /etc/mail directory.2 Add these lines to the service.switch file:

hosts: filesaliases: files

3 Add these lines to /etc/mail/localhosts:localhost[server external IP address]

4 To apply your changes to the localhosts file, restart sendmail.5 Comment out all lines in the /etc/resolv.conf file.

Creating the sendmail-required databasesThe last step to installing sendmail is creating the required databases, which include:

Chapter 3 Installing Immunity 9


10

• the access database, which stores rules to accept, reject and discard messages based on sender name, address or IP number;

• the virtusertable database, which maps virtual domains into new addresses;• the aliases database, used to redirect mail addressed to one recipient to another.

To create the sendmail-required databases

1 Create the virtuals, access, relays and localhosts files using touch:touch virtuals access relays localhosts

2 Convert the access and virtusertable source files into databases using makemap:makemap hash access.db <accessmakemap hash virtuals.db <virtuals

3 Create the file /etc/mail/aliases and add the following line:postmaster:root

This alias entry routes all incoming mail addressed to postmaster to root.4 Update the sendmail aliases database:

newaliases5 If domain-based relaying is enabled, create a file called mailers—which is the mai-

lertable file specified in config.mc—in the /etc/mail directory. For each domain, add a line to the file in the following format:[domain] esmtp:[IP Address]

NOTE If DNS service is unavailable, enclose the IP address in brackets ([ ]) to prevent sendmail from attempting to use the DNS server.

Then, use touch on the mailers file and convert it to a database:touch mailersmakemap hash mailers < mailers

Simplifyingsendmail

compilation

If make is installed, you can simplify sendmail re-compilation when sendmail con-figuration files have changed with a Makefile.Create a new file named Makefile in the /etc/mail directory and then add these lines to it:all: aliases.db access.db virtuals.db mailers.dbaliases.db: aliases @newaliases%.db: % @makemap hash $@ < $< && echo $<virtuals.db: virtualsaccess.db: accessmailers.db: mailers

WARNING You must add two tab characters to the beginning of the indented lines shown above or the Makefile will not work.

Verifying installation of procmailprocmail, the default local delivery agent (LDA), is typically included in most oper-ating systems; however, you can verify that procmail is installed using the following command line statement:



ls -l /usr/bin/procmailIf procmail is not installed, download it using the wget command from ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS/procmail-3.21-1.i386.rpm. Also, if procmail is not in the /usr/bin/ folder, use the which com-mand to discover its location.

Testing the new sendmail installationTo test the new sendmail installation, start sendmail (/usr/sbin/sendmail -bd) and send a test message locally:telnet localhost 25helo foomail from: [email address]rcpt to: [email address]datasubject: testThis is a test message. (a period on a blank line ends the message)quit

In the rcpt to field, type a fully-qualified email address of a local account to test local delivery; use a fully-qualified email address of a remote account to test remote delivery.If “Message accepted for delivery” is returned, sendmail is properly configured to accept mail for delivery.The next step is to verify that sendmail delivered the test message. Mail logs are stored in /var/log/maillog. To view the mail log, use the tail command:tail /var/log/maillog

If you just installed sendmail, there will be only one entry in the maillog file. Verify that no error or failure messages are present and that the stat attribute value equals Sent.NOTE When testng mailertable functionality, verify that the message was

relayed to the appropriate server.If the test message was addressed to a local user, you can verify that the message was received by examining the user’s mail spool. The mail spool is located in /var/spool/mail. To view the mail spool, use the tail command:tail /var/spool/mail

If the test message is in the mail spool, sendmail is properly configured to deliver email locally.

Configuring or upgrading sendmailExisting installations of sendmail version 8.11 or later can be configured to use Immunity if the Milter interface is enabled. To determine this, type:sendmail -bt -d0.4 </dev/null | grep MILTER

If the output contains the word, MILTER, then the Milter interface is enabled in the sendmail installation.


ftp://ftp.redhat.com/pub/redhat/linux/7.2/en/os/i386/RedHat/RPMS/procmail-3.21-1.i386.rpm




12

After verifying that an existing sendmail installation meets Immunity requirements, use the installation and configuration instructions in Installing sendmail, page 7 as a guideline for rebuilding sendmail so it will work with Immunity.To retain the configuration settings from the older version of sendmail, copy the site.config.m4 into the new version.

Installing the Immunity softwareImmunity uses few resources and is easy to install directly on gateway MTA serv-ers. To achieve peak performance, install sufficient RAM to reduce or eliminate swapping. If you are saving suspected spam, consider installing high-performance storage subsystems in order to reduce I/O bottlenecks.If you are simulating an “appliance” implementation, Immunity works well on a 1U rack-mounted server running Linux. Load this setup with sufficiently fault-tol-erant hard disk space and 512 MB to 1 GB of RAM to optimize your anti-spam server.NOTE Cloudmark recommends that you perform a complete backup of all

data on the destination server prior to installation.Before installing Immunity software, ensure your Linux system meets the following requirements:

Before you install Immunity:• Make sure you have proper permissions to install software on the destination

server. Immunity must be installed as root.• Increase the number of file descriptors that a single process can open to 1024. To

do this, add these two lines to /etc/system: set rlim_fd_cur = 1024set rlim_fd_max = 1024

Component Specifications

Immunity Server i386 server capable of hosting one of the supported operating systems. Increasing RAM and hard disk space may improve per-formance. Increasing RAM and hard disk space may improve performance

Database Server 5-10 GB extra for storing detained messages, but varies depending on mail traffic and storage needs. As a general rule, allot enough storage space for 30 to 60 days of suspected spam per user. The database server can reside on the same server as Immunity or separately

Operating Systems RedHat Linux 7.x, 8.x, 9.0 or Enterprise Server 3.0

Libraries See Appendix A, Linux Library Compatibility (pg. 43)

Sendmail Version 8.11 to 8.12.10, compiled with Milter

Table 3-1 Linux system requirements



Then, to install the Immunity software, unpack the Immunity tar.gz package in either the /usr/local/ or /srv/ directory using the tar command with the z, x, v and f switches.

Upgrading Immunity from a previous version If you are doing a fresh install of Immunity, skip this section and proceed to Install-ing the Immunity software, page 12.When upgrading Immunity, it is recommended that you backup your current installation. If you are upgrading Immunity from version 1.x, you can migrate your configuration settings to the new version. If you are upgrading Immunity from ver-sion 2.x, you should migrate both the Immunity database and the configuration settings from the previous installation to the latest version.The steps are:

• Back up the previous installation• Install the latest version• Migrate the configuration settings• Migrate the database settings• Copy ext directory contents

To back up the previous installation, stop Immunity and then rename Immunity’s directory using a unique name.Next, install the latest version of Immunity following the steps in Installing the Immunity software, page 12.Once installed, copy any configuration settings from the previous configuration files into the latest configuration files.WARNING Do not replace the entire configuration file, as the latest files may

contain new configuration options previously unavailable.Finally, copy the following directories and files from the ext directory of the old version to the ext directory of the new:

• local• feedback• feedback_docs• local_info.db• local_feat

NOTE Not all of these directories and files will exist; copy only those that do.To upgrade a MySQL database, copy the database configuration settings in immu-nity.cfg from the previous version to the latest version. Since SQLite is a file sys-tem-based database, you must copy the immunity/data/ directory from the previous installation to the immunity/data/ directory in the latest version and ensure that the permissions are set identically on the two directories and all files. If you already set up your database, skip the section, Setting up the database, page 13.

Setting up the databaseAfter installing Immunity, you must set up a database for it. The supported data-bases are SQLite and MySQL. The database you choose depends on the degree of



14

performance scalability you require. In general, if you have a small user population and do not intend to store messages in the Immunity database, use SQLite; how-ever, if your user population is larger than 2,500 users and/or you need greater storage capacity for stored messages, use MySQL.The remaining sections provide instructions for creating the Immunity database in SQLite and MySQL.

Running the database setup script with SQLiteIf you are using SQLite, run the provided database setup script to create the Immunity database.To run the SQLite database setup script

1 From the root of the Immunity installation, run the database setup script:setup/dbsetup.pl

2 When prompted to select the type of database you are using, type 1 for SQLite.Select SQLite by typing 1.

3 When prompted to enter a folder location for the SQLite database, press Enter to accept the default path (/usr/local/immunity/data) or enter a path to an existing directory and then press Enter.You will then be notified if the database was setup successfully.

Rerunning theSQLite setup

script

If you move your database or clean start Immunity, you can rerun the database setup script. Rerunning the script will delete your database files, so copy or move them before running the script to save your data.The steps to rerun the SQLite database setup script are identical to those presented in Running the database setup script with SQLite, page 14; however, when rerun, the script will inform you that the immunity.cfg file is already setup with database set-tings. Type Y at the prompt to overwrite the immunity.cfg file and press Enter to continue running the script.

Creating a user in MySQL for ImmunityFor Immunity to use a MySQL database, you must create a user in MySQL with the necessary permissions to create and modify the Immunity database (created in the next section, Creating the Immunity database in MySQL, page 14).To create a user with the appropriate permissions, log on to MySQL and select the mysql database with the use command (use mysql). Then, enter the following commands:grant all privileges on *.* to '[user name]'@'%' identified by '[password]' with grant option;grant all privileges on *.* to '[user name]'@'localhost' identified by '[password]' with grant option;flush privileges;

Creating the Immunity database in MySQLOnce a user is created in MySQL for Immunity, you can run the database setup script to create the Immunity database.



To create the Immunity database with the provided setup script

1 From the root of the Immunity installation, type the following command at the prompt:setup/dbsetup.pl

2 When prompted to select the type of database you are using, type 2 for MySQL and press Enter.

3 When you press Enter, a prompt reminds you that a user with database creation privileges must be setup. If you followed the instructions in Creating a user in MySQL for Immunity, page 14, press Enter to continue.

4 The script then prompts you for the following information:• Database host name (default 127.0.0.1)• Port number to connect to the database (default 3306)• User name, password and database name (default authdb) you set up in Creating a

user in MySQL for Immunity, page 14.Press Enter after each value you specify.When you are finished, the script creates the database and tables and informs you when the Immunity database setup is complete.NOTE The setup script may take up to 10 minutes to complete.



16

4
Configuring Immunity
Immunity is configured and run by four primary sets of functionality, each of which is governed by a corresponding file:

• Configuration settings in immunity.cfg, contain parameters that control the basic operation of Immunity and are edited directly in the file.

• Whitelisting in whitelist.cfg, allows you to whitelist individual or ranges of IP addresses and domains. Whitelists are created and maintained by editing whitelist.cfg directly.

• Cartridge settings in cartridge.cfg, which determines how updates are applied to Immunity’s spam-filtering ability.

• Policy actions in policy.cfg, define how Immunity acts on a message based on the classification it applies to it (e.g., spam or legitimate). Although you can edit poli-cies in this file directly, you should use the Administration Dashboard. If you do make the changes to the file, restart Immunity to apply them; otherwise, changes made using the Administration Dashboard are applied immediately.

Configuration settingsYou can configure Immunity settings in the immunity.cfg file—located in the etc directory in the root directory of your Immunity installation—using any text edi-tor.The following table list some of the variables in the immunity.cfg file:NOTE Items in the file that begin with blank spaces or are preceded by one

or more hash marks (#) are inactive.

Variable Default Value(s) Description

max body size 32 Positive integer

Size (KB) of message analyzed by Immunity when classifying it

spool path ./spool directory path

Directory for autospooling (if enabled for Save and Copy actions); specify a directory for temporary mail storage

spam value definition

96 Positive integer

Spam score (%) that identifies spam

user cache yes yes, true, 1 or no, false, 0

Toggles memory caching of user data-base, which is updated in 10-minute intervals

Table 4-1 Immunity configuration variables

17


18

A description of the remainder of configuration variables follows.

Automatic spam filtering and user validationWhen a user first receives spam, Immunity determines whether they are automati-cally added to its database of users based on the value of the filter by default variable. If the variable is set to yes, the user is added to the database and then assigned either validated or non-validated status.Validated users are email addresses that can be verified as legitimate by the mail server administrator. You can automatically validate users as they are added to the Immunity database by setting the validate users by default variable to yes, true or 1; if set to no, false or 0, an email (called a welcome message) will be sent to the user containing a hyperlink that, when clicked, validates the user. You can also manually validate users using the Administration Dashboard, as described in Searching for specific users, page 40.

run as commented User with sufficient sendmail access per-missions

User that Immunity uses to control sendmail communication socket; by default, Immunity uses the setting specified in sendmail.cf; if commented out, root is used

keep mail days 21 Positive integer

Number of days to keep retained mes-sages before deleting; storage require-ments must be considered when applying this setting, based on the amount of email and the retention period

milter owner User speci-fied by the RunAsUser parameter in send-mail.cf

User with sufficient permis-sions to use the Milter socket

User that Immunity uses to communi-cate with sendmail via the Milter socket. If the RunAsUser parameter is not set, then Immunity uses root (if root was used to log on to Immunity)

treat email addresses as case sensitive

no yes or no Toggles case-sensitivity for email addresses

mailer timeout 30 Positive integer

Timeout (in seconds) for communica-tion between Immunity and the MTA for sending detained messages reports and releasing messages from the detention center

email genetic map refresh interval

720 Positive integer

Frequency (in minutes) of nD Visualizer updates; minimum value is 60. If 0, no updates occur


Table 4-1 Immunity configuration variables

Chapter 4 Configuring Immunity


Spam filtering is automatically enabled for validated users; however, only the first 1000 spam messages are blocked for non-validated users. In addition, non-vali-dated users are removed from the Immunity database after the number of days specified by the keep not validated users days variable.The following table lists all variables related to automatic spam filtering and user validation, as well as their default and possible values:

Customizing thewelcomemessage

You can customize the text of the welcome message sent to newly added, non-val-idated users. The etc/welcomeheader.txt file, located in the parent directory of Immunity, contains the welcome message. Change the contents of this file with any text editor to suit your specific requirements.

Detained messages reportsImmunity can generate a detained messages report for each user that lists all mes-sages detained by Immunity (as suspected spam). Users can view these messages and delete spam or move misclassified—or legitimate—mail to their Inbox.To enable detained messages reports, set the run detained messages reports variable to yes.When enabled, detained messages reports are sent to users at a specified frequency (e.g., daily, weekly, etc.). You can assign a default frequency for newly added users with the default detained messages report frequency variable or set the frequency using the Administration Dashboard, as described in Managing users, page 39.Administrators can manage the system resources required by the detained mes-sages reports process by specifying the time of day and the frequency at which Immunity generates the reports. The detained messages report hour begin and detained messages report hour end variables together specify the time period in which Immunity generates reports. You can also manage storage resources by specifying how many days detained messages reports links should remain active with the keep detained mes-sages reports days variable.Following is a list of configuration variables related to detained messages reports processing and the default and possible values for each:

Variable Default Value(s)

filter by default yes yes, true, 1 or no, false, 0

validate users by default yes yes or no

keep not validated users days 7 Positive integer

Table 4-2 Automatic spam filtering and user validation configuration variables


run detained messages reports

yes yes, true, 1 or no, false, 0

default detained mes-sages report frequency

never never, every week day, every other week day, once per week

Table 4-3 Detained messages reports configuration variables

Chapter 4 Configuring Immunity 19


20

Customizing thedetained

messages report

You can customize the header placed at the top of detained messages reports by editing the detained messages reports header file, which is located in the directory specified by the detained messages report header variable. You can add your own custom text, as well as HTML.In addition, you can specify the From address of the report using the detained mes-sages report from variable, as well as customize the subject line with the detained mes-sages report subject variable.

Administration Dashboard access settingsYou can log on to the Administration Dashboard (page 23), the web-based inter-face to Immunity functionality, using the user name and password set by the admin username and admin password configuration variables.By default, the Administration Dashboard is served on port 880; however, you can change the port using the html port variable. The web pages comprising the Admin-istration Dashboard are located in the directory specified by the html dir variable.To access the Administration Dashboard from a remote computer, set the use remote admin variable to yes. You can control which remote computers can access it using the html ip allow variable. To allow all remote computers to connect to the Administration Dashboard (using the proper credentials, of course), leave the value empty; otherwise, specify which computers can access it by supplying the full IP address of each computer—separated by commas—or a partial IP address for a range of IP addresses.The default web session timeout variable determines how long (in minutes) a session with the Administration Dashboard remains active after a specified period of inac-tivity. If there is no interaction with the Administration Dashboard within the specified time period, you will be prompted to reauthenticate next time you try to use it.

detained messages report hour begin

9 Positive integer (0-23)

detained messages report hour end

17 Positive integer (0-23)

keep detained messages reports days

14 Positive integer

detained messages report header

./etc/digestheader.txt File path

detained messages report from

immunity@[hostname] Email address to use in From field of detained messages reports; [hostname] is the Immunity server

detained messages report subject

commented out Any text


Table 4-3 Detained messages reports configuration variables



Default and possible values for Administration Dashboard access settings is pro-vided below:

Statistics calculation variablesTo collect spam-filtering statistics and display them on the Administration Dash-board (page 23), set the enable statistics variable to true. If set to false, statistics are not accumulated.Immunity calculates the time and money saved by spam filtering using the value from the seconds wasted per spam, average annual employee salary and num work days per employee configuration variables. Time saved is calculated by dividing the average amount of time spent on each spam messages (by default, 5 seconds) by the amount of spam messages received; money saved is calculated by the following formula:number of spam messages * seconds wasted per spam * average annual employee salary / num work days per employee / 8 hours per day / 3600 seconds per hour

Only the statistics displayed on the Administration Dashboard are used in the cal-culation.The following table lists all variables related to statistics calculations, with the default and possible values for each:

When enabled, statistics are updated continously.


admin username admin any text

admin password boats any text

html port 880 port number

html dir ./html directory path

use remote admin yes yes or no

html ip allow commented out IP address

default web session timeout

30 number of minutes

Table 4-4 Administration Dashboard access settings configuration variables


enable statistics true Boolean

seconds wasted per spam 5 Positive integer

average annual employee salary 30000 Positive integer

num work days per employee 250 Positive integer

Table 4-5 Statistics calculation variables



22

Database connection propertiesTo connect Immunity to a database, first specify the type of database engine you are running with the database type variable.If you are running SQLite, you can specify the directory where the Immunity data-base is stored using the database dir variable; otherwise, for the other databases, use the database host and database port variables to specify the location, as well as the database name using the database name variable.Supply the authentication credentials for the database using the database user and database password variables (except SQLite users).

Immunity event loggingImmunity logs events related to its operation. You can specify the directory and file name log events are recorded to using the log target variable, as well as determine the severity of the events that are logged (using the log level variable).

A note about configuration in multiple server environmentsIf you split digest processing tasks among multiple Immunity servers, set the keep messages reports days, keep not validated users days and keep mail days variables to high val-ues on every server except the one delegating the digest processing tasks.

Starting and stopping ImmunityBefore starting Immunity for the first time, you must configure operational param-eters as described in Configuration settings, page 17. Start Immunity from the parent directory of the Immunity installation using the following command:./immunity start


database type sqlite mysql, sqlite

database dir data full or relative directory path; SQLite only

database host localhost IP address or server name

database port 3306 port number

database name authdb any text

database user authuser any text

database password authuser any text

Table 4-6 Database connection properties configuration variables


log target ./log/immunity.log filename and path

log level 6 positive integer, 0-6

Table 4-7 Immunity event logging configuration variables



When Immunity starts, it begins assigning confidence levels to all messages and processes them with the assigned action.To stop Immunity, use this command:./immunity stop

You can also stop Immunity from the Administration Dashboard. When Immunity is stopped, it does not queue messages for spam checking at a later time; both spam and legitimate messages pass through with no action taken.

Accessing the Administration DashboardThe Administration Dashboard provides access to all Immunity configuration set-tings and functions. To access it, open a browser and enter the following URL:http://localhost:880From a remote machine, enter either of the following:http://nameofyourmachine:880http://ipaddressofyourmachine:880The default HTML port number for Immunity is 880. If you change the port num-ber in the immunity.cfg file, you must also change the port number in the afore-mentioned URLs.When you launch the Administration Dashboard, the Home page is displayed.

Figure 4-1 Administration Dashboard Home page

The Home page is the starting point for all Immunity administrative functions. It displays spam-filtering related statistics and the operational status of Immunity, and also provides access to the nD Visualizer tool.

Creating policiesImmunity applies one action to an individual message, which is determined by your policy. Your policy specifies which actions are taken on messages of varying confi-

View operational status and related statistics

Open nD Visualizer tool

View spam statistics graphically


http://localhost:880

http://nameofyourmachine:880

http://ipaddressofyourmachine:880


24

dence levels. Each action is then applied to messages in the specified confidence range. For example, you might establish the following policies:

• If Immunity has a 100% confidence that the message in question is spam, delete (or DROP) it.

• If the confidence that the message is spam is from 96% to 99.99%, detain (or SAVE) the message on the MTA.

• If the confidence that the message is spam is from 50% to 95.99%, deliver the message to the user and add text to the subject line (or TAG) with [Spam] to make it easier for the user to manage their email.

• If the confidence level is under 50%, deliver the message directly to the recipient.The Configuration page displays active policy actions and their threshold percent-ages, ordered from highest to lowest value.To create (or edit or delete) policies, click the Configuration tab on the Administra-tion Dashboard.

Figure 4-2 Configuration page of the Administration Dashboard

Immunity has a default policy of SAVE 96%. This policy indicates that messages 96% likely to be spam are saved for review, but are not delivered to the recipients.The following table lists currently supported actions:

Action Description

Save Store a copy of the message without sending it to the recipient; stored messages can be accessed in the Detention Center

Add Header Add a header to the message and deliver to the recipient

Tag Tag the message with text either in the body or subject of the message to identify it as possible spam

Drop Delete the message

Refuse Delete message and send an error message to the sender

Redirect Redirect the message to a designated location, such as a spam folder

Table 4-8 Immunity configurable mail actions

View and edit configured policies

Add new policies

View and change operational status



To add an action to the policy configuration, select it from the Action to Apply box and then click the Add button. When you click Add, a Threshold and Config-uration box appear, allowing you to configure those options.

Determining thresholdSince the score for mail messages can range from 0 (for legitimate mail) to 100 (for spam), thresholds are used to specify scoring ranges. Then, actions are assigned to these ranges to apply to messsages. The score specified in the Threshold box indi-cates that the associated action will be applied to a message with that score or higher (up to the next threshold value or 100%, whichever comes first). The table below illustrates how threshold values create scoring ranges:

Figure 4-3 Sample thresholds established by Configuration page policies

As the illustration shows, the 96% threshold creates a scoring range of 96% to 100%. As a result, the SAVE action is applied to any messages with a score in this range. Similarly, the 50% threshold creates a scoring range of 50% to 95%. The TAG action is applied to any message with a score in this range. Any message between 0% and 49% are delivered directly to the recipient.

Configuring action attributesThere are several variables you can configure for an action in the Configuration box. This section provides a list of and definitions for all the variables.WARNING Change only the variable settings in bold text. Editing any other

information will cause the action to function improperly.

REFUSE The REFUSE action rejects spam at the MTA gateway and returns the mail to the sender, along with a customizable message (which could be used to simulate the absence of an mailbox, for example). The syntax is:config=[rcode=500; xcode=5.0.0; msg=[Delivery denied]]

The rcode and xcode parameters map to specific SMTP response states defined by Reqeust for Comments (RFCs). rcode is defined by RFC 821; xcode, RFC 2034. For more information on RFCs, browse to http://www.ietf.org/rfc.

Copy Deliver message to recipient and store a copy in the Immunity database

Tag and Add Header (TAH)

Add a spam-identifying tag to the message somewhere in the message and its header

Save and Refuse (SAR)

Save the message without delivering to recipient and send an error message to the sender

Action Description

Table 4-8 Immunity configurable mail actions

TAG SAVE

96%50%0 100

SPAMLEGITIMATE


http://www.ietf.org/rfc

http://www.ietf.org/rfc


26

You can type any text for the msg parameter; it displays in the body of the message returned to the sender.

DROP The DROP action deletes the message from the MTA and, as a result, the message is not delivered to the recipient. No further action is taken by Immunity or the MTA. The deleted message cannot be recovered.

TAG The TAG action adds a specified text string to the subject or body of a message as a visual indicator to the recipient that message is suspected as spam. Tagging a message as spam can also be used to trigger a server or client-side rule. For exam-ple, Microsoft Exchange can be configured to create a “suspected spam” folder in each user’s server-side mailbox and then automatically direct tagged messages into that folder. This provides a highly effective link between Immunity and server-based MTAs.You can indicate where the tag is located (body or subject line of message) and what the tagged text string is, using the following syntax:target=subject; action=prefix; text=[SPAM: ]]

The target parameter specifies where the tag appears: either in the subject or body. You can specify whether the tag appears at the beginning or end of the target (using prefix and postfix, respectively) with the action attribute.The text parameter can contain any tag text. Typing %p%% inserts the spam score (as a percentage); %w inserts the text “Whitelisted,” if, in fact, the messages were sent by a whitelisted sender address. To increase visibility, the tag text should con-tain all capital letters and be terminated with a colon (as in the above syntax).

ADDHEADER The ADDHEADER tag adds a header line to the mail message. This is typically transparent to the user (as most mail clients suppress excess header information), but can be used to trigger server and/or mail client rules. For example, if the mail is suspected as spam, a header could be added that triggers the MTA to place the message in an end-user’s suspected spam folder.The configuration syntax for ADDHEADER allows you to specify the header text and a value:config=[header=[X-SPAM]; value=[%p%%]]

This sample configuration would output this header, if the spam score was 96%: X-SPAM 96%. Use the value parameter to insert the spam score (%p%%) or the text, “Whitelisted,” (%w) where applicable.

SAVE The SAVE action stores spam messages in the Detention Center. For more infor-mation on the Detention Center, see Managing detained messages, page 33.You can save the spam confidence score with the email, as shown in the Save action syntax:[confidence=true] record

COPY Similar to the SAVE Action, COPY stores a copy of the suspected spam messages in the Detention Center for administrative review, but also sends the message to the recipient.



You can save the spam confidence score with the email in the Detention Center, as shown in the following configuration syntax:[confidence=true] record

TAH The TAH action combines both the TAG and ADDHEADER actions. The com-bined syntax is:[subject_action=prefix; subject_text=[SPAM (%p%%):]; header_name=[X-SPAM]; header_value=[%p%%]]

The parameter values are explained in TAG, page 26 and ADDHEADER, page 26.

REDIRECT The REDIRECT action redirects suspected spam to a specified email address. Typically, redirects are sent to individuals who want to review suspected spam, but do not have access to the Administration Dashboard (and, as a result, the Deten-tion Center). The configuration syntax lets you specify the email address as a value to the target parameter:config=[[email protected]]

SAR The SAR action combines the SAVE and REFUSE actions. The syntax is:reject_rcode=500; reject_xcode=5.0.0; reject_msg=[Message rejected]; save record confidence=true;

Refer to SAVE, page 26 and REFUSE, page 25 for information on parameters and their respective values.

Editing (or deleting) action policiesTo edit an action, click the button next to an action (in Policy Configuration area) and then click Edit.To delete an action, click the button next to the action and then click Delete. When prompted to confirm the delete of the action, click OK to delete it or Cancel to keep it.

WhitelistingImmunity provides system-level whitelisting support, which allows you to specify domains, IP ranges, envelope or header information that should automatically be passed through without being scanned for spam. Whitelisting configuration set-tings are stored in the file whitelist.cfg, in the etc directory of Immunity parent directory.There are three types of whitelisting:

• Host whitelisting checks the IP address and/or the domain of the mail server from which a message is being received. While host whitelisting is a highly effective anti-spam measure, it will require you to expose Immunity directly to external mail servers.Following are sample configurations that allow mail from hosts with the specified IP addresses to bypass spam-filtering:type=host; address=[1.2.3.4]type=host; address=[1.2.3]



28

In the first sample, only mail from the host at the exact IP address bypasses spam-filtering; the second sample allows mail to bypass spam-filtering if only the first three numbers of the IP address match.

• Header whitelisting checks the header fields of incoming mail. This is not fool-proof because spammers sometimes forge header information. In addition, header information is rewritten as it is relayed through various networks. As a result, a header for a spam message may be added when it is relayed by a trusted host and could then be passed to the recipient without being scanned for spam.Following are sample configurations where header whitelisting is used to bypass spam-filtering for all addresses from the .gov and doj.org domains, respectively:type=header; header=[From]; value=[@.*gov];type=header; header=[From]; value=[@doj\.org];

To match an explicit email address:type=header; header=[From]; value=[\buser@domain\.com\b];

• Envelope whitelisting checks the SMTP envelope of an incoming mail. This pro-vides a flexible whitelisting mechanism that will match against any substring or reg-ular expression in the specified command field of the envelope. Like header whitelisting, spammers can forge (or spoof) the from address to create the appearance that the message comes from a trusted source.Following are sample configurations for envelope whitelisting bypasses spam-fil-tering for mail messages containing .ite in the “mail from” and the “recipient to” attributes, respectively.type=envelope; command=[mail from]; value=[@.*ite];type=envelope; command=[rcpt to]; value=[@.*ite];

Note that email address strings contain a leading less than sign (<) and trailing greater than sign (>). So, either pattern in the following examples can be used when searching for an explicit email address (for both header and envelope whitelisting):type=envelope; command=[rcpt to]; value=[^<user@domain\.com>$];type=envelope; command=[rcpt to]; value=[\buser@domain\.com\b];

To receive emails from any sender in a domain or any of its first-level domains:type=envelope; command=[rcpt to]; value=[@([^.]*\.domain|domain)\.com\b];

The preceding example would allow mail from [email protected], [email protected] and [email protected]—but not [email protected] more information on regular expressions for Unix-based operating systems, go to http://www.devshed.com/Server_Side/Administration/RegExp/page1.htm.Changes to the whitelist take effect upon a restart of Immunity.


http://www.devshed.com/Server_Side/Administration/RegExp/page1.htm


BlacklistingImmunity can make use of sendmail-based blacklisting functionality. For further information, check the sendmail website at http://www.sendmail.org/m4/anti_spam.html#access_db.

Micro-updates settingsThe micro-updates feature of Immunity connects to a Cloudmark Internet server to download updates to Immunity’s spam-filtering functionality. You can enable micro-updates and configure various properties in the cartridge.cfg file. The fol-lowing table lists the micro-updates configuration variables:

The updated micro-updates file is downloaded to the /etc/micro_updates direc-tory of the Immunity parent directory.

Updating the EGMCloudmark distributes updated versions of the EGM approximately every 30 to 60 days to relay particularly important discoveries in defeating new mutations of spam. The updates are based on the ongoing and automatic analysis of spam and legitimate email at the Cloudmark research center to refine and evolve the EGM.The EGM update is usually distributed via FTP as a tar package. As a regular part of your service contract, Cloudmark will notify you when an EGM update is avail-able.To install the EGM update


micro-update hostname

microup-dates.cloud-mark.com

URL Specifies the hostname that the spam-DNA update connects to when down-loading micro-updates; downloads over port 80 or 25

micro-update path /vr8 File path Specifies the path for the micro-update download from Cloudmark’s micro-updates server

micro-updatefilename

srl.txt File name Specifies the file name used for micro-updates on the Cloudmark micro-updates server

micro-update interval

24 Positive integer

Specifies how frequently (in hours) Immunity applies the latest micro-update

micro-updatetimeout

10 Positive integer

Specifies the timeout period (in sec-onds) when checking for micro-updates

enablemicro-updates

yes yes or no Enables (or disables) the download of micro-updates via the Internet

Table 4-9 Micro-updates configuration variables


http://www.sendmail.org/m4/anti_spam.html#access_db

http://www.sendmail.org/m4/anti_spam.html#access_db


30

1 Stop Immunity by typing “./immunity stop” at the command prompt or shutting it down from the Administration Dashboard. If you do not stop Immunity, the updater script will not run.

2 Run the script file, “cartridge-installer-<EGM update version>.bin,” where <EGM update version> is the version of the EGM update.

3 When prompted by the script, specify the directory Immunity is installed in. By default, it is /srv/immunity. Ensure you have write permissions to the directory before attempting to update the EGM in the specified directory.If Immunity is not found in the directory you specified, the script will not run.

4 After you specify the installation directory, the script creates backups of your old EGM and then installs the new one.If you attempt to install an older EGM over a newer one, the script will not run.

5 When the script is finished, restart Immunity (./immunity start) at the command prompt.

Verifying operation and configurationTo verify Immunity’s operational status, configuration and the effectiveness of its spam-filtering capabilities, follow the instructions and guidelines in the next two sections.

Checking operational statusYou can verify the operational status of Immunity from the Home and Configura-tion page of the Administration Dashboard, as shown in Figure 4-1 on page 23 and Figure 4-2 on page 24, respectively. When Immunity is started from the command line (see Starting and stopping Immunity, page 22), the status displayed on the Administration Dashboard can be either Suspended or Running.You can suspend Immunity when it is running by clicking the Suspend button and then Change on the Configuration page. When the status is suspended, you can resume Immunity by clicking the Resume button and then Change on the same page.If you want to stop Immunity, click Stop and then Change. You are prompted to verify your intent to stop Immunity on a warning page. If you want to stop Immu-nity, click the Stop button; otherwise, click Cancel.NOTE The Stop operation is logged.To resume Immunity, you will have to start it from the command line, as described in Starting and stopping Immunity, page 22.

Testing spam classification functionalityTo verify that Immunity is functioning and configured properly, you should send at least 100 spam messages through the system and then verify the results. If config-ured properly, Immunity should not classify any of the spam messages as legiti-mate. Repeat with 100 legitimate messages. Immunity should not classify any as spam.



NOTE Cloudmark provides customers with sample test messages to use, if needed. Contact Cloudmark support or your sales representative.



32

5
Working with Immunity
This chapter describes how administrators and end-users manage spam and mis-classified messages with Immunity. It also shows how administrators can monitor the flow of spam using the spam statistics report functionality, as well as how to manage user settings.

Managing detained messagesThe Detention Center stores messages that Immunity has classified as spam. If an end-user thinks a message has been misclassified, you can search the Detention Center for it. If the message appears legitimate, you can then release it to the recip-ient.NOTE You can also send reports to users listing detained messages for

them, as described in Detained messages reports, page 19 and Detained Messages Report, page 41.

You can search the entire detained messages database by date received, domain, subject or recipient (and any combination thereof). You can also list messages with a specific confidence level assigned to them.

Figure 5-1 Detention Center page of the Administration Dashboard

Search results can be displayed for all dates or within a specified date range. To dis-play all messages detained since Immunity was installed, select the All dates option; otherwise, specify a date range in the date drop-down menus and time text boxes.NOTE By default, the last 1000 detained messages with a confidence level of

at least 96% are displayed when you click the Detention Center tab.

Specify a range of dates

Specify search criteria for detained messages or leave blank to display all

33


34

An important note about narrowing search parametersGenerating large numbers of search results can be very memory-intensive and, as a result, strain system resources. It also takes considerable time to process them.When searching the Detention Center, you should narrow the search parameters as much as possible to avoid returning large result sets. For example, instead of searching for all records above a given confidence level, use additional criteria, such as the recipient's address or subject line keywords.This can also apply to feedback and user searches, although both of these are less likely to generate the same volume of results as the Detention Center can.

Detention Center search resultsThe Detention Center search results page lists all messages matching your search criteria, allowing you to delete messages or release them to the intended recipients.

Figure 5-2 Detention Center search results

You can specify the number of results displayed on the page (25, 50, 100, 250, 500 or 1000) by clicking an item on the Show drop-down menu and then clicking OK.To release or delete a message, select the check box next to it and then click Release To Recipient or Delete, respectively. To select all messages displayed on the page, click Check All; to deselect them, click Clear All.NOTE Check All and Clear All only apply to messages displayed on a single

page, not every message in the search results.Messages released to recipients are added to the Feedback page, where Immunity uses the messages to improve its spam-filtering capability. To delete the message from Immunity, select the Delete after Releasing check box before releasing it to the recipient. The message is still used as feedback, but is not delivered to the recipient.To send a copy of the selected message(s), type an email address in the text box next to the Send Copy To button and then click the button.Click New Search to return to the Detention Center page.

Viewing messagedetails

To better determine whether a message is legitimate or spam, you can click the subject of a message to display its details, such as the entire message text, its head-ers and more. You can perform the same release and delete actions on the message as you can on the Detention Center search results page.

Choose message release options

Click to display detailed header and body information•••

Chapter 5 Working with Immunity


There are two hyperlinks on the message details page that allows you to move for-ward and backward through the messages in the search results: the previous mes-sage link moves backwards through the search results; the next message link moves forward. Click the view all messages text to return to the Search Results screen.

Managing administrative and end-user feedbackBoth administrators and end-users can submit feedback to Immunity if a message was misclassified as spam or legitimate. The Feedback page lists misclassified mes-sages and are added to it when:

• an end-user releases a message from their Detained Messages folder.• an administrator releases a message from the Detention Center or submits feed-

back using the administrator command line tool, cm_add_feedback (page 36).

Figure 5-3 Feedback page of the Administration Dashboard

When submitted, Immunity automatically determines whether message feedback applies to the entire organization or just the user (feedback scope). It does this by finding similar messages in the EGM and, based on their classification, determines where to apply the feedback. If the message is similar to a significant number of spam messages—but was classified as legitimate by the reporter—the feedback will apply only to the reporter; if it is not similar to any messages in the EGM or its classification is the same as other similar messages, the feedback will be applied organization-wide.Using the Feedback page, you can verify the legitimacy of misclassification feed-back and the feedback scope and then make changes, if necessary. For example, if a message was classified as spam by Immunity—but an end-user erroneously reported it as legitimate—you can remove it from the EGM using the Feedback page. When a message is removed, Immunity will not consider it when examining other messages for spam.By default, all unreviewed feedback is displayed when you click the Feedback tab. A message on the Feedback page whose feedback scope and classification have not been verified or changed are considered unreviewed. When an administrator accepts the assigned feedback scope and/or classification, the message is consid-ered reviewed.


Search for feedback from specific users and other criteria

Chapter 5 Working with Immunity 35


36

Click New Search to search for messages by the email address of the user submit-ting feedback, the recipient or sender of the message, as well as the subject line content. You can also search by message classification, scope, and modified and reviewed status. A search can display all feedback submitted since Immunity was installed or can be narrowed to specific date ranges.

Feedback search resultsThe Feedback search results page displays all messages meeting the specified search criteria, allowing you to select one or more messages and then change the feedback scope or review status for them, or delete them from Immunity entirely.

Figure 5-4 Feedback search results

You can specify the number of results displayed on the page (25, 50, 100, 250, 500 or 1000) by clicking an item on the Show drop-down menu and then clicking OK.To select all messages displayed on the page, click Check All; to deselect them, click Clear All.NOTE Check All and Clear All only apply to messages displayed on a single

page, not every message in the search results.When you have selected messages, you can change the feedback scope using the drop-down menu at the bottom of the page. You can also mark feedback as reviewed (or unreviewed) and delete messages from the Feedback page with this menu.

Viewing messagedetails

To better determine the legitimacy of the feedback, you can click the subject of a message on the search results page to display message details, such as the entire body of a message and its headers. You can apply the same actions for this individ-ual message as you can for multiple messages on the search results page, as well as send a copy of the message on which feedback was submitted.

Submitting feedback using the cm_add_feedback utilityThe cm_add_feedback command line utility allows you to submit feedback on messages users send to you directly instead of using their Detained Messages Folder (page 41). Such messages must be converted to mbox format (the standard format for Linux and sendmail), as described in Exporting messages to mbox files, page 37. Once converted, use the cm_add_feedback utility to submit feedback to Immunity.

Change the scope or review status, or delete messages

Click the Subject to display details of message feedback•••



To submit feedback using the utility, specify the mbox file name and the classifica-tion of messages contained in it (either “spam” or “legit”) using the -M and -t flags, respectively.Optionally, you can use the -r flag to specify the feedback reporter and the -n flag to set a limit on how many messages can be processed at a time. The default num-ber of messages that can be processed is 500; the maximum is also 500.If you do not specify a reporter, the feedback will apply organization-wide unless there are multiple recipients for the messages. In this case, the feedback will not be applied to any particular user.The -h flag describes the syntax and usage of the cm_add_feedback utility.

Exportingmessages to

mbox files

To export messages to mbox format, your end-users must send you misclassified messages as an attachment in a new email. Messages cannot be forwarded because they lose important header information required by Immunity for analysis.Then, for each message, you must copy all message headers and the entire message source into a single text file. To do this, use an email client that provides full access to each of these properties. Some email clients only provide partial header infor-mation, such as Microsoft Outlook, which does not allow you to view MIME headers.The exact text and header information you should copy to the file—as well as instructions for delimiting multiple messages added to it—are explained in the fol-lowing instructions, using Mozilla Thunderbird as an example.To create an mbox file using Mozilla Thunderbird and a text editor

1 Create a new text file using a text editor, such as Notepad.2 Open the message sent to you by your customers and then, on the View menu,

click Message Source.3 Copy only the message source text between the beginning and ending MIME part

tags of the attached message and paste it into a text editor.To find the beginning of the MIME part tag of the attached message, search for this header and value combination:Content-Type: message/rfc822

The ending MIME part tag is indicated by two dashes at the end of the NextPart line and has the same number value. The next figure shows where typical MIME parts begin and end:

Figure 5-5 Beginning and ending MIME part tags in the message source

4 Paste the selection into the text file.

Copy everything between the beginning MIME part tag and...

...the end MIME part tag (NextPart with the same number and two dashes at the end)

•••



38

5 If you are adding more than one message to the file, separate them by a blank line, followed by a From header in the following format:From [email protected] Web Feb 11 19:25:21 2004

6 Convert the file into Unix format using a utility such as dos2unix.When the mbox file is created, use the cm_add_feedback utility to submit feed-back, as described in Submitting feedback using the cm_add_feedback utility, page 36.

Using the nD Visualizer to View Feedback and ClassificatonThe nD Visualizer tool allows you to review message classification and feedback graphically. To launch it, go to the Home page and click Open nD Visualizer. Refer to Appendix C, nD Visualizer (pg. 47) for instructions on its use.

Generating statistical reportsThe Statistics page of the Administration Dashboard generates statistical reports on messages processed by Immunity. Statistics can be generated by message classi-fication, i.e., spam, legitimate or both, or policy action(s), as well as the time and money saved by Immunity’s spam-filtering functionality (see Statistics calculation variables, page 21). You can also generate statistics on messages within specific confidence level and/or date ranges.

Figure 5-6 Statistics page of the Administration Dashboard

Statistics search results are displayed in chronological order, with each line display-ing data accumulated for a minute, hour, day or month within the specified date range. The frequency of the each line is specified on the Show drop-down menu. The date range is specified using the date drop-down menus and time text boxes. The All dates option displays all statistics since Immunity was installed.Each line contains the number of messages meeting the specified criteria, followed by the percentage of messages meeting this criteria out of all messages processed. The last item is the total number of messages processed in the specified time

Choose how results are displayed


Choose actions, classifications and more, plus confidence level ranges to include in report



period; selecting the Cumulate Data option displays the sum of totals in all preced-ing lines.To display the number of messages with confidence levels between a specific range, select the Confidence Level check box and type the range in the respective text boxes. Select the Consolidate the levels option to display the number of mess-sages within the specified confidence level range in a single column; select the Show each level option to create a column for each confidence level in the speci-fied range. The number of messages with that confidence level is displayed in each column.To predict the number of messages that will meet the criteria specified on the Sta-tistics page within a year, select the Annualize Data Forward check box.To generate statistics using the criteria you specified, click Submit or click Down-load to save the data to a text file on your computer. You can then open the CSV-formatted text file in most spreadsheet software, such as Microsoft Excel.

Managing usersThe Manage Users page allows you to toggle spam filtering, modify Detained Mes-sages Report frequencies and set feedback permissions for all (or some) users. You can also add new users to Immunity, as well as set the Detained Messages Report header file.

Figure 5-7 Manage Users page of Administration Dashboard

There are several configurable options for all Immunity users available on the Manage Users page:

• Spam-filtering status. You can enable or disable spam-filtering for all users by clicking the corresponding option (enable or disable) on the Status drop-down menu and then clicking Apply.

• Feedback permissions. To enable or disable feedback reporting for all users, click Allow or Ignore on the Feedback drop-down menu, respectively and the click Apply. The Apply to reporter only option instructs Immunity to only use feedback submitted by the reporter for that reporter and not the entire organization.

Add new users to the system

Search for users in the system

Modify spam-filtering, feedback settings and report frequency for all users

Customize the message digest header



40

• Message Detained Messsages Report frequency. To specify how frequently Detained Messages Reports are sent to all users, select an option from the Detained Messages Reports drop-down menu and then click Apply. Options include sending the report every weekday, once per week (based on the day of week you installed Immunity), every other weekday or never. There is also an option to send the report immediately.The remaining functionality of the Manage Users page is described in the next three sections.

Searching for specific usersYou can display a list of users matching the criteria you specify by typing all or part of an email address in the Address containing text box and then clicking the Search button; clicking Show All Users to display all users.You can specify the number of results displayed on the page (25, 50, 100, 250, 500 or 1000) by clicking an item on the Show drop-down menu and then clicking OK.By default, users are sorted alphabetically by email address. To sort by another col-umn, click the column name; to change the column order from ascending to descending (and vice versa), click the column name again.You can modify the same settings for individual users on the search results page as you can for all users on the Manage Users page (i.e., spam filtering, feedback per-missions and Detained Messages Reports frequency). In addition, you can delete users.To modify settings for users (or delete them), select the check box next to each user and then select a function from the drop-down menu at the bottom of the page. To select all users displayed on the page, click Check All; to deselect them, click Clear All.NOTE Check All and Clear All only apply to users displayed on a single page,

not every user in the search results.

Adding new usersTo manually add new users to Immunity, type the email address of the user in the Enter email address text box and then click Add. By default, the Detained Mes-sages Report frequency is set to the value specified in the default Detained Mes-sages Reports frequency configuration variable (see Configuration settings, page 17). In addition, spam filtering is enabled and feedback is allowed.

Setting the Detained Messages Report header fileTo set the Detained Messages Report header file, type the name of an HTML file containing the header in the Customize Message Digest Header text box. The HTML file can include links to images (such as your company logo), but the images must be available from an intranet or Internet location accessible to all users. See Customizing the detained messages report, page 20, for more information.



End-user interaction with detained messagesThere are two ways end-users can view detained messages: the detained messages report, which lists newly detained messages since the last report, and the detained messages folder, which lists all detained messages. They can then determine whether the message is properly classified as spam (and delete it) or move legiti-mate mail to their Inbox.

Detained Messages ReportThe Detained Messages Report is sent to individual users as an email that lists all messages detained on the server for the specified user since the last report. Users can read the messages, move them to their mailbox or delete them.

Figure 5-8 Detained messages report

To view the body of a message, click the Subject of the message.NOTE Microsoft Outlook users must enable the security setting, "Submit

nonencrypted form data," for the security zone they are using. If it is disabled or set to prompt, the buttons in the Detained Messages Report will not work. By default, this setting is enabled for the Internet sites security zone.

Users can select one or more messages by clicking the check box next to it and then clicking Delete. They can also move messages to their Inbox by clicking Move To My Inbox. Users can select all messages on the screen by clicking All Messages in Report.Users can choose not to receive reports by clicking Unsubscribe From Reports. which sets the Detained Messages Report frequency to never for the user.Clicking Detained Messages Folder displays all messages currently detained on the server for an individual user, which is described in the next section.

Detained Messages FolderThe Detained Messages Folder shows all messages detained on the server for the user, rather than just messages from a single report as in the Detained Messages Report. The end-user can open their Detained Messages Folder by clicking the Detained Messages Folder hyperlink, located at the bottom of their Detained Mes-sages Report.

Click the Subject to display message details•••



42

A

AP

PEN

DIX
Linux Library Compatibility
Required Linux librariesThe key libraries that Immunity uses for Linux are:

In event that Immunity cannot start due to the failure to load these packages, you must install them manually. The RedHat RPM compat-gcc-c++-7.3-2.96.118.i386.rpm provides the libstdc++ library; the rest are installed in the RPM glibc-2.3.2-27.9.7.i686.rpm.

Library Directory

libdl /lib/libdl.so.2

libpthread /lib/libpthread.so.0

libstdc++ /usr/lib/libstd++-libc6.2-2.so.3

libm /lib/libm.so.6

libc /lib/libc.so.6

ld-linux /lib/ld-linux.so.2

Table A-1 Required Linux libraries and directory locations

43


44
Appendix A

B

AP

PEN

DIX
Testing Immunity
Before you deploy Immunity in a live production environment, it is strongly rec-ommended that you first create a test environment that will allow you to determine which levels of actions are appropriate for your enterprise.

Creating test sets of emailTesting can be accomplished with any given stream of SMTP messages. A com-monly used method is to fork your main incoming message stream for one or more existing email accounts.Once you have a set of test emails (we recommend a set of no less than 1000 mes-sages) you should conduct two types of testing:

• Stability testing• Accuracy testing

Stability testingStability is the most basic form of testing that ensures mail flows freely and effi-ciently through the Immunity system and into your existing email system. It is rec-ommended that you take samples of your inbound mail stream, fork (duplicate) them and relay them through Immunity and into your regular email system.NOTE Take the necessary steps to avoid duplicate deliveries due to the fork-

ing process before relaying mail.

Accuracy testingAccuracy testing is used to determine the levels you should use to set your actions. For example, some organizations will activate the SAVE or REFUSE actions at a low confidence level (such as 50%) because they want to stop more spam and are less concerned with false-criticals (person-to-person email that is accidentally labeled as spam). Other organizations might set their SAVE or REFUSE values at 80% or 99%.The basic method for the accuracy test is to pass a medium to large spool of mes-sages through the system and measure either the percentage of spam that is caught, the percentage of false-criticals that slip through or both.There are three primary types of accuracy tests you can conduct:

1 A mixed spam and legitimate message pool test to measure both false-positives and spam identification accuracy.

2 A false-positive accuracy test

45


46

3 A spam identification accuracy testIt is recommended that you use three types of input spools for testing purposes:

Mixed messagespool

A message spool that contains a typical ratio of legitimate messages to spam pro-vides the most real-world testing scenario. In order for it to be fast and effective, you have to know exactly how many spam and legitimate messages the spool con-tains; otherwise, the only way to measure how accurate the filtering system is, is to examine and count the entire spool by hand and sort it into spam and legitimate groups. Only then could you compare the filtering results to the actual count.

All spam messagespool

Using a message spool of pure spam provides the “worst case” test for spam-iden-tifying performance because every message in the spool is an opportunity for Immunity to fail. Cloudmark can provide an “all spam” spool for your testing.

All legitimatemessage spool

An “all legitimate” message spool will not provide you with useful data about spam identification, but it will thoroughly test Immunity's ability to avoid false criticals.

Appendix B

C

AP

PEN

DIX
nD Visualizer
The nD Visualizer graphically depicts the EGM, allowing administrators to easily review message classification and feedback from Cloudmark and their organiza-tion, as well as get an overview of spam trends.

Message clustersGenetically similar messages are grouped in clusters based on their classification. Clustered messages may share similar words and phrases, identical landing URLs, and be marked by some of the same spamGenes.

Figure C-1 nD Visualizer

Each cluster is color-coded based on the percentage of spam messages a cluster contains: a red cluster contains messages that are all classified as spam for your organization; green clusters contain messages all classified as legitimate for your organization.Yellow is added to the color of a cluster containing both spam and legitimate mes-sages: the more yellow a cluster, the more disagreement on message classification; the closer the cluster’s color to red or green, the less disagreement.Administrators can analyze messages in yellow clusters and then decide whether to provide corrective feedback using the Feedback page of the Administration Con-

Point to a cluster to display com-mon message characteristics

Customize clus-ter view and fil-ter criteria

47


48

sole (page 35) or let Immunity set organization and individual user message classifi-cation preferences automatically.When there are groups of messages with even more genetic similarities, they are placed in clusters inside another cluster.

Viewing cluster detailsClick a cluster to view its details. When you click it, the EGM display zooms in on the cluster, as shown in Figure C-2, Viewing message details, page 50. A label shows the keywords, spamGenes or other characteristics that each message in the cluster have most in commonNOTE This same label displays when you are viewing the entire EGM (i.e., not

zoomed in on a cluster) and point to a cluster.The Cluster Details area shows how many messages are in a cluster, the percentage of messages that are spam, and how many messages feedback was supplied for. In addition, two icons are used to indicate how the group of messages are classified for the organization. If more than 50% of the messages are classified as spam, the icon with the red X is depressed; otherwise, the green checkmark icon will be depressed to indicate that more than 50% of the cluster’s messages are considered legitimate.

Highlighting clusters by feedback scopeYou can highlight clusters based on where messages originated from and their feedback scope using the display options in the Email Genetic Map area:

• Global highlights clusters containing messages supplied by Cloudmark and your organization.

• My organization highlights clusters containing your organization’s messages on which feedback is applied to both individual reporters, as well as organization-wide.

• Individuals highlights clusters containing messages that apply only to the individ-ual who supplied feedback. You can select a specific user on the drop-down menu.

Highlighting clusters by message trafficYou can view message clusters based on the last time they were used by Immunity to classify messages using options in the Message Traffic area. By default, All is selected, which displays all messages used (and not used) by your organization to classify incoming messages. Under My Organization, choose an option to display only your organization’s messages within a specified time frame.

Highlighting clusters by keywordsTo highlight clusters of messages by using particular keywords contained in the subject, sender email or spam characteristics, type the keywords in the Message Search box and click Go. To restore highlighting for all clusters, remove any key-words from the text box and then click Go again.

Appendix C


Using saved views Choosing a saved view automatically applies message filtering criteria based on the type of clusters you want to highlight. For example, you can highlight clusters con-taining messages that only your organization recieved.Following is a list of each saved view and a description of the clusters they high-light:

• Global EGM. This option highlights all clusters, including those with messages provided by Cloudmark and your organization. It is the equivalent of selecting Global in the Email Genetic Map area, and then selecting All in the Message Traf-fic area.

• My Organization’s EGM. This option highlights clusters containing messages whose feedback applies to your organization and individual reporters. It is the equivalent of selecting My Organization in the Email Genetic Map area.

• My Organization’s Traffic. This option highlights clusters containing messages used at your organization to classify incoming messages. It is the equivalent of selecting Global in the Email Genetic Map area, and then selecting Ever in the Message Traffic area.

• Messages With Contention. This option highlights messages—not clusters—with disagreement over the classification. Such messages are colored yellow. For more information on message coloring, see Viewing message details, page 49.

• Clusters With Contention. This option highlights clusters where there is dis-agreement over classification. Such clusters contain both red and green squares (see Viewing message details, page 49 for more detail).

• Recent Feedback. This option highlights clusters containing messages on which feedback was supplied by individual users within the last week. It is the equivalent of selecting Individuals in the Email Genetic Map area, and then selecting In Last Week in the Message Traffic area.

Customizingcluster

appearance

Using the View menu, you can customize the appearance of clusters to better dis-tinguish between those meeting your filter criteria and those that do not. You can also highlight spam and legitimate messages and change the cluster colors to reflect the average similarity of messages contained in them.Following is a description of each customizable view menu option:

• Filter Action. To hide clusters that do not meet the filter criteria you specify, point to Filter Action and click Remove Entirely. By default, clusters that do not meet the specified filter criteria fade, but remain visible (the Fade Color option).

• Show. Point to Show on the View menu and then choose spam or legit to highlight clusters that contain spam or legitimate messages, respectively.

• Cluster Coloring. By default, the percent spam menu option is checked, which applies to the red-to-yellow, green-to-yellow color scheme described in Message clusters, page 47. Choosing the avg. similarity menu option uses a red-to-yellow color scheme to indicate the degree of similarity of messages in the cluster: red means messages are more alike in the cluster than clusters colored yellow.

Viewing message detailsTo view details on a message in a cluster, first click the cluster to display its mes-sages.

Appendix C 49


50

Figure C-2 Viewing message details

Each message is represented by a square and is color-coded according to its classi-fication. A red square is spam; a green square is legitimate. Yellow squares indicate disagreement on message classification.NOTE The same label that displays when you point to a cluster (and shows

the shared message characteristics) is also displayed when you click the cluster.

When you place the pointer over a message square, the sender email address and message subject line are displayed. When you click the message, the Message Details area uses two icons to indicate how messages are classified for three enti-ties: Cloudmark, the organization and individual users. If the icon with a green checkmark is depressed, the message is classified as legitimate for the entity the icon is next to; if the icon with a red X is depressed, the message is classified as spam for that entity.To zoom out of a cluster, click outside the cluster circle.

Point to a mes-sage to display the From: and Subject: line

Indicates how the message was classified and by whom

Appendix C

IND

EXIndex

AAdd Header policy action 24Addheader policy action 26adding new users 40admin password configuration setting 20, 21admin username configuration setting 20, 21Administration Dashboard

access settings 20accessing 23Configuration page 24Detention Center page 33Feedback page 35Home page 23Manage Users page 39Statistics page 38

average annual employee salary configurationsetting 21

Bblacklisting 29

Ccartridge.cfg file 17cm_add_feedback command line tool 35Configuration page (Administration Dashboard)24configuration settings

admin password 20, 21admin username 20, 21average annual employee salary 21database dir 22database host 22database name 22database password 22database port 22

database type 22database user 22default detained messages report frequency

19default web session timeout 20, 21detained messages report from 20detained messages report header 20detained messages report hour begin 19, 20detained messages report hour end 19, 20detained messages report subject 20email genetic map refresh interval 18enable statistics 21filter by default 18, 19html dir 20, 21html ip allow 20, 21html port 20, 21keep detained messages reports days 19, 20keep mail days 18keep not validated user days 19log level 22log target 22mailer timeout 18max body size 17num work days per employee 21run as 18run detained messages reports 19seconds wasted per spam 21spam value definition 17spool path 17treat email addresses as case sensitive 18use remote admin 20, 21user cache 17validate users by default 18, 19

configuring Immunity 17configuring policy action attributes 25conventions

51


52

notational 2typographical 2

Copy policy action 25, 26creating policies 23

Ddatabase

configuring on Linux 13connection properties 22creating a MySQL user 14creating for sendmail 9creating with MySQL 14setup script for SQLite 14

database dir configuration setting 22database host configuration setting 22database name configuration setting 22database password configuration setting 22database port configuration setting 22database type configuration setting 22database user configuration setting 22default detained messages report frequency con-figuration setting 19default web session timeout configuration setting20, 21deleting policies 27detained messages

detained messages folder 41detained messages report 41end-user interaction with 41managing 33searching for 33viewing details 34

detained messages folder 41detained messages report from configurationsetting 20detained messages report header configurationsetting 20detained messages report hour begin configura-tion setting 19, 20detained messages report hour end configura-tion setting 19detained messages report hour hour end config-uration setting 20detained messages report subject configuration

setting 20detained messages reports

customizing 20defined 19end-user email 41frequency 40setting header file 40

detecting spam 3Detention Center page (Administration Dash-board) 33Drop policy action 24, 26

Eediting policies 27EGM

updating 29email border managers

interoperability with 5email genetic map refresh interval configurationsetting 18email systems

interoperability with 5enable statistics configuration setting 21envelope whitelisting 28

FFeedback page (Administration Dashboard) 35feedback scope

defined 35filter by default configuration setting 18, 19firewall

interoperability with 5

Hheader whitelisting 28Home page (Administration Dashboard) 23host whitelisting 27html dir configuration setting 20, 21html ip allow configuration setting 20, 21html port configuration setting 20, 21

IImmunity

Index


administering 33configuration settings 17installing on Linux 12log events 22managing feedback 35network component interoperability 5running in distributed environments 4running in the enterprise 4starting 22stopping 22support resources for 2upgrading existing installation 13verifying operation 30

immunity.cfg file 17installing

Immunity on Linux 12Linux system requirements 12

interoperabilityemail border managers 5email systems 5firewalls 5

Kkeep detained messages reports days configura-tion setting 19, 20keep mail days configuration setting 18keep not validated users days configuration set-ting 19

Llog events 22log level configuration setting 22log target configuration setting 22

Mmailer timeout configuration setting 18Manage Users page (Administration Dashboard)39managing feedback

administrators 35end-users 35

managing users 39max body size configuration setting 17micro-updates

configuring settings for 29directory 29

micro-updates settingsenable micro-updates 29micro-update filename 29micro-update hostname 29micro-update interval 29micro-update path 29micro-update timeout 29

Milteradding to sendmail configuration 7defined 4

Nnotational conventions 2num work days per employee configuration set-ting 21

Ppolicies

creating 23deleting 27determining threshold 25editing 27handling spam with 4

policy actionsAdd Header 24Addheader 26configuring attributes for 25Copy 25, 26Drop 24, 26Redirect 24, 27Refuse 24, 25SAR 27Save 24, 26Save and Refuse (SAR) 25Tag 24, 26Tag and Add Header (TAH) 25TAH 27

policy.cfg file 17

RRedirect policy action 24, 27Refuse policy action 24, 25

Index 53


54

run as configuration setting 18run detained messages reports configurationsetting 19

SSAR policy action 27Save and Refuse (SAR) policy action 25Save policy action 24, 26searching for users 40seconds wasted per spam configuration setting21sendmail

building from source 7configuring an existing installation 11configuring for Immunity 8creating required databases 9installing 7Milter defined 4requisite knowledge 1

spamdefined 3detecting 3ensuring proper detection 5handling with policies 4testing classification functionality 30

spam value definition configuration setting 17spamGenes

defined 3spool path configuration setting 17starting Immunity 22statistics

calculation variables 21downloading to file 39viewing 38

Statistics page (Administration Dashboard) 38stopping

Immunity 22support resources 2system requirements

Linux 12

TTag and Add Header (TAH) policy action 25Tag policy action 24, 26

TAH policy action 27thresholds

determining 25treat email addresses as case sensitive configu-ration setting 18typographical conventions 2

Uupgrading existing Immunity installation 13use remote admin configuration setting 20, 21user cache configuration setting 17users

adding 40managing 39searching for 40

Vvalidate users by default configuration setting 18,19

Wwelcome message

customizing 19defined 18

whitelist.cfg file 17, 27whitelisting 27

using envelope 28using header 28using host 27whitelist.cfg file 17, 27

Index

Date post:	27-Jun-2015
Category:	Documents
Upload:	databaseguys
View:	173 times
Download:	6 times

Installation

Documents