Configuration Parameters

The component uses configuration parameters which are specified in the [MailD] section of the integrated configuration file of Dr.Web for UNIX Mail Servers.

LogLevel

{logging level}

Logging level of the component.

If the parameter value is not specified, the DefaultLogLevel parameter value from the [Root] section is used.

Default value: Notice

Log

{log type}

Logging method of the component.

Default value: Auto

ExePath

{path to file}

Path to the executable file of the component.

Default value: <opt_dir>/bin/drweb-maild

•For Linux, Solaris: /opt/drweb.com/bin/drweb-maild

•For FreeBSD: /usr/local/libexec/drweb.com/bin/drweb-maild

RunAsUser

{UID | user name}

The parameter determines under which user name the component should be run. The user name can be specified either as the user’s number UID or as the user’s login. If the user name consists of numbers (i.e. similar to number UID), it is specified with the “name:” prefix, for example: RunAsUser = name:123456.

When a user name is not specified, the component operation terminates with an error after the startup.

Default value: drweb

FixedSocketPath

{path to file}

Path to the UNIX socket of the fixed component copy.

If this parameter is specified, the Dr.Web ConfigD configuration daemon checks that there is always a running component copy that is available to the clients via this socket.

Default value: (not set)

DnsResolverConfPath

{path to file}

Path to the subsystem configuration file of domain name permissions (DNS resolver).

Default value: /etc/resolv.conf

TemplatesDir

{path to directory}

Path to the directory that contains the templates for emails returned to the user in case of email blocking.

Default value: <var_dir>/templates/maild

•For Linux, Solaris: /var/opt/drweb.com/templates/maild

•For FreeBSD: /var/drweb.com/templates/maild

TemplateContacts

{string}

Administrator contacts of Dr.Web for UNIX Mail Servers for the insertion in the messages about threats (used in message templates).

The contact information will be added to the repacked messages only if it gets an attachment with a password protected archive with threats and other unwanted objects removed from the initial message. If, according to the current value of the RepackPassword parameter (see below), attached archives are not protected with a password, then contact information is not added to the modified message.

Default value: (not set)

ReportLanguages

{string}

Languages used for generation of service mail messages (for example, mail messages returned to the sender in case of email blocking). Each language is identified by two-letter designation (en, ru, etc.).

You can specify a list as the parameter value. The values in the list must be separated with commas (each value in the quotation marks). The parameter can be specified more than once in the section (in this case, all its values are combined into one list).

Example: Add to the list the following languages: ru and de.

1.Adding of values to the configuration file.

•Two values in one string

[MailD]
ReportLanguages = "ru", "de"

•Two strings (one value per a string)

[MailD]
ReportLanguages = ru
ReportLanguages = de

2.Adding values via the command drweb-ctl cfset.

# drweb-ctl cfset MailD.ReportLanguages -a ru
# drweb-ctl cfset MailD.ReportLanguages -a de

Default value: en

RepackPassword

{None | Plain(<password>) | HMAC(<secret>)}

The method for generation of a password for archives with malicious objects placed in messages and sent to recipients. The following methods are allowed:

•None—archives will not be protected with password (not recommended).

•Plain(<password>)—all archives will be protected with the same password <password>.

•HMAC(<secret>)—the unique password will be generated for each archive based on the pair(<secret>, <message identifier>).

To restore the password that protects an archive using message identifier and known secret, it is possible to use the following command: drweb-ctl idpass.

By default, for this parameter, value None is set which is recommended for changing in the course of the product configuration.

Default value: None

MilterSocket

{path to file | IP address:port}

Socket for connection to MTA as Milter filter of mail (MTA will connect to this socket when using Dr.Web MailD as the corresponding filter). Usage of the UNIX socket or network socket is allowed.

The processing rules for messages received for scanning via Milter are set in the MilterRuleSet parameter (look below).

Default value: (not set)

MilterBlockUnchecked

{Boolean}

Block transmission of an email message received for scanning via Milter, if its contents could not be scanned.

Default value:

MilterBlockUnchecked = No

MilterScanTimeout

{time interval}

Timeout for scanning one email message initiated by Dr.Web MailD, if the email message was received for scanning from MTA via Milter.

A value in the range from 1s to 1h can be specified

Default value: 3m

MilterHeuristicAnalysis

{On | Off}

Indicates whether heuristic analysis is used for detection of unknown threats during email message scanning initiated by Dr.Web MailD, if an email message has been received for scanning from MTA via Milter.

Heuristic analysis provides higher detection reliability but, at the same time, it increases time of virus scanning.

Allowed values:

•On—instructs to use heuristic analysis when scanning.

•Off—instructs not to use heuristic analysis.

Default value: On

MilterPackerMaxLevel

{integer}

Maximum nesting level when scanning packed objects. All objects at a deeper nesting level are skipped during email message scanning initiated by Dr.Web MailD, if an email message for scanning is received from MTA via Milter.

A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.

Default value: 8

MilterArchiveMaxLevel

{integer}

Maximum nesting level when scanning archives. All objects at a deeper nesting level are skipped during email message scanning initiated by Dr.Web MailD, if an email message for scanning is received from MTA via Milter.

A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.

Default value: 8

MilterMailMaxLevel

{integer}

Maximum nesting level when scanning email messages and mailboxes. All objects at a deeper nesting level are skipped during email message scanning initiated by Dr.Web MailD, if an email message for scanning is received from MTA via Milter.

A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.

Default value: 8

MilterContainerMaxLevel

{integer}

Maximum nesting level when scanning other containers (such as HTML pages). All objects at a deeper nesting level are skipped during email message scanning initiated by Dr.Web MailD, if an email message for scanning is received from MTA via Milter.

A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.

Default value: 8

MilterMaxCompressionRatio

{integer}

Maximum compression ratio of compressed/packed objects (ratio between the uncompressed size and the compressed size). If the ratio of an object exceeds the limit, this object will be skipped during email message scanning procedures initiated by Dr.Web MailD, if an email message for scanning is received from MTA via Milter.

The compression ratio must not be smaller than 2.

Default value: 500

SpamdSocket

{path to file | IP address:port}

Socket for connection to MTA as Spamd filter of mail (MTA will connect to this socket when using Dr.Web MailD as the corresponding filter). Usage of the UNIX socket or network socket is allowed.

The processing rules for messages received via Spamd are set in the SpamdRuleSet parameter (look below).

Default value: (not set)

SpamdBlockUnchecked

{Boolean}

Block transmission of an email message received for scanning via Spamd, if its contents could not be scanned.

Default value: No

SpamdScanTimeout

{time interval}

Timeout for scanning one email message initiated by Dr.Web MailD, if the email message was received for scanning from MTA via Spamd.

A value in the range from 1s to 1h can be specified

Default value: 3m

SpamdHeuristicAnalysis

{On | Off}

Heuristic analysis provides higher detection reliability but, at the same time, it increases time of virus scanning.

Allowed values:

•On—instructs to use heuristic analysis when scanning.

•Off—instructs not to use heuristic analysis.

Default value: On

SpamdPackerMaxLevel

{integer}

A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.

Default value: 8

SpamdArchiveMaxLevel

{integer}

A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.

Default value: 8

SpamdMailMaxLevel

{integer}

A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.

Default value: 8

SpamdContainerMaxLevel

{integer}

A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.

Default value: 8

SpamdMaxCompressionRatio

{integer}

The compression ratio must not be smaller than 2.

Default value: 500

RspamdSocket

{path to file | IP address:port}

Socket for connection to MTA as Rspamd filter of mail (MTA will connect to this socket when using Dr.Web MailD as the corresponding filter). Usage of the UNIX socket or network socket is allowed.

The processing rules for messages received via Rspamd are set in the RspamdRuleSet parameter (look below).

Default value: (not set)

RspamdBlockUnchecked

{Boolean}

Block transmission of an email message received for scanning via Rspamd, if its contents could not be scanned.

Default value: No

RspamdScanTimeout

{time interval}

Timeout for scanning one email message initiated by Dr.Web MailD, if the email message was received for scanning from MTA via Rspamd.

A value in the range from 1s to 1h can be specified

Default value: 3m

RspamdHeuristicAnalysis

{On | Off}

Heuristic analysis provides higher detection reliability but, at the same time, it increases time of virus scanning.

Allowed values:

•On—instructs to use heuristic analysis when scanning.

•Off—instructs not to use heuristic analysis.

Default value: On

RspamdPackerMaxLevel

{integer}

A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.

Default value: 8

RspamdArchiveMaxLevel

{integer}

A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.

Default value: 8

RspamdMailMaxLevel

{integer}

A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.

Default value: 8

RspamdContainerMaxLevel

{integer}

A value in the range from 0 to 60 can be specified. If the value is set to 0, nested objects are not scanned.

Default value: 8

RspamdMaxCompressionRatio

{integer}

The compression ratio must not be smaller than 2.

Default value: 500

In addition to the parameters listed above, the settings section also contains three sets of rules <Interface>RuleSet* (<Interface>RuleSet0, …, <Interface>RuleSet8), which directly control scanning of email messages received via this interface (<Interface> – interface type: Milter, Spamd or Rspamd). For some values in conditions (for example, IP address ranges, lists of website categories, black and white lists of web sources, etc.), there is a substitution of values loaded from text files and also extracted from external data sources via LDAP (Dr.Web LookupD component is used). When configuring email messages the whole list of rules for the interface that was used for receiving the message is checked in the ascending order, until the rule containing the ultimate resolution is found. The gaps in the rule list are ignored.

In case of operation of Dr.Web MailD in the mode of transparent proxy (i.e. during the operation between two MTA or between MTA and MUA via the following protocols: SMTP, POP3, IMAP), the rules specified in the settings of the Dr.Web Firewall for Linux are used.

For easy editing of the rules list gaps are left, i.e. RuleSet<i> sets that do not contain the rules. Note that you cannot add the items other than RuleSet0, …, RuleSet6, but you can add and to remove any rule in any element of RuleSet<i>. Viewing and editing rules can be performed in any of the following ways:

•by viewing and editing the configuration file configuration file (in any text editor) (note that this file stores only those parameters which value is different from the default ones);

•via the command-line-based interface—Dr.Web Ctl (drweb-ctl cfshow and drweb-ctl cfset commands).

The use of the drweb-ctl cfset command to edit the rules (hereinafter the <rule>—text of the rule).

When you use the drweb-ctl tool to edit the list of rules, enclose the text of your added rule into single or double quotes, and use backward slashes ('\') as escape characters before any double quotes within the text of the rule—if the text of the rule itself happens to contain double quotes.

It is important to remember the following storage features of rules in RuleSet<i> variables of the configuration:

•The conditional part and colon can be omitted when adding unconditional rules. However, such rules are always stored in the list of rules as a string “ : <action>”;

•When adding rules that contain several actions (such rules as '<condition> : <action 1>, <action 2>'), such rules will be modified into a chain of elementary rules '<condition> : <action 1>' and '<condition> : <action 2>'.

•The logging or rules does not allow for disjunction (logical “OR”) of conditions in the conditional part, so, in order to implement the logical “OR”, the chain of rules should be logged with each rule having a disjunct-condition in its condition.

To add an unconditional rule for skipping the connections (the PASS action) to the MailD.MilterRuleSet1 set, you only need to execute the following command:

However, to remove this rule from the specified rule set, it is required to execute the following command:

To add the MailD.MilterRuleSet1 rule to the rule set that changes a path to standard templates for connections from unresolved addresses and performs blocking, it is necessary to execute the following command:

However, this command will add two rules to the specified set, so, in order to remove them from the set of rules, you need to execute two following commands:

To add to the MailD.MilterRuleSet1 rule set such rule as “Block if a malicious object KnownVirus or URL from the category Terrorism are detected”, it is necessary to add the following two rules to this rule set:

To remove them from the set of rules, you also need to execute two commands, as it is shown in the example above.

By default, the following set of rules is defined for each interface for interaction with MTA.

Concordance of threat categories used in rules of Dr.Web for UNIX Mail Servers (for the threat_category variable) with threat categories used in the product version 6 and earlier is presented in the table:

Important! To ensure that emails from the indicated domains are not scanned indeed, this rule must be listed higher that any rule related to scanning (i.e. rules that contain such conditions as threat_category, url, url_category, total_spam_score).

In this case, the file /etc/file1 must contain regular expressions (one expression per line), for example:

3.Reject all emails from the domains listed in files /etc/file1 and /etc/file/2 (a verdict Message from a BAD domain will be forwarded to MTA)

4.Scan for threats those emails that were send to the domains example.com and example.org, the rest of the emails skip without scanning:

Important! To ensure that emails from the indicated domains are definitely scanned, below this rule in the list of rules there must be rules related to scanning (i.e. rules that contain such conditions as threat_category, url, url_category, total_spam_score).

5.Scan for spam those emails that were sent from domains example.com and example.org, do not scan the rest of the emails:

Important! To ensure that emails received not from the indicated domains are definitely not scanned, below this rule in the list of rules there must be no rules related to scanning (i.e. rules that contain such conditions as threat_category, url, url_category, total_spam_score).

The examples listed above can be added to the list of rules for any interface conjugated with MTA besides Spamd, because this interface does not provide data of the SMPT session, so the use of conditions smtp_mail_from and smtp_rcpt_to is pointless.