|
Особые случаи Правил |
|
Обработка писем с несколькими получателями В случае если письмо имеет несколько получателей, для которых одни и те же параметры в результате срабатывания разных Правил получают различные значения (например, для одного сработало Правило, содержащее настройку html=yes, а для другого – html=no), то возникающие противоречия разрешаются следующим образом: 1.Если параметры, получившие разное значение для различных получателей, указанных в письме, допускают клонирование, то письмо клонируется (создаются независимые копии письма, каждое из которых будет направлено конкретному получателю), к каждой копии применяются свое значение этого параметра. 2.Если параметр не допускает клонирования письма, то разные значения параметра для разных получателей заменяются на единственное значение этого параметра, извлекаемое из соответствующей секции настроек конфигурационного файла, или значение параметра по умолчанию, если он не задан в конфигурационном файле. 3.Если для всех получателей письма сработало одно и то же Правило, или во всех сработавших Правилах этот параметр имеет одно и то же значение, то для письма используется единое значение параметра, взятое из сработавших Правил. Обратите внимание, что при обработке письма для всех параметров, не измененых в сработавших Правилах, будут использованы значения, указанные в конфигурационных файлах. Для параметров, значения которых не указаны в конфигурационном файле, будут использованы значения по умолчанию. Письмо будет отправлено на проверку всем подключаемым модулям, указанным в секции [Filters], за исключением тех, которые указаны в сработавших Правилах, как пропускаемые (<plug-in>/use = no или scan=all:-<plug-in>). Пример 1: a) Имеется 2 Правила: [Rules] b) Обрабатывается письмо со следующими заголовками: FROM: <another_user@externaldomain.com> В этом случае клонирования письма не происходит – при его обработке используется настройка для Suspicious подключаемого модуля Drweb по умолчанию из конфигурационного файла plugin_drweb.conf. Это связано с тем, что настройки для получателей различны, а различие значений параметра drweb/Suspicious клонирования не вызывает (он не относится к перечню «клонирующих» параметров). Пример 2: a) Имеется 3 Правила: [Rules] b) Обрабатывается то же самое письмо, что и в предыдущем примере: FROM: <another_user@externaldomain.com> К письму будет применено только последнее Правило, т.к. параметр drweb/Suspicious не относится к параметрам с накапливающей семантикой и не является клонирующим, и потому по первым двум правилам из-за различных его значений для обоих получателей он сбросится в значение по умолчанию, но третье правило также сработает для этого письма, и присвоит параметру drweb/Suspicious значение reject,add-header(BLA:BLA). Пример 3: a) Имеется набор Правил: [Rules] b) Настройки отправки уведомлений MailD по умолчанию следующие: ... c) Обрабатывается зараженное письмо: FROM: <root@domain.ru> Поскольку все уведомления отправляются от лица адреса, указанного в FilterMail, то будет отправлено пять уведомлений: oОт <drweb@domain.ru> администратору <admin@domain.ru>; oОт <drweb@domain.ru> отправителю <root@domain.ru>; oОт <drweb@domain.ru> получателю <user1@domain.ru>; oОт <drweb@domain.ru> получателю <user2@domain.ru>; oОт <drweb@domain.ru> получателю <user3@domain.ru>. При этом администратор <admin@domain.ru> получит уведомления на русском и японском, отправитель <root@domain.ru> получит уведомление на английском, а все получатели (<user1@domain.ru>, <user2@domain.ru>, <user3@domain.ru>) получат уведомления на японском. Обратите внимание, что Правило from:root@domain.ru cont NotifyLangs=ru в данном случае не применимо, так как при посылке уведомления отправителю адрес <root@domain.ru> выступает в качестве получателя уведомления (поэтому для этого уведомления будет использован языковой файл, указанный по умолчанию – en). Поэтому если нужно, чтобы ему приходили уведомления на русском, верным будет написать Правило to:root@domain.ru cont NotifyLangs=ru Правила с неявной частью SETTINGS Как уже упоминалось выше, секцию SETTINGS в Правилах можно не указывать. В этом случае предполагается, что параметры можно запросить непосредственно с сервера при помощи Lookup, заданной в части CONDITION. Это полезно, например, при работе с LDAP или с базами данных. Пример: to:regex:.*@drweb.com && "ldap:///?drwebRules?sub?(mail=$s)" cont В этом Правиле, если получатель находится в домене drweb.com, и отправитель или все получатели удовлетворяют LDAP-условию mail=$s, то параметры в SETTINGS-часть Правила будут подставлены из поля drwebRules LDAP-запроса. Загрузка происходит для каждого нового письма, и затем кешируется на время его проверки – таким образом пользователь может менять свои настройки в "горячем" режиме, не перезапуская сервер. Пожалуйста, обратите внимание, что Lookup к LDAP заключен в кавычки: это связано с присутствием в нем скобок. Возвращаемые полем drwebRules поля должны представлять собой корректные строки SETTINGS (т.е. <parameter>=<value>[, <parameter>=<value>, ...]). Например, если они хранятся в некоторой таблице базы данных, то они должны иметь следующий вид: Пример:
Также обратите внимание, что если часть SETTINGS в Правиле присутствует, а в условии CONDITIONS стоит выражение Lookup, извлекающее некоторые настройки из источника данных, то извлеченные при срабатывании Правила настройки будут присоединены (конкатенированы) к уже имеющейся части SETTINGS слева (сначала пойдут настройки, извлеченные из источника, а потом те, которые записаны непосредственно в SETTINGS-части Правила). Это важно иметь в виду в случае возможного конфликта разных значений одного и того же параметра, вставленных в Правило из разных мест. Пример: a) Допустим, таблица table в базе данных, доступ к которой настроен через ODBC, имеет следующий вид:
b) В конфигурационном файле задано следующее Правило: "to:odbc:select Rules from table where Address='$s'" cont modifier/LocalRules = select message\, append_text "text from rule", modifier/LocalRules = quarantine В этом случае, при срабатывании Правила, с учетом всех настроек, если письмо идет получателю test1@drweb.com, то для него будут использоваться следующие настройки (SETTINGS): modifier/LocalRules = select message, append_text "text from DB", select message, append_text "text from rule", quarantine Обратите внимание, что поскольку параметр modifier/LocalRules имеет "накапливающий" характер, то новые значения этого параметра в Правиле не затирают предыдущие, а добавляются в список через запятую. Если в письме кроме test1@drweb.com есть еще получатели, и для них в базе данных указаны другие значения modifier/LocalRules (или они вообще не указаны), то все значения modifier/LocalRules из базы данных будут проигнорированы для всех получателей. Будет использоваться только та часть настроек, которая задана в Правиле (значение совпадает для всех получателей): select message, append_text "text from rule", quarantine При необходимости в используемых Lookup можно локально переопределять настройки OnError и SkipDomains используемого источника данных. Пример: to:ldap:onerror=exception|skipdomains=file:/etc/drweb/skipdomains.list|///?description?sub?(cn=$u) cont В соответствии с указанным условием, требуется, чтобы имена всех получателей письма (части username из записи адреса username@domain, согласно используемому макросу $u) были найдены в LDAP. Однако при этом в Lookup-выражении также определена настройка SkipDomains, требующая пропускать без запроса домены (часть domain адреса), которые будут найдены в файле /etc/drweb/skipdomains.list. Поэтому правило будет обработано следующим образом: 1.Из письма извлекается перечень получателей (поле To:). 2.Берется адрес очередного получателя письма. 3.Определяется, принадлежит ли домен этого адреса списку доменов, пропускаемых без запроса. Если да, то переход к следующему адресу из списка (пункт 2). Если нет, то выполняется LDAP-запрос. Обратите внимание, что если в письме всего один получатель, и его домен принадлежит к пропускаемым, то запрос к LDAP выполнен не будет, и фактически данное правило не сформирует никаких настроек для данного письма. 4.Если результат запроса положительный, содержимое поля description используется как настройка (конкатенируется слева к ранее извлеченным настройкам), затем – переход к следующему адресу из списка (пункт 2). В противном случае, если результат запроса отрицательный (имя пользователя не найдено в источнике данных), то условие Правила считается ложным для письма, Правило отвергается и все извлеченные из LDAP настройки отбрасываются. Оставшиеся запросы к LDAP не выполняются. 5.Если выполнить LDAP-запрос не удается, то эта ситуация является ошибкой обработки письма, обработка Правил для этого письма будет остановлена, и, в соответствии с настройкой OnError=exception, будет выполнено действие, указанное в параметре ProcessingErrors (секция [Maild]). Подробнее об обработке ошибок в Правилах см. ниже. Поскольку в Правиле указана директива продолжения поиска cont, после просмотра этого Правила, если не было ошибок, будет продолжен просмотр других правил. Обратите внимание, что если в рассмотренном примере в письме указано несколько получателей, и из LDAP для них будут извлечены настройки с разными значениями параметров, то реально примененные настройки будут определены в результате клонирования письма или замены на значения параметров из конфигурационного файла (как описано выше, в пункте Обработка писем с несколькими получателями). Соединение настроек Правил из разных источников Как указано в начале раздела, при обработке письма значения требуемых параметров извлекаются из Правил, расположенных во внутренней базы данных, затем – из Правил в секции [Rules], а потом из значений параметров, указанных в конфигурационном файле. Рассмотрим пример соединения для письма настроек, извлекаемых из разных мест в соответствии с описанным в начале главы алгоритмом. Пример: a) Пусть во внутренней базе данных для пользователя test@drweb.com имеются следующие Правила: > email-info test@drweb.com Т.е. с почтовым адресом test@drweb.com связано три Правила обработки, причем третье – с неявной частью SETTINGS, проверяющее условие через Lookup и импортирующее результат выборки (значение поля rules) как SETTINGS-часть Правила. Правило использует данные из таблицы maild базы данных, доступ к этой таблице также настроен через ODBC. b) Пусть запись в таблице, связанная с адресом test@drweb.com, имеет следующий вид:
c) И пусть, кроме того, в секции [Rules] основного конфигурационного файла задано следующее Правило: [Rules] В этом случае для письма, в котором в качестве получателя указан адрес test@drweb.com, выполняется следующий просмотр Правил: 1)Сначала выполняются Правила из внутренней базы данных. Поскольку все они тождественно истинны (в качестве условия задано true), то их значения используются. Кроме того, параметр modifier/LocalRules обладает накапливающей семантикой, а значит, значения из всех Правил для него будут последовательно конкатенированы. 2)Далее, в соответствии с третьим Правилом, будет произведен запрос к базе данных и результат запроса (значение поля rules для адреса test@drweb.com) также будет присоединен к текущему накопленному значению. 3)После этого (поскольку не встретилось stop и параметр modifier/LocalRules обладает накапливающей семантикой) просматриваются истинные Правила из секции [Rules] конфигурационного файла. Найденные значения параметра modifier/LocalRules также будут конкатенированы. Итого, после просмотра всех Правил, для письма, в котором в качестве получателя указан адрес test@drweb.com, параметр modifier/LocalRules будет иметь следующее совокупное значение: 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 |