Integration with Mail Systems

This method of integration assumes connection of Dr.Web MailD directly to the mail server as an external filter for email scanning. It is possible to connect to any mail server (for example, Exim, Sendmail, Postfix) that uses the following interfaces: Milter, Spamd, Rspamd.

To integrate Dr.Web MailD with a mail server, you will need to review the current values of parameters in the Dr.Web MailD‘s settings section in the configuration file (the [MailD] section) and change them if necessary.

Using parameters TemplateContacts and ReportLanguages, determine parameters of email generation when repacking email messages with threats and/or spam. As the value of parameter RepackPassword, indicate method of generation of passwords for protected archives with threats that are going to be added to email messages once unpacked (value None, indicated by default, allows to abandon the protection of archives with a password, which is permissible but not recommended).

To start with, it is necessary to determine the used conjugation interface (Milter, Spamd or Rspamd), and indicate the parameters of the MTA connection and parameters of email scanning, received for scanning via the selected interface. All parameters of Dr.Web MailD, that control its conjugation with MTA via an interface, have a respective prefix in their names:

It is necessary to indicate values of the following parameters (where <interface> is a prefix in the parameter name that corresponds to the selected one for conjugation with the MTA interface):

1.<interface>Socket is a socket that will be used by Dr.Web MailD to obtain scanned email messages from MTA via the corresponding interface. Usage of the UNIX socket or network socket is allowed.

2.Email message scanning parameters (<interface>ScanTimeout, <interface>HeuristicAnalysis, <interface>PackerMaxLevel, <interface>ArchiveMaxLevel, <interface>MailMaxLevel, <interface>ContainerMaxLevel, <interface>MaxCompressionRatio), that limit the length and resource intensity of email message scanning. When a fine-grained configuration is not required, it is recommended that values for parameter data are kept in their default state.

3.<interface>BlockUnchecked—response of Dr.Web MailD to impossibility of scanning of the received email message (exceeding the set limits (see previous item), violation of email message structure, anti-virus engine error, availability of attached archives protected with a password, etc.). If this parameter is set to Yes, then in case of impossibility to scan an email message and/or its attachments, MTA will receive a setting to reject this email message.

4.To configure the filtering rules for emails in a more fine-grained way (on the basis of various conditions), you can also edit the scanning rules <interface>RuleSet (description of rules is available in Appendix D in Administrator manual).

After all settings are adjusted, restart Dr.Web for UNIX (use the command drweb-ctl reload). You can also restart the configuration daemon Dr.Web ConfigD (use the service drweb-configd restart command).

If interaction of Dr.Web MailD with MTA uses the Spamd/Rspamd interface, the only possible action for Dr.Web MailD within this interaction is to inform MTA whether the email message is clean or classified as spam. If the email message violates any limit set by the rules, or if there is any threat in the email message, the following verdict is sent to MTA “The email message is spam”. All actions aimed at processing the email message (for example, adding headers, rejection of the email message, delivery to the recipient, etc.) must be defined in the settings on the part of MTA. Also, in this case Dr.Web MailD does not guarantee the return of the modified email message to MTA, so such actions as REPACK (“repacking” of the email message by removing malicious attachments and adding a notification on threat detection) are also not guaranteed.

To return to MTA the reason of an email message rejection via the Spamd/Rspamd interface, use the action REJECT <description>. The indicated parameter <description> will be used as a header value “Message” added by MTA to the email message after the message with the scanning results. Besides, <description> can be used for detection the reason for rejection of an email message and applying a corresponding action depending on that reason within MTA rules. Example usage of REJECT <description>:

SpamdRuleSet0 = threat_category in (KnownVirus, VirusModification, UnknownVirus) : REJECT "The message contains a THREAT"
SpamdRuleSet1 = body match (“.*buy.*") : REJECT "This is a SPAM message"

To enable interaction between MTA and Dr.Web MailD, edit the configuration of the mail server to allow using Dr.Web for UNIX as an external filter that scans emails processed by MTA.

1.Indicate the interface used for interaction of MTA with Dr.Web MailD when scanning email messages (Milter, Spamd, Rspamd).

2.Indicate parameters for connection of MTA to Dr.Web MailD via the chosen interface (used socket must match with the one indicated in the parameter <interface>Socket for the corresponding interface in the settings of Dr.Web MailD).

3.Configure the MTA behavior in response to receipt of email scanning results via the interaction interface.

Below are the example cases of settings for MTA Postfix, Sendmail and Exim for connection of Dr.Web MailD as an external filter of email messages via the following interfaces: Milter, Spamd and Rspamd.

In the examples below, the <MailD socket>, <MailD IP address> and <MailD port> values should be replaced with the socket listened by Dr.Web MailD (which is indicated in the Dr.Web MailD settings, in the <interface>Socket parameter, where <interface> is the prefix in the name of the parameter corresponding to the selected interface conjugated with MTA).

For example, if Dr.Web MailD is integrated with MTA via the Milter interface using the network socket, and MTA with Dr.Web MailD both work on a local host, and Dr.Web MailD listens to port 12345 for the connections via Milter, than this value should be specified as the MilterSocket parameter in the [MailD] section of Dr.Web for UNIX configuration file. In the MTA settings, the 127.0.0.1:12345 value should be specified as the <MailD socket> variable, the 127.0.0.1 address as the <MailD IP address> variable, the 12345 value as <MailD port> variable.

In some cases, socket address for the connection with Dr.Web MailD should be supplemented with prefix <type> with the type of the used addresses in the MTA settings (inet, inet6, unix).

Note that the only required setting is smtpd_milters, the rest of them can be omitted.

After changing the file sendmail.mc, do not forget to modify it into the active configuration file sendmail.cf by executing any of the following commands:

Note that all the commands listed above presume that files of configuration Sendmail are located in the directory /etc/mail.

spamd_address = <MailD socket>
acl_smtp_data = acl_check_data

acl_check_data:
warn spam = nobody:true
add_header = X-Spam_score: $spam_score\n\
X-Spam_score_int: $spam_score_int\n\
X-Spam_bar: $spam_bar\n\
X-Spam_report: $spam_report\n\
condition = ${if match {$spam_report}{SPAM}}
deny spam = nobody:true
condition = ${if match {$spam_report}{THREAT}}
accept

spamd_address = <MailD socket> variant=rspamd
acl_smtp_data = acl_check_data

acl_check_data:
warn spam = nobody:true
add_header = X-Spam_score: $spam_score\n\
X-Spam_score_int: $spam_score_int\n\
X-Spam_bar: $spam_bar\n\
X-Spam_report: $spam_report\n\
condition = ${if match {$spam_report}{SPAM}}
deny spam = nobody:true
condition = ${if match {$spam_report}{THREAT}}
accept

Indicated settings examples suppose the usage of Exim of version 4.6 (or later) built with the option WITH_CONTENT_SCAN=yes. besides, it is supposed that Dr.Web MailD will return the message that contains the word SPAM or THREAT (i.e. the following action must be applied REJECT <text>, and in line <text>, there must be word SPAM or THREAT respectively), in consequence of which Exim will apply to the email message an action warn or deny (see example of an action REJECT above.)

If you use a mail server that is unable to communicate with Dr.Web for UNIX via Milter, Spamd or Rspamd, or using the ClamAV protocol (directly using the Dr.Web ClamD component), configure the Dr.Web Firewall for Linux component so that information received via the Internet gateway, with Dr.Web for UNIX installed on it, were scanned by the SpIDer Gate network connections monitor (a transparent proxy mode).

To configure Dr.Web for UNIX, first you will need to review the current values of parameters in the configuration file in the settings section of Dr.Web MailD (the [MailD] section) and change them if necessary:

To configure the transparent proxy mode, change the value of the InputDivert parameter, which is located in the configuration file, in the section with the settings of Dr.Web Firewall for Linux (the [LinuxFirewall] section):

•<network interface>—is the name of a network interface (eth0, wlan etc.) through which inbound connections that must be checked are accepted by the mail server.

•<list of ports>—a list of hosts’ port numbers the connections of which must be aiming in order to be checked (25, 110, 143, etc.).

To view and to change the settings of Dr.Web Firewall for Linux and SpIDer Gate you can use the following means:

•The command-line-based management tool—Dr.Web Ctl (use the drweb-ctl cfshow and drweb-ctl cfset commands).

•The management web interface of Dr.Web for UNIX (by default, you can access it via a web browser at https://127.0.0.1:4443/).

It will configure Dr.Web Firewall for Linux in such a way that the data received via the eth0 network interface and directed to ports 25 (usually SMTP protocol), 110 (usually POP3 protocol) or 143 (usually IMAP protocol) will be checked by SpIDer Gate that will redirect them for check to the email scanning component Dr.Web MailD.

Moreover, it is necessary to make sure that the scan of corresponding mail protocols by SpIDer Gate is enabled (parameters InspectSmtp, InspectPop3, InspectImap are set to On).

To provide integration of Dr.Web for UNIX into the channels of email delivery that use the SSL/TLS secure connection, the following additional actions are required:

•Enable scanning of the traffic transmitted via SSL/TLS by indicating the value of the corresponding parameter by executing the command:

It is recommended that the command cfset of the tool drweb-ctl or management web interface is used, because in this case the scanning rules will change automatically. They depend on this parameter.

•Export a certificate, which will be used by Dr.Web for UNIX for integration into the protected SSL/TLS channels by executing the command (it is necessary to indicate the name of the file used for saving the certificate in the PEM format):

•Add an obtained certificate to the system list of trusted certificates and, possible, write it as the trusted certificate for mail clients and server. For details, see Appendix E of the Administrator Manual.

It is necessary to indicate the following parameters in the configuration file, in the section of the settings of Dr.Web Firewall for Linux (the [LinuxFirewall]) section):

1.Parameters of scanning of email messages and attachments detected in them (ScanTimeout, HeuristicAnalysis, PackerMaxLevel, ArchiveMaxLevel, MailMaxLevel, ContainerMaxLevel, MaxCompressionRatio) that limit the length and resource intensity of email message scanning. When a fine-grained configuration is not required, it is recommended that values for parameter data are kept in their default state.

2.Parameters of scanning of links and files in email messages by indicating the corresponding parameters Block*.

3.Indicate the parameter of the value BlockUnchecked, that defines the reaction of Dr.Web MailD to impossibility of scanning of the received email message (exceeding the set limits (see previous item), violation of email message structure, anti-virus engine error, availability of attached archives protected with a password, etc.). If this parameter is set to Yes, then in case of impossibility to scan an email message and/or its attachments, MTA will receive a setting to reject this email message.

4.To configure the filtering rules for emails in a more fine-grained way (on the basis of various conditions), you can also edit the rules RuleSet (description of rules is available in Appendix D in Administrator manual).