Chapter 5. NOD32LMS configuration
5.2.1. Renaming the original MDA and its replacement by
NOD32MDA
This is a simple approach even without a need to make any changes in the agent MTA. But
still, prior starting with the proper setup modification, the user is required to know exactly
what MDA agent is used by the system. This information can be grabbed only by exploring the
MTA configuration file. More information on how to do this is described shortly for individual
MTAs always at the start of the appropriate subsections 5.2.2.1. (sendmail), 5.2.2.2. (postfix),
5.2.2.3. (qmail), 5.2.2.4. (exim version 3 or less) and 5.2.2.4. (exim version 4). Please, check the
appropriate text parts and then return here. For illustration purposes, we will use the MDA
procmail.
In the next step we have to find the location of the MDA. In order to do so we use the following
command:
which procmail
that will give as the full path to agent MDA in return. Now the most important part of the
modification is to rename the original procmail binary file to procmail.real:
mv /usr/bin/procmail /usr/bin/procmail.real
and create the soft link to module nod32mda with the name ’procmail’ located in the directory
where the original MDA procmail was found, i.e. with the name ’/usr/bin/procmail’:
ln -s /usr/bin/nod32mda /usr/bin/procmail
With the above modifications, we have ensured that all the messages originally sent by the MTA
for delivery to MAILBOX (by using an original MDA) will now be primarily sent to module
nod32mda. Still there remains the second part of the modification to provide that all messages
processed by nod32mda will be sent to the original procmail MDA (at this time renamed to
procmail.real). In order to do so, we have to modify parameter ’mda_path’ within the section
[mda] of the main NOD32LMS configuration file (/etc/nod32/nod32.cfg) as follows:
mda_path = "/usr/bin/procmail.real"
After all of the above modifications one has to restart the daemon nod32d in order to reread the
new configuration of NOD32LMS.
Note that in the above example we have used procmail as an MDA, however, the whole pro-
cedure can be done with any other known MDA which is a great advantage of this approach.
On the other hand, there is a potential problem within this configuration that may occur in
circumstances of MDA software upgrade. Indeed, once we will decide to upgrade the MDA
software (for instance procmail in our case), the upgrading mechanism will provide the new bi-
nary file /usr/bin/procmail that will cancel the link to nod32mda scanning module created by
the above procedure and the configuration will be broken. Thus, even if the approach suggested
in this section works in all cases, it is always necessary keep in mind that the problem of the
15