Configuration Parameters

Top  Previous  Next

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

The section contains the following parameters:

LogLevel = {logging level}

Logging level.

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

Default value:

LogLevel = Notice

Log = {log type}

Logging method.

Default value:

Log = Auto

ExePath = {path to file}

Path to the executable file of the component.

Default value:

ExePath = <opt_dir>/bin/drweb-maild

For Linux:

ExePath = /opt/drweb.com/bin/drweb-maild

For FreeBSD:

ExePath = /usr/local/libexec/drweb.com/bin/drweb-maild

For Solaris:

ExePath = /opt/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:

RunAsUser = drweb

FixedSocketPath = {path to file}

Path to the UNIX socket of the fixed component copy.

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

Default value:

FixedSocketPath =

DnsResolverConfPath = {path to file}

Path to the configuration file of domain names resolving subsystem (DNS resolver).

Default value:

DnsResolverConfPath = /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:

TemplatesDir = <var_dir>/templates/maild

For Linux:

TemplatesDir = /var/opt/drweb.com/templates/maild

For FreeBSD:

TemplatesDir = /var/drweb.com/templates/maild

For Solaris:

TemplatesDir = /var/opt/drweb.com/templates/maild

TemplateContacts = {string}

Administrator contacts of Dr.Web for UNIX 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:

TemplateContacts =

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. The parameter can be specified more than once in the section (in this case, all its values are combined into one list).

Default value:

ReportLanguages = 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:

RepackPassword = None

MilterSocket = {path to file | IP: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:

MilterSocket =

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:

MilterScanTimeout = 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:

MilterHeuristicAnalysis = 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

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

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

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

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

SpamdSocket = {path to file | IP: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:

SpamdSocket =

SpamdBlockUnchecked = {boolean}

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

Default value:

SpamdBlockUnchecked = 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:

SpamdScanTimeout = 3m

SpamdHeuristicAnalysis = {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 Spamd.

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:

SpamdHeuristicAnalysis = On

SpamdPackerMaxLevel = {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

SpamdArchiveMaxLevel = {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

SpamdMailMaxLevel = {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

SpamdContainerMaxLevel = {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

SpamdMaxCompressionRatio = {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

RspamdSocket = {path to file | IP: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:

RspamdSocket =

RspamdBlockUnchecked = {boolean}

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

Default value:

RspamdBlockUnchecked = 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:

RspamdScanTimeout = 3m

RspamdHeuristicAnalysis = {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 Rspamd.

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:

RspamdHeuristicAnalysis = On

RspamdPackerMaxLevel = {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

RspamdArchiveMaxLevel = {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

RspamdMailMaxLevel = {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

RspamdContainerMaxLevel = {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

RspamdMaxCompressionRatio = {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

Rules

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

For Milter (MilterRuleSet0, ..., MilterRuleSet8)

MilterRuleSet0 =
MilterRuleSet1 = : set MailTemplatesDir = "milter"
MilterRuleSet2 =
MilterRuleSet3 = total_spam_score gt 0.80 : REJECT
MilterRuleSet4 =
MilterRuleSet5 = threat_category in (KnownVirus, VirusModification, UnknownVirus, Adware, Dialer) : REPACK as _match
MilterRuleSet6 =
MilterRuleSet7 = url_category in (InfectionSource, NotRecommended, OwnersNotice) : REPACK as _match
MilterRuleSet8 =

For Spamd (SpamdRuleSet0, ..., SpamdRuleSet8)

SpamdRuleSet0 =
SpamdRuleSet1 = : set MailTemplatesDir = "spamd"
SpamdRuleSet2 =
SpamdRuleSet3 = threat_category in (KnownVirus, VirusModification, UnknownVirus, Adware, Dialer) : REJECT
SpamdRuleSet4 =
SpamdRuleSet5 = url_category in (InfectionSource, NotRecommended, OwnersNotice) : REJECT
SpamdRuleSet6 =
SpamdRuleSet7 = total_spam_score gt 0.80 : REJECT
SpamdRuleSet8 =

For Rspamd (RspamdRuleSet0, ..., RspamdRuleSet8)

RspamdRuleSet0 =
RspamdRuleSet1 = : set MailTemplatesDir = "rspamd"
RspamdRuleSet2 =
RspamdRuleSet3 = threat_category in (KnownVirus, VirusModification, UnknownVirus, Adware, Dialer) : REJECT
RspamdRuleSet4 =
RspamdRuleSet5 = url_category in (InfectionSource, NotRecommended, OwnersNotice) : REJECT
RspamdRuleSet6 =
RspamdRuleSet7 = total_spam_score gt 0.80 : REJECT
RspamdRuleSet8 =

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 are created in the settings of the Dr.Web Firewall component for Linux.

If Dr.Web ASE, the component for email message scanning for signs of spam, is unavailable, then email message scanning for signs of spam is not performed. In this case, rules that contain scanning of spam level (value total_spam_score) are unavailable in sets RuleSet for all interfaces.

When processing email messages, the whole list of rules is checked downwardly, until the rule containing the ultimate resolution is found. The gaps in the rule list are ignored. They serve for quick and convenient editing of the list by adding any necessary rules in these gaps and deleting the rules, if necessary. Note that you cannot add your own RuleSets to the provided <Interface>RuleSet* list, but you can add any rule into any <Interface>RuleSet (using the following commands:

# drweb-сtl cfset MailD.<Interface>RuleSet<i> "<rule>"

and

# drweb-сtl cfset MailD.<Interface>RuleSet<i> -a "<rule>"

where <Interface> is the interface type (Milter, Spamd, Rspamd), <i> is the number of the set RuleSet, and <rule> is the text of your added rule. When you use the drweb-ctl tool to edit the list of rules, enclose the text of your added rule into 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.

For some values in the rule conditions (for example, IP adresses ranges, web resource category names, white and black list of websites, etc.), loading values from a text file or from external data sources via the LDAP (Dr.Web LookupD component is used) is allowed. For more information, refer to “Rules for Traffic Monitoring” in the Appendix D of the Administrator Manual.