Rule format
Each message processing rule is specified as a string of the following type:
CONDITION stop|cont [SETTINGS]
where:
•CONDITION – condition which must be true for a message to which settings and/or actions specified in the SETTINGS part are applied.
•SETTINGS – settings and/or actions applied to a message for which CONDITION part of the rule is true.
Note that the SETTINGS part can be absent. That can be in one of the following cases:
1.If the Rule does not contain specific settings and is used for filtering;
2.If the Rule uses settings that are loaded from an external source while the CONDITION is check (Lookup from LDAP, DB, file or another source is used).
•Directive following the CONDITION part, specifies actions to be performed if the CONDITION is true for a message:
ostop – stop further search of matching Rules;
ocont – continue search Rules downwards.
If CONDITION is false for a message, the directive specified after that has no effect: Rule search continues.
|
If a rule is too long and cannot be specified on a single line, insert a "\" character at the end of the line and continue the rule on the next line. |
Rule CONDITIONs
Each of the CONDITION parts is a combination of Boolean terms:
BOOL_TERM [<log_op> BOOL_TERM]
where BOOL_TERM – Boolean term that can get either true or false value after the message parameter is checked (the parameter can be set with the [param_name:][value] expression) or identically equal to true or false. A Boolean term has the following format:
<[param_name:][value]> | true | false
param_name - parameter name, value - parameter value.
|
Do not use white spaces between the parameter name and its value (that is, after the colon character) in Boolean terms. |
Names of parameters that can be used in rule conditions are presented in the following table:
Parameter name |
Description |
Value type |
|---|---|---|
any |
Either sender's or recipient's address. Example: any:regex:*@domain.com Either sender's or recipient's address must be in the domain.com. |
|
from, sender |
Address of the message sender. Example: from:admin@domain.com Sender of the message must have the admin@domain.com address. |
|
to, rcpt |
Address of the message recipient. Example: "rcpt:ldap:///??sub?(mail=$s)" All message recipients must be found in the LDAP by the mail field |
|
block |
Object that caused a plug-in to block the message. A message is considered blocked if reject action was applied to it. In this case, the plug-in that blocked the message returns a list of strings describing the reasons for blocking (there can be more than one reason). For example, Drweb plug-in, in the event of virus (or another known threat) detection, returns the threat name. If the message was blocked for a different reason (for example, due to SkipObject event), the plug-in returns a value of the <parameter> = <value> configuration string (in the format "<parameter>: <value>"), execution of which caused the block. For example, HeadersFilter plug-in can inform that a message was blocked due to the missing header <header> specified in the MissingHeader parameter. If so, the plug-in response is as follows: "MissingHeader: <header>". Examples: 1) block:file:viruses.txt Name of the object or reason that caused the message block; must be specified in the list from the file (it is implied to be the name of the detected threat ). 2) "block:regex:.*skip.*" Description of a reason that caused the message block; must contain the "skip" substring (for example, action applied upon SkipObject event). |
|
client-ip |
IP address of the message sender (if receiving information on the sender's IP address was specified in the Maild core settings). Note that you cannot use CIDR format here. Example: client-ip:127.0.0.1 The message must be sent from the local machine. |
|
client-port |
Port of the client that sent the message. Example: client-port:1234 The message must be sent from the 1234 port. |
Port number |
server-unix-socket |
Absolute path to the Unix socket file used for receiving the connection. Example: server-unix-socket:/var/drweb/ipc/sock1 |
Path to UNIX socket |
server-ip |
IP address of the interface used by Receiver to get the message. Note that you cannot use CIDR format here. |
|
server-port |
Port of the server which accepted the connection. |
Port number |
id |
Unique identifier of Receiver that got the message (if the identifier was set in the Receiver settings). |
Identifier string |
auth |
Indicates whether the client which sent the message obtained authorization. Note that the parameter does not have an argument. Example: auth: |
Absent |
size |
Size of the message. Specify a comparison operator before the size: •!= – Not equal. •== – Equal. •< – Less than. •> – Greater than. •<= – Less or equal. •>= – Greater or equal. If a comparison operator is not specified, the default <= operator is used. Size is specified in KB, MB or GB (enter the corresponding suffix after the number - k, m, g). Example: "size:>=10m" |
Size or comparison operator |
score |
Message score. Before the size, it is required to specify the comparison operator. If not specified, the default <= operator is used. Example: "score:!=1000" |
Number or comparison operator |
Note that:
•If the parameter name is not specified in the Boolean term, the any parameter is used by default (for example, user@domain.com stop <some_settings> is equal to the following Rule: any:user@domain.com stop <some_settings>).
•If the parameter value contains white spaces or '|', '&', ')', '(' '!' '=' ',' characters, the value must be quoted. To use a '"' character within the quotation marks, escape the character with the backslash '\'.
•If the Rule contains an empty address, specify it as follows "", and do not use angle brackets (<>) for that. For example, from:"" stop scan=no.
To create composite conditions, use the following logical operators to join simple Boolean terms: AND ('&&'), OR ('||'), NOT ('!'). You can also use brackets to set priority of logical operations. Condition must contain at least one Boolean term.
Example 1:
true stop <some_settings>
Settings <some_settings> are applied unconditionally if the Rule is used during the processing (that is, the condition is true for any message). As the stop directive is specified afterwards, all subsequent rules are not used.
Example 2:
sender:test && "size:>=10k" cont scan=no
This condition is true if the message sender is "test" and the message size is greater than 10 KB. In this case, the message is passed without further check. Note the usage of quotation marks: they are necessary in this example.
Example 3:
!("rcpt:ldap:///??sub?(mail=$s)" OR auth:) stop
This Rule is applied if at least one of the recipients, specified in TO:, is not found in LDAP by mail field and the sender is not authorized.
Rule SETTINGS
SETTINGS part of a rule is a sequence of Parameter = Value pairs:
[plugin_name/]param = value, [plugin_name/]param = value ...
where plugin_name (if specified) – name of the plug-in, which parameter values are used, param – parameter name, value – parameter value.
If the plug-in name is not specified, the rule configures parameters of the main Dr.Web MailD configuration file (section name is not specified). For example, AdminMail=root@domain directive means that the value of the AdminMail parameter in the [Notifier] section of Dr.Web MailD configuration file is changed.
At least one Parameter = Value pair is required. List items are separated by commas, so if value contains a comma, enter a backslash "\" before the character to escape it.
Example 1:
sender:a@drweb.com cont headersfilter/Action = pass, vaderetro/max_size = 100k
When this rule is applied (to the a@drweb.com sender), Action = pass parameter value is used for Dr.Web HeadersFilter plug-in and the maximum size (max_size) of the message checked by Vaderetro plug-in is set to 100k. After that, search of matching subsequent Rules continues (as the cont directive is specified).
Example 2:
to:a@drweb.com cont drweb/ProcessingErrors = pass\, redirect(err@drweb.com)
Note that one ProcessingErrors parameter for Drweb plug-in is set, and this parameter has two values separated by commas (pass, redirect(err@drweb.com)). Thus, it cannot be enclosed in quotation marks as a configuration parser treats it as one value and does not split them into substrings when parsing the ProcessingErrors parameter. The comma is escaped.
Rule processing is performed in the following order: up to down and left to right, so:
•If the value of the same parameter in one Rule (SETTINGS part) is specified several times, the successive parameter value substitutes the previous one.
•If several Rules are matching, where different values are specified for the same parameter (in the SETTINGS part), the first assigned value is set and the subsequent values are ignored.
Example 3 (one Rule with several values for the same parameter):
true cont html=yes, html=no
Value of the html parameter (the parameter description is provided below) is set to no.
Example 4 (several matching rules with different parameter values):
true cont html=yes
true cont html=no
Value of the html parameter is set to yes.
Behaviour described above is relevant for all parameters except for those with additive semantics. A subsequent value for such parameter does not conflict with the previous one, but is added to it. As a result, all found parameter values are joined in a single list of values. At that, when a stop directive is specified, Rule search stops and the values gathered by that moment are assigned to the parameter. In the present document, parameters with additive semantics are marked with the 
icon in their descriptions.
Moreover, some parameters are of the cloning type. These parameters are processed for every receiver separately: that is, if different values of the parameter are specified for different message recipients, a separate copy of the message is created for each of them and corresponding settings are applied to each copy. In the present document, parameters that support cloning are marked with the 
icon in the description.
Parameters used in Rule SETTINGS
Parameters used in the SETTINGS part of a Rule, are divided into the following categories:
•parameters used in Rules only.
•parameters which values are specified in the Dr.Web MailD configuration file or configuration files of other modules or plug-ins.
In the present document, parameters that can be used in Rules, are marked with 
icon.
1. Parameters used only in Rules:
html = {logical} |
Enables or disables generation of notifications in HTML format. If the value is set to Yes, Dr.Web MailD generates notifications in HTML format; otherwise, they are generated as text. Note that this parameter does not manage DSN. |
|---|
quarantine = {logical} |
Enables or disables moving rejected messages to Quarantine. If the value is set to Yes, such messages are quarantined. Otherwise, messages cannot be move to Quarantine, even if they were rejected. |
|---|
scan = {text} |
Determines which plug-ins, specified in the [Filters] section, are used by Dr.Web MailD to check messages. If the parameter value is set to All, Dr.Web MailD uses all plug-ins. If the parameter value is set to No, Dr.Web MailD uses no plug-ins. Plug-ins are listed with a colon ":" as a delimiter. To exclude a plug-in from the list, use a minus sign "-" with no white spaces before the plug-in name. Note that if the value is set to All, plug-in names cannot be specified in the list without a minus sign, as that is useless. Examples: scan = All - use all plug-ins scan = no - do not use any plug-in scan = All:-plugin1 - use all plug-ins except for plugin1 scan = Plugin1:Plugin2 - use only Plugin1 and Plugin2 plug-ins scan = All:Plugin1 - invalid, as it is not allowed to use plug-in names without "-" after All scan = -Plugin1:All - invalid as All must be specified first scan = -Plugin1 - invalid as All is missing before the plug-in name. |
|---|
notify[.<notification type>] = {allow | block} |
This parameter configures different types of notifications. If the value is set to allow, sending notifications of the corresponding type is allowed. If the value is set to block, sending notifications of the corresponding type is blocked. If the notification type is not specified, this parameter value is applied to all notifications. What notification types are available depends on what types are supported by Dr.Web Notifier. Additionally installed plug-ins can add their own notification types. By default, the following notifications are available: •notify.Virus - notifications on detection of a virus in a message •notify.Cured - notifications on cured viruses detected in a message •notify.Skip - notification on skipped messages •notify.Archive - notifications on messages that were not checked due to archive check restrictions •notify.Error - notifications on errors that occurred during message check •notify.Rule - notification on a message blocked by a Rule •notify.License - notifications on messages that were not checked due to licence restrictions •notify.Malware - notifications on detected malicious programs. The parameter value can be followed by an optional modifier indicating what types of recipient's addresses match this parameter. You can specify several address types, separated by colons. The following modifier values (recipient's address types) are available: •sender - notifications sent to the message sender •rcpt - notifications sent to the message recipients •admin - notifications sent to the administrator •any, or a modifier is not specified - notifications sent to the addresses of any type. Examples: notify=block or notify=block (any) - block notifications of all types. notify.Virus=block (sender:admin) - block notifications sent to the administrator and message sender upon a virus detection. If for a notification of a certain type (<type>) no notify.<type> rule is found, it is assumed that the corresponding notification is disabled. Note that this parameter does not manage DSN. |
|---|
NotificationNamesMap = |
Allows mapping of used template names to the new ones. For example, the parameter can be used to generate notifications of different types depending on the envelope. As the parameter value, the following information is specified: •nameN - name of the requested notification, for which a new template file is set. For the list of names, see the notify parameter description. Besides that, you can also specify report for general report templates and dsn - for DSN. •file_nameN - part of a new template file name. The full name is composed according to the following scheme: file name is prepended with the respective prefix sender_, rcpts_, admin_, report_ or dsn, file extension is substituted with .msg. The resulting file name, e.g. sender_file_nameN.msg, is searched in the directory specified in the TemplatesBaseDir parameter value in the [Notifier] section. Example: NotificationNamesMap = virus my-virus, archive my-arch |
|---|
SenderAddress = {address1|address2|...} |
Address where the message must be sent. The address is transmitted to Sender. It is possible to specify several address separating them by the "|" character (similar to the Router parameter from the [Sender] section). When using the SenderAddress parameter in Rules of the following type: <CONDITION> cont SenderAddress = address1|address2|address3 a message that satisfies <CONDITION> is sent to the first available address from the list. That is, if address1 is unavailable, the message is sent to address2, and if that address is also unavailable - to address3. This parameter can use the following special macros: •CLIENT-IP - IP address of the client which sent the message •CLIENT-PORT - Port of the client from which sent the message •SERVER-IP - IP address served by Dr.Web MailD •SERVER-PORT - Port on which the message was received by Receiver. If Sender supports this parameter, the component transmits the message to the specified address. For example, the following rule true cont SenderAddress=inet:10025@CLIENT-IP redirects all incoming messages to the port 10025 of the host which sent the message. In the current Dr.Web MailD version, this parameter is supported only by drweb-sender module with SMTP/LMTP send method. |
|---|
|
Default parameter values, listed in the table above, are set in the[Rule]configuration file section for which the name is not specified. To ensure proper functionality of the CLIENT-IP and CLIENT-PORT macros, used in the SenderAddress parameter, specify the following parameter values: •In the [Receiver] section: RealClients = yes •In the [Maild] section: GetIpFromReceivedHeader = yes |
2. Parameters from the main configuration file which can be used in Rules:
Section |
Parameters |
|---|---|
RedirectMail MaxScore MaxScoreAction LicenseLimit EmptyFrom ProcessingErrors UseCustomReply ReplyEmptyFrom ReplyProcessingError ReplyMaxScore |
|
FilterMail
|
|
<plug-in>/log_level <plug-in>/log_ipc_level <plug-in>/syslog_facility <plug-in>/path_to_lib |
3. Plug-in parameters that can be used in Rules:
Plug-in |
Parameters |
|---|---|
HeuristicAnalysis AddXHeaders Paranoid
LicenseLimit Infected Suspicious Incurable Adware Dialers Jokes Riskware Hacktools SkipObject ArchiveRestriction ScanningErrors ProcessingErrors BlockByFilename UseCustomReply ReportMaxSize ReplyInfected ReplyMalware ReplySuspicious ReplySkipObject ReplyArchiveRestriction ReplyError ReplyBlockByFilename |
|
FullCheck NoHamFrom AddVersionHeader AddXDrwebSpamStateNumHeader AddXSpamLevel AddXHeaders CheckDelivery SubjectPrefix NotifySubjectPrefix UnconditionalSpamThreshold UnconditionalSubjectPrefix SpamThreshold UnconditionalAction Action NotifyAction SpamCustomReply
CheckForViruses AllowRussian AllowCJK UseCustomReply FromProtectedNetworkScoreAdd ProtectedNetworkReplyCacheLifeTime ReplyToProtectedNetworkScoreAdd |
|
ScanEncodedHeaders
FilterParts
Action UseCustomReply ReplyRuleFilter |
|
Encoding UseCustomReply ReplyRuleFilter
|
Note that the operational logic of the <plug-in>/use parameter is similar to the one of the scan parameter (exclude a plug-in from or include it in the list of the used plug-ins). The parameter can be also used to include or exclude plug-ins on Rule matching, as the scan parameter does not have additive semantics.
Example:
If it is required to disable Drweb and Vaderetro plug-ins with the use of two rules, then the following two Rules
to:regex:test@.* cont scan=all:-vaderetro
to:regex:test@.* cont scan=all:-drweb
result in disabling only Vaderetro plug-in (as repeated change of the scan parameter is rejected). However, if the second Rule is changed as follows:
to:regex:test@.* cont scan=all:-vaderetro
to:regex:test@.* cont drweb/use=no
Vaderetro plug-in will be disabled after appliance of the first Rule and Drweb plug-in will be disabled after appliance of the second one. The same effect can be reached if scan=all:-vaderetro is substituted to vaderetro/use=no in the SETTINGS part of the fist Rule.
In the SETTINGS part of a Rule, you can use parameter values set in a named settings group (specified as a [Rule:<section name>] section in the main configuration file). For that purpose, specify the rule=<group name> directive. In the current Dr.Web MailD version, no more than one rule parameter can be used (for examples, refer to [Rule] section description).