Dr.Web MailD может работать не только в качестве прокси-сервера почтовых протоколов SMTP/LMTP, но и использоваться в качестве сервиса для проверки почты в режиме «callback». В этом режиме MTA, принимающие почту, пересылают ее для проверки на Dr.Web MailD, как на внешний фильтр, используя протокол SMTP/LMTP. После проверки письма Dr.Web MailD должен вернуть его, используя протокол SMTP/LMTP, на тот же сервер, с которого он его получил.
Схема реализации режима «callback» приведена на рисунке ниже.
Рис. 21. Интеграция Dr.Web MailD с почтовыми системами в режиме "callback"
По составу запущенных модулей и основным настройкам этот режим не отличается от обычного режима интеграции SMTP/LMTP-прокси.
Особые настройки Callback-режима
Особенность настроек заключается в том, что Sender должен обеспечить возврат письма на тот же хост, с которого Receiver его получил (но на другой порт). Для этого требуется добавить в настройки Правила, изменяющие правила отправки писем. Правила указываются в секции [Rules] основного конфигурационного файла Dr.Web MailD. Для указания адреса возврата проверенных писем в Правилах следует использовать параметр SenderAddress.
Типовое Правило в этом случае имеет следующий вид:
<CONDITION> cont SenderAddress = inet:<pont-num>@CLIENT-IP
где <CONDITION> - условие срабатывания Правила (в простейшем случае, для безусловного срабатывания Правила, достаточно указать true), а <port-num> - номер порта на сервере, на котором MTA ожидает возвращения письма (например, 10025). CLIENT-IP - это специальный макрос, используемый для подстановки в адрес для отправки IP-адреса, запомненного Receiver при приеме письма.
Обратите внимание, что все действия с письмами как для Receiver, так и для подключаемых модулей, следует настроить таким образом, чтобы избежать отказов в приеме писем для проверки (не использовать действия reject, discard, tempfail), или настроить MTA таким образом, чтобы они правильно реагировали на отказ «callback»-фильтра при приеме письма.
Кроме того, если в конфигурации Dr.Web MailD предусмотрено разрешение на генерацию DSN (например, используется асинхронный режим и параметр SkipDSNOnBlock установлен в No) и уведомлений, то в этом случае в <CONDITION> Правила должно стоять условие, не позволяющее отправлять служебные письма на тот адрес, на котором MTA ожидает проверенные письма. Для этого в <CONDITION> следует использовать проверки, использующие параметр from (sender). Все DSN всегда отправляются с пустым From, а все уведомления отправляются с полем From, содержащим адрес, взятый из параметра FilterMail (секция [Notifier]).
Пример:
!(from:"" || from:"root@localhost") cont SenderAddress = inet:10025@CLIENT-IP
Данное Правило отправит исходящее письмо на порт 10025 хоста, с которого оно получено, если в его поле From не пустое и не содержит адрес root@localhost.
Поскольку параметр Правил SenderAddress только динамически переопеределяет значение параметра Address, указанное в секции [Sender], то, если Правило не сработает, письмо будет отправлено на MTA, адрес которого указан в настройках Sender. Рекомендуется указать там адрес действующего почтового сервера, чтобы оперативно получать письма, информирующие о проблемах в обработке писем (на рисунке этот MTА указан пунктиром).