Формат Правил

Каждое Правило обработки писем записывается в виде строки и имеет вид:

CONDITION stop|cont [SETTINGS]

где:

•CONDITION – условие, которое должно быть истинно для некоторого письма, чтобы при его проверке использовались настройки и/или действия, указанные в части SETTINGS.

•SETTINGS – настройки и/или действия, которые нужно выполнить при проверке письма, если для него оказалось истинным условие CONDITION.

Обратите внимание, что раздел SETTINGS в Правиле может отсутствовать. Это может быть в двух случаях:

1.Если Правило не несет в себе специфических настроек, а является только "правилом-фильтром";

2.Если используемые для проверки письма настройки загружаются прямо в процессе выполнения проверке CONDITION из внешнего источника (используется Lookup из LDAP, БД, файл и т.п.).

•Директива, стоящая после CONDITION, определяет, какие действия следует выполнить, если условие в CONDITION оказалось истинным для письма:

ostop – прекратить поиск подходящих Правил ниже;

ocont – продолжить просматривать список Правил вниз.

Если условие CONDITION для некоторого письма оказалось ложным, то указанная после него директива не оказывает никакого влияния: будет продолжен просмотр списка Правил.

Если при записи Правило получается слишком длинным и не помещается в одну строку, в конце строки ставится знак "\", и описание Правила продолжается на следующей строке.

Условия (CONDITION) Правил

Каждое из условий CONDITION представляется в виде логической комбинации единичных логических термов:

BOOL_TERM [<log_op> BOOL_TERM]

где BOOL_TERM – логический терм, либо принимающий в значение «ложь» или «истина» в результате проверки некоторого параметра письма (задается выражением [param_name:][value]), либо тождественно равный true или false. Формально логический терм представляется в виде:

<[param_name:][value]> | true | false

param_name - имя параметра, а value - его значение.

Между именем параметра и значением (т.е. сразу после двоеточия) в логическом терме не должно быть пробелов.

Названия параметров, которые могут быть использованы в условиях Правил, представлены в таблице:

Имя параметра	Описание	Тип значения
any	Либо адрес отправителя, либо адрес получателя сообщения. Пример: any:regex:*@domain.com Или отправитель, или получатель сообщения должны иметь адрес в домене domain.com.	Lookup
from, sender	Адрес отправителя сообщения. Пример: from:admin@domain.com Oтправителем письма должен быть владелец адреса admin@domain.com.	Lookup
to, rcpt	Адрес получателя сообщения. Пример: "rcpt:ldap:///??sub?(mail=$s)" Все получатели письма должны быть найдены в LDAP по полю mail.	Lookup
block	Имя объекта или причины, вызвавшей блокировку письма некоторым подключаемым модулем. Блокировкой письма считается применение к нему каким-либо модулем действия reject. В этом случае модуль, заблокировавший письмо, возвращает список строк, описывающих причины блокировки (их может быть больше одной). Например, модуль Drweb, в случае если был обнаружен вирус (или другая известная угроза) вернет его имя. Если блокировка была вызвана по другой причине, (например, по выполнению реакции на событие SkipObject), то он возвращает полное строки конфигурации "<параметр>: <значение>", выполнение которой привело к блокировке письма. Например, модуль HeadersFilter может возвращать сообщение, что письмо было заблокировано по причине отсутствия заголовка <header>, указанного в параметре MissingHeader, в следующем виде: "MissingHeader: <header>". Примеры: 1) block:file:viruses.txt Имя объекта или причины, вызвавшей блокировку письма некоторым подключаемым модулем, должно быть в списке, взятом из файла (подразумевается, что это имя некоторой найденной угрозы). 2) "block:regex:.skip." Описание причины, вызвавшей блокировку письма некоторым подключаемым модулем, должно содержать подстроку "skip" (например, выполнение реакции на событие SkipObject).	Lookup
client-ip	IP-адрес отправителя письма (если получение информации об IP-адресе отправителя было задано в настройках компонента Maild core). Обратите внимание, что в качестве аргумента нельзя использовать формат CIDR. Пример: client-ip:127.0.0.1 Письмо должно быть отправлено с локальной машины.	Lookup
client-port	Порт клиента, отправившего письмо. Пример: client-port:1234 Письмо должно быть отправлено с порта 1234.	Номер порта
server-unix-socket	Абсолютный путь к файлу UNIX-сокета, на котором было принято соединение. Пример: server-unix-socket:/var/drweb/ipc/sock1	Путь к UNIX-сокету
server-ip	IP-адрес интерфейса, на котором Receiver принял письмо. Обратите внимание, что в качестве аргумента нельзя использовать формат CIDR.	Lookup
server-port	Порт сервера, на котором было принято соединение	Номер порта
id	Уникальный идентификатор компонета Receiver, принявшего письмо (если был задан в настройках компонента Receiver).	Строка-идентификатор
auth	Прошел ли авторизацию клиент, отправивший письмо. Обратите внимание, что параметр не имеет аргумента. Пример: auth:	Отсутствует
size	Размер сообщения. Перед размером можно указывать оператор сравнения: •!= – Не равно. •== – Равно (совпадает). •< – Меньше, чем. •> – Больше, чем. •<= – Меньше или равно. •>= – Больше или равно. Если отношение не указано, то по умолчанию предполагается, что это <=. Размер указывается в килобайтах, мегабайтах или гигабайтах, для чего после числа указывается соответствующий суффикс (k, m, g). Пример: "size:>=10m"	Размер или оператор сравнения
score	Счет сообщения. Перед размером можно указывать оператор сравнения. Если оператор не указан, то по умолчанию предполагается, что это <=. Пример: "score:!=1000"	Число или оператор сравнения

Обратите внимание, что:

•Если имя параметра в логическом терме не указано, то по умолчанию используется параметр any (например, запись user@domain.com stop <some_settings> эквивалентна Правилу any:user@domain.com stop <some_settings>).

•Если в значении параметра содержатся пробелы или символы '|', '&', ')', '(' '!' '=' ',' то его надо заключать в кавычки. Чтобы задать символ '"' (кавычка) внутри кавычек, его надо предварять (экранировать) знаком '\'.

•Если в Правиле нужно использовать пустое значение адреса, то следует использовать запись вида "", а использовать угловые скобки (<>) в данном случае нельзя (например from:"" stop scan=no).

В качестве логических операторов используются AND ('&&'), OR ('||'), NOT ('!'). При помощи них можно составлять сложные условия из простых логических термов. Также можно использовать скобки для управления старшинством логических операций. Минимально условие правила состоит из одного логического терма.

Пример 1:

true stop <some_settings>

Настройки <some_settings> будут применяться всегда, если до этого Правила дошла очередь при проверке (условие тождественно истинно для любого письма). Более никакие нижележащие Правила применены не будут, т.к. будет выполнена директива stop.

Пример 2:

sender:test && "size:>=10k" cont scan=no

Данное условие будет истинным, если отправителем письма является "test" и размер письма больше 10 килобайт. В этом случае сообщение будет пропущено без проверки. Обратите внимание на использование кавычек: они тут необходимы.

Пример 3:

!("rcpt:ldap:///??sub?(mail=$s)" OR auth:) stop

Данное Правило сработает, если хотя бы один получатель письма, взятый из TO: не найден в LDAP по полю mail и отправитель не является авторизованным.

Настройки (SETTINGS) Правил

Часть SETTINGS правил имеет вид перечисления пар Параметр = Значение:

[plugin_name/]param = value, [plugin_name/]param = value ...

где plugin_name (если указано) – название подключаемого модуля, к которому относится параметр, param – название параметра, а value – его значение.

Если имя модуля не указано, то это означает, что переопределяется значение параметра из основного конфигурационного файла Dr.Web MailD (имя секции не указывается). Например, указание в Правиле директивы AdminMail=root@domain означает переопределение для данного письма параметра AdminMail в секции [Notifier] конфигурационного файла Dr.Web MailD.

В перечислении должно присутствовать не менее одной пары Параметр = Значение. Элементы списка разделяются запятыми, поэтому, если в значении value содержится запятая, то перед ней следует поставить обратный слэш "\" (экранировать).

Пример 1:

sender:a@drweb.com cont headersfilter/Action = pass, vaderetro/max_size = 100k

При срабатывании этого Правила (для отправителя a@drweb.com) выбирается значение параметра Action = pass для подключаемого модуля Dr.Web HeadersFilter и максимальный размер проверяемого сообщения (max_size), равный 100k, для подключаемого модуля Vaderetro, после чего будет продолжен поиск подходящих Правил ниже (т.к. указана директива cont).

Пример 2:

to:a@drweb.com cont drweb/ProcessingErrors = pass\, redirect(err@drweb.com)

Обратите внимание, что задается один параметр ProcessingErrors для подключаемого модуля Drweb, имеющий в качестве значения два значения, разделенных запятой (pass, redirect(err@drweb.com)). Поэтому данном случае нельзя заключать его в кавычки, так как в этом случае парсер конфигурации будет воспринимать его как одно значение и не разбивать на подстроки при разборе параметра ProcessingErrors. Запятая в данном случае экранируется.

Вся обработка Правил происходит по порядку, сверху вниз и слева направо, поэтому:

•Если в одном и том же Правиле (в его части SETTINGS) значение одного и того же параметра задается несколько раз, то последующее значение параметра замещает значение предыдущее.

•Если сработало несколько Правил, в которых (в части SETTINGS) присваиваются разные значения одному и тому же параметру, то неизменным сохраняется первое присвоенное значение, а попытки последующих изменений будут проигнорированы.

Пример 3 (одно Правило с несколькими значениями одного и того же параметра):

true cont html=yes, html=no

Параметру html (о параметре html см. ниже) будет присвоено значение no.

Пример 4 (несколько сработавших Правил с разными значениями одного и того же параметра):

true cont html=yes
true cont html=no

Параметру html будет присвоено значение yes.

Описанное выше поведение относится ко всем параметрам, кроме параметров, которые обладают накапливающей ("аддитивной") семантикой. Каждый раз, когда встречается параметр с накапливающей семантикой, новое его значение, взятое из очередного сработавшего Правила, не конфликтует с предыдущим значением, присвоенным параметру, а добавляется к нему. В результате все найденные значения параметра объединяются в единый список-значение. При этом директива stop, встреченная в очередном сработавшем Правиле, для таких параметров работает как обычно – просмотр дальнейших Правил прекращается, параметр получает в качестве значения накопленный к этому моменту список значений. В данном документе параметры, обладающие аддитивной семантикой, отмечаются в их описании пиктограммой .

Кроме того, имеется также особый тип параметров, называющихся клонирующими. Эти параметры обрабатываются для каждого получателя отдельно: т.е. если у двух получателей письма, в результате срабатывания разных Правил, для какого-либо параметра будут указаны разные значения, то для каждого из получателей будет создана отдельная копия письма, к которой будут применены свои настройки обработки. В данном документе параметры, поддерживающие клонирование, отмечаются в их описании пиктограммой .

Параметры, используемые в настройках (SETTINGS) Правил

В части SETTINGS Правил могут использоваться параметры следующих видов:

•те, которые встречаются только в Правилах.

•те, значения которых задаются в конфигурационном файле Dr.Web MailD или в конфигурационных файлах других модулей или подключаемых модулей.

В данном документе параметры, которые могут использоваться в Правилах, отмечаются в их описании пиктограммой .

1. Параметры, используемые только в Правилах:

html = {логический}

Использовать ли HTML-форматирование уведомлений MailD.

В случае если указано Yes, уведомления MailD генерируются в формате HTML, в противном случае – в текстовом виде.

Обратите внимание, что этот параметр не управляет видом DSN.

quarantine = {логический}

Разрешение перенаправления отвергнутых писем в Карантин.

В случае если указано Yes, разрешается перемещать письма в Карантин, в случае если они не пройдет проверку подключаемыми модулями.

В противном случае письмо не попадет в Карантин, даже в случае, если оно будет отвергнуто подключаемыми модулями.

scan = {текст}

Параметр определяет, какие подключаемые модули Dr.Web MailD, из заданных в секции [Filters], будут использованы для проверки письма.

Если указано значение All, будут задействованы все модули. Если указано No, то никакие модули не будут использоваться.

Также имеется возможность указать выборочный список используемых подключаемых модулей. Разделителем между именами модулей служит двоеточие ":". Чтобы исключить из использования какие-либо модули, следует перед их именем ставить знак минус "-" без пробела между минусом и именем модуля. Обратите внимание, что при указании значения All не разрешается использовать имена подключаемых модулей без знака минус, так как это является бессмысленным.

Примеры:

scan = All - использовать все модули;

scan = no - не использовать ни одного модуля;

scan = All:-plugin1 - использовать все подключаемые модули, кроме plugin1;

scan = Plugin1:Plugin2 - использовать только подключаемые модули Plugin1 и Plugin2;

scan = All:Plugin1 - неверно, т.к. нельзя использовать имена модулей без "-" после All;

scan = -Plugin1:All - неверно, т.к. All может быть только на первой позиции;

scan = -Plugin1 - неверно, т.к. в начале отсутствует All.

notify[.<тип уведомления>] = {allow | block}
[(<типы адресов>)]

Данный параметр управляет отправкой уведомлений MailD разных типов.

Значение allow разрешает вывод соответствующего уведомления, а значение block – запрещает. Если тип уведомления не указан, то значение параметра применяется ко всем уведомлениям.

Возможные типы уведомлений зависят от того, какие виды уведомлений поддерживает компонент Notifier. Дополнительно установленные подключаемые модули могут добавлять свои собственные типы уведомлений.

По умолчанию поддерживаются следующие типы уведомлений:

•notify.Virus - уведомления об обнаруженных вирусах в почтовом сообщении;

•notify.Cured - уведомления об излеченных вирусах в сообщении;

•notify.Skip - уведомления о письмах, содержащих объекты, пропущенные при сканировании;

•notify.Archive - уведомления о сообщениях, не проверенных в связи с ограничениями на проверку архивов;

•notify.Error - уведомления об ошибках, возникших при проверке писем;

•notify.Rule - уведомления о блокировании письма каким-либо правилом;

•notify.License - уведомления о письмах, не проверенных в связи с лицензионными ограничениями;

•notify.Malware - уведомления об обнаруженных вредоносных программах.

Следом за значением параметра в скобках может идти необязательный модификатор, указывающий, адресаты каких типов подпадают под действие этого значения параметра. Можно указать несколько видов адресов, разделенных двоеточиями. Возможные значения модификатора (типы адресата):

•sender - отправитель письма;

•rcpt - получатель письма;

•admin - администратор;

•any, либо модификатор отсутствует - адресат любого типа.

Примеры:

notify=block или notify=block (any) - блокирование всех уведомлений для всех адресатов.

notify.Virus=block (sender:admin) - блокирование уведомлений о найденных вирусах для администратора и отправителя письма.

Если для уведомления некоторого типа <type> не найдено правило notify.<type>, а также не найдено общее правило notify, то предполагается, что соответствующее уведомление отключено.

Обратите внимание, что эта настройка не управляет видом DSN.

NotificationNamesMap =
name1 file_name1,
name2 file_name2,
...

Этот параметр позволяет отображать названия используемых шаблонов уведомлений в новые. Например, может использоваться для формирования уведомлений разного вида в зависимости от конверта.

Здесь, соответственно:

•nameN - имя запрашиваемого уведомления, для которого устанавливается новый файл шаблона. Список имен можно найти в описании параметра notify. Кроме того, здесь можно для шаблонов общих отчетов указывать слово report, а для DSN - dsn.

•file_nameN - часть имени нового файла с шаблоном уведомления. Полное имя шаблона составляется по следующей схеме: в начало имени файла добавляется один из необходимых префиксов: sender_, rcpts_, admin_, report_ или dsn_, расширение файла меняется на .msg. В результате получается имя файла, например sender_file_nameN.msg, который будет искаться в каталоге, указанном в значении параметра TemplatesBaseDir секции настроек [Notifier].

Пример:

NotificationNamesMap = virus my-virus, archive my-arch

SenderAddress = {address1|address2|...}

Адрес, передаваемый компоненту Sender, чтобы тот отправил на него письмо.

Можно указывать несколько адресов, разделяя их знаком "|" (по аналогии с параметром Router из секции [Sender]).

При использовании параметра SenderAddress в Правилах вида:

<CONDITION> cont SenderAddress = address1|address2|address3

сообщение, удовлетворяющее условию <CONDITION>, будет послано на первый доступный адрес из этого списка. То есть, если address1 недоступен, то письмо будет отправлено на address2, а если и этот адрес не доступен, то на address3.

Данный параметр может использовать специальные макросы:

•CLIENT-IP - IP-адрес клиента, от которого было получено письмо

•CLIENT-PORT - Порт клиента, с которого было получено письмо

•SERVER-IP - IP-адрес, который обслуживается Dr.Web MailD

•SERVER-PORT - Порт, через который Receiver принял письмо.

Если Sender поддерживает данный параметр, то он передаст письмо именно на указанный адрес.

Например, Правило вида

true cont SenderAddress=inet:10025@CLIENT-IP

будет перенаправлять все исходящие письма на хост, с которого они получены, на порт 10025.

В текущей версии Dr.Web MailD параметр SenderAddress поддерживается только модулем drweb-sender с SMTP/LMTP методом отправки почты.

Значения «по умолчанию» для параметров, перечисленных в таблице выше, задаются в «безымянной» секции [Rule] конфигурационного файла.

Для корректной работы макросов CLIENT-IP и CLIENT-PORT, используемых в параметре SenderAddress, необходимо установить значения следующих параметров:

•В секции [Receiver]: RealClients = yes

•В секции [Maild]: GetIpFromReceivedHeader = yes

2. Параметры из секций основного конфигурационного файла, которые могут быть использованы в Правилах:

Секция

Параметры

[Maild]

RedirectMail

MaxScore

MaxScoreAction

LicenseLimit

EmptyFrom

ProcessingErrors

UseCustomReply

ReplyEmptyFrom

ReplyProcessingError

ReplyMaxScore

[Notifier]

AdminMail

FilterMail

NotifyLangs

[Filters]

<plug-in>/use - Параметр разрешает или запрещает использование указанного подключаемого модуля при проверке писем. Имеет логический тип {yes, no}. Обратите внимание, что этот параметр может быть использован только в Правилах и не задается в конфигурационном файле!

<plug-in>/max_size

<plug-in>/log_level

<plug-in>/log_ipc_level

<plug-in>/syslog_facility

<plug-in>/path_to_lib

3. Параметры подключаемых модулей, которые могут быть использованы в Правилах:

Модуль	Параметры
Drweb	HeuristicAnalysis AddXHeaders Paranoid RegexsForCheckedFilename LicenseLimit Infected Suspicious Incurable Adware Dialers Jokes Riskware Hacktools SkipObject ArchiveRestriction ScanningErrors ProcessingErrors BlockByFilename UseCustomReply ReportMaxSize ReplyInfected ReplyMalware ReplySuspicious ReplySkipObject ReplyArchiveRestriction ReplyError ReplyBlockByFilename
Vaderetro	FullCheck NoHamFrom AddVersionHeader AddXDrwebSpamStateNumHeader AddXSpamLevel AddXHeaders CheckDelivery SubjectPrefix NotifySubjectPrefix UnconditionalSpamThreshold UnconditionalSubjectPrefix SpamThreshold UnconditionalAction Action NotifyAction SpamCustomReply WhiteList BlackList CheckForViruses AllowRussian AllowCJK UseCustomReply FromProtectedNetworkScoreAdd ProtectedNetworkReplyCacheLifeTime ReplyToProtectedNetworkScoreAdd
HeadersFilter	ScanEncodedHeaders RejectCondition AcceptCondition FilterParts RejectPartCondition AcceptPartCondition MissingHeader Action UseCustomReply ReplyRuleFilter
Modifier	Encoding UseCustomReply ReplyRuleFilter LocalRules - Локальные правила проверки писем модулем (аналогичен по формату параметру GlobalRules подключаемого модуля). Обратите внимание, что этот параметр модуля может быть использован только в Правилах и не задается в самом конфигурационном файле подключаемого модуля! О формате правил модуля см. в описании подключаемого модуля.

Обратите внимание, что логика работы параметра <plug-in>/use аналогична логике работы параметра scan (включение или исключение модуля в список используемых для проверки). Однако он может использоваться для дополнительного включения или выключения подключаемых модулей при срабатывании разных Правил, т.к. параметр scan не обладает накапливающей семантикой.

Пример:

Если в результате срабатывания двух Правил требуется отключить подключаемые модули Drweb и Vaderetro, то использование Правил вида

to:regex:test@.* cont scan=all:-vaderetro
to:regex:test@.* cont scan=all:-drweb

приведет к тому, что отключится только модуль Vaderetro (поскольку повторное изменение параметра scan будет отброшено). Однако, если переписать второе Правило следующим образом:

to:regex:test@.* cont scan=all:-vaderetro
to:regex:test@.* cont drweb/use=no

то после срабатывания первого Правила отключится Vaderetro, а после второго также и Drweb. Тот же эффект будет достигнут, если в SETTINGS-части первого правила заменить scan=all:-vaderetro на vaderetro/use=no.

Для использования в SETTINGS-части Правила значений параметров из некоторой именованной группы настроек (задается как секция с заданным названием [Rule:<название_секции>] в основном конфигурационном файле), используется директива rule=<имя группы>. В текущей версии Dr.Web MailD в каждом Правиле обработки писем может быть использовано не более одного параметра rule (примеры см. в описании секции [Rule]).