|
Special Cases |
|
Processing messages with several recipients If a message has different recipients and Rules set different parameter values for them (for example, a rule setting html=no matches one recipient, and a rule setting html=yes matches another), the conflict is resolved in the following way: 1.If the parameters, which have different values specified for different recipients, allow cloning, the message is cloned (separate message copies are created and sent to the corresponding recipient). Each copy has the parameter value set for its recipient. 2.If the parameter does not allow message cloning, different parameter values for different recipients are substituted with the same parameter value from the corresponding section of configuration file settings. If the parameter is not specified in the configuration file, the default value is used. 3.If the same rule matches all the recipients or in the matching rules the parameter value is the same, this value is used. Note that if parameter values are not changed in the Rules, values for these parameters are taken from the corresponding configuration file. For those parameters, values of which are not specified in the configuration file, default values are used. The message is sent for check to all plug-ins, specified in the [Filters] section, except for those indicated in Rules as not used (<plug-in>/use = no or scan=all:-<plug-in>). Example 1: a) The following two rules are specified: [Rules] b) Message with the following headers is processed: FROM: <another_user@externaldomain.com> In this case, the message is not cloned, as setting of Drweb plug-in specified for Suspicious is taken from the plugin_drweb.conf configuration file. This is because settings for recipients are different and the drweb/Suspicious parameter is not of the cloning type. Example 2: a) The following three rules are set: [Rules] b) The processed message is the same as in the previous example: FROM: <another_user@externaldomain.com> Only the last rule is applied to the message, as drweb/Suspicious does not have additive semantics and is not of the cloning type. Thus, different settings specified in the first two rules cause the value to reset to the default. The third rule is also applied to the message and sets the reject,add-header(BLA:BLA) value to the drweb/Suspicious parameter. Example 3: a) The following Rules are set: [Rules] b) Default settings for MailD notifications sending are: ... c) The following infected message is processed: FROM: <root@domain.ru> As all notifications are sent from the address specified in FilterMail, the following 5 notifications are sent: oFrom <drweb@domain.ru> to the administrator <admin@domain.ru>; oFrom <drweb@domain.ru> to the sender <root@domain.ru>; oFrom <drweb@domain.ru> to the recipient <user1@domain.ru>; oFrom <drweb@domain.ru> to the recipient <user2@domain.ru>; oFrom <drweb@domain.ru> to the recipient <user3@domain.ru>. Administrator with the <admin@domain.ru> address receives notifications in Russian and Japanese languages, sender with the <root@domain.ru> address - in English language, and all users (<user1@domain.ru>, <user2@domain.ru>, <user3@domain.ru>) - in Japanese language. Note that the from:root@domain.ru cont NotifyLangs=ru rule is not applied in this example as when sending notifications to <root@domain.ru>, the address is treated as the notification recipient's address, so notifications are generated with the use of the default language file (in English language). If it is required to use Russian language for notifications, specify the following Rule: to:root@domain.ru cont NotifyLangs=ru Rules with implicit SETTINGS part As mentioned above, SETTINGS part of a rule can be absent. If so, parameters are requested directly from the server with the use of Lookup specified in the CONDITION part. It can be useful, for example, when working with LDAP or databases. Example: to:regex:.*@drweb.com && "ldap:///?drwebRules?sub?(mail=$s)" cont In this Rule, if a recipient is in the drweb.com domain and sender or all the recipients satisfy the LDAP condition mail=$s, parameters in the SETTINGS part are substituted from the drwebRules field of the LDAP request. Values are substituted for every new message and then are cashed while the message is checked - thus, a user can change settings in "hot" mode without server restart. Note that Lookup to LDAP is enclosed in quotation marks because of the brackets used in the Lookup. Fields returned by drwebRules, must be correct SETTINGS strings (that is <parameter>=<value>[, <parameter>=<value>, ...]). For example, if stored in a database table, they must be of the following type: Example:
Also note that if SETTINGS part is specified in the Rule and CONDITIONS part contains Lookup that retrieves settings from a data source, these settings are to be joined (concatenated) to the SETTINGS on the left (first, settings retrieved from the source are specified and then those which are set directly in the SETTINGS part of a Rule). It is important to note in case of a conflict between different values of the same parameter inserted into the Rule from different sources. Example: a) Let us assume that a table in the database, access to which is configured using ODBC, is of the following type:
b) In the configuration file, the following Rule is specified: "to:odbc:select Rules from table where Address='$s'" cont modifier/LocalRules = select message\, append_text "text from rule", modifier/LocalRules = quarantine In this case, when the Rule is matching, the following SETTINGS are applied for the message sent to test1@drweb.com: modifier/LocalRules = select message, append_text "text from DB", select message, append_text "text from rule", quarantine Note that the modifier/LocalRules parameter has additive semantics and new values do not reset the previous ones but are added separated by commas. If the message has other recipients, except test1@drweb.com, for which other modifier/LocalRules values are specified in the database (or the values are not specified at all), all modifier/LocalRules values from the database are ignored for all of the recipients. Only the settings set in the Rule are used (the same value for all the recipients): select message, append_text "text from rule", quarantine When necessary, you can override OnError and SkipDomains settings of the used data source. Example: to:ldap:onerror=exception|skipdomains=file:/etc/drweb/skipdomains.list|///?description?sub?(cn=$u) cont According to the specified condition, all names of the message recipients (username part in the username@domain address), according to the used $u macro, must be taken from LDAP. However, SkipDomains setting is also specified in the Lookup and instructs to skip domains without request (domain part in the address) that are found in the /etc/drweb/skipdomains.list file. Thus, the rule is processed as follows: 1.List of recipients is retrieved from the message (field To:). 2.Address of another recipient is taken. 3.Domain membership to the list of domains to be skipped without request is verified. If so, the next address in the list is checked (step 2). If not, LDAP request is executed. Note that if the message is sent to one recipient, and the domain is in the list of skipped domains, this rule forms no settings for the message. 4.If the request result is positive, content of description field is used as a setting (concatenated on the left to the settings retrieved earlier), then step 2 is executed. Otherwise, if the request result is negative (user name is not found in the data source), the Rule condition is false for the message, this Rule is rejected and all settings retrieved from LDAP are discarded. Remaining requests to LDAP are not performed. 5.If LDAP request fails, that is considered as a message processing error. Processing of this message stops and, according to OnError=exception setting, action specified in the ProcessingErrors ([Maild] section) parameter is performed. For more information on how errors are handled in Rules, see below. As the cont directive is specified and no errors occurred, viewing of other rules continues. Note that if the message is sent to several recipients and different parameter values are retrieved for them from LDAP, the setting values are either determined after cloning of the message or substituted with parameter values from the configuration file (as described above in the Processing messages with several recipients paragraph). Joining Rule settings from different data sources As described at the beginning of this section, values of required parameters are retrieved from Rules stored in the built-in database, then - from Rules specified in the [Rules] section, and after that - from the configuration file. Let us consider an example which illustrates joining of settings retrieved from different sources according to the described algorithm. Example: a) Let us assume that the following Rules are specified for the test@drweb user in the built-in database: > email-info test@drweb.com Three processing Rules relate to test@drweb.com address; at that, the third rule has implicit SETTINGS part that checks condition using Lookup and imports selected set (rules field value) as the SETTINGS part of the Rule. The Rule uses data from the maild database table; access to this table is also configured via ODBC. b) Let us assume that the table entry which relates to test@drweb.com address is as follows:
c) And let us also assume that the following Rule is specified in the [Rules] section of the main configuration file: [Rules] In this case, the following procedure is performed for the message with the test@drweb.com sender address: 1)At first, Rules from the built-in database are applied. As they are identically true (true is specified as condition), their values are used. Moreover, the modifier/LocalRules parameter has additive semantics and values from the Rules are sequentially concatenated. 2)According to the third Rule, rules field value for the test@drweb.com address is queried from the database. The received value is added to the current concatenated parameter value. 3)As stop directive did not occur and the modifier/LocalRules parameter has additive semantics, true Rules in the [Rules] section of the configuration file are searched. Found values of the modifier/LocalRules parameter are concatenated. As the result, for the message sent to test@drweb.com, the modifier/LocalRules parameter has the following concatenated value: modifier/LocalRules = select message, append_text "Scanned! (1)", quarantine, select message, append_text "Scanned! (2)", select message, append_text "Scanned! (3)", select message, append_text "Scanned! (4)", quarantine |