Doctor Web, Ltd.

Dr.Web® for Unix mail servers

(Linux, FreeBSD, Solaris)

Mail filtering systems

Administrator Manual

Version 4.44.1
The material published herein is the property of Doctor Web, Ltd.
and may not be reproduced in any form without written permission
of Doctor Web, Ltd. and proper attribution.

Dr.Web is a registered trademark of Doctor Web, Ltd.

Other products mentioned herein are trademarks or registered

trademarks of their respective companies.

There might be improvements and changes in the software not

described in this Manual. Corrected and augmented versions of this
Manual are available at the official website of Doctor Web, Ltd.,
http://www.drweb.com/.

Release date: 03/18/08

© Doctor Web, Ltd.

http://www.drweb.com/

2
Contents
1.1. What is this Manual about?................................................................................8
1.2. Terms and abbreviations....................................................................................9
1.3. Requirements....................................................................................................10
2. Installation, upgrade and deinstallation.............................................................11

2.1. Installing for Linux...........................................................................................11

2.2. Installing for FreeBSD......................................................................................15
2.3. Installing for Solaris..........................................................................................18
2.4. Upgrading for Linux.........................................................................................22
2.5. Upgrading for FreeBSD....................................................................................24
2.6. Upgrading for Solaris.......................................................................................26
2.7. Deinstalling........................................................................................................29
2.8. Software registration. License key file..............................................................29
2.8.1. Using several key files...............................................................................30
2.8.2. License and demo key files........................................................................31
2.8.3. Key files delivery.......................................................................................31
2.8.4. Restoring lost key files..............................................................................32

3. Operation............................................................................................................33

3.1. Program files location.......................................................................................33

3.2. Command line options. Signals processed by Dr.Web modules......................34
3.3. Configuring and starting the program.............................................................35
3.3.1. Editing configuration files.........................................................................36
3.3.2. Starting the system.....................................................................................76

3.4. Components......................................................................................................77
3.4.1. Checker......................................................................................................77
3.4.2. Receiver.....................................................................................................78

3
Dr.Web® for Unix mail servers
3.4.3. Sender........................................................................................................79
3.4.4. Notifier......................................................................................................80
3.4.5. Monitor......................................................................................................80
3.4.5.1. Command line options....................................................................80
3.4.5.2. Settings............................................................................................81
3.4.5.3. Starting the Monitor........................................................................85
3.4.6. Agent ........................................................................................................86
3.4.6.1. Anti-virus statistics collection........................................................87
3.4.6.2. Operation modes.............................................................................88
3.4.6.3. Command line options....................................................................88
3.4.6.4. Settings............................................................................................89
3.4.6.5. Starting the Agent ..........................................................................96

3.5. Connecting to Dr.Web Enterprise Suite...........................................................97

3.6. Rules affecting messages processing.................................................................98
3.7. Collecting anti-virus statistics ........................................................................106
3.8. Update utility...................................................................................................111
4. Plug-ins.............................................................................................................112

4.1. Anti-virus plug-in............................................................................................112

4.1.1. Installing base package............................................................................113
4.1.1.1. Installing for Linux.......................................................................113
4.1.1.2. Installing for FreeBSD..................................................................114
4.1.1.3. Installing for Solaris.....................................................................114
4.1.2. Installing plug-in......................................................................................115
4.1.2.1. Installing for Linux.......................................................................116
4.1.2.2. Installing for FreeBSD..................................................................117
4.1.2.3. Installing for Solaris.....................................................................119
4.1.3. Upgrading plug-in....................................................................................120
4.1.3.1. Upgrading for Linux.....................................................................121
4.1.3.2. Upgrading for FreeBSD................................................................122

4
 4.1.3.3. Upgrading for Solaris....................................................................123
4.1.4. Connecting with the plug-in.....................................................................124
4.1.5. Configuring plug-in.................................................................................124

4.2. Filtering by headers plug-in............................................................................130

4.2.1. Installing plug-in......................................................................................130
4.2.1.1. Installing for Linux.......................................................................130
4.2.1.2. Installing for FreeBSD..................................................................132
4.2.1.3. Installing for Solaris.....................................................................134
4.2.2. Upgrading plug-in....................................................................................135
4.2.2.1. Upgrading for Linux.....................................................................135
4.2.2.2. Upgrading for FreeBSD................................................................137
4.2.2.3. Upgrading for Solaris....................................................................138
4.2.3. Connecting with the plug-in.....................................................................139
4.2.4. Configuring plug-in.................................................................................139

4.3. Anti-spam vaderetro plug-in..........................................................................143

4.3.1. Installing plug-in......................................................................................144
4.3.1.1. Installing for Linux.......................................................................145
4.3.1.2. Installing for FreeBSD..................................................................146
4.3.1.3. Installing for Solaris.....................................................................148
4.3.2. Upgrading plug-in....................................................................................149
4.3.2.1. Upgrading for Linux.....................................................................150
4.3.2.2. Upgrading for FreeBSD................................................................151
4.3.2.3. Upgrading for Solaris....................................................................152
4.3.3. Connecting with the plug-in.....................................................................153
4.3.4. Configuring plug-in.................................................................................154
4.3.5. Updating VadeRetro library.....................................................................158

5. Integration with mail systems............................................................................159

5.1. Operation in smtp-proxy mode......................................................................159

5
Dr.Web® for Unix mail servers
5.2. Integration with CommuniGate Pro MTA....................................................159
5.2.1. Configuring CommuniGate Pro...............................................................159
5.2.2. Configuring Dr.Web for mail servers......................................................161
5.2.3. Known issues...........................................................................................165

5.3. Integration with Sendmail MTA....................................................................165

5.3.1. Configuring Sendmail..............................................................................166
5.3.2. Interaction with Sendmail........................................................................171
5.3.3. Known issues...........................................................................................172

5.4. Integration with Postfix MTA........................................................................172

5.4.1. Interaction with Postfix............................................................................174
5.4.1.1. Using after-queue mode................................................................174
5.4.1.2. Using milter protocol....................................................................176

5.5. Integration with Exim MTA...........................................................................179

5.5.1. Interaction with Exim..............................................................................180
5.5.1.1. Using special transport.................................................................180
5.5.1.2. Using local_scan function............................................................182
5.5.2. Known issues...........................................................................................184

5.6. Integration with QMail MTA.........................................................................184

5.6.1. Configuring Qmail...................................................................................185
5.6.2. Configuring Dr.Web for mail servers......................................................186
5.6.3. Known issues...........................................................................................187

5.7. Integration with ZMailer MTA......................................................................188

5.7.1. Interaction with ZMailer..........................................................................188
5.7.1.1. Using smtp-session stage in context filter mode.........................190
5.7.1.2. Using routing stage in context filter mode..................................190
5.7.2. Additional parameters..............................................................................191

5.8. Integration with Courier MTA.......................................................................193

6
 5.8.1. Interaction with Courier...........................................................................193
5.8.2. Configuring Dr.Web for mail servers......................................................195

6. Contact information..........................................................................................197

Appendix 1. Migration from Dr.Web mail filters for Unix systems......................198

7
Dr.Web® for Unix mail servers

1. Introduction
1.1. What is this Manual about?
This Manual describes Dr.Web for Unix mail servers, based on the
Dr.Web MailD technology – a product from the Dr.Web Mail Security
Suite product group.
In this Manual we will call this program Dr.Web MailD, or Dr.Web for
Unix mail servers.
Depending on the set of connected plug-ins, the Dr.Web MailD filters
check e-mails for viruses, spam and unwanted messages.
Dr.Web MailD can be administrated from Dr.Web Enterprise Suite.
Operation of Dr.Web MailD is controlled by one of its component –
the Agent (for more information see p. 3.4.6)

The present Manual describes the following features of Dr.Web

MailD:
• General description of the program and differences of the
product’s versions (Chapter 1.1);
• Program installation (Chapter 2);
• Program administration (Chapter 3);
• Description of plug-ins for Dr.Web MailD (Chapter );
• Peculiarities of the program’s operation with different mail
systems (Chapter 5).

At the end of the Manual you can find contact information of Dr.Web
technical support service.

Note, that Dr.Web MailD is being constantly upgraded. New versions

of the program and its plug-ins are being regularly released. Most
changes deal with the improvements in the mail processing, as well

8
 as integration with other Unix applications. A list of applications
compatible with Dr.Web MailD keeps extending. Therefore, the
current Manual may not fully cover the version you are using. To
keep abreast of the latest changes, refer to the documentation
distributed with the mail filtering systems.

1.2. Terms and abbreviations

The following terms are used in the Manual.

Table 1. Terms and abbreviations

Symbol Comment

Note, that Marks important note or instruction

Attention Warns about possible errors

Key file A definition or the link to a definition

/var/drweb Names of files and directories

• In this Manual to define directories to which the components of

Dr.Web MailD are installed %bin_dir, %etc_dir and
%var_dir are used. Depending on the used OS, these
directories denote the following:
• for Linux and Solaris
%bin_dir stands for /opt/drweb
%etc_dir stands for /etc/drweb
%var_dir stands for /var/drweb
• for FreeBSD
%bin_dir stands for /usr/local/drweb
%etc_dir stands for /usr/local/etc/drweb
%var_dir stands for /var/drweb

9
Dr.Web® for Unix mail servers
The following abbreviation will be used in the Manual without further
explanation:
• OS — operating system

1.3. Requirements
Dr.Web MailD is designed for Linux, FreeBSD and Solaris operating
systems (for x86 platforms only).
Dr.Web MailD for Linux is compatible with the Linux distribution
based on the glibc library versions 2.2 and 2.3. (Dr.Web MailD for
Linux OS based on glibc version 2.3 is compatible with Linux OS
based on glibc 2.4). Dr.Web MailD for FreeBSD is compatible with
FreeBSD versions 4.11, 5.x, 6.0. Dr.Web MailD for Solaris is
compatible with Solaris versions 9 and 10.
Hardware requirements for Dr.Web MailD are similar to requirements
for the operation in the console (text) mode in the OS the software is
designed to be used – Linux, FreeBSD and Solaris. To install the
program 20 Mb of disk space are required.
Depending on the computational load and used plug-ins hardware
requirements may differ.

10
 2. Installation, upgrade and deinstallation
Names of distributions and directories created
during the installation depend on the version of the
anti-virus software and the OS.

Installation and uninstallation of the software are described below.

If Dr.Web MailD of the previous version is already installed, you can
upgrade it to higher version. The upgrade procedure is described in
p. 2.4.

The uninstall procedure of Dr.Web MailD is described in p. 2.7

2.1. Installing for Linux

The examples given below describe installation of
Dr.Web MailD configured to operate with the Qmail
mail system. In all examples the version of Dr.Web
MailD is 4.44.1, Linux OS based upon glibc 2.3. In
other cases, names of files and directories will differ
accordingly (namely, the part with the Dr.Web
MailD version number, glibc version and name of
the mail system will differ)

Dr.Web MailD for Linux distributions are delivered as two tar-

archives: the drweb-maild-qmail-4.44.1-
glibc2.3.tar.gz archive contains the main modules of Dr.Web
MailD; the drweb-updater-4.44.1-glibc2.3.tar.gz
archive contains the updating utility for Dr.Web MailD.
Such delivery is not associated with any definite distribution. The
main modules of Dr.Web MailD for Linux are installed as follows:
1. Save the archive with the main modules of Dr.Web MailD
onto a computer.

11
Dr.Web® for Unix mail servers
2. Log on as a root user. For this, execute the su command
and enter the password of the root user.
3. Go to the directory where the archive is saved.
4. Extract files from the archive. A drweb-maild-
qmail-4.44.1-glibc2.3 directory will be created
Example:
> tar xzf drweb-maild-qmail-4.44.1-
glibc2.3.tar.gz

Then, there are 2 modes to install the

software: the manual and the automatic.
The installation in the automatic mode is
made by the install.sh installation
script located in the drweb-maild-
qmail-4.44.1-glibc2.3 directory
created during the unpacking of the
archive with the main modules of Dr.Web
MailD. The install.sh script does the
following:
1. It copies the directory tree contained in the drweb-
maild-qmail-4.44.1-glibc2.3 directory to the
root directory.
2. It creates the drweb user and the drweb group and sets
rights to access the directories of Dr.Web MailD.
3. If Perl command processor is installed on the computer, it
calls the configure.pl configuration script, which sets
values for the main parameters of the configuration file of
Dr.Web MailD (you should only type the values the script
requires). If it is impossible to start the configure.pl
script, set the values for the main parameters manually.
(see p. 3.3).

12
4. It integrates Dr.Web MailD with a mail system

In case you cannot or do not want to use

the install.sh script, installation can
be done in the manual mode:
1. Copy the directory tree nested in the drweb-maild-
qmail-4.44.1-glibc2.3 directory to the root
directory (you can set your own structure of directories,
but in this case you should edit the program’s
configuration file accordingly, read p. 3.3.1).
Example:
> cp -a drweb-maild-qmail-4.44.1-glibc2.3/*
/
2. Create the drweb user and the drweb group. Then set
access rights to the directories:
Example:
> chown -R drweb:drweb /etc/drweb
> chown -R drweb:drweb /opt/drweb
> chown -R drweb:drweb /var/drweb
3. Specify the values for the main parameters of the
configuration file of Dr.Web MailD. If Perl command
processor is installed on the computer, you can set these
values by launching the configure.pl script which is
located in the /opt/drweb/maild/scripts/
directory (by default). The script will ask you to enter the
values of the necessary parameters and save them to the
configuration file.
In case you cannot or do not want to launch the
configure.pl script, specify the values for the main
parameters of the configuration file of Dr.Web MailD
manually (see p. 3.3).
4. Integrate Dr.Web MailD with a mail system (read p. 5)

13
Dr.Web® for Unix mail servers

Then, the updating utility should be installed:

1 Copy the archive with the updating utility to the computer
where the program is installed.
2 Change the current user of the system to the root user.
For this, execute the su command and input the root
user password in the corresponding dialog.
3 Go to the directory with the updating utility archive.
4 Unpack the archive. The drweb-updater-4.44.1-
glibc2.3 directory will be created.
Example:
> tar xzf drweb-updater-4.44.1-
glibc2.3.tar.gz
5. Move the directory tree nested in the drweb-
updater-4.44.1-glibc2.3 directory to the root
directory (you can also set your own structure of
directories, but you will have to edit Dr.Web MailD,
configuration file accordingly, read p. 3.3.1).
Example:
> cp -a drweb-updater-4.44.1-glibc2.3/* /
6. Set access rights for created directories.
Example:
> chown -R drweb:drweb /etc/drweb
> chown -R drweb:drweb /opt/drweb
> chown -R drweb:drweb /var/drweb

14
2.2. Installing for FreeBSD
Examples given below describe installation of
Dr.Web MailD configured to operate with the Qmail
mail system. In all these examples Dr.Web MailD
for FreeBSD 6.0 is used. For other Unix-based OSs,
names of files and directories may differ (namely,
the part with the Dr.Web MailD version number,
the OS version and the name of the used mail
system).

The distribution of Dr.Web MailD for FreeBSD is delivered as two

tarball-archives for manual installation: the drweb-maild-
qmail-4.44.1-freebsd60.tar.gz archive contains the
main modules of Dr.Web MailD; the drweb-updater-4.44.1-
freebsd60.tar.gz archive contains the updating utility of
Dr.Web MailD.
The main modules of Dr.Web MailD for FreeBSD are installed as
follows:

1 Save the archive with the main modules of Dr.Web MailD

onto a computer.
2 Log on as a root user. For this, execute the su command
and input the password of the root user.
3 Enter the directory where the archive is saved.
4 Extract files from the archive. A drweb-maild-
qmail-4.44.1-freebsd60 directory will be
created
Example:
> tar xzf drweb-maild-qmail-4.44.1-
freebsd60.tar.gz

15
Dr.Web® for Unix mail servers
Then, there are 2 modes to install the
software: the manual and the automatic.
The installation in the automatic mode is
done by the install.sh installation
script located in the drweb-maild-
qmail-4.44.1-freebsd60 directory
created during the unpacking of the
archive with the main modules. The
install.sh script does the following:
1 It saves the directory tree nested in the drweb-
maild-qmail-4.44.1-freebsd60 directory to
the root directory.
2 It creates the drweb user and the drweb group.

3 It sets rights to access directories of Dr.Web MailD.

4 In case Perl command processor is installed on the
computer, it calls a configure.pl configuration script,
which sets values for the main parameters of the
configuration file of Dr.Web MailD (you should only type
the values the script requires). If it is impossible to start
the configure.pl script, set the values for the main
parameters manually. (see p. 3.3).
5 It integrates Dr.Web MailD with a mail system

In case you cannot or do not want to use the install.sh script,

installation can be carried out in the manual mode:
1 Copy the directory tree nested in thedrweb-maild-
qmail-4.44.1-freebsd60 directory to the root
directory (you can set your own structure of directories,
but in this case you should edit the program’s
configuration file accordingly, read p. 3.3.1).
Example:

16
 > cp -pR drweb-maild-qmail-4.44.1-
freebsd60/* /
2 Create a drweb user and a drweb group. Then set
access rights to the directories:
Example:
> chown -R drweb:drweb /usr/local/etc/drweb
> chown -R drweb:drweb /usr/local/drweb
> chown -R drweb:drweb /var/drweb
3 Specify values for the main parameters of the
configuration file of Dr.Web MailD. If Perl command
processor is installed on the computer, you can set these
values by launching the configure.pl script which is
located in the /opt/drweb/maild/scripts/
directory (by default). The script will ask you to enter the
values of the necessary parameters and save them to the
configuration file.
In case you cannot or do not want to launch the
configure.pl script, specify the values for the main
parameters of the configuration file of Dr.Web MailD
manually (see p. 3.3).
4 Integrate Dr.Web MailD with a mail system (read.p. 5)

Then, the updating utility should be installed:

1 Copy the archive with the updating utility onto a computer
where the program is installed.
2 Change the current user of the system to the root user.
For this, execute the su command and input the
password of the root user in the corresponding dialog.
3 Go to the directory with the updating utility archive.
4 Unpack the archive. The drweb-updater-4.44.1-
freebsd60 directory will be created.

17
Dr.Web® for Unix mail servers
Example:
> tar xzf drweb-updater-4.44.1-
freebsd60.tar.gz
5 Copy the directory tree nested in the drweb-
updater-4.44.1-freebsd60 directory to the root
directory (you can also set your own structure of
directories, but you should edit Dr.Web MailD
configuration file accordingly, read p. 3.3.1).
Example:
> cp -pR drweb-updater-4.44.1-freebsd60/*
/
6 Set access rights for created directories.
Example:
> chown -R drweb:drweb /usr/local/etc/drweb
> chown -R drweb:drweb /usr/local/drweb
> chown -R drweb:drweb /var/drweb

2.3. Installing for Solaris

Examples given below describe installation of
Dr.Web MailD configured to operate with the Qmail
mail system. In all these examples Dr.Web MailD of
version 4.44.1 for Solaris is used. For other Unix-
based OSs the names of files and directories may
differ (namely, the part of the name of the Dr.Web
MailD version, the OS version and the name of the
used mail system).

The Dr.Web MailD for Solaris distribution is delivered as two

tarball-archives for manual installation: the drweb-maild-
qmail-4.44.1-solaris10.tar.gz archive contains the
main modules of Dr.Web MailD; the drweb-updater-4.44.1-
solaris10.tar.gz contains the Dr.Web MailD updating utility.

18
 1 Save the archive with the main modules of Dr.Web MailD
onto a computer.
2 Log on as a root user. For this, execute the su command
and enter the password of the root user.
3 Go to the directory the archive is saved.
4 Extract files from the archive. A drweb-maild-
qmail-4.44.1-solaris10, directory will be
created
Example:
> gzip -d drweb-maild-qmail-4.44.1-
solaris10.tar.gz
> tar xf drweb-maild-qmail-4.44.1-
solaris10.tar
Then, there are 2 modes to install the software: the manual and the
automatic. The installation in the automatic mode is done by the
install.sh installation script located in the drweb-maild-
qmail-4.44.1-solaris10 directory created during the
unpacking of the archive with the main modules of Dr.Web MailD.
The install.sh script does the following:

1 It saves the directory tree nested in the drweb-

maild-qmail-4.44.1-solaris10 directory to the
root directory.
2 It creates the drweb user and the drweb group.

3 It sets rights to access directories of Dr.Web MailD.

4 In case Perl command processor is installed on the
computer, it calls the configure.pl configuration
script, which sets values for the main parameters of the
configuration file of Dr.Web MailD (you should only type
the values the script requires). If it is impossible to start
the configure.pl script, set the values for the main
parameters manually. (see p. 3.3).

19
Dr.Web® for Unix mail servers
5 It integrates Dr.Web MailD with a mail system

In case you cannot or do not want to use the install.sh script,

installation can be done in the manual mode:
1 Copy the directory tree nested in the drweb-maild-
qmail-4.44.1-solaris10 directory to the root
directory (you can set your own structure of directories,
but in this case you should edit the program’s
configuration file accordingly, read p. 3.3.1).
Example:
> cp -pR drweb-maild-qmail-4.44.1-
solaris10/* /
2 Create the drweb user and the drweb group. Then set
access rights to the directories:
Example:
> chown -R drweb:drweb /etc/drweb
> chown -R drweb:drweb /opt/drweb
> chown -R drweb:drweb /var/drweb
3 Specify the values for the main parameters of the
configuration file of Dr.Web MailD. If Perl command
processor is installed on the computer, you can set these
values by launching the configure.pl script which is
located in the /opt/drweb/maild/scripts/
directory (by default). The script will ask you to enter the
values of the necessary parameters and save them to the
configuration file.
In case you cannot or do not want to launch the
configure.pl script, specify the values for the main
parameters of the configuration file of Dr.Web MailD
manually (see p. 3.3).
4 Integrate Dr.Web MailD with a mail system (read p. 5)

20
Then, the updating utility should be installed
1 Copy the archive with the updating utility onto a computer
where the program is installed.
2 Change the current user of the system to the root user.
For this, execute the su command and input the
password of the root user into the corresponding dialog.
3 Go to the directory with the archive of the updating utility.
4 Unpack the archive. The drweb-updater-4.44.1-
solaris10 directory will be created.
Example:
> gzip -d drweb-updater-4.44.1-
solaris10.tar.gz
> tar xf drweb-updater-4.44.1-solaris10.tar
5 Move the directory tree nested in the drweb-
updater-4.44.1-solaris10 directory to the root
directory (you can also set your own structure of
directories, but you will have to edit the Dr.Web MailD
configuration file accordingly, read p. 3.3.1).
Example:
> cp -pR drweb-updater-4.44.1-solaris10/* /

6 Set access rights for created directories.

Example:
> chown -R drweb:drweb /etc/drweb
> chown -R drweb:drweb /opt/drweb
> chown -R drweb:drweb /var/drweb

21
Dr.Web® for Unix mail servers
2.4. Upgrading for Linux
The examples below describe the upgrade of
Dr.Web MailD configured to operate with the Qmail
mail system. In all these examples Dr.Web MailD v.
4.44.1 for Linux based on glibc 2.3 is used. In other
cases, names of files and directories will differ
accordingly (namely, the part of the Dr.Web MailD
version number, the glibc version and the name of
the mail system will differ).

The Dr.Web MailD distribution for Linux is delivered as two tar-

archives: the drweb-maild-qmail-4.44.1-
glibc2.3.tar.gz archive contains the main modules of Dr.Web
MailD; the drweb-updater-4.44.1-glibc2.3.tar.gz
archive contains the updating utility of Dr.Web MailD.
The main modules of Dr.Web MailD for Linux are upgraded as
follows:
1 Copy the archive with the main modules of Dr.Web MailD
onto a computer where the program will be upgraded.
2 Change the current user of the system to the root user.
For this, execute the su command and input the
password of the root user in the corresponding dialog.
3 Go to the directory with the archive with the main modules
of Dr.Web MailD.
4 Unpack the archive. The drweb-maild-
qmail-4.44.1-glibc2.3 directory will be created.
Example:
> tar xzf drweb-maild-qmail-4.44.1-
glibc2.3.tar.gz
5 The install.sh installation script is located in the
drweb-maild-qmail-4.44.1-glibc2.3 created
during the unpacking of the archive with the main modules

22
 of Dr.Web MailD. To upgrade Dr.Web MailD, launch this
script with the update parameter. Being launched with
this parameter, the install.sh script performs the
following actions:
5.1Terminates the already installed Dr.Web MailD
5.2Copies the directory tree nested in the drweb-
maild-qmail-4.44.1-glibc2.3 directory to the
root directory and files of the installed version of Dr.Web
MailD replace all files of the already installed Dr.Web
MailD, except for configuration files. The configuration
files of the already installed Dr.Web MailD remain
unchanged. During the replacement of the configuration
files of the new version of Dr.Web MailD the script adds
the .new suffix to their names.
5.3Sets access rights for Dr.Web MailD directories.
5.4If necessary, integrates Dr.Web MailD with a mail
system.

Then, the updating utility should be upgraded:

6 Copy the archive with the updating utility onto a computer
where the program is installed.
7 Change the current user of the system to the root user.
For this, execute the su command and input the
password of the root user into the corresponding dialog.
8 Go to the directory with the archive of the updating utility.
9 Unpack the archive. The drweb-updater-4.44.1-
glibc2.3 directory will be created.
Example:
> tar xzf drweb-updater-4.44.1-
glibc2.3.tar.gz
10 Copy the directory tree nested in the drweb-
updater-4.44.1-glibc2.3 directory to the root
directory (you can also set your own structure of

23
Dr.Web® for Unix mail servers
directories, but you should edit the Dr.Web MailD
configuration file accordingly, read p. 3.3.1).
Example:
> cp -a drweb-updater-4.44.1-glibc2.3/* /
11 Set access rights for created directories.
Example:
> chown -R drweb:drweb /etc/drweb
> chown -R drweb:drweb /opt/drweb
> chown -R drweb:drweb /var/drweb

2.5. Upgrading for FreeBSD

The examples below describe the upgrade of
Dr.Web MailD configured to operate with the Qmail
mail system. In all these examples Dr.Web MailD v.
4.44.1 for FreeBSD v. 6.0. is used. In other cases,
names of files and directories will differ accordingly
(namely, the part of the Dr.Web MailD version
number, the OS version and the name of the mail
system will differ).

The Dr.Web MailD distribution for FreeBSD is delivered as two tar-

archives: the drweb-maild-qmail-4.44.1-
freebsd60.tar.gz archive contains the main modules of
Dr.Web MailD; the drweb-updater-4.44.1-
freebsd60.tar.gz archive contains the updating utility of
Dr.Web MailD.
The main modules of Dr.Web MailD for FreeBSD are upgraded as
follows:
12 Copy the archive with the main modules of Dr.Web MailD
onto a computer where the program will be upgraded.
13 Change the current user of the system to the root user.
For this, execute the su command and input the
password of the root user into the corresponding dialog.

24
 14 Go to the directory with the archive with the main modules
of Dr.Web MailD.
15 Unpack the archive. The drweb-maild-
qmail-4.44.1-freebsd60,
Example:
> tar xzf drweb-maild-qmail-4.44.1-
freebsd60.tar.gz
16 The install.sh installation script is located in the
drweb-maild-qmail-4.44.1-freebsd60
directory created during the unpacking of the archive with
the main modules of Dr.Web MailD. To upgrade Dr.Web
MailD, run the script with the update parameter. Being
launched with such parameter, the install.sh script
will perform the following actions:
16.1Terminates the already installed Dr.Web MailD
16.2Copies the directory tree nested in the drweb-
maild-qmail-4.44.1-freebsd60 directory to
the root directory and files of the installed version of
Dr.Web MailD replace all files of the already installed
Dr.Web MailD, except for configuration files. The
configuration files of the already installed Dr.Web MailD
remain unchanged. During the replacement of the
configuration files of the new version of Dr.Web MailD
the script adds the .new suffix to their names.
16.3Sets access rights for Dr.Web MailD directories.
16.4If necessary, integrates Dr.Web MailD with a mail
system.

Then, the updating utility should be upgraded:

1 Copy the archive with the updating utility onto a computer
where the program will be installed.

25
Dr.Web® for Unix mail servers
2 Change the current user of the system to the root user.
For this, execute the su command and input the password
of the root user into the corresponding dialog.
3 Go to the directory with the archive of the updating utility.
4 Unpack the archive. The drweb-updater-4.44.1-
freebsd60 directory will be created.
Example:
> tar xzf drweb-updater-4.44.1-freebsd60.tar.gz
5 Copy the directory tree nested in the drweb-
updater-4.44.1-freebsd60 to the root directory
(you can also set your own directory tree, but you will
have to edit the Dr.Web MailD configuration file
accordingly, read p. 3.3.1).
Example:
> cp -pR drweb-updater-4.44.1-freebsd60/* /
6 Set access rights for created directories.
Example:
> chown -R drweb:drweb /usr/local/etc/drweb
> chown -R drweb:drweb /usr/local/drweb
> chown -R drweb:drweb /var/drweb

2.6. Upgrading for Solaris

The examples below describe the upgrade of
Dr.Web MailD configured to operate with the Qmail
mail system. In all these examples Dr.Web MailD v.
4.44.1 for Solaris 10.0 is used. In other cases,
names of files and directories will differ accordingly
(namely, the part of the Dr.Web MailD version
number, the OS version and the name of the mail
system will differ

The Dr.Web MailD distribution for Solaris is delivered as two tar-

archives: the drweb-maild-qmail-4.44.1-

26
solaris10.tar.gz contains the main modules of Dr.Web
MailD; the drweb-updater-4.44.1-solaris10.tar.gz
archive contains the updating utility of Dr.Web MailD.
The main modules of Dr.Web MailD for Solaris are upgraded as
follows:
7 Copy the archive with the main modules of Dr.Web MailD
onto a computer where the program will be upgraded.
8 Change the current user of the system to the root user.
For this, execute the su command and input the password
of the root user into the corresponding dialog.
9 Go to the directory with the archive with the main modules
of Dr.Web MailD.
10 Unpack the archive. The drweb-maild-qmail-4.44.1-
solaris10,
Example :
> gzip -d drweb-maild-qmail-4.44.1-solaris10.tar.gz
> tar xf drweb-maild-qmail-4.44.1-solaris10.tar
11 The install.sh script is located in the drweb-maild-
qmail-4.44.1-solaris10 directory created during the
unpacking of the archive with the main modules of Dr.Web
MailD. To upgrade Dr.Web MailD, run the script with the
update parameter. Being launched with such parameter,
the install.sh script performs the following actions:
11.1Terminates the already installed Dr.Web MailD
11.2Copies the directory tree nested in the drweb-
maild-qmail-4.44.1-solaris10 directory to
the root directory and files of the installed version of
Dr.Web MailD replace all files of the already installed
Dr.Web MailD, except for configuration files. The
configuration files of the already installed Dr.Web MailD
remain unchanged. During the replacement of the
configuration files of the new version of Dr.Web MailD
the script adds the .new suffix to their names.

27
Dr.Web® for Unix mail servers
11.3Sets access rights for Dr.Web MailD directories.
11.4If necessary, integrates Dr.Web MailD with a mail
system.

Then, the updating utility should be upgraded:

12 Copy the archive with the updating utility onto a computer
where the program will be installed.
13 Change the current user of the system to the root user.
For this, execute the su command and input the
password of the root user into the corresponding dialog.
14 Go to the directory with the archive of the updating utility.
15 Unpack the archive. The drweb-updater-4.44.1-
solaris10
Example :
> gzip -d drweb-updater-4.44.1-
solaris10.tar.gz
> tar xf drweb-updater-4.44.1-solaris10.tar
16 Copy the directory tree nested in the drweb-
updater-4.44.1-solaris10 to the root directory
(you can also set your own directory tree, but you should
edit the Dr.Web MailD configuration file accordingly, read
p. 3.3.1).
Example :
> cp -pR drweb-updater-4.44.1-solaris10/* /
17 Set access rights for the created directories.
Example :
> chown -R drweb:drweb /etc/drweb
> chown -R drweb:drweb /opt/drweb
> chown -R drweb:drweb /var/drweb

28
 2.7. Deinstalling
When uninstalling Dr.Web MailD, it is recommended to save (copy to
a safe location) license key files, log files of various components of
Dr.Web MailD, and configuration files. Before the program is
uninstalled, the launched components must be terminated.

If Dr.Web MailD and its plug-ins were installed automatically by the

install.sh script, you can uninstall the program automatically
too, with the help of the uninstall scripts. These scripts are located in
the %bin_dir/maild/scripts directory.

The uninstall.sh script uninstalls Dr.Web MailD and its plug-ins.

The scripts named as plugin_NAME_uninstall.sh, where
NAME, – is the name of the plug-in, uninstall the corresponding plug-
ins.

If Dr.Web MailD was installed manually, just delete all files and
directories created during the installation to uninstall Dr.Web MailD.
If necessary, you can also delete the drweb user and the drweb
group by standard OS tools.

2.8. Software registration. License key file

User’s rights to use Dr.Web MailD and its plug-ins are regulated by
the special file called the key file. The key file contains, in particular,
the following information:
• a list of plug-ins for Dr.Web MailD the user is allowed to use
(operation of some plug-ins for example headersfilters does not
depend on names of these plug-ins being included to the key
file);
• the license term of usage
• other restrictions (i.e. a number of messages a Dr.Web MailD
can analyze each day)

29
Dr.Web® for Unix mail servers
The key file has the key extension and must be located by default in
the installation directory.

The key file has a write-protected format and

therefore must not be edited. Editing the file makes
it invalid. Consequently, it is not recommended to
open your key file with a text editor, which may
occasionally corrupt it.

If you place the key file to a different directory than the program
installation directory, you should specify its location in the
LicenseFile parameter of the StandaloneMode section of
the configuration of the Agent component (read p. 3.4.6)
If the key file cannot be read (wrong path or not enough rights,
usage term expired, blocked or wrong key), the system terminates its
operation.

2.8.1. Using several key files

Several key files can be used in Dr.Web MailD. All the plug-ins
licensed to a customer comprise the list of plug-ins (this list must
have at least one plug-in). Limitations of the definite plug-in are sum
total of limitations set for this plug-in in different key files.
During the operation of Dr.Web MailD all plug-ins must have identical
limitations. If different license limitations are set for different plug-
ins, Dr.Web MailD uses the greater limitation.
Example:
Three key files are used. One is for the drweb plug-in and
has limitation to check 10000 messages a day. The second
key file is for the vaderetro plug-in and has limitation to
check 15000 messages a day. The third key file is also for the
drweb plug-in and has limitation to check 10000 messages a
day.
As a result, Dr.Web MailD can operate with drweb and
vaderetro plug-ins specified in key files.

30
 The limitation for check of messages is set for 15000
messages a day as for the vaderetro plug-in the limitation
is set for 15000 a day, the sum of two different key files has
the limitation for 20000 messages a day for the drweb plug-
in. Dr.Web MailD chooses the greater limitation of 15000
messages a day.

2.8.2. License and demo key files

Users who have purchased the anti-virus from Doctor Web authorized
partners receive a license key file. The parameters of the key file are
specified according to the license a user has purchased. The license
key file contains the name of the user (or a company name), and the
name of the selling company.
If a user needs to extend the licensed rights of the purchased key file
additional license key files can be purchased and used together with
the key file purchased earlier. The licensed rights of the key files
used simultaneously are summed up subject to the rule described
above in this section.
For evaluation purposes users may also obtain demo key files. Demo
key files allow to enjoy full functionality of the program and the virus
definitions updates, but have a limited term of use and no users’
support is provided.

2.8.3. Key files delivery

The key file may be supplied with the key extension, or as a zip
archive containing the key file.
The key file may be received in one of the following ways:
• supplied or sent as a zip archive containing a file with the
key extension (usually after the registration on the web
site, explained below). Extract the key file using the
appropriate archiving tool and place it to the directory where
the program’s executable files reside (by default it is /opt/

31
Dr.Web® for Unix mail servers
drweb for Linux and Solaris, /usr/local/drweb for
FreeBSD and OpenBSD)
• included into the distribution package
• supplied on a media as a file with the .key extension. The
user should copy it manually to the directory specified above
The license key file is sent to users via email, as a rule, after the
registration on the web site (the location of the web site is specified
in the registration card accompanying the product). Visit this site, fill
in the web form with the customer data and type the registration
serial number (printed in the registration card). The key file will be
sent to the specified address.

2.8.4. Restoring lost key files

Please keep the key files until they expire. If Dr.Web MailD is
reinstalled, the same key file(s) can be used. If a license key file is
lost, you can register and receive the license key file again. During
such registration the same serial number and personal data should
be specified. Only e-mail address may be different. In this case
technical support service will send key files to your new e-mail
address.
The number of requests for a key file is limited to 25 times. To
restore your license key file in case when you have registered your
license key file more than 25 times, you should send a support
request at http://support.drweb.com/request/. To restore your key
file specify the data input during the registration and your e-mail
address and describe your request in details. The key file will be sent
to you by the technical support service.

32
3. Operation
Dr.Web MailD is a group of interacting program modules. Program
modules process messages according to the following algorithm:
• A component called Receiver deals with incoming
messages first. Then Receiver directs them to
Checker – a component responsible for scanning of
messages.
• The Checker component calls plug-ins one by one,
which assures complete analysis of messages.
• Messages that pass the analysis are delivered to the mail
system by the Sender component.

• During their operation, program modules can generate

reports on messages check results. These reports are
generated by the Notifier component and can be sent
to senders and recipients of messages, as well as system
administrator.
Message processing by Dr.Web MailD can be customized by rules
described in p. 3.6.

3.1. Program files location

• By default, Dr.Web MailD is installed to %bin_dir,
%etc_dir and %var_dir directories.
A structure of subdirectories in these directories does not depend on
used OSs.
Files of the program executable modules are located in the
%bin_dir directory.
Configuration files –
%etc_dir/agent.conf
%etc_dir/monitor.conf

33
Dr.Web® for Unix mail servers
%etc_dir/maild_{mail system name}.conf

Language resources files –

%etc_dir/maild/
Documentation is located in the %bin_dir/doc directory.

Program documentation is represented by several text files in two

versions – in English and in Russian (KOI8-R and UTF-coded texts).
The %var_dir/infected directory is used to store messages
moved there in case the anti-virus plug-in is configured to quarantine
infected and suspicious files.

3.2. Command line options. Signals processed by

Dr.Web modules
In general, the command line for Dr.Web MailD modules will look as
follows: module_name [-options] agent_socket, where:

• module_name – name of a Dr.Web MailD module;

• options – additional command line options. Information on
description of command line options for the Dr.Web MailD
modules is given below;
• agent_socket – a socket through which the Dr.Web MailD
modules receive configuration data from the Dr.Web agent.
For details see description of the agent (p. 3.4.6).

As for any Unix-program, for modules of Dr.Web MailD command line

options are used. A full list of options is available on starting the
module with the –h or –help option. In the current version of
Dr.Web MailD the following command line options are supported:
• -v, --version – displays information on the current
version of the program;

34
 • -l <level>, --level<level> — sets details level
for the startup log of Dr.Web MailD. Default value: info
• -t <value, in sec>, -timeout<value, in
sec> – timeout for receiving configuration data
Example:
drweb-maild -t 30 local:/var/drweb/ipc/.agent
– to start the main module of Dr.Web MailD with 30 second timeout
to receive configuration data and the following socket address
local:/var/drweb/ipc/.agent.
Some modules of Dr.Web MailD support specific command line
options. This will be discussed separately.
All the modules staying constantly in program’s memory support
processing of the following signals:
• SIGHUP. When this signal is received, the modules reread
their configuration files. When such a signal is received by
the Monitor module, configuration files are reread by all
launched modules.
• SIGINT and SIGTERM – having received one of these
signals the modules terminate.
Some modules of Dr.Web MailD may support processing of additional
signals, which is described in each case separately.

3.3. Configuring and starting the program

You can start Dr.Web MailD with default settings but it is
recommended to configure it according to your preferences and
usage demands. Dr.Web MailD settings are specified in 3
configuration files, located in the %etc_dir directory.
drweb_maild.conf contains settings for Dr.Web MailD;
agent.conf contains settings for Agent component;
monitor.conf contains settings for Monitor component.

35
Dr.Web® for Unix mail servers
Basic configuration of Dr.Web MailD (provided all files of the system
are located in default directories) includes the following parameters:
• In [Maild] section:

 ProtectedNetworks
 ProtectedDomains
 InMaxThreads
 OutMaxThreads
• In [Notifier] section
 AdminMail
 FilterMail
 NotifyLangs
• In [Filters] section

 BeforeQueueFilters
 AfterQueueFilters
If a Perl command processor is installed on the computer, you can
set these values by launching the configure.pl script which is
located in the %bin_dir/maild/scripts/directory (by
default). The script will ask you to enter the values of the necessary
parameters and saves them to the configuration file.

Apart from the indicated parameters, you must set additional

parameters of the configuration file of Dr.Web MailD. A number of
such parameters depend on the used mail system (see p.5).

3.3.1. Editing configuration files

Configuration files of Dr.Web MailD are text files (therefore, you can
make changes to these files using almost any suitable editor). These
text files have the following structure:
--- beginning ---
[Section name 1]

36
Parameter1 = value1, ..., valueK
.....
ParameterM = value1, ..., valueK
......
[Section name X]
Parameter1 = value1, ..., valueK
.....
ParameterY = value1, ..., valueK
--- end ---

";" and "#" symbols in the configuration file are used to mark the
beginning of comments. Text that goes after these symbols in each
line is ignored by modules of the Dr.Web MailD when they read
parameters of the configuration file.
If a certain parameter of the configuration file is not specified, it does
not mean that this parameter has no value (this mistake frequently
occurs when customizing software). In this case the default value is
used.
For some parameters default value is automatically specified when
the parameters are not defined correctly. Only a few parameters are
optional or do not have default values. They will be described later.
If some value of the parameter is specified incorrectly, Dr.Web MailD
displays an error message and terminates.
If during the load of any configuration file unknown parameters are
detected, Dr.Web MailD continues to operate and a corresponding
message is written to a log file.
Values can be set in commas (and must be set in commas if they
contain blanks).
Some parameters can have several values. In this case values either
are delimited using "," (comma) or parameter’s value is specified
several times in different lines of the configuration file. When it is
possible to specify several values for a certain parameter, it is
indicated explicitly.
Examples:

37
Dr.Web® for Unix mail servers
Values are delimited using commas:
Names = drweb, headersfilter
A value is specified in several lines of the configuration file:
Names = drweb
Names = headersfilter

In this Manual parameters are described as follows:

• ParameterName = {Parameter type|possible
values of parameter}
• Its description
• {whether several values are possible}

• Default value: {value|not specified}

Parameters are described in the same order as they are given in the
configuration file created during installation of the program. The
exact set of parameters in the configuration file depends on a mail
system the version of Dr.Web MailD is designed for.
In the Parameter type field you can enter the following values:

• Digital value – parameter’s value is a whole, positive number;

• Time – value is specified in time units. Value consists of a whole
number that can be followed by a letter which denotes a time unit
(s - seconds, m - minutes, h – hours; register is not important).
If parameter’s value does not contain a letter, it means that a second
is used as the time unit.
Example: 30s, 15m;

• Size – parameter’s value is specified in units used for measuring

computer memory and storage. The value consists of a whole number
that can be followed by a letter which denotes a size unit (b – bytes, k
– kilobytes, m – megabytes, g - gigabytes, the register is not
important)
If parameter’s value does not contain a letter, it means that bytes are

38
 used as the size unit.
Examples: 20b, 15k;

• Path to file|directory – defines location of a file or

directory in the system;
• Actions – defines actions applied to messages by plug-ins of
Dr.Web MailD. Actions are divided into 2 groups: main and optional.
For each parameter that has action type you must specify 1 main
action and 3 optional actions. Main action is specified first.
For different parameters a set of possible main actions is different.
Possible main actions are the following:
o Cure instructs to cure infected object;
o Remove instructs to delete infected object
o Discard instructs to delete a message without any
notifications;
o Pass allows message;
o Reject blocks message;
o Tempfail instructs to generate notification informing that
dispatch of the message is temporarily impossible
Possible optional actions are the following:
o Quarantine – move message to the quarantine directory;
o Redirect[(mail address)] – move a message to the
address specified in brackets. If the address is not specified,
the message is sent to the address specified in the
RedirectMail parameter;
o Notify – send a notification on event.
• Address defines socket addresses for the components of Dr.Web
MailD and external modules. These parameters are set in the
TYPE:ADDRESS format. The following types are possible:

39
Dr.Web® for Unix mail servers
o inet – TCP sockets are used. Address must be specified
in the PORT@HOST_NAME format
HOST_NAME can be IP address or host domain name.
Example: Address = inet:3003@localhost

o local – local unix sockets are used. In this case ADDRESS

is a path to the socket file.
Example: Address =
local:/var/drweb/run/.drwebd
o pid instructs to read address of the process from the pid-
file. This type of address is available only in special cases and
if this type can be specified, it is indicted explicitly.
• Text – parameter’s value is specified as a text string. Text can
be set in quotes (if there are blanks in the string, you must use
quotes).
• Strings and files – a set of textual values separated
with commas. If the parameter value equals to the
file:/PATH_TO_FILE template, where PATH_TO_FILE
– is the path to a file, then textual values are received from the
PATH_TO_FILE file. Each value in the PATH_TO_FILE file
should be written in a separate line. If during the receipt of
information from the PATH_TO_FILE file an error occurs, a
corresponding message is written to a log file and the loading of
the program continues.
• Other values – parameters can also have a type that has not
been described above.
• For parameters that define logging details for subsystems of
Dr.Web MailD the following values are possible (all possible
values are indicated for each parameter):
 Quiet – disable logging;
 Fatal – log only critical errors;

40
  Error – log all errors;
 Warn (alert) – log errors and alerts;
 Info – log errors, warnings and notifications
 Debug – detailed logging of all events (used for
debugging purposes)

[General] section
This section includes settings that affect operation of Dr.Web MailD.

BaseDir = {path to directory}

Dr.Web MailD base directory where sockets, database etc. are stored.
At program restart initiated upon receiving HUP signal, in the current
version of the Dr.Web MailD this parameter cannot be changed.
Default value: /var/drweb

MaxTimeoutForThreadActivity = {time}
Timeout to close a thread. The parameter is applied when Dr.Web
MailD is restarted or shut down. Timeout for Dr.Web MailD to shut
down can be calculated in the following way: multiply the number of
pools by the value of the MaxTimeoutForThreadActivity
parameter and add a specified time constant "to be more accurate".
Default value: 30s.

IpcTimeout = {time}
Timeout to establish interaction between components of Dr.Web
MailD.
Default value: 40s

41
Dr.Web® for Unix mail servers
Hostname = {text}
Name of the host under which the program operates. If the value is
not specified, the value returned by the gethostname (3) function is
used.
Default value: no value

[Logging] section
This section includes parameters that define level of logging details
for the basic modules of Dr.Web MailD.
Level = {Quiet|error|Alert|info|debug}
Defines level of logging details.
Default value: Info

IpcLevel = {Quiet|error|Alert|info|debug}
Level of logging details for Ipc library.
Default value: Alert

SyslogFacility ={Daemon|Mail|Local0 .. Local7}

Type of facility which syslogd service uses to generate notifications
on events (for details refer to documentation on syslog).
Default value: Mail

[MailBase] section

This section includes settings of the database of Dr.Web MailD

MaxStoredMessages ={number}
Maximum number of messages stored in the database (0 – number
of messages is not limited). If the number of messages in the

42
database exceeds the number specified in this parameter, old
messages are deleted from the database until the necessary number
of messages is reached. The messages already sent are immediately
deleted. The messages which are not sent yet are being sent and
deleted.
Default value: 100000

MaxStorageSize = {size}
Maximum size of the database, specified in bytes. (0 – means that
size is not limited). If the size of the database exceeds the database
limit, the database is cleaned from old messages until necessary size
of the database is reached (read description of the
MaxStoredMessages parameter).
Default value: 0

MaxPoolSize = {digital value}

Maximum size of database pool. Parameter's value defines a number
of memory areas of 8K allocated for DB pool. If value is set to 0, the
program automatically determines it, on the basis of available
physical memory. In the current version of Dr.Web MailD at restart
with HUP, the parameter cannot be changed.
Default value: 0

FrozenTimeout = {time}
Additional time for processing a message. If plug-in cannot process a
message within the specified time, in the SendTimeout parameter
time can be extended by a value specified in FrozenTimeout
parameter. In the current version of Dr.Web MailD, additional time
for processing messages can be set only for anti-spam plug-in and
must be enabled explicitly.

43
Dr.Web® for Unix mail servers
Default value: 2h

DeleteTimeout = {time}
Time period for message to be stored in database. The value of
DeleteTimeout must be greater than the value of the
FrozenTimeout timeout
Default value: 48h

BackupPeriod= {value}
Time period to backup database. If value is set to 0, no backup is
performed.
Default value: 0

BackupName = {file name}

Name of database backup file. If a file name ends with a question
mark – "?", each backup is saved to a separate file, and question
mark in the file name is replaced with current time.
Default value: /var/drweb/msgs/db/.maildb.backup

[Filters] section

This section includes general settings of the plug-ins

LibDir = {path to directory}

Directory where Dr.Web MailD plug-ins are located
Default value:
• In Dr.Web MailD for Linux and Solaris
–/opt/drweb/maild/plug-ins;

44
 • In Dr.Web MailD for FreeBSD – /usr/local/drweb/
maild/plug-ins

Settings = {plug-ins settings}

Parameters that affect loading of plug-ins of Dr.Web MailD.
Settings of plug-ins are indicated in the following format (use a
comma as a delimiter): plug-in name: [parameter1]|
[parameter2] ...,
Parameters are given along with their values – parameter name
= parameter value.
Parameter values (apart from paths to files) are not case sensitive. In
the current version of Dr.Web MailD the following parameters can be
set for plug-ins:
section = {text} – name of a section of the configuration
file where parameters that affect operation of the plug-in can
be found.
By default, name of the section is taken from the plug-in.

max_size = {size}
Max size of a message to scan. 0 – there is no limitation.
Limitation to size by default depends on the queue the plug-in
is started from and is defined by the value of the
MaxSizeBeforeQueueFilters or
MaxSizeAfterQueueFilters parameter.

log_level = {Quiet|Error|Alert|Info|Debug}
log details level of a plug-in.
default value coincides with the value of the Level
parameter in the [Logging] section.

45
Dr.Web® for Unix mail servers

log_ipc_level = {Quiet|Error|Alert|Info|
Debug}
Logging details for Ipc library
Default value of this parameter coincides with the value of the
IpcLevel parameter of the [Logging] section.

syslog_facility = {Daemon|Mail|Local0 ..
Loca7}
Type of facility that syslog service uses to generate
notifications on events (for details refer to documentation on
syslog).
Default value coincides with the value of the
SyslogFacility parameter of the [Logging] section.

print_to_console = {yes|no}
yes value instructs plug-in to display its log in the console.
Default value coincides with the value of the
PrintToConsole parameter of the [Logging] section.
path_to_lib = {path to file}
Path to the plug-in’s library. The path can be either relative or
absolute one. If relative, path to the library is set with regard
to the directory specified by the LibDir parameter in the
[Filters] section. Default value is formed in the following
way: to the value of the LibDir parameter add /lib line
and then a name of the plug-in with the .so extension. The
name of the plug-in is written in small letters. For example,
for VadeRetro plug-in for the Dr.Web MailD installed on
Linux with default settings, the path will be as follows:

46
 –/opt/drweb/maild/plug-
ins/libvaderetro.so

Examples:
Settings = vaderetro: max_size = 400k|
log_level=debug, drweb: max_size = 10m
This line sets for the vaderetro plug-in the maximum size
of a message to 400 Kb and logging details to debug, and
for drweb plug-in maximum size of a message to 10 Mb.

Default value: not specified

BeforeQueueFilters = {list of filters}List of plug-ins

that process a message before it is moved to the database of Dr.Web
MailD (read p. 3.4.1).
Default value: drweb

MaxSizeBeforeQueueFilters = {size}
Maximum size of a message to be processed by plug-ins defined as
BeforeQueueFilters. This parameter affects only plug-ins for
which a maximum size of a message is not specified separately. In
case 0 is specified, there is no limitation to the size of the message.

Default value: 0

AfterQueueFilters = {list of plug-ins}

List of plug-ins that process a message after they are moved to the
database of Dr.Web MailD (read p. 3.4.1).
Default value: not specified.

47
Dr.Web® for Unix mail servers
MaxSizeAfterQueueFilters = {size}
Maximum size of a message to be processed by plug-ins defined as
AfterQueueFilters. This parameter affects only plug-ins for
which a maximum size of a message is not specified separately. In
case 0 is specified, there is no limitation to the size of the message.

Default value: 0

Plug-insBaseDir = {path to directory}

A directory for files of plug-ins.
Default value: /var/drweb/plug-ins

[Stat] section
This section includes parameters that affect collection of statistics on
operation of Dr.Web MailD.

Send = {yes|no}
This parameter defines whether the statistics on operation of Dr.Web
MailD is sent to the statistics server (or to the ES server in case
Dr.Web anti-virus system operates within the anti-virus network
created with Enterprise Suite). In case Send = yes, statistics are
sent, otherwise not sent.
Default value: Yes.

SendPeriod ={value}
Time interval to send statistics on operation of Dr.Web MailD to the
server.
Default value: 10m

48
Timeout = {time}
Timeout to wait for response from the statistics server.
Default value: 30s

[Reports] section
In this section parameters that affect generation and dispatch of
reports on operation of the plug-ins of Dr.Web MailD.

Send = {yes|no}
This parameter defines dispatch of reports. In case Send = yes is
specified reports are sent, otherwise not sent.
Default value: yes.

SendPeriod = {time}
The parameter defines time interval to generate and send reports.
Default value: 24h

Mail = {email address}

Email address for reports to be sent to. If address is not specified,
reports are sent to address specified in the AdminMail parameter
of [Notifier] section. Several parameters divided by commas
may be specified as the parameter's value. Report will be sent to all
specified addresses.
Default value: not specified

Names = {list of plug-ins}

List of plug-ins on which operation report is created.

49
Dr.Web® for Unix mail servers
If parameter is not specified, report is created for plug-ins set as
BeforeQueueFilter and AfterQueueFilter in the
[Filters] section.

Default value: not specified

MaxPoolSize = {digital value}

The parameter sets a number of memory areas of 8K allocated for
reports database. If parameter is set to 0, program automatically
determines it on the basis of the available physical memory. In the
current version of Dr.Web MailD at restart with HUP the parameter
cannot be changed.
Default value: 100

TopListSize = {digital value}

This parameter sets for displaying in report lists of frequently blocked
objects and their addresses from which the maximum number of
blocked objects are sent. The value of the TopListSize
parameter defines a number of entries in each list. If
TopListSize=0, lists are not created. If TopListSize=-1, size
of lists is not limited.
Default value: 20

[Maild] section

This section includes general parameters that affect operation of

Dr.Web MailD.

ProtectedNetworks = {Strings and files}

List of networks protected with Dr.Web MailD. Either a list of IP-
addresses or masks of IP-addresses is allowed.

50
Example: ProtectedNetworks = 10.0.0.0/24,
127.0.0.0/8, 192.168.0.68
Default value: not specified

ProtectedDomains = {Strings and files}

List of domains protected with the Dr.Web MailD.
Example: ProtectedDomains = example.ru,
example.com
Default value: localdomain.ru, localdomain.com.

IncludeSubdomains = {yes|no}
With yes specified, sub domains which are indicated in
ProtectedDomains parameter are protected.
Default value: yes

InMaxThreads = {digital value}

Maximum number of pool threads for incoming messages.
Default value: 3

OutMaxThreads = {digital value}

Maximum number of pool threads for outgoing messages
Default value: 3

RedirectMail = {email address}

Email address to which messages are sent when Redirect action
is applied
Default value: root@localhost

51
Dr.Web® for Unix mail servers

Quarantine = {path to directory}

Quarantine directory.
Default value: /var/drweb/infected

QuarantineFilesMode = {digital value}

Rights set for files moved to quarantine.
Default value: 0660

QuarantineFilenamesMode = {Std|Tai|Rand48}
There are several modes that determine the process of naming of
quarantined files:
• Std – names of files are created with mkstemp command.
The %QuarantineFilenamesPrefix.XXXXXX
template is used, where
%QuarantineFilenamesPrefix is a prefix, specified
by the QuarantineFilenamesPrefix parameter, and
XXXXXX is a combination of random letters and figures.
• Tai – names of files are created according to the TAI
format. The sec.%usec.
%QuarantineFilenamesPrefix.XXXXXX
template is used;
• Rand48 – names of files are created with the lrand48
command. The
%QuarantineFilenamesPrefix.XXXXXXXX.
template is used.
Default value: Std

QuarantineFilenamesPrefix ={text value}.

Prefix added to the name of file moved to quarantine is specified as

52
%QuarantineFilenamesPrefix.
Default value: drweb.quarantine

LicenseLimit = {actions}
This parameter defines actions that should be applied to messages
which have not been scanned due to license limitations.
Possible main actions: pass, discard, reject and other
additional actions.
Default value: pass

EmptyFrom = {Actions}
The parameter defines actions applied to messages with a blank
SMTP envelope of the sender. Such messages are generated when
the mail notifications are created or by spammers. The following
main actions are possible: continue, discard and reject.
Additional actions are also possible.
Default value: continue

ProcessingErrors ={actions}
This parameter defines what action should be applied to messages
that generate errors at scanning.
Possible main actions: tempfail, pass, discard, reject

All additional actions are possible

Default value: pass

RulesLogLevel = {Quiet|Error|Alert|Info|Debug}
Logging level for rules processor
Default value: Info

53
Dr.Web® for Unix mail servers

PidFile = {path to file}

Path to the pid-file of drweb-maild process

Default value: /var/drweb/run/drweb-maild.pid

In case Dr.Web MailD blocks a message, its SMTP-reply contains an

error code (550 5.7.0) and a text message which is defined by
the parameters described below. Values of parameters should be
specified in quotes.

UseCustomReply = {yes|no}
In case yes value is set for this parameter, contents of SMTP-
responses of Dr.Web MailD are specified by the parameters given
below. When no is set, default values are used.

Default value: no

ReplyEmptyFrom = {text value}

SMTP-reply, generated in cases when a message is blocked due to
the fact that SMTP envelope of the sender is missing.
Default value: "DrWEB maild: Messages from <> are
blocked by administrator."

ReplyError = {text value}

SMTP-reply to messages blocked due to program errors.
Default value: "DrWEB maild: Message is rejected
due to software error."

54
[Receiver] section

This section includes parameters that affect settings of the

Receiver component in Dr.Web MailD versions for Exim, Postfix,
Sendmail and the version used for operation in the proxy mode via
smtp.

Address ={address}
Socket for receiving smtp/lmtp calls from Dr.Web MailD.

Default value: depends_upon_distribution

MaxThreads = {digital value}

Maximum number of threads in a pool of messages received
simultaneously by the Receiver component.

Default value: 10

ProcessingErrors ={actions}
This parameter defines what action should be applied to messages
that generate errors at scanning.
Possible main actions: tempfail, discard, reject

All additional actions are possible

Default value: reject

StalledProcessingInterval = {time}
Time interval to send to drweb-maild stalled messages which
have been received by Dr.Web MailD, but have not been processed
on time by its plug-ins. This can happen when power outages take
place or network problems occur.

55
Dr.Web® for Unix mail servers
Default value: 10m

OneCommandTimeout = {time}
Maximum time for an smtp/lmtp command to be executed
Default value: 5m

OneMessageTimeout = {time}
Maximum time for a message to be received
Default value: 10m

AddReceivedHeader = {yes|no}
If yes is specified, the Received header is added to all received
messages
Default value: depends_upon_distribution

ReturnReject ={yes|no}
ReturnReject parameter defines operation of the Receiver
module in case the Reject event occurs. If yes is specified, an
error with 5xx number is returned; otherwise the error with 2xx
number is returned and a DSN report is sent to a sender. In case
Dr.Web MailD interacts with Exim mail system and the
BeforeQueueFilters parameter instructs to use certain plug-
ins, the value for the ReturnReject parameter should be no to
avoid possible freezing of messages in the Exim’s queue.
Default value: depends_upon_distribution

MaxRecipients ={digital value}

56
(for Dr.Web MailD operating as smtp-proxy only)
Maximum number of recipients (if 0 is set, the number of recipients
is not limited)
Default value: 100

MaxConcurrentConnection ={digital value}

(for Dr.Web MailD operating as smtp-proxy only)
Maximum number of SMTP-connections with one IP-address. 0 –
means no limitations
Default value: 5

MaxMailsPerSession ={digital value}

(for Dr.Web MailD operating as smtp-proxy only)
Maximum number of messages per session. 0 – means no limitations

Default value: 20

MaxReceivedHeaders ={digital value}

(for Dr.Web MailD operating as smtp-proxy only)
Maximum number of the Received header in a message. 0 –
means no limitations.
Default value: 100

MaxErrorsPerSession ={digital value}

(for Dr.Web MailD operating as smtp-proxy only)
Maximum number of errors per session. 0 – means no limitations.

Default value: 10

MaxMsgSize ={size}

57
Dr.Web® for Unix mail servers
(for Dr.Web MailD operating as smtp-proxy only)
Maximum size of a message.
Default value: 10m

RelayDomains = {Strings_and_files}
(for Dr.Web MailD operating as smtp-proxy only)
List of domains messages can be forwarded to.
Default value: no value

Next parameters define checks of IP-addresses of connections not

marked as trusted IP, at different stages of an SMTP-session. These
parameters influence Dr.Web MailD operating as smtp-proxy only.

By default, the localhost and unix-socket.connections are

marked as trusted IP.
The check actions for IP-addresses of a connection are written to the
value of the corresponding parameter one by one and are separated
with commas. The order of actions to be taken conforms to the order
they are written.
The actions taken at all stages of a connection:
• sleep time – to "put to sleep" an SMTP-connection for
specified time (in seconds)
• reject – to return an error (5*)
• tempfail – to return a temporary error (4*)
• mark_trust – mark an address as Trusted IP
• pass_sasl_authenticated – if SASL-authentication
was successful, skip other checks

SessionRestrictions={text}

58
The parameter defines checks made immediately at the beginning of
a connection.
Actions specific for this stage:
• trust_protected_network – Checks if an IP-
address of a connection is in the list defined by the
ProtectedNetworks parameter, the address is
marked as Trusted IP
• trust_protected_domains – Checks if an IP-
address of a connection is in the list defined by the
ProtectedDomains parameter. The check is made via
the double DNS request:
A PTR request is sent and then the host is checked against
the ProtectedDomains list. If it is in the list, an A
request is sent and checked, if it matches at least one of the
received IP-address with the address which initiated the
connection. If they match, then the IP-address of the
connection is marked as Trusted IP.
• trust_white_networks – Checks if an IP-address is
in the whitelist. The whitelist is specified in the
WhiteNetworks parameter. If it is in the whitelist, the
IP-address is marked as Trusted IP.
• trust_white_domains – Checks if the domain of the
connection address is in the whitelist of domains. The
whitelist is specified in the WhiteDomains parameter. To
perform this check a PTR request is sent. If the domain is in
the whitelist, the address is marked as Trusted IP.
• reject_dnsbl – A check against RBL/DNSBL blacklists.
The servers are specified in the DNSBLList parameter. To
perform the check, an A request is sent. If the address is
listed in one of the lists, the session terminates and the
error is returned.

59
Dr.Web® for Unix mail servers
• reject_black_networks – An address is checked
against the blacklist of IP-addresses. Addresses are specified
in the BlackNetworks parameter. If the address is in
the blacklist, the session terminates and the error is
returned
• reject_black_domains – A domain address is
checked against the blacklist of domains. Domains are
specified in the BlackNetworks parameter. To perform
the check a PTR request is sent. If the address is in the list,
the session terminates and the error is returned

Default value: trust_protected_network,

trust_sasl_authenticated

HeloRestrictions ={text}
The parameter sets checks for the HELO/EHLO stage. Actions
specific for this stage:

• reject_unknown_hostname – if a host name has

neither DNS A,nor MX records, a message is blocked. A
and sometimes MX requests are sent during the check.

• reject_diff_ip – if an IP-address of a host differs

from the host a connection was made from, a message is
blocked.
Default value: no value.

SenderRestrictions = {text}
Checks performed at the FROM stage. Actions specific for this stage:

60
 • trust_sasl_authenticated – if SASL-
authentication was successful, the address is marked as
Trusted IP
• reject_unknown_domain – if the host of a sender
does not have either DNS A, or MX records, the message is
blocked. During the check A or sometimes MX request is
sent.
Default value: no value

RecipientRestrictions = {text}
Checks performed at the RCPT stage. All senders of the message are
checked one by one. Actions specific for this stage:
• reject_unknown_domain – if the host name of a
recipient does not have either DNS A, or MX records, the
sending of a message to this recipient is blocked. During the
check A and sometimes MX requests are sent.

• reject_unauth_destination – if the recipient’s

domain is not in any list specified in the RelayDomains
and ProtectedDomains parameters, the sending of a
message to this recipient is blocked.
Default value: reject_unauth_destination

DataRestrictions = {text}
Checks performed at the DATA stage. Actions specific for this stage:

• reject_spam_trap – a check for a spam trap. The

format of a recipient’s address – <user@host>. If host
is in the list specified in the ProtectedDomains
parameter (if this list is not empty) and user is in the list
specified in the SpamTrap parameter, the message is

61
Dr.Web® for Unix mail servers
blocked. The SpamTrap list may also contain full e-mail
addresses, and then full e-mail address is checked against
this list.

• reject_multi_recipient_bounce – blocking
messages with empty senders or several recipients.
Default value: no value.

RestrictionStat = {yes|no}
The parameter defines if the statistics of checks should be collected.
If the collection of the statistics is allowed, it can be collected by
sending the SIGUSER1 signal to the drweb-receiver process. The
statistics will be saved in the restrictions.txt file in the directory
specified in the BaseDir parameter of the General section of this
configuration file.
Default value: no

DelayRejectToRcpt = {yes|no}
The yes value for this parameter instructs Dr.Web MailD to
postpone blocking of messages till the RCPT stage. It allows to
operate with old «bugged» mail clients and write addresses of
blocked recipients to a log file.
Default value: yes

BlackNetworks = {Strings and files}

WhiteNetworks = {Strings and files}
Black and whitelists of networks used in
trust_white_networks and reject_black_networks

62
actions. The syntax of the parameter is equal to the
ProtectedNetworks parameter syntax.
Default value: no value.

DNSBLList = {Strings and files}

The list of DNSBL servers queried when the reject_dnsbl action
is performed. The servers are queried one by one according to the
order they are written to the parameter value, until the first server
blocks a message, or until the list ends.
Default value: no value.

PositiveDNSBLCacheTimeout = {time}
Positive timeout for caching of responses from DNSBL-servers.
Default value: 24h

NegativeDNSBLCacheTimeout = {time}
Negative timeout for caching of responses from DNSBL-servers
Default value: 10m

NegativeDNSCacheTimeout = {time}
Negative timeout for caching of all DNS responses, except for DNSBL
Default value: 10m

BlackDomains = {Strings and files}

WhiteDomains = {Strings and files}
Black and whitelists of domains used when the
trust_white_domains and reject_black_domains

63
Dr.Web® for Unix mail servers
actions are performed. The syntax of the parameter is equal to the
ProtectedDomains parameter syntax.
Default value: no value.

SpamTrap = {Strings and files}

A list of addresses for spam traps used during the
reject_spam_trap action.
Default value: no value.

[SASL] section

In this section reside parameters of SASL-authorization of Dr.Web

MailD operating as an smtp proxy-server

Use = {yes|no}
The yes value of this parameter enables SASL-authorization

Default value: no

Driver = {cyrus}
Name of the driver of SASL-authorization. In current version only one
driver is available: cyrus. To use it, the cyrus-sasl2 library should
be installed and set up
Default value: cyrus

BrokenAuthClients = {yes|no}
The parameter enables/disables support of old SMTP-clients with
non-standard version of syntax of the AUTH protocol.

Default value: yes

64
AuthenticatedHeader = {yes|no}
If yes is set for this parameter, names of registered users are added
to the Received header of a message

Note: if parameter is set to yes, names of SASL users are visible for
all.
Default value: no

[Cyrus-SASL] section

This section contains parameters controlling the cyrus-sasl driver in

Dr.Web MailD operating as smtp-proxy.

Lib = {path to a file}

Absolute path to the cyrus-sasl2 library
Default value: /usr/lib/libsasl2.so.2

Path = {text}
A string from which a name of the configuration file is made (the
.conf extension is added to the parameter value) from which the
cyrus-sasl2 library receives its settings
Default value: maild

ServerHostname = {text}
Host name. If the parameter value is not specified, the Hostname
parameter value of the General section of this configuration file is
used as the host name. If the value for this parameter is not
specified either, the value returned by the gethostname function is
used as the hodt name.
Default value: no value.

65
Dr.Web® for Unix mail servers

ServerRealm = {text}
The parameter defines the SASL area of the server.
Default value: no value.

SecurityOptions = {text}
A list of security settings. The settings are separated by commas.

The following security settings are allowed:

• noplaintext – do not allow SASL procedures
vulnerable to simple “passive” attacks (such as PLAIN,
LOGIN, etc.)
• noactive – protection against active attacks without
searching the dictionary during the authorization process.
• nodictionary – do not allow SASL procedures
vulnerable to ”passive” dictionary attacks
• noanonymous – do not allow SASL procedures allowing
anonymous authentication
• mutual_auth – to obligatory use SASL procedures
requiring mutual authentication.
Default value: noanonymous

[Sender] section

This section affects settings of the Sender component which is

responsible for the delivery of messages. This section of the
configuration file is missing in versions of the Dr.Web MailD used for
integration with CommuniGate Pro.

66
UseSecureHash = {yes|no}
When yes is specified, SecureHash header is added to outgoing
messages. The value of the parameter depends on the mail system
daemon integrates with and settings of this system.
The UseSecureHash and SecureHash parameters are not
necessary when Dr.Web MailD integrates with Courier and Exim and
when it operates as an smtp proxy server.

When Dr.Web MailD is integrated with Sendmail or Qmail:

If messages are sent to the same mail system they have been
received from, yes must be specified to avoid cycling of
messages and to optimize the system efficiency.
If messages are received from the one mail system and sent
to a different Sendmail system, no must be specified as a
value to keep the value of the SecureHash header within
the system.
When Dr.Web MailD is integrated with Zmailer:

It is possible to specify yes only in case drweb-zmailer

operates at the routing stage (for example, in case drweb-
zmailer is launched via process.cf). In this case all the
messages generated by drweb-sender are processed with
drweb-zmailer and adding the SecureHash header
helps to avoid cycling of messages as well as unnecessary
double-checking.
When Dr.Web MailD is integrated with Postfix:

Specify yes in case if interaction between mail system and

Dr.Web MailD is carried out via milter protocol (using
drweb-milter). In this case all messages generated by
drweb-sender are processed by drweb-milter and

67
Dr.Web® for Unix mail servers
adding the SecureHash header helps to avoid cycling of
messages as well as unnecessary double-checking.
Default value: depends on the distribution file

SecureHash={text value}
Defines value of the SecureHash header (see description of the
UseSecureHash parameter). To increase system stability, it is
recommended to change the default value of this parameter.
Default value: «PLEASE EDIT - !!! SECURITY CRITICAL
!!!»

StalledProcessingInterval = {time value}

Time period for Dr.Web MailD to send stalled messages which have
been processed by Dr.Web MailD plug-ins but have not been sent on
time by the Sender component. This can happen when power
outages take place or network problems occur.
Default value: 10m

SendingIntervals = {time values}

Time intervals between the attempts to send messages the Sender
failed to deliver from the first time. If a message cannot be sent, it is
deleted and the request to form a DSN report that a message cannot
be delivered is sent to the Notifier component.
Default value: 0, 30s, 60s, 10m, 30m, 1h, 2h

Method = {smtp|lmtp|pipe}
Sender can send messages to clients in the following ways:
• smtp – messages are sent via SMTP

68
 • lmtp - messages are sent via LMTP
• pipe – messages are sent by starting external program and
sent to that program via pipe

Default value: depends on the distribution file

MailerName = {Sendmail|Postfix|CommuniGate|
Qmail|Exim|Zmailer|Courier}
Name of the mail system Dr.Web MailD is integrated with.
Parameter is used if Method = pipe

Default value: depends on the distribution file

Address = {address}
If pipe set as the value of the Method parameter, in the Address
parameter a full path should be specified to the mail system which
receives messages. If other values of the Method parameter are
specified, a socket via which messages are sent is specified in the
Address parameter.
If Dr.Web MailD operates as SMTP-proxy, in additional to standard
types, YPE of the following type is allowed to be used in this
parameter:
mx:HOSTNAME, where HOSTNAME – is the host name. If such type
is used, the program receives all XM records from HOSTNAME and
sends the message accordingly.
Default value: depends on the distribution file

Options = {random value}

Optional parameters, transferred to mail system, when transporting
messages to it through pipe.

69
Dr.Web® for Unix mail servers
Default value: not specified

InMaxThreads = {digital value}

Maximum number of concurrent threads in input pool.
Default value 10

OutMaxThreads = {digital value}

Maximum number of concurrent threads in output pool.
Default value: 10

The parameters mentioned below should be only specified in case the

Dr.Web MailD interacts with Exim and Postfix and in case it runs as
an smtp proxy-server.

HeloCmdTimeout = {time}
Timeout for HELO/EHLO commands to be executed
Default value: 5m

MailFromCmdTimeout = {time}
Timeout for MAIL command to be executed
Default value: 5m

RcptToCmdTimeout = {time}
Timeout for RCPT command to be executed

Default value: 5m

DataCmdTimeout = {time}
Timeout for DATA/BDAT commands to be executed

70
Default value: 2m

DataBlockTimeout = {time}
Timeout for a message to be sent
Default value: 3m

EndOfDataTimeout = {time}
Timeout to send acknowledgement that a message has been
received from mail system.
Default value: 10m

OtherCmdsTimeout = {time}
Timeout for other SMTP/LMTP commands to be executed.
Default value: 2m

PipeTimeout = {time}
Timeout for receiving a response through pipe
Default value: 2m

SendDSN = {yes|no}
The parameter defines if DSN reports should be sent
Default value: yes

Router = {Strings and files}

If Dr.Web MailD operates as SMTP-proxy, this parameter defines
routing rules of messages depending on recipients. Messages sent to
different recipients can be sent via different addresses.

71
Dr.Web® for Unix mail servers
If a message has several recipients, and messages to different
recipients should be routed to different addresses, the list of
recipients is divided into groups and the messages aimed for
recipients of one group are sent to one definite address.
For each group of recipients a copy of the message is created and
then the messages are sent via different addresses.
The values of the parameter are set in DOMAIN ADDRESS,

where:
• DOMAIN – a string against which the envelopes of
recipients are checked. The envelopes look like
<user@host>. The search is case-insensitive. For
example, if @localhost is searched, it will be found both
in <test@localhost> and in the
<[email protected]> envelope, and if
@localhost> is searched, it will be found in the
<test@localhost> envelope only
• ADDRESS – address via which a message is sent, if the
domain string is found in the envelope. The format of the
address is similar to the Address parameter of the current
section of the configuration file.
Default value: no value.

[Milter] section

Parameters included into this section affect operation of drweb-

milter, which is responsible for operation between Dr.Web MailD
and the mail system via milter. This section is available only in
configuration files of Dr.Web MailD integrated with Postfix and
Sendmail

Address = {address}

72
Address for connection via milter that corresponds to that
specified in the settings of the mail system (must be set in the
sendmail.cf file for Sendmail and main.cf file for Postfix).
Path to PID file must not be used as address.
Default value: inet:[email protected]

Timeout = {time}
Timeout to wait for establishing connection via milter
The value of this parameter must be greater than a value of any
timeout in the configuration file of the mail system.
Default value: 2h

PendedConnections = {digital number}

Maximum length of the queue of calls sent to establish connection
with the mail system
Default value: 64

DebugLevel = {digital value}

Details level for notifications of the milter library; 0 – minimum
details, 14 – maximum details

Default value: 0

HaveInsHeader = {yes|no}
In case yes is specified as a value of this parameter, it tells Dr.Web
MailD that the milter library supports smfi_insheader function
which allows for adding headers to the beginning and the end of
messages. This support is available in the Sendmail version 8.13.1
and later and all versions of Postfix

73
Dr.Web® for Unix mail servers
Default value: yes

CanChangeBody = {yes|no}
In case yes is specified as the value of this parameter, it tells
Dr.Web MailD that the mail system supports modification of the
message body. Sendmail has this function. Postfix supports this
function beginning from v. 2.4.
When the program is restarted on receiving HUP signal, this
parameter does not change.
Default value:
For Sendmail: yes

For Postfix: no

ProcessingTimeout = {time value}

Timeout for drweb-milter to wait for plug-ins of the Dr.Web
MailD to scan a message. It is recommended to set a greater value
for this parameter than that set for the SendTimeout parameter in
the [MailBase] section.

Default value: 40s

ProcessingErrors = {actions}
Actions applied to messages in case processing errors occur. Only
one of the main actions (tempfail, discard, pass,
reject) can be specified as the value of this parameter.
Default value: reject

MaxThreads = {digital value}

74
Maximum number of threads in the pool that process message check
results.
Default value: 3

[Notifier] section

This section includes settings of drweb-notifier module of

Dr.Web mail daemon, which is responsible for creation and sending
to a user reports on actions of the Dr.Web MailD.

TemplatesBaseDir ={path to directory}

Directory where templates for reports are stored.
Default value:
For Linux and Solaris: /etc/drweb/maild/templates

For FreeBSD:
/usr/local/etc/drweb/maild/templates

LngBaseDir={path to directory}
Directory with language resources.
Default value:
For Linux and Solaris: /etc/drweb/maild/lng

For FreeBSD: /usr/local//etc/drweb/maild/lng

AdminMail = {email address}

Email address of the administrator of the mail system
Default value: root@localhost

FilterMail = {email address}

Email address of the sender indicated in reports.

75
Dr.Web® for Unix mail servers
Default value: [email protected]

NotifyLangs = {list of languages}

Languages which are used for generation of reports
Possible values: en – English, ru – Russian.

Default value: en

TemplatesParserLogLevel = {Quiet|Error|Alert|
Info|Debug}
Logging level for the subsystem which is responsible for generation
of reports on the basis of templates.
Default value: Info

RulesLogLevel = {Quiet|Error|Alert|Info|Debug}
Level of logging details for rules processor.
Default value: Info

3.3.2. Starting the system

The easiest way to start Dr.Web MailD is to use drweb-monitor
module. For this, you only need to start drweb-monitor service
(on Linux, use the following command /etc/init.d/drweb-
monitor start).

Each module can be started separately but mind that drweb-

agent must be started first (other modules receive configuration
information from the agent).

76
3.4. Components
3.4.1. Checker
The Checker, which is a main component of the system, is
represented by the drweb-maild module. It performs mime-
processing of messages, sends messages to plug-ins for analysis and
is responsible for storing messages to the database.

Messages are processed by plug-ins which connect to the Checker

component. A user can load and unload plug-ins at any time and
there is no need to stop operation of the drweb-maild module.
Messages are processed by plug-ins in the order defined by the
system user.
Plug-ins are divided in two queues – BeforeQueueFilters and
AfterQueueFilters.
As soon as a message arrives, it is processed by plug-ins from
BeforeQueueFilters. Then, in case AfterQueueFilters
are not specified, results of the analysis are sent back to Receiver
component. In case AfterQueueFilters are specified, once the
message is analyzed by plug-ins defined as
BeforeQueueFilters, it goes to the database and then to the
inner queue of drweb-maild module. Code of successful analysis
is sent to the Receiver component. Then the message is
processed by plug-ins specified as AfterQueueFilters.

77
Dr.Web® for Unix mail servers
When plug-ins are specified as
BeforeQueueFilters, messages are
processed with a high speed but system reliability is
low. When plug-ins are specified as
AfterQueueFilters, the speed is slower but
the reliability increases. Moreover some plug-ins
can operate only as AfterQueueFilters.

Check results are sent either to the Receiver component (in case
it is possible, for example the timeout for waiting for results is not
expired and this function is available in the used version of the
component) or to the Sender component. Moreover, all
notifications generated by plug-ins go through the Sender
component.
Operation of some plug-ins requires usage of database. Such plug-ins
cannot be specified as BeforeQueueFilters.

3.4.2. Receiver
The Receiver component is responsible for receiving mail directly
from mail systems or via smtp/lmtp protocols and transferring it to
the Checker component. Depending on used mail systems and
protocols, functions of the Receiver component are taken up by
different modules (drweb-receiver, drweb-milter,
drweb-cgp-receiver and so on). Moreover, a simultaneous
operation of several modules of the Receiver component is
supported, which makes possible to receive and process messages
from different sources simultaneously. Some modules of the
Receiver component allow to modify/forward messages; this
depends on the check results received from the Checker
component. For example, such capability is implemented in the

78
 drweb-milter module, which allows to send messages’ check
results to the SendMail system before the end of an smtp-session.
All the modules of the Receiver component support processing of
SIGALRM. If this signal is received, the Receiver component
checks the internal structure of directories in search of ”lost” for
some reasons messages. If such messages are found, an attempt to
send them to their recipients is taken.
The drweb-receiver module operating as smtp-proxy supports
also processing of SIGUSR1. If this signal is received, the module
saves to a file the addresses’ check statistics (read comments to the
Receiver/RestrictionStat parameter of the configuration file of Dr.Web
Mail Daemon)

3.4.3. Sender
The Sender component is responsible for channeling mail either
directly to different mail systems or via smtp/lmtp protocols.
Depending on used mail systems and protocols, functions of the
Sender component are taken up by different modules (drweb-
sender, drweb-cgp-sender, etc.).
The Sender component can receive calls for messages from
Checker, Notifier and Monitor components.
All the modules of the Sender component support processing of the
following signals:
• SIGALRM – when this signal is received, the Sender
component checks the internal structure of directories in
search of "lost" for some reasons messages. If such
messages are found, an attempt to send them to their
recipients is taken.
• SIGUSR2 – if this signal is received, the component makes
an attempt to send all the messages waiting to be sent in its
internal queue.

79
Dr.Web® for Unix mail servers
3.4.4. Notifier
The Notifier component is responsible for reports generated
during the operation of the system and represented by the drweb-
notifier module. Calls for reports can be sent by plug-ins (for
example, in case a virus is found) as well as by system components.
For instance, the Checker module can send calls for general report
with information on operation of all connected plug-ins; the Sender
component can send calls for DSN reports informing on inability to
send a message.

3.4.5. Monitor
The Monitor component (further called monitor) is represented by
the drweb-monitor module and assures stable operation of
Dr.Web MailD system. The monitor is responsible for loading system
components starting additional components if necessary. If an
attempt to load a module is unsuccessful, the monitor takes another
attempt. Number of attempts and time period between attempts are
defined by components’ settings.
During its operation, the monitor can interact with other system
modules by sending signals.
As soon as all anti-virus modules are loaded, the monitor starts to
control their operation. In case a module or one of its components
starts to operate abnormally, the monitor reload its. A number of
attempts and time period between attempts are also defined by
monitor settings.
If an anti-virus module starts to operate abnormally, the monitor
informs the system administrator.

3.4.5.1. Command line options

Drweb-monitor in addition to command line option supported by
all the modules of Dr.Web MailD (see p.3.2), allows for usage of the
following options:

80
 • -c <file name>, --conf <file name> – instructs
to use alternative configuration file
• -r, --run application1[,application2] –
instruct to start applications. For example, -r
AGENT,MAILD – without blanks.

3.4.5.2. Settings
Settings of the Monitor components are specified in a separate
configuration file – %etc_dir/monitor.conf.

The structure and the principles of parameters’ descriptions of the

configuration file are fully described in p. 3.3.

[Logging] section.
This section includes parameters which affect details level of logging
for the monitor.
Level = {fatal|error|warn|info|debug}
Defines details level for the monitor’s log.
Default value: Info

IPCLevel = {fatal|error|warn|info|debug}
Defines the detail level of logging for interaction of the monitor with
other modules of Dr.Web MailD.
Default value: Error

SyslogFacility = {Daemon | Local0 .. Local7 | Kern

| User | Mail}

Type of facility, which generates a notification message on event

using syslog system service (for details refer to the documentation on
syslog)..
Default value: Daemon.
[Monitor] section.
81
Dr.Web® for Unix mail servers
The section includes main parameters regulating operation of the
drweb-monitor.
RunForeground = {yes|no}
When yes is specified, the monitor does not act as a “daemon”
which allows to get information on its state using special tools (for
eхample daemontools).

Default value: no

User = {text value}

Name of the user whose privileges are used to start the monitor
Default value: depends on the distribution file of the Dr.Web MailD

Group = {text value}

Name of the group whose privileges are used to start the monitor
Default value: drweb

PidFileDir ={path to directory}

Name of the directory where PID of the monitor is saved when the
module is started.
Default value: /var/drweb/run/

ChDir = {path to directory}

Change of active directory when monitor is launched. If this
parameter is set, when launched, monitor changes the active
directory and starts to use the one defined by this parameter.
If this parameter is not set, active directory is not changed.
Default value: /

82
MetaConfigDir {path to directory}
Name of directory containing meta-configuration files. These
parameters regulate interaction of the monitor with Dr.Web MailD
modules. The content of meta-configuration files is set by Dr.Web
MailD developers and its editing is unnecessary.
Default value:
for FreeBSD: /usr/local/etc/drweb/monitor/

for Linux and Solaris: /etc/drweb/monitor/

Address ={address}
Socket through which monitor receives signals.
Default value: local:/var/drweb/ipc/.monitor

Timeout = {digital value}

Timeout (in seconds) to establish connection between the monitor
and components of anti-virus system.
Default value: 30

TmpFileFmt = {text value}

Template for the name of the monitor’s temporary files. Format of
the template: path_to_file.XXXXXX, where XXXXXX denotes a
combination of random letters and figures in the names of temporary
files.
Default value: /var/drweb/msgs/tmp/monitor.XXXXXX

RunAppList ={text value}

List of modules run by monitor. The modules are divided by a
comma, if more than one is specified.

83
Dr.Web® for Unix mail servers
Default value: MAILD

UseEnterpriseMode = {Yes|No}
When yes is specified, list of modules that must be started by the
monitor is taken not from the RunAppList parameter, but from
the drweb-agent.

Default value: yes

RecoveryTimeList= {digital value}

Time interval (in seconds) between attempts to restart stalled
applications.
You can specify several values, divided by a comma for each
parameter. The first attempt to restart application will be performed
upon the expiration of the time determined by the first parameter
value; the second attempt – upon the expiration of the time
determined by the second parameter value and so on.
Default values: 0,30,60

SenderResponseTime = {digital value}

Maximum response time period (in seconds) for the Sender
component. If there is no response from the component during the
specified time, monitor assumes it is not running.
Default value: 30

AgentAddress = {address}
Socket through which monitor interacts with the agent.
(the parameter value should be the same as the Address
parameter value of the Agent’s configuration file).
Default value: local:/var/drweb/ipc/.agent

84
 AgentResponseTime = {digital value}
Timeout (in seconds) to wait for response from drweb-agent. If
there is no response from the component during the specified time,
the monitor assumes drweb-agent is not running and restarts it.

Default value: 30

[Update] section

In this section reside the updating parameters of applications of

Dr.Web for Unix systems via Dr.Web Enterprise Suite (consult
Dr.Web Enterprise Suite. Administrator Manual)

TmpDir = {path to directory }

A directory where the monitor saves temporary files during the
update
Default value: /var/drweb/update/root

RootDir ={path to directory}

Dr.Web MailD root directory.
Default value: /

3.4.5.3. Starting the Monitor

When drweb-monitor is started (with default settings), the
following is performed:
1 drweb-monitor is being loaded. The module searches
for the configuration file. In case the file is not found,
loading is aborted.

85
Dr.Web® for Unix mail servers
2 Monitor disconnects from the terminal. Therefore
notifications on errors can not reach the terminal and are
only logged.
3 A socket for interaction with other modules of Dr.Web
MailD is created. It is possible to establish several
connections via TCP (loading will continue if at least one
connection is successful)
In case a unix-socket is used, make sure that its directory
is accessible for reading and writing by a user whose
privileges is used by drweb-monitor module. If not a
single socket can be created, loading of the monitor is
aborted.
4 a PID-file storing monitor process id is created. If the file
is not found, loading is aborted.
5 drweb-monitor loads other modules of the Dr.Web
MailD. If a certain module cannot be loaded properly, the
monitor takes another attempt to load it. In case all
attempts taken by the monitor to load a module failed,
the monitor unloads all loaded modules and terminates its
operation. All problems are reported by the monitor using
one of the possible notification modes (by logging, via e-
mail, by starting a selected application). Notification
modes used for different modules are defined in the
monitor’s meta configuration file.

3.4.6. Agent
The Agent component (also called «agent») represented by
drweb-agent module controls settings of Dr.Web MailD modules,
regulates operation of Dr.Web MailD according to the used license
and collects anti-virus statistics.
During its operation, agent can interact with other system modules
by sending signals.

86
 Agent controls system operation in the standalone mode and when
the system is integrated with Dr.Web Enterprise Suite.

All the components of Dr.Web MailD (excepting

Monitor component) receive configuration data
via the drweb-agent module. Therefore, the
module must be started before other components
are loaded.

The drweb-agent is a memory resident module. Agent sends to

the modules of Dr.Web MailD configuration parameters when these
modules are loaded or once system settings are changed. Agent
controls system operation parameters according to license.

3.4.6.1. Anti-virus statistics collection

If Dr.Web MailD checks e-mails for viruses, the agent collects anti-
virus statistics and sends it to http://stat.drweb.com (access to the
Internet is required). When the system operates in the
Enterprise mode, agent sends statistics to Dr.Web Enterprise
Suite server. This information is processed by Dr.Web server and
results are published on the web site. You as a user of Dr.Web MailD
have access to virus statistics for your server and global statistics (to
have a look at global statistics you do not have to be a Dr.Web MailD
user). Agent can simultaneously process statistics which comes from
several Dr.Web software products. These products must support
interaction with the agent.
Agent collects the following information:
• total number of found viruses
• number of modifications for each virus
• number of scanned messages (in the current version of agent
component this information is not sent to
http://stat.drweb.com)

87
Dr.Web® for Unix mail servers
Agent needs a user id (UUID) to connect to the site at
http://stat.drweb.com. By default, md5 of a key file is used as UUID.
You can also receive your personal UUID. For this, contact technical
support. When you receive a personal UUID, you must specify it in
the configuration file.

3.4.6.2. Operation modes

Drweb-agent module can operate in 2 modes: Standalone
and Enterprise.

In case Dr.Web MailD is used in the anti-virus network built with

Dr.Web Enterprise Suite (further called ES), agent can work in
Enterprise mode. In this mode drweb-agent module
integrates with your ES server and receives settings and license keys
from this server. Agent is controlled from the anti-virus console which
connects to ES server. To make drweb-agent work in the
Enterprise mode, all parameters of the [EnterpriseMode]
section in the agent’s configuration file must be defined correctly.
If Dr.Web MailD is used on a computer that is not included into ES
anti-virus network, drweb-agent module operates in the
Standalone mode. If drweb-agent works in this mode, files
with settings for system modules and license keys are stored on local
drives.

3.4.6.3. Command line options

In addition to the command line options supported by all the modules
of Dr.Web MailD (see p. 3.2); drweb-agent allows for the usage
of the following command line options:
• -c <file name>, --conf <file name> – instructs
to use alternative configuration file
• -v, --version – displays current version of the module

88
3.4.6.4. Settings
Settings of the Agent component are defined in the
%etc_dir/agent.conf configuration file.
The structure and principles of description of parameters of the
configuration file are fully described in p. 3.3.

[Logging] section.
This section includes parameters that affect logging of drweb-
agent.
Level = {quiet|error|alert|info|debug}
Defines details level of the agent’s log
Default value: Info

IPCLevel = {quiet|error|alert|info|debug}
Defines detail level of logging for interaction of the agent with other
modules of Dr.Web MailD.
Default value: Error

SyslogFacility = {Daemon | Local0 .. Local7 | Kern

| User | Mail}

Type of facility which syslog service uses to generate notification

messages on events (for details refer to the documentation on
syslog).
Default value: Daemon.
[Agent]
This section includes parameters that affect operation of the agent.
MetaConfigDir = {path to directory}

89
Dr.Web® for Unix mail servers
Directory with meta configuration files of drweb-agent. Meta
configuration files describe interaction of drweb-agent with other
modules.
These files are created by developers of Dr.Web MailD and do not
require editing.
Default value:
For Linux/Solaris: /opt/drweb/agent/

For FreeBSD: /usr/local/drweb/agent/

RunForeground = {Yes|No}
When yes is specified for this parameter, the monitor does not
function as a “daemon” which allows to get information on its state
using special tools (for example daemontools).

Default value: no

UseMonitor = {Yes|No}
The Yes value tells the drweb-agent module that the Monitor
component is used with Dr.Web MailD.
Default value: Yes

UpdatePeriod = {digital value}

Time period in minutes (not less than 5 minutes) for drweb-agent
to update statistics
Default value: 5

MonitorAddress = {address}
A socket through which the anti-virus agent interacts with the
drweb-monitor module (the value of the parameter must be the
same as the value of the Address parameter in the configuration
file of the monitor).
Default value: local:/var/drweb/ipc/.monitor

90
MonitorResponseTime = {digital value}
Timeout (in seconds) for drweb-monitor to respond. If within
this period the monitor does not respond, the agent think that it is
running and does not attempt to interact with the monitor.
Default value: 3.

PidFile ={path to file}

Name of the file where PID of drweb-agent is saved when the
module is started.
Default value: /var/drweb/run/drweb-agent.pid

[Server] section.
This section includes parameters that affect interaction between
drweb-agent with other modules of Dr.Web MailD.
Address = {address}
Socket through which drweb-agent interacts with other modules.

In case you indicate several sockets, use a comma as a delimiter.

Default value: local:/var/drweb/ipc/.agent, inet:
4040@localhost
Threads = {value}
Number of simultaneous threads of drweb-agent.

The parameter defines the maximum number of simultaneous

connections with the modules that send statistics to the agent.
Restart of the program on receiving SIGHUP signal cannot initiate a
change of this parameter
Default value: 2

Backlog ={value}

91
Dr.Web® for Unix mail servers
Maximum number of requests to establish connection through the
socket defined by the Address parameter of the [Server]
section.
Default value: 24

Timeout = {digital value}

Timeout (in seconds) to establish connection between the agent and
other components.
Default value: 30

[EnterpriseMode] section.
This section includes parameters that affect operation of drweb-
agent in the Enterprise mode.

UseEnterpriseMode = {Yes|No}
When Yes is set for this parameter drweb-agent operates in the
Enterprise mode. When No is set, the module operates in the
Standalone mode.
Default value: No

PasswordFile={path to file}
Name of file where name and password hashes for accessing ES
server are stored.
Default value: /var/drweb/agent.pwd

ComputerName = {computer name}

Name of the computer included into the anti-virus network
Default value: system name of computer

92
VirusbaseDir={path to directory}
Path to virus base
Default value: /var/drweb/bases

PublicKeyFile = {path to file}

Name of public key file for accessing ES server.
Default value:
For Linux and Solaris: /opt/drweb/agent.pub

For FreeBSD: /usr/local/drweb/agent.pub

ServerHost = {IP-address}
IP-address of ES server
Default value: 127.0.0.1

ServerPort = {port number}

Port used to access ES server
Default value: 2371

CryptTraffic ={yes|possible|no}
Encryption of traffic between ES server and the drweb-agent
module
Default value: possible

CompressTraffic = {yes|possible|no}
Compression of traffic between ES server and the drweb-agent
module

93
Dr.Web® for Unix mail servers
Default value: possible

[StandaloneMode] section
Settings of drweb-agent that affect its operation in the
standalone mode.

StatisticServerHost ={text value}

IP-address or domain name of the server where virus statistics are
stored
Default value: stat.drweb.com

StatisticServerPort ={digital value}

Port used to access the virus statistics server
Default value: 80

UUID = {identifier}
Personal identifier which is used to access the virus statistics server
at http://stat.drweb.com.
The parameter must be set in case, if a personal UUID is required to
access the virus statistics server.
If the parameter is not set, a hash function of the md5 of the license
key file is used for accessing the server
Default value: not specified

LicenseFile = {list of paths to files}

Location of the key files of Dr.Web MailD (license or demo key files).
Default value:
For Linux and Solaris: /opt/drweb/drweb32.key

94
 For FreeBSD: /usr/local/drweb/drweb32.key

EmailsFile = {path to file}

Path to a file with a list of e-mail addresses for Dr.Web MailD to scan.
This file is used only in case you have obtained a license for 15 or 30
e-mail addresses. Dr.Web MailD will scan messages coming to
indicated mail boxes for viruses. Messages coming to other addresses
will not be scanned by the system
Every mail addresses is written in a separate line. The following
formats are possible: name or name@mail_server. See
email.ini. It will serve you as an example.
Default value: /var/drweb/emails

[Update] section

In this section reside the updating parameters of applications of

Dr.Web for Unix systems via Dr.Web Enterprise Suite (consult
Dr.Web Enterprise Suite. Administrator Manual)

TmpDir = {path to directory }

A directory where the monitor saves temporary files during the
update.
Default value: /var/drweb/update/root

RootDir ={path to directory}

Dr.Web MailD root directory.
Default value: /

95
Dr.Web® for Unix mail servers
3.4.6.5. Starting the Agent
When drweb-agent is started (with default settings), the
following is performed:
1 The module searches for the configuration file. In case
the file is not found, loading is aborted. If parameters of
the [EnterpriseMode] section are specified in the
configuration file (and computer is included into ES
network), agent works in the Enterprise mode.
Otherwise, if parameters of the[Standalone] section
are specified in the configuration file, agent works in the
Standalone mode. If parameters of
the[Standalone] section are not specified, loading is
aborted.
2 A socket for interaction with other modules of Dr.Web
MailD is created. It is possible to establish several
connections via TCP (loading will continue, if at least one
connection is successful).
In case a unix-socket is used, make sure that its directory
is accessible for reading and writing for a user whose
privileges is used by the drweb-agent module. If not a
single socket can be created, loading of the agent is
aborted.
Further process flow depends on the
mode of agent operation. If agent
operates in the Enterprise mode, the
process goes on like this:
1. The module attempts to establish connection to ES server.
If the server is inaccessible or authorization on the sever
failed, agent tries to load in the standalone mode. If
connection is established, loading continues.

96
 2. Agent receives license key files and settings for anti-virus
modules from ES server. As soon as license keys and
settings are received, agent is ready for operation.
If agent operates in the Standalone
mode, the process goes on like this:
1 Meta configuration files of Dr.Web MailD modules are
being loaded. These files describe parameters of agent
interaction with modules. Location of meta configuration
files is defined by the MetaConfigDir parameter of
the [Agent] section in the configuration file. After that
agent is ready for operation.

3.5. Connecting to Dr.Web Enterprise Suite

To enable interaction of Dr.Web MailD system and Dr.Web Enterprise
Suite, you must register the system on ES server. For this, do the
following:
1 Create an administrator account using the anti-virus
console. This procedure is described in Dr.Web Enterprise
Suite. Administrator Manual.
2 Set the Agent of the registered workstation for the
Enterpris mode (read p.3.4.6.2).
3 Delete a hash-file of the password (if any), set by the
PasswordFile parameter of the
[EnterpriseMode] section of the Agent’s
configuration file.
4 Run the Agent. The Agent will start in the Enterprise
mode and having not found the password hash-file will
ask to submit the registration data: user name and
password. When the data is input, the Agent writes the
hash of the name and the password into a file specified in
97
Dr.Web® for Unix mail servers
the PasswordFile parameter and then terminates. In
future the data from this file (if it was input correctly) will
be used to connect Dr.Web MailD to the ES server.

In case the registration is successful, Dr.Web MailD is ready to

operate in the Enterprise mode.

Consult Dr.Web Enterprise Suite. Administrator Manual for more

details on Dr.Web MailD operation in the Enterprise mode.

3.6. Rules affecting messages processing

One of the most important things about Dr.Web MailD is rules. Rules
allow to flexibly change parameters of Dr.Web MailD operation
depending on the content of messages. In the current version of
Dr.Web MailD, rules can affect sender and recipient addresses as well
as malicious objects detected in messages.
Rules are written to the Dr.Web MailD configuration file (see p. 3.3):
rules affecting email addresses can be found in the [User] section
(user section), rules affecting malicious objects found in messages in
the [Viruses] section (viruses section and other blocking objects).

Each rule is written in a single line and consists of two parts: regular
expression which defines value for application of a rule and Dr.Web
MailD parameters specified in the rule. If a line is not enough, the
"\" symbol is used at the end of the line and the rule is further
described in the next line.

Regular expressions used in the rules of Dr.Web MailD have the

following peculiarities:
• Regular expression which contains blanks should be set in
double quotes.

98
 • To invert a regular expression, (i.e. to put a rule into
application when no matches with regular expression found)
you should insert exclamation mark "!" in front of it.
• In front of regular expression in the user section you can
specify a qualifier indicating types of addresses which are
checked for matches with regular expression. Qualifier can take
on two values: Rcpt: – instructs to check only recipient
addresses and Sender: – instructs to check only sender
addresses. If no qualifier is specified, recipient addresses as
well as sender addresses are checked. Qualifiers for regular
expressions can be specified in the virus section, but it does not
affect usage of regular expressions.
Examples:
Rcpt:!@example\
com - this regular expression will work in case
recipient address does not belong to example.com domain.
The rule with this regular expression will be applied if sender
address is "A. [email protected]".

Parameters specified in the rules are written as follows:

• When enumerated, parameters are divided by a comma;
• Each parameter is written as a pair of name and value, divided
by "=".

Rules suitable for a message that is processed by Dr.Web MailD are

searched for according to the following guidelines:
• Check of regular expressions for matches with recipients and
detected viruses is performed in the same order as that in
which rules are specified in the configuration file - from top to
bottom and from left to right. If regular expression is suitable,

99
Dr.Web® for Unix mail servers
commands of the rule (search for matches of address types
and conditions and setup of parameters) are executed.
• if parameter value has been specified several times, the last
specified value will be saved. The exception is parameters
which depend on conditions (see description of the Notify
parameter below).
• Settings set by rules on the basis of recipient address match
have a higher priority over settings set by rules on the basis of
sender address match.
• If a message is meant for several recipients, search of regular
expressions and application of rules are performed for each
recipient separately, and therefore different reports can be sent
to recipients.
• For parameters left without specified values after application of
all suitable rules values from default section are set.
default section is described below.

In rules the following parameters can be set:

html={yes|no}
The yes instructs Dr.Web MailD to generate notification in html-
format; otherwise reports are generated in text format. Algorithm for
setting a parameter is as follows:
Suitable rules of [Viruses] section are analyzed first. If
parameter is not specified by rules of this section, rules of
[Users] section are analyzed.

Default value: yes

Quarantine={yes|no}
Yes instructs to move a message to quarantine.

100
Algorithm for setting a parameter is as follows: suitable rules of
[Viruses] section are analyzed first. If for all viruses detected in a
message, Quarantine parameter is set to no, further search for
parameter match is aborted. Otherwise the [Users] section is
searched. Even if the [Quarantine] parameter is set to yes only
for a single recipient or sender, message will be moved to
quarantine.
Default value: no

Scan = {text value}

This parameter indicates Dr.Web MailD plug-ins used for checking.
Plug-in’s names are divided by colon. In addition to plug-in names
the keyword All can be added to parameter's value. This keyword
instructs all plug-ins to check a message. Keyword All allows to use
for checking all plug-ins apart from excluded ones. Excluded plug-ins
are enumerated after the keyword All with a minus sign in front
each of them. There is no blank between a minus sign and a name of
plug-in. Plug-in names without a minus sign must not be written after
the keyword All. You should not write plug-in names with minus
signs without the keyword All.

Algorithm for setting a parameter:

only suitable rules of the [Users] section are analyzed for
parameter value. Setting scan parameter in rules of the
[Viruses] section is useless; however, that is not an error.

Default value: All

Examples:
• scan = all - message is checked by all plug-ins
• scan = all:-foo – message is checked by all plug-ins
apart from foo

101
Dr.Web® for Unix mail servers
• scan = Foo:Moo message is checked only by foo and moo
plug-ins
• scan = all:foo – wrong parameter format: after keyword
all you cannot specify names of plug-ins without the '–' sign.
• scan = -foo:all – wrong parameter format: the keyword
all should be placed at the very beginning of the line.
• scan = -foo – wrong parameter format: you cannot
specify plug-in’s names with '-' signs, if the keyword all is
missing.

notify[.{notification mode}]=
{allow|block}[({types of
addresses})] [condition]
The parameter regulates display of certain types of notifications. The
allow value enables a correspondent type of the notification and
the block value disables it. In case type of notification is not
specified, this parameter controls display of all notifications.
Possible types of notifications depend on types of report that the
drweb-notifier module supports. Additional plug-ins can have
their own types of notifications. By default the following types of
notifications are supported:
• notify.Virus – notifications on viruses detected in a
message
• notify.Cured – notifications on viruses cured in a message
• notify.Skip – notifications on skipped messages
• notify.Archive – notifications on messages, which have
not been checked due to restrictions for archives
• notify.Error – notifications on errors occurred when
checking messages

102
 • notify.Rule – notifications on messages blocked by
certain rules
• notify.License – notifications on messages skipped due
to license limitations
• notify.Malware – notifications on detected malware
Parameter value can be followed by optional qualifier specified in
brackets which indicates address types for notifications.
You can specify several address types divided by a colon. Possible
qualifier values:
• sender – notifications for sender
• rcpt – notifications for recipient
• admin – notifications for administrator
• any, (or no qualifier at all) - notifications for all address types
Optional qualifier can be followed by conditions of the notify
parameter setup. A condition consists of the keyword if and a
regular expression. Regular expressions in conditions of the notify
parameter correspond to regular expressions, specified for the rules
of the [Users] section, i.e. can work for certain email addresses.
Parameters with somewhat different conditions are not ignored in
favor of parameters of the same type which are described further in
the configuration file.
Examples:
• Notify=block; notify=block (any) – the same
action is performed: all notification types are blocked.
• notify.Virus = block (sender:admin) –
notifications on detected viruses are blocked for administrator
and sender.
• notify.Error = allow if
Sender:@example\.com – allows all notifications on

103
Dr.Web® for Unix mail servers
occurred errors when processing a message if sender address
belongs to example.com;

• notify.Cured = block (any) if

Rcpt:!"@foo\.com" – blocks all notifications on cured
objects in case recipient address does not belong to foo.com

• notify = (any) if "foo\.com" – incorrect; the

value for the notify parameter (allow or block) is not
specified
• notify.Malware = block (rcpt:sender) "foo"
– incorrect; keyword if is missing in front of the description of
condition.
Default notification parameters:
• notify = block(any)
• notify.Virus = allow(any)
• notify.Cured = allow(admin:sender)
• notify.Skip = allow(sender)
• notify.Archive = allow(admin:sender)
• notify.Error = allow(admin:sender)
• notify.Rule = allow(admin)
• notify.License = allow(admin)
• notify.Malware = allow(any)

The algorithm for setting a parameter is the following:

Suitable rules of the [Viruses] sections are analyzed first.
Even if the notify parameter is set to yes only for a single
virus found in a message, further search for parameter match
is aborted and report is generated. If analysis of the
[Viruses] section is performed, and notification is not

104
 enabled even for a single virus, search for parameter match
goes on in the [Users] section.

Default value: not specified.

rule ={section name}

Frequently used parameter groups can be combined in User
parameter section. Using the rule parameter you can include
parameters of the [Users] section to the list of parameters,
specified for a rule. Each section must have a unique name.
Current version of Dr.Web MailD supports no more than one
parameter for a rule.
Format of the header of the [Users] section is the following:

[Rule: name], where name is a unique section name, which may

contain Latin letters, numbers and even blanks. Parameters are
specified in a separate line. The ending of section can be marked by
either the beginning of the next section or the end of the
configuration file. Configuration file includes a special section of user
parameters - section of default parameters. This section is named
as default; the Rule keyword can be omitted in the header of the
section. Parameter values specified in this section used for
parameters which values have not been specified by user section
rules.
In default section default values for all parameters are specified,
whose values can be set by rules. If in default section values for
some parameters are not specified, values from the Dr.Web MailD
code will be used. These values correspond to the values, specified in
the default section of the configuration file after daemon is installed.
As an example of the section of user parameters, let us take a
parameter section, which block all reports and disable moving
messages to quarantine:
[Rule:MySection]
105
Dr.Web® for Unix mail servers
quarantine = no
notify = block

Example of using MySection in the rules of user section:

[Users]
Rcpt:"example\.com" rule=mysection
Sender:"lol@foo\.com" notify.Skip=allow,
notify.Virus=allow if\
rcpt:"foo\.com",
rule=MySection

Once these rules are executed, reports will be blocked and moving
messages to quarantine whose recipient belongs to example.com
domain will be disabled. If a message has been sent from
[email protected], only reports on found viruses will be enabled if
recipient belongs to foo.com domain and moving files to

quarantine will be disabled. Pay attention to the fact that in the last
example the notify.Skip=allow parameter is disabled by
notify=block parameter from MySection.

3.7. Collecting anti-virus statistics

During operation of Dr.Web MailD along with the connected anti-virus
plug-in, statistics on virus events may be collected. The statistics are
directed to Dr.Web statistics server (or to Dr.Web Enterprise Suite
server in case agent operates in the Enterprise mode).

On the server you can see statistics for your server as well as global
statistics for all servers where Dr.Web for Unix system or Dr.Web
MailD with an anti-virus plug-in is deployed.

106
Statistics reflect information on the most frequently detected viruses
(their detection frequency and rating in percentage) for a definite
period.
The data can be displayed both in HTML and in XML formats. The
latter is especially useful in case you want to publish these data on
your web-site: you can customize it to your web-site design and
content.
To get information on global statistics for all used servers, visit the
web-page at http://stat.drweb.com. The web-page contains a list of
viruses detected on all used web-servers (arranged by frequency in
the descending order) with information on the number of detection
cases and rating in percentage (see a table fragment in pic. 1). The
look of the table depends on your browser.

107
Dr.Web® for Unix mail servers

Picture 1. Virus statistics

You can change parameters of your request and see new results:
1. Select the Mail or the Files radio button to display
statistics on viruses detected in email messages or files.
2. Then, using the Start date and the End date
dropdown boxes set the necessary period for statistics.
3. In the Top box type a number of viruses that should be
displayed (only the most frequently detected viruses will
appear)

108
 4. Select the Plot graph checkbox to see data in a
graphical form.
5. Click Query.

File containing statistics data in XML format can be found at

http://info.drweb.com/export/xml/top. A fragment from such file is
given below:
- <drwebvirustop period="24" top="5"
updatedutc="2005-04-12 09:02:01">
- <item>
<vname>Win32.HLLM.Netsky</vname>
<place>1</place>
<percents>58.3163167883155</percents>
</item>
- <item>
<vname>Win32.HLLM.MyDoom</vname>
<place>2</place>
<percents>30.0401772318628</percents>
</item>
- <item>
<vname>Trojan.Bankfraud</vname>
<place>3</place>
<percents>3.19479137845705</percents>
</item>
- <item>
<vname>Win32.HLLM.Dasha</vname>
<place>4</place>
<percents>2.36114304419496</percents>
</item>
- <item>
<vname>Win32.HLLM.Hazafi</vname>
<place>5</place>
<percents>2.28885520219163</percents>
</item>
</drwebvirustop>
Here the following attributes are used:
• period – time spent on collection of statistics (set in hours)
• top – number of the most frequently detected viruses to
display in the table

109
Dr.Web® for Unix mail servers
• updatedutc – time of last update
• vname – virus name
• place – rating position
• percents – detection rating in percentage
Time period for collecting statistics data and a number of viruses to
display in the table cannot be changed by a user.
To receive personal statistics data, go to the web-page at
http://stat.drweb.com/view/<UID>, where <UID> is an md5
checksum indicated in the user key file. The page containing personal
statistics data has the format that matches the format of a page with
global statistics.
A file containing personal statistics in XML format can be found at
http://stat.drweb.com/xml/<UID>, where <UID> — is an md5
checksum indicated in the user key file. A fragment from such file is
given below:
<?xml version="1.0" encoding="UTF-8" ?>
- <drwebvirustop period="24" top="20"
user="<UID>"
lastdata="2005-04-12 07:00:00+04">
- <item>
<caught>69</caught>
<percents>24.1258741258741</percents>
<place>1</place>
<vname>Win32.HLLM.Netsky.35328</vname>
</item>
- <item>
<caught>57</caught>
<percents>19.9300699300699</percents>
<place>2</place>
<vname>Win32.HLLM.MyDoom.54464</vname>
</item>
..............................................
</drwebvirustop>
Here the following attributes are used:
• period – time spent on collection of statistics (set in hours)

110
 • top – number of the most frequently detected viruses to
display in the table
• user – user id
• lastdata – last time when data is received from the user
• vname – virus name
• place – rating position
• caught – number of detection cases
• percents – detection rating in percentage
As in case you send a query for global statistics,
you cannot set the time period and number of
viruses to be displayed

3.8. Update utility

Certain plug-ins of Dr.Web MailD require regular updating of their
databases/libraries in order to function successfully. In current
version of Dr.Web MailD such plug-ins are the Drweb anti-virus plug-
in and the vaderetro anti-spam plug-in.
To simplify the updating of Dr.Web MailD plug-ins there is an
update.pl updating utility located in the %bin_dir directory.
At every start the updating utility receives the updating files from the
web-site of Doctor Web, Ltd. and places them to the plug-ins'
directories.
To regularly update plug-ins, it is enough to periodically run the
updating utility. To schedule the launches of the updating utility Cron
should be used.
If Dr.Web MailD is integrated with Dr.Web ES, the program’s
updating is centralized via the Dr.Web ES repository. Consult Dr.Web
Enterprise Suite. Administrator Manual for more information.

111
Dr.Web® for Unix mail servers

4. Plug-ins
At the moment the following plug-ins of Dr.Web MailD system are available:
anti-virus plug-in, VadeRetro anti-spam plug-in and headersfilter plug-in.

4.1. Anti-virus plug-in

Drweb is an anti-virus plug-in for check of e-mail. The plug-in
requires the drwebd module (Dr.Web Daemon or anti-virus
daemon) and Dr.Web anti-virus engine which check e-mail messages
for viruses. Messages are sent to the drwebd module for scanning
in segments. Therefore mime-processing support by the engine as
well as by the drwebd module is not required.
The drwebd module and the Dr.Web anti-virus engine are supplied
in the base package of Dr.Web, which should be installed before the
Drweb plug-in is installed. Functioning and setting of the anti-virus
engine and the anti-virus daemon are described in details in Dr.Web
for Unix-systems. Administrator Manual.

If Dr.Web for Unix is installed on a computer,

additional installation of the Dr.Web base package
is not required as both the drwebd module and the
Dr.Web anti-virus engine are parts of the Dr.Web
Anti-virus for Unix.

Once the analysis is complete, the plug-in sends scanning results to

the drweb-maild module and (in case yes is specified as a value for
the AddXHeaders parameter in the plug-in's configuration file)
adds the following headers:
• X-Anti-virus: Name. Name – name and version of
anti-virus software
• X-Anti-virus-Code: Code. Code – drwebd
module's return code.

112
4.1.1. Installing base package
In all examples given below it is assumed that the base package will
be installed on a computer after Dr.Web MailD is installed. Depending
on the OS version and version of the base package digits in file
names may somewhat differ from those given below.

4.1.1.1. Installing for Linux

The distribution of the base package for Linux is delivered as a tar-
archive (drweb-4.44.1-glibc2.3.tar.gz). This type of
delivery is not connected to any distribution of the system. The base
package for Linux is installed as follows:
1 Copy the distribution of the base package onto a
computer you want to install it.
2 Change the current user of the system to the root user.
For this, execute the su command and input the
password of the root user into the corresponding dialog.
3 Go to the directory with the base package distribution.
4 Unpack the archive. The drweb-4.44.1-glibc2.3
directory will be created.
Example :
> tar xzf drweb-4.44.1-glibc2.3.tar.gz
5 Copy the directory tree nested in the drweb-4.44.1-
glibc2.3 to the root directory (you can also set your
own directory tree, but you will have to edit the Dr.Web
MailD configuration file accordingly, read p. 3.3.1).
Example :
> cp -a drweb-4.44.1-glibc2.3/* /
6 Set access rights for created directories.
Example :
> chown -R drweb:drweb /etc/drweb
> chown -R drweb:drweb /opt/drweb
> chown -R drweb:drweb /opt/drweb

113
Dr.Web® for Unix mail servers
4.1.1.2. Installing for FreeBSD
The distribution of the base package for FreeBSD is delivered as a
tar-archive (drweb-4.44.1-freebsd60.tar.gz). This type
of delivery is not connected to any distribution of the system. The
base package for FreeBSD is installed as follows:
1 Copy the distribution of the base package onto a
computer you want to install it.
2 Change the current user of the system to the root user.
For this, execute the su command and input the
password of the root user into the corresponding dialog.
3 Go to the directory with the base package distribution.
4 Unpack the archive. The drweb-4.44.1-
freebsd60 directory will be created
Example :
> tar xzf drweb-4.44.1-freebsd60.tar.gz
5 Move the directory tree nested in the drweb-4.44.1-
freebsd60 to he root directory (you can also set your
own directory tree, but you will have to edit the Dr.Web
MailD configuration file accordingly, read p. 3.3.1).
Example :
> cp -pR drweb-4.44.1-freebsd60/* /
6 Set access rights for created directories.
Example :
> chown -R drweb:drweb /usr/local/etc/drweb
> chown -R drweb:drweb /usr/local/drweb
> chown -R drweb:drweb /var/drweb

4.1.1.3. Installing for Solaris

The distribution of the base package for Solaris is delivered as a tar-
archive (drweb-4.44.1-solaris10.tar.gz). This type of
delivery is not connected to any distribution of the system. The base
package for Solaris is installed as follows:

114
 1 Copy the distribution of the base package onto a
computer you want to install it.
2 Change the current user of the system to the root user.
For this, execute the su command and input the
password of the root user into the corresponding dialog.
3 Go to the directory with the base package distribution.
4 Unpack the archive. The drweb-4.44.1-
solaris10 directory will be created
Example :
> tar xzf drweb-4.44.1-solaris10.tar.gz
5 Move the directory tree nested in the drweb-4.44.1-
solaris10 to he root directory (you can also set your
own directory tree, but you will have to edit the Dr.Web
MailD configuration file accordingly, read p. 3.3.1).
Example:
> cp -a drweb-4.44.1-solaris10/* /
6 Set access rights for created directories.
Example :
> chown -R drweb:drweb /etc/drweb
> chown -R drweb:drweb /opt/drweb
> chown -R drweb:drweb /var/drweb.

4.1.2. Installing plug-in

In all the examples given below, it is presumed that the Drweb plug-
in is installed to a computer where Dr.Web MailD system has already
been installed. Depending on versions of used OS and plug-ins, file
names can be different from those which are used below.
If the drweb plug-in of any previous version is already installed in a
computer, you can upgrade it. The upgrade procedure is described in
p. 4.1.3.

115
Dr.Web® for Unix mail servers
4.1.2.1. Installing for Linux
Drweb for Linux is distributed as a tarball-archive (drweb-maild-
plugin-drweb-4.44.1-glibc2.3.tar.gz). The software
is installed manually in the following way:
1. Save a distribution file of the plug-in to a computer where
you want to install the software.
2. Switch to root user. For this, execute the su command
and type the root password
3. Go to the directory where you have saved the distribution
file.
4. Switch to root user. For this, execute the su command
and type the root password
5. Extract files from archive. A drweb-maild-plugin-
drweb-4.44.1-glibc2.3 directory with subdirectories
arranged in the tree will be created.
Example:
> tar xzf drweb-maild-plugin-drweb-4.44.1-
glibc2.3.tar.gz

Then, there are 2 modes to install the plug-in: the manual and the
automatic. The installation in the automatic mode is done by the
install.sh installation script located in the drweb-maild-
plugin-drweb-4.44.1-glibc2.3 directory created during
the unpacking of the anti-virus plug-in the install.sh script does
the following:

1 It copies the directory tree nested in drweb-maild-

plugin-drweb-4.44.1-glibc2.3 directory to the
root directory.
2 It sets rights to access directories of the anti-virus plug-in.

116
 3 It integrates the plug-in with Dr.Web MailD.

In case you cannot or do not want to use the install.sh script,

the installation can be done manually:

1 Copy the directory tree nested in the drweb-maild-

qmail-4.44.1-glibc2.3 directory to the root
directory (you can change the structure of directories, but
in this case you should edit the program’s configuration
file accordingly, read p. 3.3.1).
Example:
> cp -a drweb-maild-plugin-drweb-4.44.1-
glibc2.3/* /
2 Then set access rights to the created directories:
Example:
> chown -R drweb:drweb /etc/drweb
> chown -R drweb:drweb /opt/drweb
3 Integrate the plug-in with Dr.Web MailD (read p. 4.1.4)

4.1.2.2. Installing for FreeBSD

Drweb for Linux is distributed as a tarball-archive (drweb-maild-
plugin-drweb-4.44.1-freebsd60.tar.gz). The
software is installed manually in the following way:
1. Save a distribution file of the plug-in to a computer where
you want to install the software.
2. Switch to root user. For this, execute the su command
and type the root password
3. Go to the directory where you have saved the distribution
file.
4. Switch to root user. For this, execute the su command
and type the root password

117
Dr.Web® for Unix mail servers
5. Extract files from archive. A drweb-maild-plugin-
drweb-4.44.1-freebsd60 directory with
subdirectories arranged in a tree will be created.
Example:
> tar xzf drweb-maild-plugin-drweb-4.44.1-
freebsd60.tar.gz

Then, there are 2 modes to install the plug-in: the manual and the
automatic. The installation in the automatic mode is done by the
install.sh installation script located in the drweb-maild-
plugin-drweb-4.44.1- freebsd60 directory created
during the unpacking of the anti-virus plug-in. The install.sh
script does the following:

1 It copies directory tree containing in drweb-maild-

plugin-drweb-4.44.1-freebsd60 directory to
the root directory.
2 It sets rights to access directories of the anti-virus plug-in.
It integrates the plug-in with Dr.Web
MailD.

In case you cannot or do not want to use the install.sh script,

the installation can done manually:

1 Copy the directory tree nested in the drweb-maild-

plugin-drweb-4.44.1-freebsd60 directory to
the root directory (you can change the structure of
directories, but in this case you should edit the program’s
configuration file accordingly, read p. 3.3.1).
Example:

118
 > cp -pR drweb-maild-plugin-drweb-4.44.1-
freebsd60/* /
2 Then set access rights to the created directories:
Example:
> chown -R drweb:drweb /usr/local/etc/drweb
> chown -R drweb:drweb /usr/local/drweb
3 Integrate the plug-in with Dr.Web MailD (read p. 4.1.4)

4.1.2.3. Installing for Solaris

Drweb for Solaris is distributed as a tarball-archive (drweb-
maild-plugin-drweb-4.44.1-solaris10.tar.gz). The
software is installed manually in the following way:
1. Save a distribution file of the plug-in to a computer where you
want to install the software.
2. Go to the directory where you have saved the distribution file.
3. Switch to root user. For this, execute the su command and
type the root password.
4. Extract files from archive. A drweb-maild-plugin-
drweb-4.44.1-solaris10 directory with subdirectories
arranged in the tree will be created.
Example:
> gzip -d drweb-maild-plugin-drweb-4.44.1-
solaris10.tar.gz
> tar xf drweb-maild-plugin-drweb-4.44.1-
solaris10.tar

Then, there are 2 modes to install the plug-in: the manual and the
automatic. The installation in the automatic mode is done by the
install.sh installation script located in the drweb-maild-
plugin-drweb-4.44.1-solaris10 directory created during
the unpacking of the anti-virus plug-in. The install.sh script
does the following:

119
Dr.Web® for Unix mail servers

1 It copies the directory tree nested in the drweb-

maild-plugin-drweb-4.44.1-solaris10
directory to the root directory.
2 It sets rights to access directories of the anti-virus plug-in.
3 It integrates the plug-in with Dr.Web MailD.

In case you cannot or do not want to use the install.sh script,

installation can be done manually:

1 Copy the directory tree nested in the drweb-maild-

plugin-drweb-4.44.1-solaris10 directory to
the root directory (you can change the structure of
directories, but in this case you should edit the program’s
configuration file accordingly, read p. 3.3.1).
Example:
> cp -pR drweb-maild-plugin-drweb-4.44.1-
solaris10/* /
2 Then set access rights to the created directories:
Example:
> chown -R drweb:drweb /etc/drweb
> chown -R drweb:drweb /opt/drweb
3 Integrate the plug-in with Dr.Web MailD (read p. 4.1.4)

4.1.3. Upgrading plug-in

The plug-in can be upgraded if the plug-in of the previous version is
already installed on a computer.
In all examples given below it is assumed that the drweb plug-in will
be installed on a computer after Dr.Web MailD is installed. Depending
on the OS version and the plug-in version the digits in file names
may somewhat differ from those given below.

120
4.1.3.1. Upgrading for Linux
The drweb distribution for Linux is delivered as a tar-archive
(drweb-maild-plugin-drweb-4.44.1-
glibc2.3.tar.gz). The drweb plug-in for Linux is upgraded as
follows:
1 Copy the distribution of the plug-in onto a computer
where you want to upgrade it.
2 Change the current user of the system to the root user.
For this, execute the su command and input the
password of the root user into the corresponding dialog.
3 Go to the directory with the plug-in distribution.
4 Unpack the archive. The drweb-maild-plugin-
drweb-4.44.1-glibc2.3 directory will be created
Example :
> tar xzf drweb-maild-plugin-drweb-4.44.1-
glibc2.3.tar.gz
5 In the drweb-maild-plugin-drweb-4.44.1-
glibc2.3 directory created during the unpacking of
the archive with the plug-in the install.sh script
resides. To upgrade, run this script with the update
parameter. If launched with this parameter, the
install.sh script will perform the following actions:
5.1Copies the directory tree nested in the drweb-
maild-plugin-drweb-4.44.1-glibc2.3
directory to the root directory and files of the installed
version of plug-in replace all files of the already installed
plug-in, except for configuration files. The configuration
files of the already installed plug-in remain unchanged.
During the replacement of the configuration files of the
new version of plug-in the script adds the .new suffix to
their names.

121
Dr.Web® for Unix mail servers
5.2Sets access rights for directories of the plug-in.

4.1.3.2. Upgrading for FreeBSD

The drweb distribution for FreeBSD is delivered as a tar-archive
(drweb-maild-plugin-drweb-4.44.1-
freebsd60.tar.gz). The drweb plug-in for FreeBSD is
upgraded as follows:
18 Copy the distribution of the plug-in onto a computer where
you want to upgrade it.
19 Change the current user of the system to the root user.
For this, execute the su command and input the password
of the root user into the corresponding dialog.
20 Go to the directory with the plug-in distribution.
21 Unpack the archive. The drweb-maild-plugin-
drweb-4.44.1-freebsd60 directory will be created
Example :
>tar xzf drweb-maild-plugin-drweb-4.44.1-
freebsd60.tar.gz
22 In the drweb-maild-plugin-drweb-4.44.1-
freebsd60 directory created during the unpacking of
the archive with the plug-in the install.sh script
resides. To upgrade, run this script with the update
parameter. If launched with this parameter, the
install.sh script will perform the following actions:
22.1Copies the directory tree nested in the drweb-
maild-plugin-drweb-4.44.1-freebsd60
directory to the root directory and files of the installed
version of plug-in replace all files of the already installed
plug-in, except for configuration files. The configuration
files of the already installed plug-in remain unchanged.
During the replacement of the configuration files of the
new version of plug-in the script adds the .new suffix to
their names.

122
 22.2Sets access rights for directories of the plug-in.

4.1.3.3. Upgrading for Solaris

The drweb distribution for Solaris is delivered as a tar-archive
(drweb-maild-plugin-drweb-4.44.1-
solaris10.tar.gz). The drweb plug-in for Solaris is upgraded
as follows:
23 Copy the distribution of the plug-in onto a computer where
you want to upgrade it.
24 Change the current user of the system to the root user.
For this, execute the su command and input the password
of the root user into the corresponding dialog.
25 Go to the directory with the plug-in distribution.
26 Unpack the archive. The drweb-maild-plugin-
drweb-4.44.1-solaris10 directory will be created
Example :
> gzip -d drweb-maild-plugin-drweb-4.44.1-
solaris10.tar.gz
> tar xf drweb-maild-plugin-drweb-4.44.1-
solaris10.tar
27 In the drweb-maild-plugin-drweb-4.44.1-
solaris10 directory created during the unpacking of
the archive with the plug-in the install.sh script
resides. To upgrade, run this script with the update
parameter. If launched with this parameter, the
install.sh script will perform the following actions:
27.1Copies the directory tree nested in the drweb-
maild-plugin-drweb-4.44.1-solaris10
directory to the root directory and files of the installed
version of plug-in replace all files of the already installed
plug-in, except for configuration files. The configuration
files of the already installed plug-in remain unchanged.
During the replacement of the configuration files of the

123
Dr.Web® for Unix mail servers
new version of plug-in the script adds the .new suffix to
their names.
27.2Sets access rights for directories of the plug-in.

4.1.4. Connecting with the plug-in

To connect drweb plug-in to Dr.Web MailD, you should add drweb
to the list of plug-ins for processing messages in the Dr.Web MailD's
configuration file (see p. 3.3). In case you want to have a message
processed by the drweb plug-in before it is moved to the database,
you should add the name of the plug-in to the values of
BeforeQueueFilters parameter in the [Filter] section of
Dr.Web MailD's configuration file.
Example: BeforeQueueFilters = drweb

If you want to have a message processed by the plug-in after it is

moved to the database you should add the name of the plug-in to
the values of the AfterQueueFilters parameter in the
[Filter] section of the Dr.Web MailD's configuration file.

Example: AfterQueueFilters = drweb

4.1.5. Configuring plug-in

All the main parameters are set in the configuration file
(%etc_dir/plugin_drweb.conf). The structure principles of
description of parameters of the configuration file are described
above (see p. 3.3).

[Anti-virus] section

Address ={address}
Address of socket, which anti-virus plug-in uses to send tasks for
checking messages to daemon. It is possible to specify several
addresses of different daemons on different servers. Address at the

124
top of the list is considered as the main one, the rest is kept in
reserve. Apart from standard address types, this parameter supports
pid.
Examples:
• Format of pid – Address =
pid:/var/drweb/run/drwebd.pid
• Format of several addresses – Address =
pid:/var/drweb/run/drwebd.pid, inet:
[email protected]
Default value: pid:/var/drweb/run/drwebd.pid

Timeout ={time}
Timeout for daemon to execute a command (0 - time is not limited).

Default value: 30s

TCP_NODELAY = {yes|no}
With the yes value, the socket will work with TCP_NODELAY

Default value: no

HeuristicAnalysis = {yes|no}
Enabling/disabling the heuristic analyzer to detect unknown viruses.
The heuristic analysis allows detection of unknown viruses. It is
based on an a priori assumption how a virus code is arranged. Such
kind of analysis is approximate and probabilistic, and we can speak of
not infected, but suspicious objects only.
With the heuristic analyzer disabled, only known viruses the
signatures of which are stored in the database can be detected. With
the heuristic analyzer enabled, programs can trigger false alarms due
to usage of codes similar to viruses. Moreover, the heuristic analyzer
125
Dr.Web® for Unix mail servers
can somewhat extend the duration of scanning (not for long,
though).
Default value: yes.

ReportMaxSize = {size}
Maximum size of Dr.Web MailD log file. If for ReportMaxSize
parameter 0 is specified, log file size is not limited.

Default value: 50k

It is not recommended to set ReportMaxSize parameter

to null; if so, size of log-files can amount to several Mbs upon
detection of malware i.e. mail bombs in messages.

AddXHeaders ={yes|no}
If yes is specified, X-Anti-virus and X-Anti-virus-Code
headers will be added to the scanned messages.
Default value: depends on the distribution file

LocalScan = {yes|no}
If yes is specified, daemon scans messages in local mode.

LocalScan parameter affects only operation of daemon whose socket

is specified first in the Address parameter. To enable daemon's
operation in local mode, directory containing messages to scan must
be accessible for reading to daemon. To cure infected messages, it
must be accessible for writing. (See also User parameter in
drweb32.ini)
Default value: yes

126
Paranoid = {yes|no}
If yes is specified, messages will be scanned in "paranoid" mode.

In this mode a message is sent for checking to daemon segment by

segment as well as "all-in-one-piece" which somewhat increases a
possibility of detecting a virus, but extends the check duration at the
same time.
Default value: no

LicenseLimit = {Action}
This parameter defines action that should be applied to messages
which have not been scanned due to license limitations.
Possible main actions: pass, discard, reject, tempfail.

Default value: pass

Infected = {Action}
Defines action for messages infected with a known virus. All main
and possible actions can be specified for this parameter.
Default value: cure, quarantine.

There are a number of parameters that affect the action of the

program that is applied to malware detected in messages. For these
parameters the same values as for the Infected parameter with
the exception of Cure can be specified.

Suspicious — a message can be infected with an unknown virus.

Incurable – message is incurable.
CureFail – Message has been cured or deleted but attempt to
receive it from the daemon failed

127
Dr.Web® for Unix mail servers
Adware – message contains adware
Dialers – message contains a dialer
Jokes – message contains a joke that can scare or annoy a user.
Riskware – message contains riskware that can be used even by
criminals.
Hacktools – message contains programs used to hack into
computers
SkipObject – messages contains objects that cannot be scanned
by daemon (for example, when password protection is used)
ArchiveRestriction – message contains archive that cannot
be scanned by daemon due to limits set for archives in daemon
settings
ScanningErrors – messages, which when being scanned make
daemon generate errors. For example, it has run short of memory or
does not have proper rights for processing.
ProcessingErrors – Messages which when being scanned
make plug-in generate errors, for example, anti-virus plug-in runs
short of memory or cannot connect to daemon.

In case a message is blocked by the anti-virus plug-in, SMTP-

response from the Dr.Web MailD has 550 5.7.0 error code and a
text message which is determined by the parameters that go below.
Value of parameters must be set in quotes.

UseCustomReply = {yes|no}
If yes is set, content of SMTP-responses sent by the Dr.Web MailD
are determined by the parameters given below. If no is set, default
values are used.
Default value: no

128
ReplyInfected = {text value}
SMTP-response, generated in cases when a message is blocked due
to detection of a virus.
Default value: "DrWEB Anti-virus: Message is
rejected because it contains a virus."

ReplyMalware = {text value}

SMTP-response to a message blocked due to detection of malware
Default value: "DrWEB Anti-virus: Message is
rejected because it contains a malware."

ReplySuspicious = {text value}

SMTP-response to a message blocked due to detection of suspicious
objects.
Default value:"DrWEB Anti-virus: Message is
rejected because it contains suspicious
content."

ReplySkipObject ={text value}

SMTP-response to a message blocked due to the fact that it cannot
be scanned.
Default value: "DrWEB Anti-virus: Message is
rejected because it cannot be checked."

ReplyArchiveRestriction = {text value}

SMTP-response to a message blocked due to limitations set for
checking of archives.

129
Dr.Web® for Unix mail servers
Default value: "DrWEB Anti-virus: Message is
rejected because it contains archive which
violates restrictions."

ReplyError = {text value}

SMTP-response to a message blocked due to a program error
Default value: "DrWEB Anti-virus: Message is
rejected due to software error."

4.2. Filtering by headers plug-in

headersfilter is a plug-in used for filtering e-mail messages by
header. When setting rules for operation of the plug-in you can use
regular expressions.

4.2.1. Installing plug-in

In all the examples given below, by default the headersfilter plug-in
is installed to a computer where Dr.Web MailD is already installed.
Depending on versions of used OS and plug-in, file names can be
different from those given below.
If the headersfilter plug-in of one of the previous versions is already
installed on a computer, you can upgrade it. The upgrade procedure
is described in p. 4.2.2.

4.2.1.1. Installing for Linux

Headersfilter for Linux is distributed as a tarball-archive (drweb-
maild-plugin-headersfilters-4.44.1-
glibc2.3.tar.gz). The software is installed manually in the
following way:
1. Save a distribution file of the plug-in to a computer where you
want to install the software.

130
 2. Switch to root user. For this, execute the su command and
type the root password
3. Go to the directory where you have saved the distribution file.
4. Extract files from archive. A drweb-maild-plugin-
headersfilters-4.44.1-glibc2.3 directory with
subdirectories arranged in a tree will be created.
Example:
> tar xzf drweb-maild-plugin-
headersfilters-4.44.1-glibc2.3.tar.gz
Then, there are 2 modes to install the plug-in: the manual and the
automatic. The installation in the automatic mode is done by the
install.sh installation script located in the drweb-maild-
plugin-headersfilters-4.44.1-glibc2.3 directory
created during the unpacking of the plug-in. The install.sh
script does the following:

1 It copies the directory tree nested in the drweb-

maild-plugin-headersfilters-4.44.1-
glibc2.3 directory to the root directory.
2 It sets rights to access directories of the headersfilter
plug-in.
3 It integrates the plug-in with Dr.Web MailD.

In case you cannot or do not want to use the install.sh script,

the installation can be done manually:

1. Copy the directory tree nested in the drweb-maild-

plugin-headersfilters-4.44.1-glibc2.3
directory to the root directory (you can change the
structure of directories, but in this case you should edit the

131
Dr.Web® for Unix mail servers
program’s configuration file accordingly, read p. 3.3.1).
Example:
> cp -a drweb-maild-plugin-
headersfilters-4.44.1-glibc2.3/* /
2. Then set access rights to the created directories:
Example:
> chown -R drweb:drweb /etc/drweb
> chown -R drweb:drweb /opt/drweb
3. Integrate the plug-in with Dr.Web MailD (read p. 4.2.3)

4.2.1.2. Installing for FreeBSD

Headersfilter for FreeBSD is distributed as a tarball-archive (drweb-
maild-plugin-headersfilters-4.44.1-
freebsd60.tar.gz). This software is installed manually in the
following way:
1. Save a distribution file of the plug-in to a computer where you
want to install the software.
2. Switch to root user. For this, execute the su command and
type the root password
3. Go to the directory where you have saved the distribution file.
4. Switch to root user. For this, execute the su command and
type the root password
5. Extract files from archive. A drweb-maild-plugin-
headersfilters-4.44.1-freebsd60 directory with
subdirectories arranged in a tree will be created.
Example:
> tar xzf drweb-maild-plugin-
headersfilters-4.44.1-freebsd60.tar.gz
Then, there are 2 modes to install the plug-in: the manual and the
automatic. The installation in the automatic mode is done by the
install.sh installation script located in the drweb-maild-

132
plugin-headersfilters-4.44.1-freebsd60 directory
created during the unpacking of the plug-in. The install.sh
script does the following:

1 It copies the directory tree nested in the drweb-

maild-plugin-headersfilters-4.44.1-
freebsd60 directory to the root directory.
2 It sets rights to access directories of the headersfilter
plug-in.
3 It integrates the plug-in with Dr.Web MailD.

In case you cannot or do not want to use the install.sh script,

the installation can be done manually:

1 Copy the directory tree nested in the drweb-maild-

plugin-headersfilters-4.44.1-freebsd60
directory to the root directory (you can change the
structure of directories, but in this case you should edit
the program’s configuration file accordingly, read
p. 3.3.1).
Example:
> cp -pR drweb-maild-plugin-
headersfilters-4.44.1-freebsd60/* /
2 Then set access rights to the created directories:
Example:
> chown -R drweb:drweb /usr/local/etc/drweb
> chown -R drweb:drweb /usr/local/drweb
3 Integrate the plug-in with Dr.Web MailD (read p. 4.2.3)

133
Dr.Web® for Unix mail servers
4.2.1.3. Installing for Solaris
Headersfilter for Solaris is distributed as a tarball-archive (drweb-
maild-plugin-headersfilters-4.44.1-
solaris10.tar.gz). This software is installed manually in the
following way:
1. Save a distribution file of the plug-in to a computer where you
want to install the software.
2. Switch to root user. For this, execute the su command and
type the root password
3. Go to the directory where you have saved the distribution file.
4. Extract files from archive. A drweb-maild-plugin-
headersfilters-4.44.1-solaris10 directory with
subdirectories arranged in a tree will be created.
Example:
> gzip -d drweb-maild-plugin-
headersfilters-4.44.1-solaris10.tar.gz
> tar xf drweb-maild-plugin-
headersfilters-4.44.1-solaris10.tar
Then, there are 2 modes to install the plug-in: the manual and the
automatic. The installation in the automatic mode is done by the
install.sh installation script located in the drweb-maild-
plugin-headersfilters-4.44.1-solaris10 directory
created during the unpacking of the plug-in. The install.sh
script does the following:

1 It copies the directory tree nested in the drweb-

maild-plugin-headersfilters-4.44.1-
solaris10 directory to the root directory.
2 It sets rights to access directories of the headersfilter
plug-in.
3 It integrates the plug-in with Dr.Web MailD.

134
 In case you cannot or do not want to use the install.sh script,
the installation can be done manually:

1 Copy the directory tree nested in the drweb-maild-

plugin-headersfilters-4.44.1-solaris10
directory to the root directory (you can change the
structure of directories, but in this case you should edit
the program’s configuration file accordingly, read p.
3.3.1).
Example:
> cp -pR drweb-maild-plugin- headersfilters
-4.44.1-solaris10/* /
2 Then set access rights to the created directories:
Example:
> chown -R drweb:drweb /etc/drweb
> chown -R drweb:drweb /opt/drweb
3 Integrate the plug-in with Dr.Web MailD (read p. 4.2.3)

4.2.2. Upgrading plug-in

The headersfilter plug-in is upgraded if the headersfilter plug-in of
the previous version is already installed on a computer. In all
examples given below it is assumed, that the headersfilter will be
installed after Dr.Web MailD is installed. Depending on the OS version
and the plug-in version, the digits in file names may somewhat differ
from those given below.

4.2.2.1. Upgrading for Linux

The headersfilter distribution for Linux is delivered as a tar-archive
(drweb-maild-plugin-headersfilter-4.44.1-
glibc2.3.tar.gz). The headersfilter plug-in for Linux is
upgraded as follows:

135
Dr.Web® for Unix mail servers
1. Copy the distribution of the plug-in onto a computer where
you want to upgrade it.
2. Change the current user of the system to the root user.
For this, execute the su command and input the
password of the root user into the corresponding dialog.
3. Go to the directory with the plug-in distribution.
4. Unpack the archive. The drweb-maild-plugin-
headersfilter-4.44.1-glibc2.3 directory will
be created.
Example :
> tar xzf drweb-maild-plugin-
headersfilter-4.44.1-glibc2.3.tar.gz
5. In the drweb-maild-plugin-
headersfilter-4.44.1-glibc2.3 directory
created during the unpacking of the archive with the plug-
in the install.sh installation script resides. To upgrade,
run this script with the update parameter. Being
launched with this parameter, the install.sh script
will perform the following actions:
5.1.Copies the directory tree nested in the drweb-
maild-plugin-headersfilter-4.44.1-
glibc2.3 directory to the root directory and files of
the installed version of the plug-in replace all files of the
already installed plug-in, except for configuration files.
The configuration files of the already installed plug-in
remain unchanged. During the replacement of the
configuration files of the new version of the plug-in the
script adds the .new suffix to their names.
5.2.Sets access rights for directories of the plug-in.

136
4.2.2.2. Upgrading for FreeBSD
The headersfilter distribution for FreeBSD is delivered as a tar-archive
(drweb-maild-plugin-headersfilter-4.44.1-
freebsd60.tar.gz). The headersfilter plug-in for FreeBSD is
upgraded as follows:
1. Copy the distribution of the plug-in onto a computer where
you want to upgrade it.
2. Change the current user of the system to the root user.
For this, execute the su command and input the
password of the root user into the corresponding dialog.
3. Go to the directory with the plug-in distribution.
4. Unpack the archive. The drweb-maild-plugin-
headersfilter-4.44.1-freebsd60 directory
will be created.
Example :
>tar xzf drweb-maild-plugin-
headersfilter-4.44.1-freebsd60.tar.gz
5. In the drweb-maild-plugin-
headersfilter-4.44.1-freebsd60 directory
created ruing the unpacking of the archive with the plug-in
the install.sh installation script resides. To upgrade,
run this script with the update parameter. Being
launched with this parameter, the install.sh script
will perform the following actions:
5.1.Copies directory tree nested in the drweb-maild-
plugin-headersfilter-4.44.1-freebsd60
directory to the root directory and files of the installed
version of the plug-in replace all files of the already
installed plug-in, except for configuration files. The
configuration files of the already installed plug-in remain
unchanged. During the replacement of the configuration

137
Dr.Web® for Unix mail servers
files of the new version of the plug-in the script adds the
.new suffix to their names.
5.2.Sets access rights for directories of the plug-in.

4.2.2.3. Upgrading for Solaris

The headersfilter distribution for Solaris is delivered as a tar-archive
(drweb-maild-plugin-headersfilter-4.44.1-
solaris10.tar.gz). The headersfilter plug-in for Solaris is
upgraded as follows:
1. Copy the distribution of the plug-in onto a computer where
you want to upgrade it.
2. Change the current user of the system to the root user.
For this, execute the su command and input the password
of the root user into the corresponding dialog.
3. Go to the directory with the plug-in distribution.
4. Unpack the archive. The drweb-maild-plugin-
headersfilter-4.44.1-solaris10 directory
will be created.
Example :
> gzip -d drweb-maild-plugin-
headersfilter-4.44.1-solaris10.tar.gz
> tar xf drweb-maild-plugin-
headersfilter-4.44.1-solaris10.tar
5. In the drweb-maild-plugin-
headersfilter-4.44.1-solaris10 directory
created during the unpacking of the archive with the plug-
in the install.sh installation script resides. To
upgrade, run this script with the update parameter.
Being launched with this parameter, the install.sh
script will perform the following actions:

138
 5.1.Copies the directory tree nested in the drweb-
maild-plugin-headersfilter-4.44.1-
solaris10 directory to the root directory and files of
the installed version of the plug-in replace all files of the
already installed plug-in, except for configuration files.
The configuration files of the already installed plug-in
remain unchanged. During the replacement of the
configuration files of the new version of the plug-in the
script adds the .new suffix to their names.
5.2.Sets access rights for directories of the plug-in.

4.2.3. Connecting with the plug-in

To connect the headersfilter plug-into Dr.Web MailD in the
configuration file of Dr.Web MailD, add headersfilter to the list
of plug-ins you want to process your messages (see p. 3.3). In case
you want to have your messages processed by the headersfilter plug-
in before they are moved to the database, add the name of the
plug-in to the values of the BeforeQueueFilters parameters
in the [Filter] section of the configuration file of Dr.Web MailD
Example: BeforeQueueFilters = drweb,headersfilter

If you want to have your messages processed by the plug-in after

they are moved to the database, add the name of the plug-in to the
values of the AfterQueueFilters parameter in the [Filter]
section of the configuration file of Dr.Web MailD.
Example: AfterQueueFilters = headersfilter

4.2.4. Configuring plug-in

All the main parameters concerning operation of the plug-in are
specified in the %etc_dir/plugin_headersfilters.conf
configuration file. The structure and descriptions of parameters of the
configuration file are described above (see p. 3.3).

139
Dr.Web® for Unix mail servers

[HeadersFilter] section

Filtration parameters are defined by rules which are described below.

Rules are analyzed in the same order as they are listed in the section,
i.e. a rule which is set first in the list is analyzed first. Rules are
analyzed until a suitable rule is found and the plug-in executes the
action which is set for this rule.

If Reject* rule is applied to a message, the

message will not be processed further. If Accept*
rule is applied to a message, other rules will be
ignored and the message will be processed by
other plug-ins of the Dr.Web MailD.

ScanEncodedHeaders = {yes|no}
If yes is specified as the parameter’s value, headers of messages
are processed until decoding is complete. For example, yes as the
value for the ScanEncodedHeaders parameter and
RejectCondition = Subject = "iso-8859-5"
rule allow to filter out messages whose subject string is encoded with
iso-8859-5. In case yes is specified as the parameter’s value all
the encoded headers will be scanned twice: before and after
encoding is complete.
Default value: yes.

RejectCondition = {set of conditions}

Rule for filtering messages. If a single condition is true of a message,
this message is filtered out. Action for filtered messages can be
specified in the Action parameter of this section.

Conditions can be specified for any header and consist of header

name and regular expression, which describes its meaning;

140
HEADER = regular expression. You can combine several
conditions using parentheses or OR and AND operations. Values
containing blanks must be set in inverted commas.
Example: RejectCondition = Subject = "money"
AND "Content-Type" = "text/html"
"!=" (not equal) operator can also be used when setting a condition.
Moreover, there are two additional types of filtration:
• No HEADER – conditions, suitable for messages without a
certain header
Example: according to the following rule:
RejectCondition = No From

All messages without From field will be

filtered out.
• HEADER = "8bit" – condition is suitable for the case when
a header contains 8-bit symbols.
Default value: not specified

AcceptCondition = {set of conditions}

Rule for accepting messages. Once a single condition is true of a
message, filtration is interrupted and the message is sent to other
plug-ins for scanning. All the information above in the
RejectCondition section is suitable for the
AcceptCondition section.

FilterParts = {yes|no}
Yes enables processing of rules specified by the
RejectPartCondition and AcceptPartCondition
parameters.
Default value: no

141
Dr.Web® for Unix mail servers
RejectPartCondition = {set of conditions}
AcceptPartCondition = {set of conditions}
Rules are similar to those of RejectCondition and
AcceptCondition, but they affect also headers of attached
objects. In addition to conditions used in RejectCondition and
AcceptCondition rules, in rules for RejectPartCondition
and AcceptPartCondition you can use the following
condition – FileName = mask, where mask is a regular
expression that complies with POSIX 1003.2 standard. Filtration of
messages according to these rules is possible if yes is set for the
FilterParts parameter (see above).
Default value: not specified

MissingHeader = {text value}

Rule defines a set of headers missing in a message, which should be
a condition for filtration. For example:
MissingHeader = "To", "From".

Default value: not specified

Action = {actions}
Actions applied to filtered objects. When you set the value, you must
specify one main and up to 3 additional values. Main values must be
set first.

Parameter can have main discard, reject actions and other

additional actions.
Default value: reject, notify

142
 In case a message is blocked by the header’s filter, SMTP-response
of Dr.Web MailD has 550 5.7.0 error code and a message defined
by the parameters that go further.

UseCustomReply = {yes|no}
In case yes is specified for this parameter, contents of SMTP-
responses are defined by the parameters given below. If no is
specified, default values are used.
Default value: no

ReplyRuleFilter ={text value}

SMTP-response, generated in case a message is blocked by the
header’s filter.

Default value:"DrWEB HeadersFilter plugin: Message

is rejected by headers rule filter."

4.3. Anti-spam vaderetro plug-in

vaderetro – is a Dr.Web MailD plug-in to filter e-mails for spam using
VadeRetro library designed by a French company Goto Software.
VadeRetro library analyzes mail in the fully autonomous mode
without requesting external sources for additional information on
spam. Moreover, the library assures for high processing speed and a
constant increase in the quality of a message analysis which is
possible due to the fact that the library's code is being dynamically
updated.
Depending on the results of the analysis, each message processed by
the VadeRetro library gets a mark – a whole number in the range
from -10000 to +10000. The less is the value, the higher is the

143
Dr.Web® for Unix mail servers
probability that the message is not spam. The threshold is set in the
SpamThreshold parameter of the plug-in’s configuration file (if
the score given to a message either equals to the SpamThreshold
parameter value, or is greater, the message is classified as spam).
Once analysis is complete, VadeRetro library adds to it the following
headers:
• X-DRWEB-SCORE: n. n – mark that Vade Retro gives to
a message
• X-DRWEB-STATE: s. s – message classification results
can take 4 values: 0, 1 , 2 and 3:
 0 – message is not spam;
 1 – message is spam;
 2 – message is infected;
 3 – message is a notification saying that delivery
failed.
• X-DRWEB-VERSION: version. version – version of
VadeRetro library. This header is added only in case yes is
specified for the AddVersionHeader parameter of the
VadeRetro plug-in's configuration file.

• Moreover, vaderetro plug-in can add value of the

SubjectPrefix parameter of the vaderetro configuration file to
the subject of the message, classified by the VadeRetro library
as spam or infected. This works only in case any value is
specified for the SubjectPrefix parameter.

4.3.1. Installing plug-in

In all the examples given below, by default the vaderetro plug-in is
installed to a computer where Dr.Web MailD system is already
installed. Depending on versions of OS and plug-in you are using

144
 names of files can be different from those which are mentioned
below.
If the vaderetro plug-in of any previous versions is already installed
on a computer, you can upgrade it. The upgrade procedure is
described in p. 4.3.2.

4.3.1.1. Installing for Linux

VadeRetro for Linux is distributed as a tarball-archive (drweb-
maild-plugin-vaderetro-4.44.1-glibc2.3.tar.gz).
The software is installed manually in the following way:
1. Save the archive containing Dr.Web MailD to a computer.
2. Enter the directory where you have saved the archive.
3. Log on as a root user. For this, type su and enter password
of the root user.
4. Extract files from archive. A drweb-maild-plugin-
vaderetro-4.44.1-glibc2.3 directory with
subdirectories arranged in a tree will be created.
Example:
> tar xzf drweb-maild-plugin-
vaderetro-4.44.1-glibc2.3.tar.gz
Then, there are 2 modes to install the plug-in: the manual and the
automatic. The installation in the automatic mode is done by the
install.sh installation script located in the drweb-maild-
plugin-vaderetro-4.44.1-glibc2.3 directory created
during the unpacking of the anti-spam plug-in. The install.sh
script does the following:

1 It copies the directory tree nested in the drweb-

maild-plugin-vaderetro-4.44.1-glibc2.3
directory to the root directory.

145
Dr.Web® for Unix mail servers
2 It sets rights to access directories of the vaderetro plug-
in.
3 It integrates the plug-in with Dr.Web MailD.

In case you cannot or do not want to use the install.sh script,

the installation can be done manually:

1 Copy the directory tree nested in the drweb-maild-

drweb-maild-plugin-vaderetro-4.44.1-
glibc2.3 directory to the root directory (you can
change the structure of directories, but in this case you
should edit the program’s configuration file accordingly,
read p. 3.3.1).
Example:
> cp -a drweb-maild-plugin-
vaderetro-4.44.1-glibc2.3/* /
2 Then set access rights to the created directories:
Example:
> chown -R drweb:drweb /etc/drweb
> chown -R drweb:drweb /opt/drweb
3 Integrate the plug-in with Dr.Web MailD (read p. 4.3.3)

4.3.1.2. Installing for FreeBSD

VadeRetro for FreeBSD is distributed as a tarball-archive (drweb-
maild-plugin-vaderetro-4.44.1-
freebsd60.tar.gz). The software is installed manually in the
following way:
1. Save the archive containing Dr.Web MailD to a computer.
2. Enter the directory where you have saved the archive.
3. Log on as a root user. For this, type su and enter password
of the root user.

146
 4. Extract files from archive. A drweb-maild-plugin-
vaderetro-4.44.1-freebsd60 directory with
subdirectories arranged in a tree will be created.
Example:
tar xzf drweb-maild-plugin-vaderetro-4.44.1-
freebsd60.tar.gz
Then, there are 2 modes to install the plug-in: the manual and the
automatic. The installation in the automatic mode is done by the
install.sh installation script located in the drweb-maild-
plugin-vaderetro-4.44.1-freebsd60 directory created
during the unpacking of the anti-spam plug-in. The install.sh
script does the following:

1 It copies the directory tree nested in the drweb-

maild-plugin-vaderetro-4.44.1-
freebsd60 directory to the root directory.
2 It sets rights to access directories of the vaderetro plug-
in.
3 It integrates the plug-in with Dr.Web MailD.

In case you cannot or do not want to use the install.sh script,

the installation can be done manually:

1 Copy the directory tree nested in the drweb-maild-

drweb-maild-plugin-vaderetro-4.44.1-
freebsd60 directory to the root directory (you can
change the structure of directories, but in this case you
should edit the program’s configuration file accordingly,
read p. 3.3.1).
Example:

147
Dr.Web® for Unix mail servers
> cp -pR drweb-maild-plugin-
vaderetro-4.44.1-freebsd60/* /
2 Then set access rights to the created directories:
Example:
> chown -R drweb:drweb /usr/local/etc/drweb
> chown -R drweb:drweb /usr/local/drweb
3 Integrate the plug-in with Dr.Web MailD (read p. 4.3.3)

4.3.1.3. Installing for Solaris

vaderetro for Solaris is distributed as a tarball-archive (drweb-
maild-plugin-vaderetro-4.44.1-solaris10.tar.
gz). The software is installed manually in the following way:
1. Save the archive containing Dr.Web MailD to a computer.
2. Enter the directory where you have saved the archive.
3. Log on as a root user. For this, type su and enter
password of the root user.
4. Extract files from archive. A drweb-maild-plugin-
vaderetro-4.44.1-solaris10 directory with
subdirectories arranged in a tree will be created.
Example:
> gzip -d drweb-maild-plugin-
vaderetro-4.44.1-solaris10.tar.gz
> tar xf drweb-maild-plugin-
vaderetro-4.44.1-solaris10.tar
Then, there are 2 modes to install the plug-in: the manual and the
automatic. The installation in the automatic mode is done by the
install.sh installation script located in the drweb-maild-
plugin-vaderetro-4.44.1-solaris10 directory created
during the unpacking of the anti-spam plug-in. The install.sh
script does the following:

148
 1 It copies the directory tree nested in the drweb-
maild-plugin-vaderetro-4.44.1-
solaris10 directory to the root directory.
2 It sets rights to access directories of the vaderetro plug-
in.
3 It integrates the plug-in with Dr.Web MailD.

In case you cannot or do not want to use the install.sh script,

the installation can be done manually:

1. Copy the directory tree nested in the drweb-maild-

plugin-vaderetro-4.44.1-solaris10
directory to the root directory (you can change the
structure of directories, but in this case you should edit the
program’s configuration file accordingly, read p. 3.3.1).
Example:
> cp -pR drweb-maild-plugin-
vaderetro-4.44.1-solaris10/* /
2. Then set access rights to the created directories:
Example:
> chown -R drweb:drweb /etc/drweb
> chown -R drweb:drweb /opt/drweb
3. Integrate the plug-in with Dr.Web MailD (read p. 4.3.3)

4.3.2. Upgrading plug-in

You should upgrade the vaderetro plug-in, if vaderetro of the
previous version is already installed on a computer.
In all examples given below it is assumed, that the vaderetro plug-in
is installed after the installation of Dr.Web MailD. Depending on the
OS version used by you and the plug-in version the digits in file
names may somewhat differ from those given below.

149
Dr.Web® for Unix mail servers
4.3.2.1. Upgrading for Linux
The vaderetro distribution for Linux is delivered as a tar-archive
(drweb-maild-plugin-vaderetro-4.44.1-
glibc2.3.tar.gz). The vaderetro plug-in for Linux is
upgraded as follows:
1. Copy the distribution of the plug-in onto a computer where
you want to upgrade it.
2. Change the current user of the system to the root user.
For this, execute the su command and input the password
of the root user into the corresponding dialog.
3. Go to the directory with the plug-in distribution.
4. Unpack the archive. The drweb-maild-plugin-
vaderetro-4.44.1-glibc2.3 directory will be
created.
Example :
> tar xzf drweb-maild-plugin-
vaderetro-4.44.1-glibc2.3.tar.gz
5. In the drweb-maild-plugin-
vaderetro-4.44.1-glibc2.3 directory created
during the unpacking of the archive with the plug-in the
install.sh installation script resides. To upgrade, run
this script with the update parameter. Being launched
with this parameter, the install.sh script will perform
the following:
5.1.It copies the directory tree nested in the drweb-
maild-plugin-vaderetro-4.44.1-
glibc2.3 directory to the root directory. The files of
the installed version of the plug-in replace the files of
the already installed plug-in, except for configuration
files. The configuration files of the already installed plug-
in remain unchanged. When configuration files of the

150
 new version are created, the .new suffix is added to
their names by the script.
5.2.It sets rights to access directories of the plug-in.

4.3.2.2. Upgrading for FreeBSD

The distribution of the vaderetro plug-in for FreeBSD is delivered as a
tar-archive (drweb-maild-plugin-vaderetro-4.44.1-
freebsd60.tar.gz). The vaderetro plug-in for FreeBSD is
upgraded as follows:
1. Copy the distribution of the plug-in onto a computer where
you want to upgrade it.
2. Change the current user of the system to the root user.
For this, execute the su command and input the
password of the root user into the corresponding dialog.
3. Go to the directory with the plug-in distribution.
4. Unpack the archive. The drweb-maild-plugin-
vaderetro-4.44.1-freebsd60 directory will be
created.
Example:
>tar xzf drweb-maild-plugin-
vaderetro-4.44.1-freebsd60.tar.gz
5. In the drweb-maild-plugin-
vaderetro-4.44.1-freebsd60 directory created
during the unpacking of the archive with the plug-in the
install.sh installation script resides. To upgrade, run
this script with the update parameter. Being launched with
this parameter, the install.sh script will perform the
following:
5.1.Moves the directory tree nested in the drweb-
maild-plugin-vaderetro-4.44.1-
freebsd60 directory to the root directory. Files of the

151
Dr.Web® for Unix mail servers
installed version of the plug-in replace all files of the
already installed plug-in, except for configuration files.
The configuration files of the already installed plug-in
remain unchanged. When configuration files of the new
version are created, the .new suffix is added to their
names by the script.
5.2.It sets rights to access directories of the plug-in.

4.3.2.3. Upgrading for Solaris

The distribution of the vaderetro plug-in for Solaris is delivered as a
tar-archive (drweb-maild-plugin-vaderetro-4.44.1-
solaris10.tar.gz). The vaderetro plug-in for FreeBSD is
upgraded as follows:
1. Copy the distribution of the plug-in onto a computer where
you want to upgrade it.
2. Change the current user of the system to the root user.
For this, execute the su command and input the password
of the root user into the corresponding dialog.
3. Go to the directory with the plug-in distribution.
4. Unpack the archive. The drweb-maild-plugin-
vaderetro-4.44.1-solaris10 directory will be
created.
Example :
> gzip -d drweb-maild-plugin-
vaderetro-4.44.1-solaris10.tar.gz
> tar xf drweb-maild-plugin-
vaderetro-4.44.1-solaris10.tar
5. In the drweb-maild-plugin-
vaderetro-4.44.1-solaris10, directory created
during the unpacking of the archive with the plug-in the
install.sh installation script resides. To upgrade, run
this script with the update parameter. Being launched

152
 with this parameter, the install.sh script will
perform the following:
5.1.It moves the directory tree nested in the drweb-
maild-plugin-vaderetro-4.44.1-
solaris10 directory to the root directory. Files of the
installed version of the plug-in replace all files of the
already installed plug-in, except for configuration files.
The configuration files of the already installed plug-in
remain unchanged. When configuration files of the new
version are created, the .new suffix is added to their
names by the script
5.2.It sets rights to access directories of the plug-in.

4.3.3. Connecting with the plug-in

To connect the vaderetro plug-in to Dr.Web MailD, add vaderetro
to the list of plug-ins you want to process your messages (see p. 3.3)
in the configuration file of Dr.Web MailD. In case you want to have
your messages processed by the vaderetro plug-in before it is
moved to the database, add the name of the plug-in to the values of
the BeforeQueueFilters parameter in the [Filter] section
of the configuration file of Dr.Web MailD
Example: BeforeQueueFilters = drweb, vaderetro

If you want to have your messages processed by the plug-in after

they are moved to the database, add the name of the plug-in to the
values of the AfterQueueFilters parameter in the [Filter]
section of the configuration file of Dr.Web MailD.
Example: AfterQueueFilters = vaderetro

153
Dr.Web® for Unix mail servers
4.3.4. Configuring plug-in
All the main parameters concerning operation of the plug-in are set
in the %etc_dir/plugin_vaderetro.conf configuration file.
The structure and principles of description of parameters of the
configuration file are described above (see p. 3.3).

[VadeRetro] section

FullCheck ={yes|no}
The yes value instructs vaderetro to thoroughly check all messages
for spam at the expense of time spent for scanning.
Default value: yes

NoHamFrom = {yes|no}
The yes value instructs vaderetro to ignore messages sent to
system mailboxes domains (mailboxes like [email protected]).

Default value: yes

AddVersionHeader = {yes|no}
The yes value instructs vaderetro to add X-DRWEB-VERSION
header with information on VadeRetro version to scanned messages.
Default value: no

CheckForViruses = {yes|no}
The yes value instructs vaderetro to perform heuristic check for
spamming viruses.
Default value:yes

154
CheckDelivery = {yes|no}
The yes value instructs vaderetro to perform check of notifications
saying that delivery failed.
Default value:no

AllowRussian = {yes|no}
In case no is set for this parameter, messages with Cyrillic encoding
are regarded mostly as spam.
Default value: yes

AllowCJK = {yes|no}
In case no is set for this parameter, messages in Chinese/Japanese/
Korean (messages in Unicode) are regarded mostly as spam.
Default value:no

WhiteListFiles ={list of paths to files }

List of files containing whitelists. In these files e-mail addresses are
specified – each address is written in a single line. You can add to
this list a number of email addresses belonging to a certain domain.
For this, use "*" in place of the address name, for example:
*@mycompany.com.
File containing a white list will look as follows:
[email protected]
*@mycompany.com
Default value: not specified

BlackListFiles ={list of paths to files}

List of files containing blacklists. The syntax is the same as that

155
Dr.Web® for Unix mail servers
used in the whitelists.
Default value: not specified

SubjectPrefix = {text value}

Prefix added to the beginning of the subject string if the message is
spam.
Default value: ""

PathToVadeRetro = {path to file}

Path to the VadeRetro anti-spam library.
Default value:
• in Dr.Web MailD for Linux and Solaris
–/opt/drweb/lib/libvaderetro.so
• in version for FreeBSD –
/usr/local/drweb/lib/libvaderetro.so

UnconditionalSpamThreshold = {digital value}

Unconditional spam threshold. If the score given to a message
exceeds this value or equals to it, the message is considered to be a
spam and actions specified in the UnconditionalAction
parameter are performed for it. The value specified in this parameter
must be either greater than the value of the SpamThreshold, or
be equal to it.
Default value: 1000

SpamThreshold = {digital value}

156
If the score given to a message exceeds this value or equals to it, the
message is considered to be a spam and action specified in the
Action parameter. The score of the message is compared against
this parameter only if the score of the message is less than the
UnconditionalSpamThreshold parameter value. The value
of this parameter must be either less than the value of the
UnconditionalSpamThreshold, parameter, or be equal to it.

Default value:100

UnconditionalAction = {action}
Actions to be taken for unconditional spam. The notify action
cannot be used.
Default value: pass

Action = {action}
Actions to be taken for spam. The notify action cannot be used.

Default value: pass

If a message is blocked by the headers filtering anti-spam plug-in, an

SMTP-response of Dr.Web MailD consists of the 550 5.7.0 error
and a text message the content of which can be specified by the
parameters given below.

UseCustomReply = {yes|no}
If yes is set for this parameter, the content of SMTP-responses is set
by the SpamCustomReply parameter. If no is set, standard
responses are used.

157
Dr.Web® for Unix mail servers
Default value: no

SpamCustomReply ={text}
SMTP-response formed in case a message is blocked by the plug-in.

Default value: "Dr.Web vaderetro plugin: this is

spam!"

4.3.5. Updating VadeRetro library

To dynamically update VadeRetro library, replace its file (location to
the file is specified by the PathToVadeRetro parameter and send
a HUP signal to the drweb-maild module to reload the library.
Automatic updating of the VadeRetro library is done by the update.pl
updating utility (read p. 3.8)

158
 5. Integration with mail systems
In this section we’ll deal with peculiarities of integration of Dr.Web
MailD with different mail systems. If Dr.Web MailD was installed
automatically using the install.sh script (read p. 2), in most cases no
additional actions are required to integrate Dr.Web MailD with a mail
system. If it was installed manually, you should set up the mail
system as described in this section.
As there is a variety of mail systems, to make integration simple,
there is a specific distribution file of Dr.Web MailD for each mail
system. This helps to simplify configuration and management of
Dr.Web MailD.

5.1. Operation in smtp-proxy mode

The fact that Dr.Web MailD can act as a proxy for mail traffic allows
to use it along with a great number of mail systems.
In this mode the drweb-receiver module acts as an smtp/lmtp
server, and drweb-sender acts as an smtp/lmtp client. drweb-
sender module can direct messages directly to the local mail
system. All the parameters that affect operation of
drweb-receiver and drweb-sender modules are included
into the [Receiver] and the [Sender] sections of the
configuration file of Dr.Web MailD (see p. 3.3).

5.2. Integration with CommuniGate Pro MTA

5.2.1. Configuring CommuniGate Pro
To enable CommuniGate Pro (further abbreviated to СGP) to send
and receive messages from Dr.Web MailD, do the following:
• Connect to CGP using WebAdmin
• Click Settings, click General and then click Helpers

159
Dr.Web® for Unix mail servers
• Specify Enabled for the not yet specified filter in the
content-filter group. In the correspondent fie
• lds set the following values:
• Type the name of the filter (DrWeb Maild) in the field
right from the field where Enabled is specified:

• Log Level: Problems

• Program Path: %bin_dir/drweb-cgp-receiver
 Time-Out: 2 minutes
 Auto-Restart: 15 seconds
(privileges with which CGP is started must be
enough to launch the drweb-cgp-
receiver module).
• Click Settings, click Mail and then click Rules (or click
Settings, click Queue and then click Rules -depends on
the version of the filter);

• Create a new rule like check messages that are

not less than N bytes; for this do the following:
 Enter the name of the rule (for example
drweb-filter) and click Add Rule,
 Click Edit. A window for setting the rule will open.
In this window specify the values given below
 In the Action field specify External Filter,

 In the Parameters field type the name of the

filter (Settings -> General ->
Helpers:filter: DrWeb Maild)
 To make sure that letters from
GROUP*,LIST*,RULES* are not checked repeatedly,

160
 you can add the following setting to the rule: Submit
Address not in GROUP*,LIST*,RULES*.
For more detailed information on configuration (in particular,
information on how to enable/disable filtering for any user) consult
documentation which comes with CGP.

5.2.2. Configuring Dr.Web for mail servers

When Dr.Web MailD interacts with CGP, drweb-cgp-sender
module acts as the Sender component. The module is started with
the mail group rights to allow writing to the directory of CGP.

When Dr.Web MailD interacts with CGP, drweb-cgp-receiver

module acts as the Receiver component. The module is started by
the CGP system with root privileges. In such configuration to assure
proper operation of Dr.Web MailD you must either explicitly specify
the name of a user with whose privileges other modules of Dr.Web
MailD are launched (the name is specified in the ChownToUser
parameter in the [CgpReceiver] section of the configuration file
of Dr.Web MailD) or leave this parameter unspecified and run Dr.Web
MailD (as well as modules that work with Dr.Web MailD, for example
drwebd if drweb plug-in is used) with root privileges.
As the drweb-cgp-sender module sends messages to CGP via
PIPE to prevent cycling of messages a special header is added to
them. The header is specified in the
UseSecureHash/SecureHash parameters of the
[CgpSender] section of the configuration file of Dr.Web MailD.
Once the settings are configured, the drweb-cgp-receiver
module will not analyze messages with such header (removing its
value). You can also disable usage of this header. For this specify no
for the UseSecureHash parameter in the CgpReceiver
section. In that case the drweb-cgp-receiver module will not
analyze all messages received via pipe.

161
Dr.Web® for Unix mail servers
Other parameters that affect interaction of Dr.Web MailD with CGP
are included into the [CgpReceiver] and [CgpSender] sections
of the configuration file of Dr.Web MailD and are described below.
The structure and the principles of description of the configuration
file are fully described above, see p. 3.3).

[CgpReceiver]

Parameters included into this section affect the process of receiving

messages from CGP mail system.
ProcessingTimeout ={time}
Timeout for mail system to wait until a message is processed by the
plug-ins of Dr.Web MailD.
It is recommended to set a greater value for this parameter than that
set for the SendTimeout parameter in the [MailBase] section.

Default value: 40s

MaxThreads = {digital value}

Maximum number of threads in the pool that process message scan
results.
Default value: 3

ProcessingErrors = {actions}
Actions applied to messages in case processing errors occur. Only
one of the main actions (tempfail, discard, pass,
reject) can be specified as a parameter's value.
Default value: reject

ChownToUser = {user name}

162
This parameter sets the owner for messages received
by MailD from CommuniGate Pro.
As drweb-cgp module is started with user name – root; you
must either leave the ChownToUser parameter unspecified starting
maild with user name - root or specify a different user name in the
ChownToUser parameter, which is used to start other maild
segments
Default value: drweb

[CgpSender]

Parameters included into this section affect the process of sending

messages to CommuniGate Pro.

UseSecureHash = {yes|no}
If yes is set for this parameter, the SecureHash header is
added to sent messages.
Default value: no

SecureHash={text}
The parameter sets the content of the SecureHash header (read
description of the UseSecureHash parameter). To increase
security of Dr.Web MailD, the default value of this parameter should
be changed to any other value.
Default value: «PLEASE EDIT - !!! SECURITY CRITICAL
!!!»

MaxThreads = {digital value}

Maximum number of threads in the pool

163
Dr.Web® for Unix mail servers
Default value: 3

SubmitDir = {path to directory}

Path to the «Submitted directory» where all the messages which are
sent to the Communigate Pro via pipe are stored.
Default value: /var/CommuniGate/Submitted

SubmitFilesMode = {permissions}
Permissions assigned to created notifications of cured messages
Default value: 0600

SubmitFilenamesPrefix = {text value}

Prefix added to the names of files storing messages sent to
CommuniGatePro.
Final names of files are created according to this template: %
{SubmitDir}/%{SubmitFilenamesPrefix}XXXXXX
Default value: drweb_submit_

SubmitFilenamesMode = {std|tai|rand48}
A mode that defines the process of naming of files sent to
CommuniGate Pro:
• Std – names of files are created with mkstemp command. the
drweb_submit_XXXXXX template is used where XXXXXX
is a combination of random letters and numbers.
• Tai – names of files are created according to the TAI format.
The %sec.%usec.drweb_submit_XXXXXX template is
used.

164
 • Rand48 – names of files are created with the lrand48
command. The drweb_submit_XXXXXXXX template is
used.
Default value: Std

5.2.3. Known issues

On Linux change (and Update) in the command line in Helpers the
previous process of the filter remains in the zombie state until CGP is
restarted.

5.3. Integration with Sendmail MTA

In this section, the Sendmail installation directory is referred to as
{sendmaildir}. Example:
/usr/local/src/sendmail-8.xx.x)=
$ cd {sendmaildir}
Sendmail and Dr.Web MailD interact via Milter API (drweb-milter
is used as the Receiver component of Dr.Web MailD) in the
following way:
• Via transport connection, determined for drweb-milter by
the __ADDRESS__ transport address (see below), Sendmail
receives inner commands from Milter API and a message itself.
A message is sent in segments depending on the stage of mail
session: hello, mail from:, rcpt to: and so on.
The message is saved by drweb-milter in the temporary
files directory. Via Milter API, drweb-milter module sends
to Sendmail instructions on action with the message. Milter API
is a multithreading library, i.e. several mail sessions can take
place simultaneously. Sendmail acts as a client and drweb-
milter acts as a server. Therefore, in the sendmail.cf
(configuration file of the mail system) address of the drweb-

165
Dr.Web® for Unix mail servers
milter module is specified and Sendmail chooses an
appropriate client’s address to establish connection with.
• Via other transport connection drweb-milter module sends
to the drweb-maild module commands and waits for reply.

Drweb-milter acts as an intermediary between the interface of

Sendmail and the drweb-maild module. Sendmail and the
drweb-milter module can be run on different computers (but
drweb-milter and drweb-maild must be run on the same
one)

5.3.1. Configuring Sendmail

The Sendmail system must support MilterAPI which assures
interaction with Dr.Web MailD. If the Sendmail you are using does
not support this API, you must add support of Milter API library. For
additional information on this operation refer to the corresponding
documentation which describes compilation of the Sendmail.

If you do not wish to recompile the sendmail.cf configuration

file, you can simply addd to it (in case the file contains the
corresponding parameters) the following lines:
For versions 8.11:
-------------------- cut ------------------
############################
# Input mail filters
############################
O InputMailFilters=drweb-filter
############################
# Xfilters
############################
Xdrweb-filter, S=__ADDRESS__, F=T,T=S:5m;R:5m;E:1h
------------------- cut -------------------
For versions 8.12:

166
In the sendmail.cf file add the following:
-------------------- cut ------------------
############################
# Input mail filters
############################
O InputMailFilters=drweb-filter
O Milter.LogLevel=6
############################
# Xfilters
############################
Xdrweb-filter, S=__ADDRESS__, F=T,
T=C:1m;S:5m;R:5m;E:1h
------------------- cut -------------------
To enable checking сообщения отправленные локально (via mail
or sendmail), you must change the submit.cf and
submit.mc files in the same way as you have changed the
sendmail.cf file.
Moreover, add the nobodyreturn value to the
PrivacyOptions parameter.
Example:
-------------------- cut ------------------
# privacy flags
O PrivacyOptions=goaway,noetrn,nobodyreturn
-------------------- cut ------------------
Or in {sendmail_src}/cf/cf/feature/msp.m4:
-------------------- cut ------------------
define(`confPRIVACY_FLAGS'
`goaway,noetrn,nobodyreturn,restrictqrun')dnl
-------------------- cut ------------------

In case the filter is unavailable, select the following checkboxes (F=):

R — reject delivery
T — postpone delivery (in case neither F=R nor F=T, then a
message is skipped and not checked),
or add to sendmail.mc (additional options are described in

167
Dr.Web® for Unix mail servers
README located in the directory storing source texts of the libmilter
library):
Only for Sendmail version 8.11:
------------------- cut -------------------
define(`_FFR_MILTER',1)
INPUT_MAIL_FILTER(`drweb-filter', `S=__ADDRESS__,
F=T, T=S:5m;R:5m;E:1h')
------------------- cut -------------------
For Sendmail version 8.12 and later:
------------------- cut -------------------
INPUT_MAIL_FILTER(`drweb-filter', `S=__ADDRESS__,
F=T, T=C:1m;S:5m;R:5m;E:1h')
define(`confMILTER_LOG_LEVEL',`6')
------------------- cut -------------------
Timeout value should be the same as Sendmail
timeout values "O
Timeout.datablock=XX" (default value is 1
hour, XX=>1h).

After changes are made, you must recompile the sendmail.cf

file.

168
__ADDRESS__ – line where transport address is
specified. Its format and value are the same as
those ones which are used for the Address
parameter of the [Milter] section of the
configuration file of Dr.Web MailD.
The address can be specified for TCP/IP sockets:
inet:__PORT__@__HOST__
(__PORT__ and __HOST__ must have
specific values, for example,
inet:3001@localhost)
or for UNIX-DOMAIN sockets:
local:__SOCKPATH__
(__SOCKPATH__ must define the path which will
be accessible with the same rights you use to start
the filter, for example:
local:/var/run/drweb-smf.sock)

Details on how to configure the filter can be found in documentation

for the Sendmail system (you can start with
{sendmaildir}/libmilter/README).
After changes are made, you must restart the Sendmail system.

169
Dr.Web® for Unix mail servers
To assure interaction between drwebd anti-virus
daemon and Dr.Web MailD, it is recommended to
install and run drwebd and Dr.Web MailD on the
same computer (it is not required to install also the
Sendmail system on this computer). In this case for
sending messages between drwebd and Dr.Web
MailD you can use scanning of local files instead of
sockets. For this, privileges under which daemon
and Dr.Web MailD are run must permit accessing
the shared directory. Moreover, privileges under
which drwebd is run must permit accessing
temporary files of drweb-maild module for
reading.

To enable drweb-maild module to log ids of Sendmail messages

– sendmails message ID, in the sendmail.cf file add the
following line:

------------------- cut -------------------

O Milter.macros.envfrom=i, ...
------------------- cut -------------------
(dots stand for other parameters which are not important).
To instruct Dr.Web MailD to write to the header Received: IP-
address and name of host from which a message arrives, check that
in the sendmail.cf file there is the following line:
------------------- cut -------------------
O Milter.macros.connect=_, ...
------------------- cut -------------------
(dots stand for other parameters which are not important).
To disable adding to syslog notifications like:
------------------- cut -------------------
X-Authentication-Warning: some.domain.com: drweb
set sender to [email protected] using -f
------------------- cut -------------------

170
 add the user with whose privileges drweb-milter module is run
(drweb by default) to the list of trusted-users in the submit.cf
file:
------------------- cut -------------------
#####################
# Trusted users #
#####################
Tdrweb
------------------- cut -------------------
Or add to the submit.mc file
------------------- cut -------------------
define(`confTRUSTED_USERS', `drweb')"
------------------- cut -------------------

5.3.2. Interaction with Sendmail

All the parameters that affect operation of drweb-milter module
and the Sender component are included into the [Milter] and
[Sender] sections of the configuration file of Dr.Web MailD and
described in p. 3.3.

To assure the system efficiency and to avoid cycling of messages, if

messages are sent back to the same mail system which forwards
them to the filter, yes must be specified as the value for the
UseSecureHash parameter of the [Sender] section in the
Dr.Web MailD configuration file (and the value of the SecureHash
parameter in that section must be also specified).
If messages are sent back to a different Sendmail system (not the
one that forwards them to the filter) no must be specified as the
value of the UseSecureHash parameter. In this case, value of the
SecureHash header will not be used outside the system.

171
Dr.Web® for Unix mail servers
5.3.3. Known issues
Description. In case a Unix socket is used for communication
between the filter and Sendmail, Milter API library (distributed with
Sendmail) does not delete (till version 8.12.2) the socket file.
Solution. For version 8.12.x there is
listener-8.12.0-1.patch. For version 8.11 you must
manually delete this file or edit the script which controls the
operation of the filter. This issue is resolved in Sendmail version
8.12.2
Description. When filter is used on computers with a high
computation load, in the mail log the following entries may appear:
"... Milter (drweb-filter): select(read):
interrupted system call"
Solution. This issue is resolved in Sendmail version 8.12.3 (and
later).
Description. When filter is used on computers with a high
computation load in the mail log the following entries may appear:
"... Milter (drweb-filter): select(read): timeout
before data write"
"... Milter (drweb-filter): to error state"
Solution. The Sendmail system cannot establish connection with the
filter within the specified timeout. In version 8.11 the timeout is set
to 5 seconds and cannot be changed. In version 8.12 the timeout can
be changed in the description of the filter (value with C):
Xdrweb-filter, S=__ADDRESS__, F=T,
T=C:1m;S:5m;R:5m;E:1h

5.4. Integration with Postfix MTA

There are 3 ways as how Dr.Web MailD can be connected to the
Postfix mail system:
• In the after-queue mode (for details go to the web page at
http://www.postfix.org/FILTER_README.html#advanced_filter)

172
 • In the before-queue mode
(http://www.postfix.org/SMTPD_PROXY_README.html)
• Using the milter protocol
(http://www.postfix.org/MILTER_README.html)

Drweb-receiver Smtp/lmtp server (Receiver component)

receives a new message from smtp module of the Postfix system,
and sends it to drweb-maild module for analysis. According to
the results of the analysis the message is either sent to the mail
system (can be modified) or blocked (some additional reports can be
sent to the mail system). Messages are sent to the Postfix mail
system via smtp/lmtp client of drweb-sender (Sender
component), which forwards messages to the smptd daemon.

For detailed information on configuration of filters

in the Postfix system refer to the documentation on
Postfix, which can be found, for example, at http://
www.postfix.org/FILTER_README.html.

Dr.Web MailD can interact with the Postfix server in the before queue
mode too (but it is not recommended to use this mode in case a
computation load is high)
Details on how to configure this mode can be found at
http://www.postfix.org/SMTPD_PROXY_README.html.

Interaction with the Postfix system through the milter protocol is

carried out in the following way:
1. Via transport connection, determined for drweb-milter
(acts as a Receiver component) by the transport
address, the Postfix system receives inner Milter API
command and a message itself. A message is sent in

173
Dr.Web® for Unix mail servers
segments depending on the stage of mail session: hello,
mail from:, rcpt to: and so on. Segments are saved by the
drweb-milter module to the temporary files directory.
Via Milter API drweb-milter module sends to the
Postfix system instructions on action with the message.
Milter API is a multihreading library; this allows to process
simultaneously several mail sessions. The Postfix system
acts as a client and and drweb-milter acts as a
server. Therefore, in the main.cf (configuration file of
the Postfix system) address of the drweb-milter
module is specified and Postfix chooses an appropriate
client’s address to establish connection with.
2. Via other transport connection drweb-milter module
sends commands to the drweb-maild module and
waits for reply.

Drweb-milter acts as an intermediary between the interface of

Sendmail and the drweb-maild module. Sendmail and the
drweb-milter module can be run on different computers (but
drweb-milter and drweb-maild must be run on the same
one)

5.4.1. Interaction with Postfix

5.4.1.1. Using after-queue mode

In the main.cf file (configuration file of the Postfix system)
add the following lines::
content_filter = scan:_ADDR_REC_
receive_override_options = no_address_mappings

174
where _ADDR_REC_ is the address of the listening drweb-
receiver module (the Address parameter of the [Receiver]
section in the configuration file of Dr.Web MailD) -
for example 127.0.0.1:8025

In the configuration file of the Postfix system (master.cf) add the

following lines:
--- cut ---

scan unix - - n -
10 smtp
-o smtp_send_xforward_command=yes
_ADDR_SEN_ inet n - n -
NN smtpd
-o content_filter=
-o
receive_override_options=no_unknown_recipient_
checks,no_header_body_checks
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o
smtpd_recipient_restrictions=permit_mynetworks
,reject
-o mynetworks=127.0.0.0/8
-o
smtpd_authorized_xforward_hosts=127.0.0.0/8
--- cut ---

where _ADDR_SEN_ – stands for the address the dwreb-sender

module connects to for sending messages (the Address parameter
of the [Sender] section in the configuration file of Dr.Web MailD) –
for example, 127.0.0.1:3003.

175
Dr.Web® for Unix mail servers
It is recommended that NN value (max. number of
processes executed by the Postfix server) was the
same as the number of threads in the pool of the
drweb-receiver module (the MaxThreads
parameter of the [Receiver] section in the
configuration file of Dr.Web MailD). To disable the
parameter, specify "-" as the NN value.

Other parameters that affect operation of drweb-receiver and

drweb-sender modules are included into the [Receiver] and
[Sender] sections of the configuration file of Dr.Web MailD and
described in p. 3.3.

After all the parameters are specified, restart the Postfix system.

5.4.1.2. Using milter protocol

All the parameters that affect operation of the drweb-milter and
drweb-sender modules (the Sender component) are included
into the [Milter] and [Sender] sections of the configuration
file of Dr.Web MailD (read p.3.3).
For the operation in this mode you need a Postfix version not earlier
than 2.3.3.
The address of the transport connection, through which Postfix
interact with the drweb-milter module can be specified as an
internet address as well as a unix socket. Address is specified by the
smtpd_milters parameter of the configuration file of the Postfix
system (main.cf). In case connection is established through an
internet address, the value of this parameter is specified in the
following format – inet:host@port (for example,
smtpd_milters=inet:127.0.0.1:3001). In case
connection is established through a unix socket, the format of the
176
address is the following: unix:pathname, where pathname is
the absolute path to the unix-socket.
In case address is specified as a unix socket, Postfix must have rights
for editing the socket file.
Address of the transport connection between the Postfix system and
the drweb-milter module must be also specified by the
Address parameter of the [Milter] section in the configuration
file of Dr.Web MailD. The value and format of the Address
parameter must be the same as the value and address of the
smtpd_milters parameter in the main.cf configuration file.
Apart from transport address in the configuration file (main.сf)
you must specify the following parameters’ values:
• milter_content_timeout = 300s
this timeout also defines the maximum time period for
Dr.Web MailD to check messages in the BeforeQueueFilters
mode. The value of this parameter should be higher than the
value of the ProcessingTimeout parameter in the
[Milter] section of the configuration file.
• milter_default_action = tempfail
This parameter defines actions of the Postfix system on errors
occurred during interaction with the drweb-milter module

• milter_protocol = 2
required version of the milter protocol;
• milter_mail_macros = _
this parameter allows Dr.Web MailD add to headers the
following - Received: messages IP-address and name of
the host a message arrives from;
• milter_end_of_data_macros = i
this parameter allows to get a message id

177
Dr.Web® for Unix mail servers
and use it along with the information on the message in
drweb-milter’s log.

Then, you must configure operation of Dr.Web MailD. In case Dr.Web

system is started using Dr.Web monitor, drweb-milter module
must be used as a Receiver. For this, in the
%etc_dir/monitor/maild_postfix.mmc file uncomment the
line which regulates launch of the drweb-milter module (it is
recommended to comment the line which regulates the launch of the
drweb-receiver module). As a result, the
maild_postfix.mmc file must contain lines similar to those below:

# drweb-receiver local:/var/drweb/ipc/.agent
15 30 MAIL drweb:drweb
drweb-milter local:/var/drweb/ipc/.agent 15 30
MAIL drweb:drweb

Moreover, you must configure operation of the drweb-sender

module (Sender component). For this, in the [Sender] section of
the configuration file of Dr.Web MailD specify the following
parameters:

Address = /usr/sbin/sendmail
Method = pipe
MailerName = postfix

In the Address parameter the path to sendmail program is

specified.
To assure system efficiency and to optimize the ”Dr.Web MailD –
Postfix” system. if messages are sent to the same mail system which

178
 forwards them to the filter, yes must be specified as the value of
the UseSecureHash parameter of the [Sender] section in the
configuration file of Dr.Web MailD (as well as for the SecureHash
parameter in the same section).
If messages are received by the filter from one Sendmail system,
and sent to another, no must be specified as the value for the
UseSecureHash parameter to keep the value of the
SecureHash header within the system.

After all the necessary parameters are configured, restart Dr.Web

MailD first and then the Postfix system.

5.5. Integration with Exim MTA

When Dr.Web MailD interacts with Exim mail system, the drweb-
receiver module acts as a Receiver and the drweb-sender
module acts a Sender.
You can connect Exim mail system to Dr.Web MailD in 2 following
ways:
6. Using special transport:
 Advantages: there is no need to recompile Exim
and the system can work with old Exim versions
 Disadvantages: Low system efficiency
7. Using Exim local_scan function. In this case the
Receiver component receives configuration data not from
Dr.Web agent as other components do but from the
configuration file of the Exim mail system.
 Advantages: High system efficiency
 Disadvantages: You must recompile Exim; Exim
version later than 4.50 is required

179
Dr.Web® for Unix mail servers
5.5.1. Interaction with Exim
All the parameters that affect interaction of Dr.Web MailD with the
Exim mail system are included into the [Receiver] and [Sender]
sections of the configuration file of Dr.Web MailD. Structure and
parameters of the configuration file are described in p. 3.3.

Primary configuration of the Exim mail system is the same for both
connection modes:
First you must add drweb user to the list of trusted users of Exim
system in the MAIN CONFIGURATION SETTINGS section of the
configuration file of Exim system.
--- cut ---
[[##########################################
# MAIN CONFIGURATION SETTINGS #
############################################]]

trusted_users = drweb
--- cut ---
Further configuration depends on the connection
mode you select.

5.5.1.1. Using special transport

The description below deals with Exim version 4.xx. For information
on the settings relevant to earlier versions of Exim (3.xx) refer to the
corresponding documentation (for example, the one that is available
at the web page at http://www.exim.org/index.html).
To the Exim settings add a special transport and router. In the
configuration file of the mail system find the section which regulates
routers’ settings. It starts with the following header:
--- cut ---
##############################################
# ROUTERS CONFIGURATION #
# Specifies how remote addresses are handled #
##############################################
# ORDER DOES MATTER #

180
# A remote address is passed to each in #
# turn until it is accepted. #
##############################################
--- cut ---

After the line that starts with begin routers add the following:
drweb_router:
driver = accept
condition = "${if eq {$received_protocol}
{drweb-scanned}{0}{1}}"
retry_use_local_part
transport = drweb_transport

Then, in the configuration file of the Exim system find the section
which deals with the description of transports. It starts with the
following header:

--- cut ---

##############################################
# TRANSPORTS CONFIGURATION #
##############################################
# ORDER DOES NOT MATTER #
# Only one appropriate transport is called #
# for each delivery. #
##############################################
--- cut ---

In this section add description of the necessary transport:

--- cut ---

drweb_transport:
driver = lmtp
socket = __ADDRESS__
batch_max = 100
timeout = 5m
user = drweb
# headers_add = "X-Maild-Checked: DrWEB for Exim"

181
Dr.Web® for Unix mail servers
--- cut ---

Where _ADDRRESS_ is the address of the listening drweb-

receiver module (the Address parameter of the [Receiver]
section of the configuration file of Dr.Web MailD) -
for example, a unix socket /var/drweb/ipc/.drweb_maild

Configure Dr.Web MailD. For this, in the Address parameter of the

Sender section in the configuration file of the Dr.Web MailD specify
the path to the Exim mail system, for example, /usr/exim/bin/
exim, and in the MailerName parameter of the Sender section
specify Exim.

Restart Dr.Web MailD and then restart Exim mail system.

5.5.1.2. Using local_scan function

Dr.Web MailD can operate in this mode when it interacts with the
Exim mail system version 4.50 and later.

Recompile Exim to add support of local_scan function. For this:

• Copy the
DEFAULT_BIN_PATH/doc/maild/local_scan/loca
l_scan.c file to the exim*/Local/ directory.
• To the Makefile file located in exim*/Local/ directory
copy parameters specified in the
%bin_dir/doc/maild/local_scan/Makefile.sam
ple file.
• If these parameters are already specified in the Makefile
file, you can uncomment or edit existing parameters.
• In the Makefile file specify user name whose privileges are
used to start Exim; the user name is the same as the that used

182
 for Dr.Web MailD. User name is defined in the EXIM_USER
parameter. By default EXIM_USER= drweb is specified

• Compile and install the Exim mail system.

Configure Exim system. To quickly configure interaction parameters
use parameters’ values from the
%bin_dir/doc/maild/local_scan/configure.sample
file. Copy the necessary lines to the local_scan section of the
configuration file of Exim.

To get information on settings applied to the operation of the

Receiver component execute the following command -
PATH_TO_BIN_DIR/exim -bP local_scan (where
PATH_TO_BIN_DIR – is the path to the directory of Exim
executable files.

Configure Dr.Web MailD to set up interaction with the Exim system.

For this in the Address parameter of the [Sender] section in the
configuration file of Dr.Web MailD specify the path to the Exim mail
system, for example /usr/exim/bin/exim. Specify Exim as
the value for the MailerName parameter of the [Sender]
section.

Keep in mind that there is no need to start the drweb-receiver

module because when Exim connects by means of the
local_scan function, the Receiver component fits into the
Exim system. If Dr.Web MailD is run by means of the monitor,
comment the line that regulates launch of the drweb-receiver module
in the %etc_dir/monitor/maild_exim.mmc file, for example
in the following way:

183
Dr.Web® for Unix mail servers
#drweb-receiver local:/var/drweb/ipc/.agent 15 30
MAIL drweb:drweb

Start Dr.Web MailD and then start the Exim mail system.

5.5.2. Known issues

In case, the Exim mail system at start generates an error which looks
like:
transport drweb_transport: cannot find
transport driver "lmtp",
It means that the lmtp transport is not supported by the system. You
can use smtp transport (for more details see documentation on Exim
for example at http://www.exim.org/), or recompile exim to add
support of lmtp transport. In case the latter variant is used to the
Local/Makefile file add the following line:
TRANSPORT_LMTP=yes

5.6. Integration with QMail MTA

The principle of operation of QMail is based on a replacement, or
better to say, proxying of a mail system.
Filter receives the message via the interface of qmail-queue
(main executable file of the Qmail system), the filter scans it and in
case a message is not infected it is forwarded to the original
qmail-queue. Regarding operation of the filter in this mode the
following should be noted – unix sockets (sockets are defined by the
ListenUnixSockets parameter of the [Qmail] section in the
configuration file of Dr.Web MailD) on which drweb-qmail module
must listen for calls to carry out analysis must be located in specific
directories. (To receive the list of directories, start qmail-queue
using the –help parameter)

For interaction with Dr.Web MailD Qmail version not earlier than 1.03
is required
184
 Dr.Web MailD should be installed after Qmail is
terminated to avoid damage of e-mails.

5.6.1. Configuring Qmail

To connect Dr.Web MailD to the Qmail system, do the following:
1. Save the original qmail-queue. Remember the path to
this directory. You will need it later.
2. Copy qmail-queue from %bin_dir directory and
save it to the qmail/bin directory. Specify necessary
rights and users for the new qmail-queue (which is a
filter of Dr.Web MailD) and for the
qmail-queue.original. The most suitable
configuration is the one which allows Dr.Web MailD and
qmail-queue to be run by the drweb user. To assure
proper operation set the following rights for the qmail-
queue module:

-rws--x--x X drweb qmail

SIZE DATE qmail-queue
-rws--x--x X qmailq qmail
SIZE DATE qmail-queue.original

To set the rights, use the following commands:

$ chown drweb:qmail qmail-queue

$ chmod 4711 qmail-queue

$ chown qmailq:qmail qmail-queue.original

$ chmod 4711 qmail-queue.original

185
Dr.Web® for Unix mail servers
5.6.2. Configuring Dr.Web for mail servers
All the parameters that affect interaction of Dr.Web MailD with the
Qmail are included into the [Qmail] and [Sender] sections of the
configuration file of Dr.Web MailD. Structure andprinciples of
description of the configuration file are described in p 3.3.
(parameters of the [Sender] section are also described there)

[Qmail]

Parameters included into this section affect interaction of Dr.Web

MailD with Qmail.

ProcessingTimeout ={time}
Timeout for mail system to wait until a message is processed by the
plug-ins of Dr.Web MailD.
It is recommended to set a greater value for this parameter than that
set for the SendTimeout parameter in the [MailBase] section.

Default value: 40s

ProcessingErrors = {actions}
Actions applied to messages in case processing errors occur. Only
one of the main actions (tempfail, discard, pass,
reject) can be specified as a parameter's value.
Default value: reject

MaxThreads = {digital value}

Maximum number of threads in the pool that process message scan
results.
Default value: 3

186
 ListenUnixSockets = {addresses}
List of unix-sockets on which drweb-qmail listens for calls to scan
messages from qmail-queue. Sockets specified in the list must
coincide with the files observed by Qmail. The list of files is displayed
on obtaining help using qmail-queue --help command.

Default value: local:/var/drweb/ipc/.qmail

QmailQueue = {path to file}

Path to source file of qmail-queue

Default value:/var/qmail/bin/qmail-queue.original

5.6.3. Known issues

Description: at start Qmail generates an error which looks like:
/var/qmail/bin/qmail-smtpd:
error while loading shared libraries:
libc.so.6: failed to map segment from shared
object:
Cannot allocate memory

Solution: The problem is that in the launch script there is a

strong restriction for the used memory. For example, if Dave Sill
scripts are used, you must increase the value in the softlimit -
m 2000000 instruction, for example adding a zero to the right of
the value.

Description: for all messages received via smtp protocol Qmail

(as soon as the body of the message is received) returns the line
which looks like:
451 qq trouble making network connection
(#4.3.0)
187
Dr.Web® for Unix mail servers
Solution: qmail-queue module may not have enough rights
to connect to the unix-socket, created by the drweb-qmail
module (acts as the Receiver component of the Dr.Web MailD) or
this unix-socket are not located in the default paths of the qmail-
queue. Check whether the rights are set correctly (see.p. 5.6.1),
and make sure that the value of the ListenUnixSocket
parameter of the [Qmail] section in the configuration file of Dr.Web
MailD corresponds to the default paths, the list of which is available
in the help, sent on execution of the following command: qmail-
queue --help.

Description: for all messages received via smtp-protocol, Qmail

(as soon as the body of the message is received) returns to the
console the line which looks like the following:

qmail-inject: fatal: qq temporary problem

(#4.3.0)
/usr/libexec/ld-elf.so.1: Shared object
"libstdc++.so.5" not found,
required by "libboost_program_options.so"

Solution: The system cannot find the necessary libraries, located

in the DEFAULT_LIB_PATH directory. You must copy the (or
create links to them) libstdc++.so.5 and libgcc_s.so.1
libraries from DEFAULT_LIB_PATH and save to the dydtem
directory with libraries (for example, on FreeBSD to /usr/local/
lib).

5.7. Integration with ZMailer MTA

5.7.1. Interaction with ZMailer
Dr.Web MailD can interact with ZMailer in two modes:

188
 • In the context filter mode at the stage of smtp-connection.
 Advantages: possibility to block a message at
the stage of smtp-connection.
 Disadvantages: low system efficiency is
possible when computation load is high; only smtp-
traffic is checked.
• In the context filter mode at the routing stage.
 Advantages: high computation load is not
important; all messages that pass through ZMailer
(including local and those sent via uucp) are
checked.
 Disadvantages: impossible (i.e. reject and
tempfail actions are similar to discard); it is
necessary to use SecureHash header to increase
system efficiency and avoid cycling of messages.

Drweb-zmailer module is used as the Receiver component of

Dr.Web MailD for Zmailer.

To assure proper operation of the drweb-zmailer and filters it is

recommended to install patches before configuring ZMailer (if
possible).
To install patches, do the following:
• Go to the $(ZMAILER_SRCHOME)/smtpserver
directory
• To check whether the patch is suitable for your version, do the
following:
$ patch -C < smtpdata.c.XXX.patch
(where XXX — is the Zmailer version the patch is suitable for)

189
Dr.Web® for Unix mail servers
• To install the patch do the following:
$ patch < smtpdata.c.XXX.patch

5.7.1.1. Using smtp-session stage in context filter mode

To enable support of Dr.Web Daemon in Zmailer, do the following:
• Copy the (or create a symbolic link to) drweb-zmailer.sh
file to the $MAILBIN directory
(this value is specified in the zmailer.conf file)

• Edit the smtpserver.conf; the following must be written:

PARAM contentfilter $MAILBIN/drweb-zmailer.sh

As the command line parameters must not be indicated in

contentfilter, you should specify them in the drweb-
zmailer.sh script.

5.7.1.2. Using routing stage in context filter mode

All the messages processed by the mail server go through the routing
stage. So the most suitable moment for processing is the end of the
routing stage. To connect the filter, edit the
$MAILBIN/cf/process.cf file.

In this file, right after the following block of text:

LOGMSG=() # This is a LIST of files where to

log..
#| The LOGMSG variable is used by the
intercept facility (in crossbar.cf)
#| to make sure only a single copy of a
message is saved when required.
#| Each sender - recipient address pair can
cause an intercept which can
#| specify a file to save the message to.
This variable is appended to

190
 #| elsewhere, and processed at the end of
this function

add the following:

###-> Dr.Web Maild support

ch=`"__DEFAULT_BIN_PATH__/drweb-zmailer.sh"
--hash __EDIT_THIS__ --file
$POSTOFFICE/router/$file`
case "$ch" in
-1*) #reject or discard
/bin/rm -f "$file"
return
;;
1*) #tempfail
/bin/rm -f "$file"
return
;;
*);;
esac
###-> end of Dr.Web Maild support

replace __EDIT_THIS__ (--hash value) with the value that is

equal to the value of the SecureHash parameter in the [Sender]
section of the configuration file of Dr.Web MailD and specify yes for
the UseSecureHash parameter in this section. The value of the
__DEFAULT_BIN_PATH__ parameter coincides with the value of
the %bin_dir valiable (read p ).

5.7.2. Additional parameters

The most simple way to disable receiving messages with a blank
SMTP envelope of the sender (usually error messages, messages
informing that a message has not been delivered or spam messages
are distributed in this way) is to install the.c.XXX.patch. The

191
Dr.Web® for Unix mail servers
procedure of installing this patch is the same as for the
smtpdata.c.XXX.patch, which is described in p.5.7.1.

As ZMailer starts drweb-zmailer module for each message again

to assure efficiency of the system all the settings of drweb-
zmailer are specified in the command line (you can set them for
example in the drweb-zmailer.sh script).

For drweb-zmailer the following parameters can be used in the

command line:
• -h [ --help ] – display help and exit
• -v [ --version ] – display information on version
and exit
• -u [ --user ] arg (=drweb) – user under whose
privileges drweb-maild is started. As ZMailer starts the
drweb-zmailer module with the rights of the root user,
either the whole Dr.Web MailD must be started with the root
rights (and specify an empty line as the value for the –u
parameter ""), or specify the necessary value for this
parameter.
• -l [ --level ] arg (=info) level of log details.
Possible values: Quiet, Error, Alert, Info,
Debug
• -i [ --ipclevel ] arg (=info) – level of
details for logging interaction with the drweb-maild
module. Possible values: Quiet, Error, Alert,
Info, Debug
• -f [ --facility ] arg (=mail) – type of
facility that syslog service uses to send notifications on
events (for more details see relevant documentation on
syslog). Possible values: Daemon, Mail, Local0-7

192
 • -b [ --basedir ] arg (=/var/drweb) – basic
temporary directory of Dr.Web MailD. This parameter is
similar to the BaseDir parameter of the [General]
section in the configuration file of Dr.Web MailD
• -t [ --timeout ] arg (=30) – timeout for
processing a message
• -file arg – path to file to be processed. It must be
specified only when the program operates in the context
filter mode at the routing stage. For more information see p.
and 5.7.1.2
• -hash arg – value of the SecureHash parameter of
the [Sender] section of the configuration file of the
Dr.Web MailD. It must be specified only in case the program
operates in the context filter mode at the routing stage. For
more information see p. and 5.7.1.2
• -interface arg (=1) – version of smtp server. It
must be specified only in case the program operates in the
context filter mode at the stage of smtp-session (see p. and
5.7.1.1). 0 – for version 2.99.55 and earlier; 1 – for version
2.99.56 and later
• -e [--error-action] arg (=reject) – action
the filter applies to the message in case an inner error
occurs. Possible values: pass, reject, discard,
tempfail

5.8. Integration with Courier MTA

5.8.1. Interaction with Courier
To connect Dr.Web MailD to Courier mail system do the following:

193
Dr.Web® for Unix mail servers
• Set access rights to the drweb-courier module by having
performed the following commands:
>chown COURIER_USER:drweb
"DEFAULT_BIN_PATH/drweb-courier"
>chmod 6771 "DEFAULT_BIN_PATH/drweb-courier",
where COURIER_USER – a user under the rights of which ,
the Courier mail system is run.
Make sure that for all directories and subdirectories in the
/var/drweb/ directory, for the drweb group read, write
and run rights are set.
• Copy the drweb-courier module (or create a symlink) to
the Courier filters directory (by default
/usr/lib/courier/libexec/filters/)
• Register the drweb-courier module in the Courier mail
system as a global one:
/usr/lib/courier/sbin/filterctl start drweb-
courier
Later, to enable filtering execute the following command:
/usr/lib/courier/sbin/filterctl stop
drweb-courier
• Create (edit) the enablefiltering file to set services for
analysis (esmtp or uucp – in case several services are set
blanks are used as a delimiter).
• Make sure that the values of the BaseDir and SocketDirs
parameters of the [Courier] section in the
maild_courier.conf file correspond to the parameters of
the Courier mail system.
For additional information see man courierfilter

• Enable filtering in the Courier system:

/usr/lib/courier/sbin/courierfilter start

194
5.8.2. Configuring Dr.Web for mail servers
All the parameters that affect interaction of Dr.Web MailD with the
Courier system are included into the [Courier] and [Sender]
sections of the configuration file of Dr.Web MailD. The structure and
principles of description of the configuration file are described above,
see p. 3.3 (description of the [Sender] section can also be found
here.

[Courier] section

Parameters included into this section affect interaction of the Dr.Web

MailD and Courier.
This section is available only in the configuration files of Dr.Web
MailD designed for interaction with Courier.

ProcessingTimeout ={time}
Timeout for mail system to wait until a message is processed by the
plug-ins of Dr.Web MailD. It is recommended to set a greater value
for this parameter than that set for the SendTimeout parameter in
the [MailBase] section.

Default value: 40s

ProcessingErrors = {actions}
Actions applied to messages in case processing errors occur. Only
one of the main actions (tempfail, discard, pass,
reject) can be specified as a parameter's value.
Default value: reject

MaxThreads = {digital value}

195
Dr.Web® for Unix mail servers
Maximum number of threads in the pool that process message scan
results.
Default value: 3

BaseDir = { path to directory }

Path to the installation directory of Courier mail system
Default value: /usr/lib/courier

SocketDirs = {path to directories}

List of directories used to create sockets necessary for interaction
with Courier mail system.
Socket is created in the first directory indicated in the list; other
directories are checked for sockets which names are similar to the
name of the drweb-courier module. If detected, such sockets
will be deleted.
On restarting the program via HUP signal, this parameter cannot be
changed.
Default value: /usr/lib/courier/var/allfilters,
/usr/lib/courier/var/filters

SocketAccess = {permissions}
Permissions are assigned to sockets through which Dr.Web MailD
interacts with Courier mail system.
On restarting the program via HUP signal, this parameter cannot be
changed.
Default value: 0660

196
6. Contact information
Dr.Web for mail servers is being constantly improved. The latest
information on its updates and news are available on the web site:
http://www.drweb.com
Sales department:
http://buy.drweb.com
e-mail: [email protected]
WWW: http://buy.drweb.com
e-mail: [email protected]
Technical support service:
http://support.drweb.com
e-mail: [email protected]
When addressing our technical support the following information will
be greatly appreciated. It will help us to examine the case
thoroughly:
• full name and version of the unix distribution file
• Dr.Web program version
• versions of applications and filters the Dr.Web Daemon is
integrated with
• configuration files of the daemon and the applications the
Dr.Web Daemon is integrated with
• log files: daemon, filters and other applications the Dr.Web
Daemon is integrated with

197
Dr.Web® for Unix mail servers

Appendix 1. Migration from Dr.Web mail

filters for Unix systems
Dr.Web MailD together with the drweb and the headersfilter plug-ins
completely substitute functionality of mail filters of Dr.Web Anti-virus
for Unix-systems (hereinafter referred to as mail filters). The Dr.Web
MailD distribution contains the set of scripts to facilitate the upgrade
to new mail filtering system. After Dr.Web MailD is installed, these
scripts reside in the %bin_dir/maild/scripts directory.

Below is described the recommended upgrade procedure from mail

filters of Dr.Web Anti-virus for Unix-systems:

1. If you plan to move a mail filter settings to Dr.Web MailD,

save its configuration file.
2. Completely remove the mail filter, including the settings of
the mail system connecting this filter.
3. Install Dr.Web MailD with all necessary plug-ins. You will
require at least the drweb plug-in. In addition, if you
want to filter messages by headers, the
headersfilter plug-in should be installed, too.
Then, if you have previously saved configuration files of the mail
filter, you can copy some of parameters of the mail filter to Dr.Web
MailD. For this, place the configuration files of the mail filter and of
the Dr.Web Anti-virus to the %etc_dir directory and use scripts
from the %bin_dir/maild/scripts directory to copy the
necessary settings of the mail filter:
• addresses_conf_to_rules.pl – to mover all
information from the addresses.conf configuration file
to Dr.Web MailD rules.

198
• users_conf_to_rules.pl – to mover all information
from the users.conf configuration file to Dr.Web MailD
rules.
• viruses_conf_to_rules.pl – to mover all
information from the viruses.conf configuration file to
Dr.Web MailD rules.
• filter_conf_to_maild.pl – to move all possible
settings of the mail filter from the drweb32.ini
configuration file and from the configuration file of the mail
filter to Dr.Web MailD configuration files (including
configuration files of the drweb and headersfilter plug-ins, if
they are installed).

199