Обработка сообщений

Обработка почтовых сообщений происходит по следующему алгоритму:

1.Сообщения, поступающие от MTA, принимаются компонентом Receiver, который передает их компоненту MailD core, отвечающему за проверку почтовых сообщений.

2.Компонент MailD core производит MIME-разбор сообщений, передает письма на обработку подключаемым модулям и отвечает за хранение писем в базе данных.

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

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

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

Обратите внимание на порядок обхода Правил:

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

oДля каждого проверяемого Правила проверяется условие CONDITION – и если оно истинно, то значение требуемого параметра ищется среди элементов секции SETTINGS этого правила.

oЕсли условие CONDITION оказалось ложно, то просмотр Правила заканчивается и происходит переход к поиску значения в следующем Правиле.

oЕсли условие CONDITION истинно и после него стоит директива cont, то происходит переход к проверке следующего Правила. Если же после истинного CONDITION стоит директива stop, то просмотр Правил заканчивается вне зависимости от того, было найдено значение требуемого параметра или нет.

Значение параметра по результатам просмотра Правил всегда определяется следующим образом:

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

•Если Правила отсутствуют, или ни одно Правило не сработало, или ни в одном из сработавших Правилах параметр не нашелся, то извлекается значение этого параметра, заданное в соответствующей секции конфигурационного файла.

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

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

3.Обработка писем может производиться подключаемыми модулями сначала в синхронном режиме (если такие модули указаны), а затем, после сохранения писем в хранилище, – в асинхронном режиме (если такие модули указаны).

4.Если проверка производилась в синхронном режиме, то результаты проверки писем отправляются компоненту Receiver (если еще не истекло время ожидания результата проверки).

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

6.Компонент Sender отвечает за отправление всех исходящих писем в различные почтовые системы. Он отправляет как исходящие проверенные письма, так и все сформированные Dr.Web MailD уведомления и отчеты.

При обработке почтовых сообщений Dr.Web MailD использует два режима обработки:

1.Синхронный режим ("before-queue"): поступившее от отправителя через Receiver письмо обрабатывается "на лету", т.е. не сохраняется в хранилище MailBase, а сразу же передается на обработку подключаемым модулям, перечисленным в списке BeforeQueueFilters. При этом Receiver не шлет отправителю ответа до окончания обработки или до истечения тайм-аута, отведенного на обработку письма. В случае если письмо не пройдет проверку, отправитель получит от Receiver в качестве ответа код ошибки.

2.Асинхронный режим ("after-queue"): поступившее через Receiver письмо сохраняется в локальное хранилище MailBase, а Receiver отвечает отправителю ответом, что письмо успешно получено. После этого письмо поступает на обработку в подключаемые модули, перечисленные в списке AfterQueueFilters. Если принятое письмо не пройдет проверку, то уведомление отправителя производится отправкой ему DSN, содержащей отчет об ошибке.

Если часть подключаемых модулей указана в списке BeforeQueueFilters, а часть – в списке AfterQueueFilters, то письмо последовательно обрабатывается сначала в синхронном, а затем – в асинхронном режимах.

Обратите внимание, что если используются подключаемые модули Dr.Web HeadersFilter и Dr.Web Modifier, т.е. если для них заданы локальные правила обработки писем, или же заданы Правила обработки писем, переопределяющие параметры данных модулей, то, если Dr.Web MailD работает в режиме SMTP/LMTP-прокси, рекомендуется помещать их в список AfterQueueFilters. Если же Dr.Web MailD интегрирован с какой-либо MTA, то рекомендуется помещать все подключаемые модули в список BeforeQueueFilters, но при этом увеличить тайм-аут IPC (параметр IPCTimeout, определенный в конфигурационном файле в секции [General]). Если эти подключаемые модули вовсе не используются для обработки писем, то рекомендуется исключить их из всех очередей в секции [Filters].

При любом способе проверки, после ее окончания, письмо, если оно не было отвергнуто (т.е. к нему не применялись действия reject, discard или tempfail), отправляется для доставки получателю в компонент Sender. При этом, если письмо поступает на отправку из синхронного режима проверки, то отправляться оно так же будет синхронно, т.е. Receiver будет ждать результата отправки письма через Sender или окончания тайм-аута. Использование тайм-аута нужно для того, чтобы не вызывать ошибки взаимодействия с внешними MTA при ведении протокольных диалогов приема и отправки писем.

Пожалуйста, обратите внимание, что наилучшие режимы использования подключаемых модулей зависят от типа проверяемого почтового трафика и типа MTA, с которым интегрирован Dr.Web MailD (включая способ интеграции). Таким образом, при изменении настроек по умолчанию прежде всего прочтите описание способа интеграции с выбранным MTA в соответствующем разделе Руководства.

Особенности взаимодействия компонентов Receiver, MailD core и Sender в различных режимах

1.Максимально допустимое время взаимодействия компонентов Receiver и MailD core ограничено величиной тайм-аута IPCTimeout (определен в конфигурационном файле, в секции [General]) В синхронном режиме этот же тайм-аут ограничивает также и время взаимодействия между компонентами MailD core и Sender. Модуль drweb-milter использует наибольшее из значений параметра IPCTimeout и параметра ProcessingTimeout из своих настроек (секция [Milter]).

Принятое письмо сохраняется во внутренней очереди MailD core и Receiver сразу же отвечает отправителю кодом SMTP 250 о том, что письмо находится в очереди и он снял с себя ответственность за его доставку. MailD core, передавая обработанное письмо в Sender для доставки получателю, также снимает с себя отвественность за доставку. Далее компонент Sender либо сразу и без проблем отправляет письмо далее, либо (в случае задержек в канале или невозможности подключиться к целевому почтовому серверу) переходит к отложенной отправке.

В этом режиме величина тайм-аута IPCTimeout должна быть соизмерима со средним временем обработки писем подключаемыми модулями.

Компонент Receiver будет ожидать, и не возвращать ответа отправителю, пока письмо не будет обработано всеми подключаемыми модулями и не отправлено далее через Sender. В случае если в течение периода времени, меньшего IPCTimeout на 1 секунду (модуль drweb-milter использует в этом случае наибольшее из значений параметра IPCTimeout и параметра ProcessingTimeout из своих настроек) компонент Sender не успеет отправить письмо, то он пропускает все попытки подключиться к целевому MTA (если их перечислено несколько в параметрах Address или Router в секции [Sender]) и сразу переходит к отложенной отправке. При этом компонент Receiver вернет отправителю специфический ответ SMTP 250 Maild Error, который означает, что письмо находится в очереди на отправку и будет отправлено, как только исчезнут проблемы с подключением к целевому MTA. Сообщение "Maild Error" говорит о том, что это – непредвиденная для синхронного режима ситуация (режим расчитан на быструю обработку всего входящего трафика и быструю его передачу в целевой MTA).

Также в этом случае в журнале возможны ошибки вида "ERROR Broken pipe", свидетельствующие о том, что компонент Sender пытался вернуть MailD core отчет об отправке сообщения через соединение, которое уже было закрыто по истечению тайм-аута.

1.Синхронный режим не предназначен для работы под интенсивной нагрузкой. Его рекомендуется использовать только в том случае, если Dr.Web MailD выступает в качестве локального почтового фильтра, и ни в коем случае не использовать, если Dr.Web MailD выступает в качестве высоконагруженного SMTP-шлюза.

2.Если в почтовом трафике, проходящем через Dr.Web MailD, имеется большая доля писем с большим количеством вложений (или вложений, больших по размеру), а также если вероятны задержки в канале или какие-либо проблемы на стороне целевого MTA, то лучше выбирать асинхронный режим работы. Также не следует помещать в очередь before-queue подключаемые модули, требующие потенциально длительное время для обработки писем.

3.В случае работы в синхронном режиме желательно не уменьшать значение тайм-аута IPCTimeout, заданное по умолчанию, а при изменении этого значения соизмерять его со временем обработки письма подключаемыми модулями (величина IPCTimeout всегда должна быть больше, поскольку срабатывание тайм-аута прямо во время проверки может привести к потере письма и недоставки его получателю). Также в этом режиме предполагается, что нет никаких задержек при отправке почты через компонент Sender к целевому MTA (он должен быть доступен и корректно настроен).

Особенности работы с MTA, интегрированными по протоколу Milter:

1.Если Dr.Web MailD подключен к MTA по протоколу Milter (в качестве Receiver используется модуль drweb-milter), то на порядок возвращения проверенного письма обратно в очередь MTA влияет только значение параметра CanChangeBody (секция [Milter] конфигурационного файла);

2.Если имеются подключаемые модули, расположенные в очереди BeforeQueueFilters (т.е. идет работа в синхронном режиме), параметр CanChangeBody = Yes и при обработке писем имеются существенные задержки (например, какой-то из модулей не успевает обработать письмо за период времени, заданный в параметре ProcessingTimeout), то в MTA возвращается код ответа SMTP, заданный в параметре ProcessingError (все перечисленные параметры расположены в секции [Milter] конфигурационного файла);

3.Если идет работа в синхронном режиме, но параметр CanChangeBody = No, и в этом случае при обработке писем не отвечает какой-либо из компонентов (MailD core или Sender), то в MTA возвращается код ответа SMTP 451;

4.Если имеются подключаемые модули, расположенные в очереди AfterQueueFilters (т.е. идет работа в асинхронном режиме), параметр CanChangeBody = Yes и при обработке писем наблюдаются существенные задержки (например, какой-то из модулей не успевает обработать письмо за период времени, заданный в параметре ProcessingTimeout), то по истечению периода времени, заданного в параметре ProcessingTimeout, в MTA возвращается код ответа SMTP 250 queued, но письмо обрабатывается далее и отправляется через Sender (модуль drweb-sender). Таким образом, в случае если параметр CanChangeBody = Yes, то асинхронный режим нежелателен, т.к. не даст выигрыша ни по скорости (поскольку требуется время на дополнение сохранение служебных файлов сообщений в хранилище), ни по надежности обработки;

5.Если идет работа в асинхронном режиме, но параметр CanChangeBody = No, и при обработке ни отвечает какой-либо из компонентов (MailD core или Sender), то письмо теряется, а в MTA возвращается код SMTP 250 queued, следовательно, этот вариант настроек крайне нежелателен!

6.Таким образом, в случае подключения к MTA по протоколу Milter асинхронного режима (т.е. размещения подключаемых модулей в очереди AfterQueue) следует избегать, поскольку он не дает никаких преимуществ в обработке писем.

Кроме того, при необходимости оптимизации процесса обработки сообщений (в случае возникновения больших задержек, очередей на приеме или отправке, зависаний, нехватке системных ресурсов и т.п.) рекомендуется провести комплекс мероприятий по оптимизации работы и использования системных ресурсов.