Operating Principles

There are three ways the component can protect emails:

1.The connection to the mail server (Sendmail, Postfix, Exim, and so on) as an external email filter (using any of the following extensions: Milter, Spamd, Rspamd, supported by the mail server), or in SMPT (Postfix) mode.

2.The connection to the mail server for email attachment scan when integrated with Dr.Web vxCube in BCC mode (using any MTA that supports sending of a hidden copy of a letter).

3.Setting up proxy that performs scanning of emails transferred via SMTP, POP3 or IMAP4 protocols transparently for the mail server. To set up this scanning method, SpIDer Gate and Dr.Web Firewall for Linux are used. As these components operate only with GNU/Linux, this method is available only for this family of operating systems.

The scanned email messages are processed according to the rules that are set in the component settings. For each interface used for interaction with mail servers, the own rule set for email message processing can be specified. In case of usage of the proxy mechanism (i.e. during the scanning of email messages received directly via the protocols SMTP, POP3, IMAP), the component uses the processing rules determined in the settings of Dr.Web Firewall for Linux.

For scanning the URLs in email messages, the same databases of web resource categories as in SpIDer Gate component, are used. Dr.Web CloudD component is used to refer to Dr.Web Cloud service (the use of the cloud service is configured in Dr.Web for UNIX Mail Servers common settings and can be disabled, if necessary). To check transmitted data, Dr.Web MailD uses the Dr.Web Network Checker component. The latter one initiates scanning via the Dr.Web Scanning Engine scan engine.

Scanning email attachments for malicious code can be performed directly by Dr.Web MailD or Dr.Web vxCube, if they have been integrated.

Processing of email messages, received from MTA via Milter, Spamd and Rspamd interfaces (in filter mode) is implemented by calling a special processing procedure (hook), written in Lua. During this procedure, according to the results of the analysis of all available information about the message (sender, recipient, internal structure, header values, spam score), the decision whether message is rejected or passed. For the Milter interface, the processing procedure returns an action (“pass”, “reject”, “return an error to sender”, and so on) that MTA should apply to the message. In the case of a “pass” as part of the verification procedure, the letter may also undergo changes such as adding headers or modifying them, placing malicious parts of the message in a password-protected archive (i.e. repacking). For Spamd and Rspamd interfaces that do not support modification of messages being scanned, the verdict is returned to MTA in form of a “spam rate” assigned to the letter and a threshold for recognizing the letter as spam (to reject the letter from MTA, the rate must exceed the threshold). In addition to the rate, the text verdict (report or action, depending on the protocol) is returned to MTA, which can be analyzed in MTA settings.

The flexibility of Lua and a large set of message information available from processing procedure allow to perform not only typical spam checks with a score received from Dr.Web Anti-Spam, search for attached threats or malicious URLs, but also implement a check of arbitrary conditions with working out the necessary verdicts for email message processing by the mail server. The description of verification procedures and examples of procedures, see Email Processing in Lua section.

For messages analysis on presence of signs of spam, Dr.Web MailD uses the special component Dr.Web Anti-Spam.