ESET NOD32 ANTIVIRUS - FOR LINUX-BSD MAIL SERVER User manual

NOD32 for Linux/BSD
Mail Server
Installation Manual
and User’s documentation
w e p r o t e c t d i g i t a l w o r l d s

2
Table of contents
1. Introduction ........................................................... 3
2. Installation.............................................................. 5
3. Product’s Roadmap .................................................. 7
4. Integration with E-mailMessaging System................11
4.1. Scanning of inbound e-mail messages............................... 13
4.1.1. Renaming the original MDA and its replacement by
NOD3 2MDA.................................................................... 13
4.1.2. Setting of NOD32MDA (in MTA) as MDA........................... 14
4.1.2.1. Setting NOD32MDA in Sendmail MTA........................... 14
4.1.2.2. Setting NOD32MDA in Postx MTA............................... 15
4.1.2.3. Setting NOD32MDA in Qmail MTA ................................ 16
4.1.2.4. Setting NOD32MDA in MTA Exim version 3................... 17
4.1.2.5. Setting NOD32MDA in MTA Exim version 4................... 19
4.2. Scanning of outbound e-mail messages ............................ 20
4.3. Content Filtering in MTA..................................................... 22
4.3.1. Content ltering in MTA Postx....................................... 22
4.3.2. Content ltering in MTA Sendmail................................... 23
4.3.3. Content ltering in MTA Exim 3 ....................................... 23
4.3.4. Content ltering in MTA Exim 4 ....................................... 25
4.3.5. Content ltering in MTA Qmail ........................................ 26
4.4. Alternative methods of content ltering............................ 27
4.4.1. Scanning e-mail messages using AMaViS........................ 27
4.4.1.1. amavis.......................................................................... 27
4.4.1.2. amavisd........................................................................ 28
4.4.1.3. amavisd-new ............................................................... 28
5. Important NOD32LMS/NOD32BMSMechanisms..........31
5.1. User Specic Conguration................................................. 32
5.2. Handle Object Policy .......................................................... 33
5.3. Black-list and white-list ..................................................... 33
5.4. Samples Submission System .............................................. 35
6. NOD32 System Update andMaintenance ...................37
6.1. Basic concept of NOD32 system update.............................. 38
6.1.1. NOD32 mirror creation..................................................... 38
6.1.2. Generation of NOD32 scanner loading modules .............. 38
6.2. Automatic update of the virus denitions database........... 39
7. Tips and Tricks.........................................................41
7.1. Dropping messages marked by NOD32
as deleted in MTA Postx................................................ 42
7.2. NOD32LMS/NOD32BMS andTLS support in MTA................ 42
8. Let us know ............................................................45
NOD32 for Linux/BSD Mail Server, First Edition
Published on 6th December 2006
Copyright © 2006 Eset, s.r.o.
NOD32 for Linux/BSDMail Server was developed by
Eset, s.r.o. For more information visit www.eset.com.
NOD32 for Linux Mail Server was developed in
co-operation with ProWeb Consulting. For more
information visit www.pwc.sk.
All rights reserved. No part of this documentation
may be reproduced, stored in a retrieval system or
transmitted in any form or by any means, electronic,
mechanical, photocopying, recording, scanning, or
otherwise without a permission in writing from the
author.
Eset, s.r.o. reserves the right to change any of the
described application software without prior notice.
NOD32 for Linux/BSD Mail Server

Chapter 1:
Introduction
1 Introduction

4
Dear user, you have acquired NOD32 for Linux/BSD Mail Server - NOD32LMS/NOD32BMS - probably the best anti-
virus system running under the Linux/BSD OS. As you will soon nd out, the system using, the state-of-the-art NOD32
scanning engine, has unsurpassed scanning speed and detection rate, combined with a very small footprint that makes
it the ideal choice for any Linux/BSD OS server.
In the rest of this chapter we review a key features of the system.
• NOD32 scanning engine algorithms provide both the highest detection rate and the fastest scanning times.
• The system is developed to run on the single-processor units as well as on the multi-processor units.
• It includes unique advanced heuristics forWin32 worms and back-doors.
• Inbuilt NOD32 archivers unpack archived objects without the need for any external programs.
• In order to increase speed and eciency of the system, its architecture is based on the running daemon (resident
program) where all the scanning requests are sent to.
• The system supports selective scanner conguration specic for user or client/server identication.
• Six various levels of logging can be congured to get information about system activity and inltrations.
• One of the major advantages is the fact that the system installation does not require external libraries or programs
except for LIBC.
• The system can be congured to notify any person in case of detected inltration.
• Information about inltration can be congured to be written into an e-mail header, footer and subject.
• The system is MTA-independent, i.e. it does not depend on Mail Server used.
To run eciently, the system requires just 16MB of hard-disk space and 32MB of RAM. The NOD32LMS/NOD32BMS
runs smoothly under the 2.2.x, 2.4.x and 2.6.x LinuxOS kernel versions and also under 5.x, 6.x FreeBSD OS kernel
versions. The NOD32LMS/NOD32BMS system supports most popular server software including Sendmail, Postx, Qmail,
Exim, etc.
From lower-powered,small oce serverstoenterprise-class ISPserverswith thousands of users,thesystemdelivers
the performance and scalability you expect from a UNIX based solution and the unequaled security of NOD32.
NOD32 for Linux/BSD Mail Server

Chapter 2:
Installation
2 Installation

6
This product is distributed as a binary le. Its format for Linux OS is:
nod32ls.i386.ext.bin
where ’ext’is a Linux OS distribution dependent sux, i.e. ’deb’for Debian Linux OS distribution, ’rpm’for RedHat and
SuSE Linux OS distributions, ’tgz’for other Linux OS distributions.
Note that we support also RedHat Ready and Novell (SuSE) Ready variation of the product 1. The RedHat and Novell
(SuSE) Ready variation of the binary le format is:
nod32ls-rsr.i386.rpm.bin
Slightly dierent format is used to name the binary le for BSD OS,
nod32bs.i386.ext.tgz.bin
where ’ext’stands for BSD OS distribution dependent sux, i.e. ’fbs4’for FreeBSD 4.xx, ’fbs5’ for FreeBSD 5.xx and
’fbs6’for FreeBSD 6.xx OS distributions.
In order to install or update the product on Linux OS, use the statement:
sh ./nod32ls.i386.ext.bin
resp. the RedHat Ready or Novell (SuSE) Ready variation of the product is installed using the following statement:
sh ./nod32ls-rsr.i386.rpm.bin
In case of BSD OS, the install statement is as follows.
sh ./nod32bs.i386.ext.tgz.bin
As a result the User License Acceptance Agreement related with the product is shown. Once you have conrmed
the Acceptance Agreement, the whole installation package is extracted into the current working directory and relevant
information regarding installation or update of the package extracted as well as information necessary for uninstall the
already installed package is printed into terminal.
Oncethepackage isinstalledandthemainNOD32daemonserviceisrunning, in Linux OS youcancheckitsoperation
by using command:
ps -C nod32d
In case of BSD OS you can use a similar command:
ps -ax nod32d | grep nod32d
You will see the following (or similar) message on return:
PID TTY TIME CMD
2226 ? 00:00:00 nod32d
2229 ? 00:00:00 nod32d
where at least two main NOD32 daemon ’nod32d’processes running in the background have to be present. One of
the processes is so-called process and threads manager of the system.The other serves as NOD32 scanning process.
The dierence from the original RedHat and SuSE Linux OS package is that the RedHat Ready and Novell SuSE Ready package
meets criteria dened by FHS Filesystem Hierarchy Standard dened as a part of Linux Standard Base document required by the
RedHat Ready and Novell SuSE Ready certicateThis means in particular that the package is installed as an addon application
ie the primary installation directory is ’⁄opt⁄eset⁄nod’instead of the base Linux OS directory structure However there are more
dierences between the original and ’Ready’variation of the product that are beyond the scope of this document
NOD32 for Linux/BSD Mail Server

Chapter 3:
Product’s Roadmap
3 Product’s Roadmap

8
Once the product package has been successfully installed, it is time to become familiar with its content.
The structure of the NOD32LMS/NOD32BMS is shown in the gure 3-1. The system is composed of the following
components.
CORE
Core of the NOD32LMS/NOD32BMS consists of main NOD32 system control and scanning daemon module nod32d.
The daemon uses NOD32 API library libnod32.so and NOD32 loading modules nod32.00X to provide essential system
tasks:anti-virusscanning, maintenanceofthe agentdaemonprocesses,maintenanceofthe samplessubmission system,
logging, notication, etc..To get detailed information on the main NOD32 system control and scanning daemon, please
refer to nod32d(8) manual page.
AGENTS
The purpose of NOD32 agent modules is to integrate the NOD32LMS/NOD32BMS with the e-mail messaging system
environment. Their functionality is build with respect to needs of most common e-mail messaging systems in the
present. Please note a special chapter in this document devoted to the topic.
UPDATE
The update utilities create a particular fraction of the system. They are built with only one purpose, i.e. update of
NOD32 loading modules containing for instance virus signatures database, archives support, advanced heuristics
support etc. Please notice a special chapter in this document devoted to the topic.
CONFIGURATION
Proper conguration is the most important condition for the system operation.Therefore we describe all the related
components in the rest of this chapter. We also strongly recommend to read nod32.cfg(5) manual page, an essential
information source regarding NOD32LMS/NOD32BMS conguration.
After the product package is successfully installed, all the components related with its conguration and
authorization are stored in directory
NOD32 for Linux/BSD Mail Server
Figure 3-1. Structure of NOD32LMS/NOD32BMS.
NOD32CLI
NOD32MDA
NOD32PIPE
NOD32SMFI
NOD32SMTP
AGENTS
license
nod32.cfg
scripts
templates
extern
CONFIGURATION
UPDATE
nod32_update
nod32update
NOD32D LIBNOD32.SO NOD32.00X
CORE

9
/etc/nod32
Note that in case of RedHat Ready and Novell (SuSE) Ready variation of the NOD32 for Linux Mail Server the
conguration and authorization directory is
/etc/opt/eset/nod32
The directory consists of the following les.
nod32.cfg
This is the most important conguration le as it maintains the major part of the product functionality. For this
reason the le is further referred to as‚main conguration le‘ or‚main NOD32 conguration le‘. After exploring the
le you can see that it is built from various parameters distributed within sections. Note the section names always
enclosed in square brackets. In the main conguration le there is always one global and several so-called agent
sections. Parameters in global section are used to dene conguration options of main NOD32 daemon‚nod32d‘ as
well as default values of NOD32 scanning engine conguration options. Parameters in agent sections are used to dene
conguration options of so-called agents, i.e. modules used to intercept various data ow types in the computer and
in its neighborhood and prepare this data for anti-virus scanning. Note that besides the number of parameters used
for the system conguration, there is also a number of rules determining organization of conguration le. To become
familiar with this knowledge. please refer to nod32.cfg(5), nod32d(8) manual page and also to manual pages related
to relevant agents.
license
This directory is used to store the product license key you have acquired from your vendor. Note that the main
NOD32 daemon will always check only this directory to evaluate license key validity unless it is redened by the main
conguration le parameter ’nod32_lic_dir’.
scripts/nod32d_license_warning_script
This script, if enabled by main conguration le parameter ’license_warn_enabled’, is executed since 30 days (once
per day) before product license expiration. It is used to send e-mail notication about the expiration status to system
administrator.
scripts/nod32d_script
This script, if enabled by main conguration le parameter ’exec_script’, is executed in case the inltration has been
detected by the anti-virus system. It is used to send e-mail notication about the event to system administrator.
templates/lms_sig_*.html.example
These les are html templates used to dene text of messages inserted as a footnote into the scanned e-mails.
To enable these html templates the‚example‘ sux must be removed from all of the template le names. Note also
that the appearance of the e-mail messages footnotes is maintained by main conguration le parameter ’write_to_
footnote’. The meaning of individual template les is as follows.
The following footnote templates are used in e-mails found as infected:
chapter 3 / Product’s Roadmap

10
e-mail header | From:
. | To:
--------------------------
e-mail body | text of e-mail body
. |
. | content of lms_sig_header_infected.html
.   |listofinltrationsfoundbythescanner
. | content of lms_sig_footer_infected.html
The following footnote templates are used in e-mails found as clean:
e-mail header | From:
. | To:
--------------------------
e-mail body | text of e-mail body
. |
. | content of lms_sig_header_clean.html
. | list of objects scanned by the scanner
. | content of lms_sig_footer_clean.html
The following footnote templates are used in e-mails that could not be scanned:
e-mail header | From:
. | To:
--------------------------
e-mail body | text of e-mail body
. |
. | content of lms_sig_header_not_scanned.html
. | list of object scanned by the scanner
. | content of lms_sig_footer_not_scanned.html
NOD32 for Linux/BSD Mail Server

Chapter 4:
Integration with E-mail
Messaging System
4 Integration with E-mail Messaging System

12
ThischapterdescribesintegrationoftheNOD32LMS/NOD32BMSwiththevarietyofknownemailmessagingsystems.
Knowledge of e-mail messaging system basic principles (gure 4-1) is of paramount importance for understanding of
the NOD32LMS/NOD32BMS operation.
MTA - Mail Transport Agent
A program (for instance sendmail, postx, qmail, exim,
etc.) providing e-mail messages transfer among local and
remote domains.
MDA - Mail Delivery Agent
A program (for instance maildrop, procmail, deliver, local.
mail, etc.) providing delivery of locally addressed e-mail
messages into particular mailboxes.
MUA - Mail User Agent
A program (for instance MS Outlook, Mozilla Mail,
Eudora, etc.) providing access and management of e-mail
messages, i.e. reading, composing, printing etc., stored in
mailboxes.
MAILBOX
A le or a le structure on a disk serving as the storage
space for e-mail messages. Note that there are several
formats of MAILBOX in Linux/BSD OS: an old fashioned
format where e-mails for each user are stored sequentially
in one user appropriate le located in directory‚/var/spool/mail‘; MBOX (a bit newer but still an old format) with e-mails
stored sequentially in one le located within user home directory; MAILDIR with e-mails stored in a separate les within
a hierarchical directory structure.
The e-mail server receives data communication typically using SMTP - Simple MailTransfer Protocol communication.
The received message is transferred by MTA either to another remote e-mail messaging system or it is delivered using
local MDA into particular MAILBOX (we assume each local network user owns a MAILBOX located at the server disk).
Note that it is responsibility of the user‘s local MUA to provide download and correct interpretation of the message at
the user’s computer. When retrieving data from MAILBOX the MUA uses typically POP3 - Post Oce Protocol or IMAP
- Internet Message Access Protocol to communicate with the MTA. To send data to the Internet the SMTP protocol
communication is used.
The NOD32LMS/NOD32BMS operating principle is based on data communication interception and scanning at the
various phases of its transfer.The interception locations are marked in the gure 4-1 by symbols S1, S2 and S3.
S1
Scanning of inbound e-mail messages, i.e. messages with the target address corresponding to the destination located
inside the local domain.
S2
Scanning of outbound e-mail messages, i.e. messages bound to some remote Internet domain via its target address.
S3
Bi-directional e-mail messages scanning, i.e. content ltering in MTA.
The rest of this chapter reviews methods of integration of NOD32LMS/NOD32BMS with variety of supported
messaging systems.
NOD32 for Linux/BSD Mail Server
MTA
MDA
Mailbox
MUA
TCP port 25 (SMPT) (SMPT)
e-mail server
S1 PIPE
S3
FILE
S2
TCP port 110 (POP3)
OR 143 (IMAP)
Client Clients
Computer
TCP port 25 (SMPT)
INTERNET
Figure 4-1. Scheme of UNIX OS e-mail messaging system.

13
4.1. Scanning of inbound e-mail messages
Scanning of the inbound e-mail messages is
performed during the messages transfer between MTA
and MDA. Scheme of this process is in the gure 4-2.
The incoming e-mail is intercepted by nod32mda
module, scanned by main NOD32 daemon ’nod32d’ and
delivered to MAILBOX using original MDA. As shown in
the gure, the virus scanning can be enabled by proper
conguration setting of MTA and nod32mda module. It is
also apparent that the solution is MDA independent.
Note that the majority of mail servers use procmail
or maildrop (MDA). The nod32mda module supports
any MDA. In particular the following MDAs were tested:
procmail, maildrop, deliver and local.mail.
Next sections reviews two dierent procedures of
nod32mda module integration with e-mail messaging
system.
4.1.1. Renaming the original MDA and its replacement by NOD32MDA
This is a simple approach even without a need to make any changes in MTA conguration le.The idea is based on
replacing of original MDA by nod32mda module. Note that the information, on what MDA is used by your MTA, can be
grabbed only by exploring the MTA conguration le. Let‘s assume that the MDA used is for instance /usr/bin/procmail.
You simply rename the original procmail binary le for instance to procmail.real:
mv/usr/bin/procmail/usr/bin/procmail.real
and create the soft link to module nod32mda with the name‚procmail‘:
ln-s/usr/bin/nod32mda/usr/bin/procmail
In case of RedHat Ready and/or Novell (SuSE) Ready variation of NOD32 for Linux Mail Server the installation path to
the nod32mda is dierent so an appropriate statement is as follows:
ln-s/opt/eset/nod32/bin/nod32mda/usr/bin/procmail
With the above modications, you ensure that all messages originally sent to MDA are primarily catched by
nod32mda module. Still there remains to provide that all messages processed by nod32mda will be sent to the original
MDA‚procmail‘ binary le (currently named‚procmail.real‘).To do so, just modify parameter‚mda_path‘ within section
[mda] of main NOD32 conguration le in the following way:
mda_path=“/usr/bin/procmail.real“
After the modications yet enter
/etc/init.d/nod32d reload
and newly created conguration will be reread by the system.
Note that we have used‚procmail‘ MDA in this case, but the advantage of the procedure is that it can be repeated
with arbitrary known MDA. Disadvantage of this method, on the other hand, is that after original MDA upgrade your
chapter 4 / Integration with E-mail Messaging System
FILE FILE
FILE
PIPE
PIPE NOD32D
MTA
NOD32MDA
Mailbox
MDA
MTA
Mailbox
MDA
Figure 4-2. Inbound e-mail messages delivery without
(the left part of the gure) and with (the right part of the
gure) NOD32 scanning.

14
conguration will be broken as the new version of MDA will cancel the link to nod32mda module.
4.1.2. Setting of NOD32MDA (in MTA) as MDA
This section contains a more rigorous approach to provide scanning of inbound messages.
Note: Some MTA modules may be congured to not use MDA component for e-mail messages delivery. In this case,
it is necessary to congure them in a way to use any, by NOD32LMS/NOD32BMS supported MDA (for instance procmail
or maildrop).
4.1.2.1. Setting NOD32MDA in Sendmail MTA
First one has to grab information on the MDA used by Sendmail. This can be found in Sendmail conguration
le ’/etc/mail/sendmail.cf’ (some older versions use the ‚/etc/sendmail.cf‘). In the section ‚Local and Program Mailer
specication‘ nd the parameter ’P’ in sentence starting with ‚Mlocal‘. This parameter represents the full path to the
MDA used. In the same sentence you will see the parameter‚A‘ representing the MDA command line used.
Replace the path at parameter ’P’ with nod32mda module path and the name at parameter ’A’ with nod32mda
module name to provide complete replacement of original MDA by nod32mda module. Note that the command line
parameters present at the parameter ’A’ must stay the same as before replacement. For instance, if the original MDA
component path is /usr/bin/procmail, the appropriate sentence in the Sendmail conguration le can be:
Mlocal,P=/usr/bin/procmail,F=lsDFMAw5:/|@qSPhnu9,
S=EnvFromL/HdrFromL,R=EnvToL/HdrToL,
T=DNS/RFC822/X-Unix,
A=procmail-t-Y-a$h-d$u
After the modications have been performed, the appropriate sentence will be the following:
Mlocal,P=/usr/bin/nod32mda,F=lsDFMAw5:/|@qSPhnu9,
S=EnvFromL/HdrFromL,R=EnvToL/HdrToL,
T=DNS/RFC822/X-Unix,
A=nod32mda-t-Y-a$h-d$u
Note that in case of RedHat Ready and/or Novell (SuSE) Ready variation of NOD32 for Linux Mail Server the
nod32mda module path is dierent, so an appropriate Sendmail conguration le sentence will be as follows.
Mlocal,P=/opt/eset/nod32/bin/nod32mda,F=lsDFMAw5:/|@qSPhnu9,
S=EnvFromL/HdrFromL,R=EnvToL/HdrToL,
T=DNS/RFC822/X-Unix,
A=nod32mda-t-Y-a$h-d$u
Warning: In case you are reading the ASCII form of this guide, do not drag and drop any of above sentences, since
it may not work. The reason is that the command line switches present at parameter ’A’of the sentence depend on the
version of original MDA and thus may not work in your case.
With the above modications you have ensured that all the e-mail messages originally sent to MDA will be catched
by nod32mda module.Yet there remains to provide that all messages processed primarily by nod32mda will be sent to
the original MDA for further delivery. In order to do so, just modify‘mda_path‘ parameter within [mda] section of main
NOD32 conguration le. In case the original MDA is‘/usr/bin/procmail‘ the‘mda_path‘ parameter will be as follows:
mda_path=“/usr/bin/procmail“
Note (for Linux Debian users):The Debian distribution uses ’/usr/lib/sm.bin/sensible-mda’as MDA. Note that this is
NOD32 for Linux/BSD Mail Server

15
not a full-blown MDA, it is rather a wrapper; the‘mda_path‘ parameter in this case has the following format:
mda_path=“/usr/lib/sm.bin/sensible-mda“
To reread of newly created NOD32 conguration, enter the following command:
/etc/init.d/nod32d reload
To accomplish the whole procedure, one has to restart the MTA Sendmail.
Note that NOD32LMS/NOD32BMS provides you with the option to dene NOD32 scanning engine parameters
individually for recipient users (resp. recipient domains). In this case it is necessary to pass the information about the
recipient user to nod32mda module using its command line interface. Note that in case you would like to pass any
command line parameter to the whole nod32mda agent it is necessary to prepend the parameter by sentence ‚--‘,
otherwise the parameter will be assumed to be passed to original MDA specied by the‘mda_path‘ parameter. Thus
for instance to pass command line option --user to nod32mda agent the above discussed parameter ‘A‘ of Sendmail
conguration le has to be dened in a following way:
A=nod32mda-t-Y-a$h-d$u----user$u
With this setting a special section [user], if dened in NOD32 conguration le, will be used by main NOD32 daemon
for scanning.
4.1.2.2. Setting NOD32MDA in Postx MTA
First one has to grab information on the MDA used by Postx. This can be found in Postx conguration le ’/etc/
postx/main.cf’.The Postx authors have written a helper utility‘postconf‘ to work with the le, so we will use it in this
procedure.Thus by entering command
postconf mailbox_command
you can receive the following information on return:
mailbox_command=maildrop-d“$USER““$EXTENSION“
From the line above you can see that the MDA used by Postx is program called ’maildrop’. In order to replace the
original MDA by nod32mda module, enter the following command
postconf-e’mailbox_command=nod32mda-d“$USER““$EXTENSION“’
Keep in mind that the command line switches used in ’mailbox_command’after the nod32mda component must
stay the same as in the original conguration le, otherwise the conguration may not work properly. The reason is that
the switches depend on the version of original MDA used by the Postx.
With the above modications you have ensured that all the e-mail messages originally sent to MDA will be catched
by nod32mda module rst. Still there remains to provide that all messages processed by nod32mda will be sent to the
original MDA for further delivery. To do so, just modify parameter ‘mda_path‘ within section [mda] of main NOD32
conguration le. In case of ’maildrop’MDA the parameter‘mda_path‘ will be as follows:
mda_path=“/usr/bin/maildrop“
For reread of newly created NOD32 conguration, enter the following command:
/etc/init.d/nod32d reload
To accomplish the whole procedure, one has to restart the MTA Postx.
Note that NOD32LMS/NOD32BMS provides you with the option to dene NOD32 scanning engine parameters
individually for recipient users (resp. recipient domains). In this case it is necessary to pass the information about the
chapter 4 / Integration with E-mail Messaging System

16
recipient user to nod32mda module using its command line interface. Note that in case you would like to pass any
command line parameter to the whole nod32mda agent it is necessary to prepend the parameter by sentence ‚--‘,
otherwise the parameter will be assumed to be passed to original MDA specied by the‘mda_path‘ parameter. Thus
for instance to pass command line option --user to nod32mda agent the‘mailbox_command‘ option has to be dened
in the following way.
postconf-e’mailbox_command=nod32mda-d“$USER““$EXTENSION“\
----user“$USER“’
With this setting a special section [user], if dened in NOD32 conguration le, will be used by main NOD32 daemon
for scanning.
4.1.2.3. Setting NOD32MDA in Qmail MTA
The delivery options in the Qmail program are congured via the command line parameters at the time of program
execution or by using short scripts where the appropriate command line statements are stored. In the following text we
assume that the Qmail is installed in a ’/var/qmail’directory and there is a QMail’s starting script ’rc’within this directory
that is always executed at the start-up of Qmail by running the standard statement
qmailctlstart
In a simplest case the script‘/var/qmail/rc‘ is of the following content:
#!/bin/sh
execenv-PATH=“/var/qmail/bin:$PATH“\
qmail-start./Maildir/sploggerqmail
Note the rst qmail-start argument instructing qmail where to deliver e-mail messages to. This time it is a special
directory structure located in ’./Maildir/’within the local user home directory. However, generally there are also other
possible variants of the argument. For instance - ./Mailbox - that instructs qmail to deliver e-mail messages to the
MAILBOX le located at the local user home directory or - ‘|preline procmail‘ - to use the ‘procmail‘ MDA as a local
delivery agent, etc. See dot-qmail(5) manual page to get detailed information on this topic.
In order to instruct qmail to use nod32mda module in the message delivery process, you have to prepend the rst
command line argument of qmail-start with the absolute path of nod32mda module, i.e. the starting script‘var/qmail/
rc‘ will contain:
#!/bin/sh
execenv-PATH=“/var/qmail/bin:$PATH“\
qmail-start’|/usr/bin/nod32mda’./Maildir/sploggerqmail
Notethatthenod32mdamoduleabsolute pathisdierentin the RedHatReadyand/orNovell(SuSE)Readyvariation
of NOD32 for Linux Mail Server, so the starting script‘var/qmail/rc‘ in that case will appear to be of the form
#!/bin/sh
execenv-PATH=“/var/qmail/bin:$PATH“\
qmail-start’|/opt/eset/nod32/bin/nod32mda’./Maildir/sploggerqmail
Note that there is space before the second character‚ and no space after it. Keep also in mind that the argument -
./Maildir/ - is used this time only as an example and in your case you must prepend argument used in your original‚/
var/qmail/rc‘ script.
With above modications you have ensured that all the e-mail messages originally sent to MDA will be catched by
NOD32 for Linux/BSD Mail Server

17
nod32mda module rst. Still there remains to provide that all messages processed by nod32mda will be passed back to
QMail’s program for further message delivery.To do so, just modify parameter‚mda_path‘ within section [mda] of main
NOD32 conguration le in the following way:
mda_path=“/var/qmail/bin/qmail-nod32mda“
Create the script ’/var/qmail/bin/qmail-nod32mda’with the following content and run command‚chmod a+x‘ on
it:
#!/bin/sh
execqmail-local--“$USER““$HOME““$LOCAL““““$EXT““$HOST““$SENDER““$1“
Using this script the nod32mda will automatically (based on present environment variables) use QMail’s recognized
exitcodesrelatedwiththe’temporaryerrorstatus’andalso’infectede-mailmessagestatus’(seealsoqmail-command(8)
manual page to get information on exit codes of Qmail).
To reread the newly created NOD32 conguration, enter the following command:
/etc/init.d/nod32d reload
To accomplish the whole procedure, one has to restart the MTA Qmail.
Note that NOD32LMS/NOD32BMS provides you with the possibility to dene NOD32 scanning engine parameters
individually for recipient users (resp. recipient domains). In this case it is necessary to pass the information about the
recipient user to nod32mda module using its command line interface.Note that in case you would like to pass any
command line parameter to the whole nod32mda agent it is necessary to prepend the parameter by sentence ’--’,
otherwise the parameter will be assumed to be passed to original MDA specied by the ’mda_path’ parameter. Thus
for instance to pass command line option --user to nod32mda agent the ’/var/qmail/rc’script shall be of the following
content,
#!/bin/sh
execenv-PATH=“/var/qmail/bin:$PATH“\
qmail-start’|/usr/bin/nod32mda’./Maildir/’\
----user“$USER“’sploggerqmail
respectively in case you use RedHat Ready and/or Novell (SuSE) Ready variation of NOD32 for Linux Mail Server the
’/var/qmail/rc’script shall be slightly dierent.
#!/bin/sh
execenv-PATH=“/var/qmail/bin:$PATH“\
qmail-start’|/opt/eset/nod32/bin/nod32mda’./Maildir/’\
----user“$USER“’sploggerqmail
4.1.2.4. Setting NOD32MDA in MTA Exim version 3
Let’s look inside the exim conguration le ’/etc/exim/exim.conf’ (resp. in older versions ’/etc/exim.conf’) to
become familiarwith its content. It is typically compound from the so-called TRANSPORTERS CONFIGURATION section
and DIRECTORS CONFIGURATION section. In order to congure exim to use NOD32LMS/NOD32BMS you have to dene
special DIRECTORS CONFIGURATION entry in a following way:
#DIRECTORSCONFIGURATION
nod32_director:
driver=smartuser
chapter 4 / Integration with E-mail Messaging System

18
condition=“${ifeq{$received_protocol}{virus-scanned}{0}{1}}“
transport = nod32_transport
verify = false
Note that above entry has to be placed as a rst of the DIRECTORS CONFIGURATION section. You also have to dene
an appropriate TRANSPORTERS CONFIGURATION entry responsible for e-mail messages delivery to nod32mda agent.
Content of the entry is as follows:
#TRANSPORTSCONFIGURATION
nod32_transport:
driver = pipe
command=/usr/bin/nod32mda-oMrvirus-scanned$local_part@$domain
user=mail
group=mail
Note that in RedHat Ready and/or Novell (SuSE) Ready variation of NOD32 for Linux Mail Server the absolute path to
nod32mda module is dierent, so the denition ofTRANSPORTS CONFIGURATION entry in this case is as follows:
#TRANSPORTSCONFIGURATION
nod32_transport:
driver = pipe
command=/opt/eset/nod32/bin/nod32mda-oMrvirus-scanned$local_part@$domain
user=mail
group=mail
Be sure that the ’user’(usually ’mail’) used in the above settings is listed in a ’trusted_users’list for this parameter.
Also be sure that the option ’qualify_domain’is undened or set to your fully qualied domain name.
With the above settings you have ensured that all the e-mail messages originally sent to local domain user will
be primarily catched by nod32mda module. Yet there remains to provide that all messages processed by nod32mda
will be sent to the appropriate mailbox. To do so, just modify parameter ‘mda_path‘ within section [mda] of main
NOD32 conguration le. In case the absolute path to the exim is ‘/usr/sbin/exim‘ the parameter ‘mda_path‘ will be
as follows:
mda_path=“/usr/sbin/exim“
To reread the newly created NOD32 conguration, enter the following command:
/etc/init.d/nod32d reload
To accomplish the whole procedure, one has to restart the MTA Exim.
Note that NOD32LMS/NOD32BMS provides you with the option to dene NOD32 scanning engine parameters
individually for recipient users (resp. recipient domains). In this case it is necessary to pass the information about
the recipient user to nod32mda module using its command line interface. Note that in case you would like to pass
any command line parameter to the whole nod32mda agent it is necessary to prepend the parameter by sentence ‘-
-‘, otherwise the parameter will be assumed to be passed to ‘exim‘ specied by the ‘mda_path‘ parameter. Thus for
instance to pass command line option --user to nod32mda agent, the parameter ‘command‘ dened in TRANSPORTS
CONFIGURATION entry must by as follows:
command=/usr/bin/nod32mda-oMrvirus-scanned$local_part@$domain\
----user$local_part
resp. in case of RedHat Ready and Novell (SuSE) Ready variation of NOD32 for Linux Mail Server used, the ’command’
NOD32 for Linux/BSD Mail Server

19
parameter has to be dened as follows:
command=/opt/eset/nod32/bin/nod32mda-oMrvirus-scanned$local_part@$domain\
----user$local_part
4.1.2.5. Setting NOD32MDA in MTA Exim version 4
Let’s look inside the exim conguration le ’/etc/exim4/exim4.conf’ to become familiar with its content. It is
typically compound from TRANSPORTS CONFIGURATION section and ROUTERS CONFIGURATION section. Usually there is
a ROUTERS CONFIGURATION entry ’localuser’responsible for e-mail messages local delivery. In order to congure exim to
use NOD32LMS/NOD32BMS you have to dene special ROUTERS CONFIGURATION entry in a following way:
#ROUTERCONFIGURATION
nod32_router:
driver = accept
domains = +local_domains
condition=“${ifeq{$received_protocol}{virus-scanned}{0}{1}}“
transport = nod32_transport
verify = false
Note that above entry has to be placed as a rst in the ROUTERS CONFIGURATION section. You have also dene
an appropriate TRANSPORTERS CONFIGURATION entry responsible for e-mail messages delivery to nod32mda agent.
Content of the entry is as follows:
#TRANSPORTSCONFIGURATION
nod32_transport:
driver = pipe
command=/usr/bin/nod32mda-oMrvirus-scanned$local_part@$domain
user=mailnull
group=mail
Note that in RedHat Ready and/or Novell (SuSE) Ready variation of NOD32 for Linux Mail Server the absolute path to
nod32mda module is dierent, so the denition ofTRANSPORTS CONFIGURATION entry in this case is as follows:
#TRANSPORTSCONFIGURATION
nod32_transport:
driver = pipe
command=/opt/eset/nod32/bin/nod32mda-oMrvirus-scanned$local_part@$domain
user=mailnull
group=mail
Be sure that the ’user’(usually ’mailnull’) is the value of ’exim_user’or pick a name from the list ’trusted_users’for
this parameter. Also be sure that the option ’qualify_domain’is undened or set to your fully qualied domain name.
With the above settings you have ensured that all the e-mail messages originally sent to local domain user will
be primarily catched by nod32mda module. Yet there remains to provide that all messages processed by nod32mda
will be sent to the appropriate mailbox. To do so just modify parameter ‚mda_path‘ within section [mda] of main
NOD32 conguration le. In case the absolute path to the exim is ‘/usr/sbin/exim‘ the parameter ‘mda_path‘ will be
as follows:
mda_path=“/usr/sbin/exim“
To reread the newly created NOD32 conguration, enter the following command:
chapter 4 / Integration with E-mail Messaging System

20
/etc/init.d/nod32d reload
To accomplish the whole procedure, one has to restart the MTA Exim.
Note that NOD32LMS/NOD32BMS provides you with the option to dene NOD32 scanning engine parameters
individually for recipient users (resp. recipient domains). In this case it is necessary to pass the information about
the recipient user to nod32mda module using its command line interface. Note that in case you would like to pass
any command line parameter to the whole nod32mda agent it is necessary to prepend the parameter by sentence‚-
-‘, otherwise the parameter will be assumed to be passed to ‘exim‘ specied by the ‘mda_path‘ parameter. Thus for
instance to pass command line option --user to nod32mda agent, the parameter ‘command‘ dened in TRANSPORTS
CONFIGURATION entry must by as follows:
command=/usr/bin/nod32mda-oMrvirus-scanned$local_part@$domain\
----user$local_part
resp. in case of RedHat Ready and Novell (SuSE) Ready variation of NOD32 for Linux Mail Server used, the ’command’
parameter has to be dened as follows:
command=/opt/eset/nod32/bin/nod32mda-oMrvirus-scanned$local_part@$domain\
----user$local_part
4.2. Scanning of outbound e-mail messages
Scanning of the outbound e-mail messages is performed during transfer of e-mail messages between the local MUA
and the MTA. A more detailed scheme of the process is shown in the gure 4-3.
The most important part of scanning the outbound messages is done by the nod32smtp module.
This lter is a resident program (daemon) that performs in general three functions:
• receives data via INET socket,
• extracts e-mail/s and feeds nod32d (scanning daemon) to scan it,
• forwards the e-mail to another port or computer.
The operation principle of outbound e-mail messages scanning is based on the following idea. We congure a
nod32smtp daemon to listen to communication incoming to port 2525 of the email server computer and forward the
scanned communication to port 25 of the same computer where, typically, the MTA daemon listens to. To congure
nod32smtp to intercept outbound email messages the following parameters must be specied in section [smtp] of the
main NOD32 conguration le.
agent_enabled = yes
listen_addr = “localhost“
listen_port=2525
server_addr = “localhost“
server_port=25
To reread the newly created NOD32 conguration,
enter the following command.
/etc/init.d/nod32d reload
So far this is just half of the job. The second part that
has to be done is automatic redirection of all the packets
arriving on port 25 of the server computer to port 2525. In
NOD32D
NOD32SMPT
INTERNET
FILEMTA
TCP port 2525TCP port 25
Local Network 192.168.1.0/24
Figure 4-3. The scheme of the scanning of outbound e-mail
messages by using nod32smtp module.
NOD32 for Linux/BSD Mail Server