Best Practices MFiltro

Configuration solutions for NETASQ Mfiltro appliances

Last update:15. Jul. 2011(rev. 1)

Table of contents

Introduction..........................................................................................................................................3
Treatment of incoming e-mails.............................................................................................................5
LDAP directory..................................................................................................................................17
Quarantine..........................................................................................................................................20
Treatment of outgoing e-mails...........................................................................................................22
Sending Non-Delivery Reports (NDR) .............................................................................................32
Some useful command lines...............................................................................................................34

Page 2 / 38

Introduction

Aim of the document:

The main aim of this document is to centralize the solutions to situations that are likely to be
encountered by users who install NETASQ MFiltro products.
Do also note that this document is a complement to the set of documentation that has been
provided in your private area, but is in no way a substitute.
In this document, you will find a summary of technical information on how to set up various
configurations, but also the issues encountered on MFiltro appliances.

Knowledge base:
You may also look up our Knowledge base, which contains articles regarding frequentlyencountered issues. It will provide a quick solution to your questions and is the first step in
resolving a configuration problem.
Before you even begin to open a case with NETASQ's support, you are strongly advised to look
through the Knowledge base first to check whether your question has already been answered in
an article.
This Knowledge base can be accessed through your client area in the menu Technical
Support / Knowledge base.

Page 3 / 38

General information:
This document presents configuration or monitoring actions that can be carried out with the
administration interface "MFiltro Management Console", which can be accessed through your
web browser in HTTPS.
This administration interface is made up of 6 main tabs:

The Monitor tab provides statistical information in real time regarding messages treated by a
rule in the policy, regarding active sessions, logs and regarding all domains through various
graphs and tables.

The Policy tab allows configuring filter rules at the protocol level (SMTP) and at the content
level (data). Various profiles can be defined in order to obtain multiple analyses. Furthermore,
you will also be able to configure the routing table, create/modify/delete different types of lists,
define requests and configure RBLs (Realtime Blackhole Lists).

The Applications tab is used for configuring the anti-spam application as well as the Kaspersky
(or ClamAV) anti-virus application. You can therefore check their functioning and update status
and modify some of the scan settings of the application.

The Administration tab allows configuring the MTA (Mail Transfer Agent), various services
(such as the DNS service, Syslog, NTP, SNMP, Web), quarantine, the SMTP server and client
side and also allows viewing queues.

The Advanced tab provides advanced information on interfaces, resources of the MFiltro
appliance (CPU, memory), logs concerning the SMTP server, statistics as well as parameters of
the SMTP engine.

The Maintenance tab allows restarting/shutting down the MTA, backing up the configuration,
updating the appliance's firmware or launching the configuration wizard of the MFiltro appliance.

WARNING
This document is intended for a technical audience with a good grasp of SMTP as
well as of NETASQ MFiltro appliances.

Page 4 / 38

Treatment of incoming mail

During deployment, the first thing to do is to configure the NETASQ MFiltro appliance
with the wizard, through your web browser at the URL http://10.0.0.254:81 .
This Wizard allows you to configure your MFiltro appliance easily and quickly in a few steps:

The first step is authentication, in order to define your login and password for the administration
of your MFiltro appliance later.

Page 5 / 38

In the second step, the network configuration and access restrictions can be set.

Page 6 / 38

Page 7 / 38

The third step allows you to register your product in your client area. If you do not have a client
account, you will be able to create one.

Page 8 / 38

The fourth step allows you to update the firmware of your MFiltro appliance if it is not up to
date.

Page 9 / 38

The fifth step allows you to define the various SMTP parameters such as protected domains and
routing policy and even allows checking the existence of recipients.

Page 10 / 38

In the sixth step, you will be able to define the perimeter of the anti-virus and anti-spam scan
according to the domains selected or from a list of e-mail addresses.

Page 11 / 38

The seventh step allows you to set various options on the anti-spam engine and on the anti-virus
engine.

Page 12 / 38

In the eighth step, you will be able to define the treatment that the anti-spam engine will perform
as well as the actions to take for e-mails that have been considered spam and/or infected.
Depending on the score obtained by the anti-spam engine, the message may be dropped,
quarantined or tagged (in the subject line).

Page 13 / 38

The ninth step finalizes the configuration of the NETASQ MFiltro appliance, with the possibility
of sending a report of the configuration to the e-mail address specified.

NOTE
The wizard can be launched a second time using the menu " Maintenance >
Wizard" in order to modify the configuration of the NETASQ MFiltro appliance.
At the same time, it is possible to access a specific step in the wizard without
modifying the previous steps, using the button "Ignore this step ".

Page 14 / 38

What are the prerequisites for checking the validity of destination addresses (SMTP alias check)
with a Microsoft Exchange server?
Some options need to be enabled on the Microsoft Exchange SMTP server in order to
validate the existence of the recipient(s). By default, the Microsoft Exchange server confirms the
existence of a user, even if it does not exist.
The consequence of this default configuration is that when spam is received, a quarantine inbox
will be created for a fictitious user and will then involve unnecessary treatment for the NETASQ
MFiltro appliance. In order to work around this issue, the following modifications need to be
made from the "Exchange System Manager" console.
To do so, go to the Exchange System Manager to view the properties of the menu "Message
delivery" and select the option "Filter recipients that are not in the address book" in the tab
"Recipient filters".

Then, display the properties of the tab "SMTP virtual server by default" in the directory
"Servers > Server name > Protocols > SMTP" (a pop-up will appear).
Next, click on "Advanced options" in the new window, then on the button "Modify" in the
window "Advanced parameters". Lastly, check the option "Apply the recipient filter" in the
window "Identification".

Page 15 / 38

Page 16 / 38

I have two internal SMTP servers that manage all my domains. Is it possible to configure high
availability between both my servers using MFiltro?
High availability can be set up between two SMTP servers using the MFiltro appliance, thanks to
the definition of priorities in the SMTP routing table, which can be accessed through the menu
"Policy > Routing". You will therefore need to define 2 rules in your routing table with a different
priority. As such, the SMTP server that has the lowest value will have priority.

Is it possible to apply load balancing between my two servers with the MFiltro appliance?
It is also possible to apply round-robin load balancing between two SMTP servers using the
MFiltro appliance. You will need to define 2 rules with the same priority in the SMTP routing table
(accessible from the menu "Policy > Routing"). As such, NETASQ MFiltro will apply load
balancing between both SMTP servers, which will then treat the same number of e-mails.

Page 17 / 38

LDAP directory

As seen in the fifth step of the wizard, the validity of a recipient can be checked for
incoming e-mails. However, the wizard only allows checking via SMTP (SMTP alias check),
whereby MFiltro checks that the address of the recipient is known to the internal SMTP server. If
this is so, the appliance will continue its treatment, otherwise, the e-mail will be blocked and a
specific code will be sent back (REJECT recipient: SMTP code 550 - [<$(_toemail)> recipient
rejected]).
Nonetheless, the validity of a recipient's e-mail address can also be checked through an
LDAP directory (e.g.: OpenLDAP, Active Directory). You will thus need to create an "LDAP"
query in the menu "Policy > Query" (e.g.: the query "ActiveDirectory" with the "LDAP
request" type) in order to confirm the existence of the user's e-mail address. Next, edit the query
that has just been created in order to enter the following information:
"Server Configuration" section:
Server IP:

IP address of your LDAP server

Server Port:

389 (the port of the LDAP protocol)

Server DN:

user@domain.com ("user" being the user that the MFiltro appliance

will use for the LDAP query.

Server Type:

ActiveDirectory (in the case of an Active Directory server)

Server Password:

Password for the user "user"

Search Base:

The database for finding users

Search Filter Format:

The filter for finding the user.

Example for an Exchange server that has been interfaced with an
Active Directory:
(proxyAddresses=smtp:[login]@[domain])

"Attribute request" section:

Use DN as search base:

Enabled

Page 18 / 38

"Tuning" section:
Wait for all
results:

Enabled

Timeout Keep:

30 seconds

You will then obtain the configuration in the example below:

Validate the configuration (click on the diskette icon) to finalize the definition of your LDAP
query.

Page 19 / 38

Next, you will need to define in the SMTP policy a rule that will allow launching the
LDAP query in order to check the existence of the e-mail address or of the alias of a user or of
the address of a group. A new rule therefore needs to be added (e.g.: "LDAP check", placed
before the rule "counter increment legit") in the "RCPT TO" section of the active SMTP
profile. Next, edit the rule and define it as follows:
IF [NOT smtp rcptto exists on directory [ActiveDirectory] using format: user [[user]], domain
[[domain]] ]
THEN REJECT recipient: SMTP code 550 - [<$(_toemail)> recipient rejected]

Once the rule has been defined, save its settings (diskette icon). To apply a configuration, don't
forget to re-apply the SMTP profile used.
From this point on, for every incoming e-mail, NETASQ MFiltro will perform a query on your
LDAP server in order to check the existence of the recipient's e-mail address.

Page 20 / 38

Quarantine

The quarantine function on NETASQ MFiltro appliances is managed by an independent

daemon, isolated from the MTA, which is named "redq" and whose aim is to treat and store emails that have been considered spam in the user's quarantine mailbox, for a defined duration.
Later on, a quarantine report will be sent to the user daily to inform him that there are spam
messages in his quarantine mailbox. The user can therefore request to receive an e-mail that has
been quarantined if he deems it legitimate.

For LDAP interfacing, is it possible to associate the aliases of a user with his main e-mail
address in order to create only one quarantine mailbox for the user?

It is indeed possible to redirect e-mails that have been considered spam to the quarantine
mailbox of the user's main e-mail address. You will need to access the rules (workflow) of your
active content profile, accessible through the menu "Policy > Content" and make the following
changes:

Page 21 / 38

The rule named "store SPAM or VIRUS(SUSPECT) or BOUNCE in quarantine" has

to be modified and the variable "quarantine" has to be set to "1" if this e-mail should be
quarantined.
The purpose of the rule "Quarantine in main email address" is to retrieve the user's main e-mail
address through an LDAP query (LDAP query seen earlier) in order to retrieve the "mail" field
and to therefore store this spam message in this user's main quarantine.

WARNING
The "mail " field corresponds to an attribute in the Active Directory schema.
In the case of other LDAP servers, the field corresponding to the user's main email address has to be specified.

Is it possible for a user to define his own domain or sender whitelist for his quarantine?

A user can define his own domain or sender whitelist from his personal quarantine. The user has
to look up his quarantine (using a link in a quarantine report or by requesting an access
token), in order to define his whitelists, by clicking on the "Parameters" button. A pop-up
window will then appear displaying all users and domains contained in his whitelist.

Page 22 / 38

Treatment of outgoing e-mails

The NETASQ MFiltro appliance is also able to treat outgoing e-mails as it has a
mechanism that allows, for all external domains, performing MX (Mail eXchange) DNS
resolution so that NETASQ MFiltro can, after a protocol and/or content scan, route outgoing emails going to SMTP servers on external domains.
For MFiltro to be able to scan outgoing e-mails, the configuration of MFiltro takes place in
several steps.
The purpose of the first step is to define a default route that must be located at the end of the
SMTP routing table (menu "Policy > Routing") and which will be based on MX DNS resolution.
The domain "*" therefore must be defined (corresponds to any domain that does not match the
previous rules) with the SMTP server defined as "MX" (corresponds to an MX DNS query).

Page 23 / 38

Some domains have several MX registrations. In these cases, you are advised to configure
NETASQ MFiltro so that it takes into account all these registrations. If the main SMTP server of
the external domain is not available, NETASQ MFiltro will be able to query secondary MX
registrations.
To configure NETASQ MFiltro in this way, go to the menu "Administration > Protocol >
SMTP client > retry rules" and modify the value of the field "Retries per session". This value
defines the maximum number of successive tries before the message will be queued. As such, for
each attempt, the following MX registration will be tested.
NETASQ's suggestion is to set the value to "3".

At the same time, it is better to modify the name of the MFiltro appliance's server name so that it
corresponds to the FQDN (Fully Qualified Domain Name) of the domain of the company (MX
registration) so that it can communicate with other public gateways.
This server name will be used in the SMTP command "HELO".
Some MTAs check the coherence between the name specified in the "HELO" command and the
MX registration (obtained thanks to inverse revolution).

For changes to be correctly applied, you are advised to restart services via the menu
"Maintenance > Restart".

Page 24 / 38

The second step involves modifying the default policy on the NETASQ MFiltro appliance
so that it can allow outgoing e-mails. Indeed, the policy generated by the wizard allows only
sending e-mails to the domains protected by the MFiltro appliance.
To allow your internal SMTP or some hosts on your LAN to send e-mails outside the network,
you will need to create a list (e.g.: allowed_ip ) through the menu "Policy > Lists", in which you
define the allowed IP addressed.

In this example, the IP address "192.168.1.1" will be allowed to send e-mails to external
domains.

Page 25 / 38

Changes must also be made to your active SMTP profile, accessible via the menu "Policy >
Protocol":
1/ The "BANNER" section:
You will need to add the rule "Check allowed IP" after the rule "Check queue size"
IF connection ip source [exists in list] [allowed_ip]
THEN variable add [outgoing_email] description [outgoing email] type [integer] value [1]

The purpose of this rule is to check whether the source IP address of the SMTP connection
corresponds to the IP address of the internal SMTP server (or of internal hosts) that send e-mails
to external domains. These addresses will be set out in the list "allowed_ip". If this is so, set the
variable "outgoing_email" to 1 to ensure that it is an outgoing e-mail.

Page 26 / 38

An "Accept allowed IP" rule must also be added after the rule "Check allowed IP ". Indeed, it is
unnecessary to conduct an RBL check if the e-mail comes from an internal domain.
IF variable [outgoing_email] (integer) [=] [1]
THEN ACCEPT connection banner: SMTP code 220 - [ESMTP server ready]

Page 27 / 38

2/ The "RCPT TO" section:

A rule has to be defined in order to ensure that outgoing e-mails are sent from domains protected
by the NETASQ MFiltro appliance. Therefore, add the rule "Check internal IP and internal
sender for outgoing email" after the rule "Let redq through"
IF variable [outgoing_email] (integer) [=] [1]
AND smtp mailfrom domain is on local domain list
THEN ACCEPT recipient: SMTP code 250 - [<$(_toemail)> recipient ok]

Thereafter, once this new SMTP profile has been applied (in order to take into account changes
that have been made), users from protected domains and whose source IP address is on the list
"allowed_ip" (in general, the IP address of the internal SMTP server) will be able to send e-mails
outside the network.

Page 28 / 38

However, in the current version of NETASQ MFiltro, anti-spam analyses should be

avoided for outgoing mail. If an outgoing e-mail is considered spam, and is consequently
quarantined, NETASQ MFiltro will send a quarantine report to the external user.
The administrator is free to set up his policy. However, if an anti-virus and anti-spam scan needs
to be applied on outgoing e-mails, the administrator of the NETASQ MFiltro appliance or the
user (sender) will need to be informed directly if spam is received.
Changes will have to be made in your active Content profile, which can be accessed via the menu
"Policy > Content"
1/ The "Content" section:
Firstly, the rule "store SPAM or VIRUS(SUSPECT) or BOUNCE in quarantine" has to be
modified as follows:
IF variable [_vaas_descr] (string) [matches exactly] [spam]
OR variable [_vaas_descr] (string) [matches exactly] [virus_suspect]
OR variable [_vaas_descr] (string) [matches exactly] [bounce]
THEN variable set [quarantine] description [Must be quarantine] type [integer] value [1]

Page 29 / 38

Page 30 / 38

Next, you will need to define a rule in order to inform the administrator or the sender that
the outgoing message has been considered spam. The rule "Inform if outgoing email and
quarantine" must therefore be created after the rule "store SPAM or VIRUS(SUSPECT) or
BOUNCE in quarantine".
IF variable [outgoing_email] (integer) [=] [1]
AND variable [quarantine] (integer) [=] [1]
THEN generate new message from [mfiltro@$(_fromdomain)] to [$(_fromemail)] subject
[***SPAM*** $(_subject)] body [The message from $(_fromemail) to $(_toemail) with the
subject $(__subject) has been considered as spam.] ;
DROP message

Page 31 / 38

Next, it is necessary to take into account incoming e-mails that the anti-spam analysis will
consider as spam and which, this time around, have to be quarantined. You therefore need to
create the rule "Put incoming emails considered as spam in quarantine" for the rule "Inform
if outgoing email and quarantine".
IF variable [quarantine] (integer) [=] [1]
THEN QUARANTINE message

Thereafter, once this new Content profile has been re-applied in order to take into account
changes that have been made, users from protected domains and whose source IP address is on
the list "allowed_ip" will be able to send e-mails outside the network, while performing and antivirus and anti-spam scan on the message contents. If the outgoing e-mail is a spam message, the
administrator or sender of the e-mail will be informed.

Page 32 / 38

Sending a Non-Delivery Report (NDR)

It is possible to configure the NETASQ MFiltro appliance so that it can send NonDelivery Report (or NDR) messages. NDRs are messages that aim to inform the sender that the
message was refused for certain reasons (e.g.: the user does not exist, domain not managed by the
MTA, etc).

To configure the sending of NDRs on the NETASQ MFiltro appliance, you will need to access
the menu "Administration > Protocol > ndr". You will then reach the following page:

Page 33 / 38

1/ The "SMTP routing NDR configuration" section:

This section allows you to configure the parameters for sending NDR messages through the
following fields:

Enable NDR by default

Enables/Disables sending NDRs

Send NDR warning every

Frequency with which pre-NDRs will be sent when the

message is in the treatment queue. (This feature is specific to
MFiltro and is not described in RFC 2821)

Sender name

Name of the user specified for sending NDRs

Sender email

E-mail address used for sending NDRs

Stylesheet

Style sheet used for sending NDRs (Not to be modified!)

2/ The "SMTP NDR delivery rules" section:

This section allows configuring the queue (named "bouncer") for sending NDRs, through the
following fields:

Retries per session

Number of tries for sending the NDR before queuing it

Retry interval

Default interval before attempting to send again (in seconds)

Retry multiplier

Multiplier coefficient of the default interval

Maximum retry interval

Maximum duration of the interval (in seconds)

Maximum queue age

Maximum duration for which an NDR can remain in the queue (in
seconds)

Page 34 / 38

Some useful command lines

Here is a list of commands that may be useful if problems arise on the NETASQ MFiltro
appliance. Indeed, certain processing errors are often encountered, in general because of the
appliance's configuration. First of all, the sender and recipient of the message have to be
identified in order to understand later, the treatment that MFiltro performs on it. You therefore
need to connect to the NETASQ MFiltro appliance via SSH and execute the following
commands:
# cd /var/log/bizimp
# grep -i "from=\"sender" messages.log | grep -i "to=\"recipient"
You will then notice in the output of this command a field named "id" which corresponds to the
identifier of the message assigned by the MTA:
20091231 11:09:50.401 messages id=Pm8w1d0010D0MuJ01m9F01 action=DROP
wf=imp:0:1 ip=10.1.12.10 from="sender@domain1.com" to="recipient@domain2.com"
size=155
It is also possible to find out about all the treatments that have been carried out by MFiltro by
executing the following command:
# grep "Pm8w1d0010D0MuJ01m9F01 " /var/log/bizimp/*
In this way, it is possible to detect the reason for the e-mail being blocked (cf. previous example).
Here, the e-mail has been deleted (DROP action) by the Content rule (imp) numbered 1 (0:1):
0091231 11:09:50.401 messages id=Pm8w1d0010D0MuJ01m9F01 action=DROP wf=imp:0:1
ip=10.1.12.10 from="sender@domain1.com" to="recipient@domain2.com" size=155
Here is a description of the variable "wf":
wf=[W]:[O]:[R] with:
[W] Worflow concerned: smtp (PROTOCOL) ou imp (CONTENT)
[O] Tab in the Workflow:
for smtp: 1 for BANNER, 2 for HELO, 3 for AUTH, (), 6 for DATA
for imp: always 0 (a single tab)

Page 35 / 38

[R] Rule concerned (rule number)

How can the treatment of a message passing through MFiltro be accurately tracked?
The operation of the NETASQ MFiltro consists of 3 steps:
1.Receipt of the La message
2.Scan of the message
3.Sending of the message
First of all, the connection of the SMTP client can be noticed through the logs
"/var/log/bizimp/smtpin.log".
20100115 10:05:59.758 smtpin sid=Vl5z1d0010D0MuJ01 smtp=OPEN ip=10.1.12.10 dip=10.1.12.50
dport=25 type=smtp
20100115 10:06:05.384 smtpin sid=Vl5z1d0010D0MuJ01 hello=NETASQ

Page 36 / 38

The majority of the problems encountered are also due to the DNS service. However, the MTA of
the MFiltro appliance uses its own DNS, instead of the operating system's DNS.

WARNING
Some queries, like firmware updates, use the operating system's DNS service
(resolver which can be configured thanks to the file /etc/resolv.conf).

Returning to the subject of the administration interface, which allows you to test the DNS service
of the MTA through the menu "Administration > Services > DNS > lookup".

In the example above, we have checked the operation of the DNS service of the MTA by sending
an A-type DNS query on the domain name "netasq.com".

Page 37 / 38

What happens if the DNSs configured on MFiltro are no longer accessible? Does the rule allow
all messages to pass through or does it block everything?
In the event the DNS servers configured on NETASQ MFiltro are no longer accessible,
the rule, which needs to send a DNS query, will reject all messages due to the fact that this rule
cannot be validated. Likewise for the LDAP server, as in the event it cannot be contacted, the rule
that checks the recipient will not be able to be validated and as a result, all messages will be
blocked.

What data must I collect in case of problems, in order to indicate them to NETASQ's technical
support, for example?
Since version 1.2.1, it has been possible to generate instantaneous "snapshots" (technical reports)
of the NETASQ MFiltro appliance by executing the following command:
# mfiltro-sysinfo
Usage: mfiltro-sysinfo [DETAIL_LEVEL]
Take a snapshot of the MFiltro
Version: 1.2
Options:
* DETAIL_LEVEL 0: normal details for the snapshot
1: high details
2: very high details (backup messages queue)
WARNING !! With the detail level 2, the snapshot can be very long !!

It is possible to obtain information on updates of the anti-virus and anti-spam engine in

command line?
The progress of application updates (Antispam and Kaspersky) can be tracked through the file
"/tmp/appupdate.log".
As such, when you launch the update of an application via the administration interface, you will
be able to track the progress of updates by executing this command:
# tail -f /tmp/appupdate.log

Page 38 / 38