17 ответов в этой теме

[Marsel2013]

Здравствуйте товарищи! Имеем FreeBSD 8.2, Postfix и Dr.Web для почтовых серверов Unix (6.0.2).

Настроил Dr.Web в режиме before_queue - повесил receiver на 25 порт, а Postfix на 26. Все работает, но одна неприятность - на почтовом сервере есть ящик always_bcc, куда копируется вся почта. Собственно, сама неприятность - вместе с легитимной почтой в ящик always_bcc падает и спам, хотя, по идее, не должен... DrWeb настроил так, чтобы он спам-письма перенаправлял в ящик spam@домен.ру, вот и получается, что спам падает и в спам-ящик и в always_bcc.

В чем может быть проблема? Какие нужны конфиги/логи/объяснения - спрашивайте, предоставлю.

[Alexander Batyukov]

Здравствуйте,

для предоставления точных рекомендаций был бы полезен конфиг /usr/local/etc/drweb/maild_postfix.conf
Можете выслать в личном сообщении

[Marsel2013]

Здравствуйте,

для предоставления точных рекомендаций был бы полезен конфиг /usr/local/etc/drweb/maild_postfix.conf
Можете выслать в личном сообщении

Спасибо за ответ, отправляю

[Marsel2013]

С "отправляю" это я поспешил. Не могу загрузить файл - Ошибка Вам запрещена загрузка файлов этого типа. Прошу прощение за нубство - но как отправить конфиг? На форуме первый день...

[pig]

В архив его.

[valya krasnoglazova]

Добрый день.

редирект всего на ящик always_bcc@protected.domain должен быть уже после фильтрации drweb-maild, который подключен в before_queue как smtpd_proxy_filter, т.е. когда возвращаем сообщение обратно в очередь Postfix для финальной доставки.

схема, видимо, примерно такая:

client (user or relay) ---> smtpd c smtpd_proxy_filter --> drweb-maild --> smtpd без smtpd_proxy_filter ---> встроенные фильтр, который настроен на выполнение redirect'а всего на always_bcc или content_filter с аналогичной функцией ---> qmgr

а спам отсекаем путем указания действия redirect (spam@domain.com) для параметра UnconditionalAction в plugin_vaderetro.conf.

в master.cf для транспорта smtpd, который передает сообщение на шаге: client (user or relay) ---> smtpd c smtpd_proxy_filter должно быть примерно следующее:

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - n - - smtpd
-o smtpd_proxy_filter=localhost:8025 # адрес на котором слушает drweb-receiver
-o receive_override_options=no_address_mappings # если используется virtual_alias_maps для редиректа всего в always_bcc, ничего не делаем с адресами
...
т.е. главное запретить редирект всего в бекап на этом шаге


а вот для транспорта на шаге: smtpd без smtpd_proxy_filter (т.е. тот smtpd, который принимает проверенное от drweb-maild и отдает qmgr для финальной доставки)
...
127.0.0.1:8026 inet n - n - 10 smtpd
-o receive_override_options= # вот тут можно вызвать встренный фильтр содержимого для отправки в бекап
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o smtpd_authorized_xforward_hosts=127.0.0.0/8

# или дописать -o content_filter= и подключить простой content_filter, который будет бекапить

Сообщение было изменено valya krasnobaeva: 05 Декабрь 2012 - 14:24

[valya krasnoglazova]

внимательно с настройками в plugin_vaderetro.conf, для UnconditionalAction - redirect (spam@domain.ru), т.е. откровенный спам отсекаем и редиректим в abuse, а вот для Action наверное лучше redirect + pass, он будет бекапиться в этом случае, но если эти письма понадобятся, их не прийдется искать в spam@domain.ru.

Какие нужны конфиги/логи/объяснения - спрашивайте, предоставлю.

нужны подробности, как настроен редирект всего в always_bcc, как происходит перезапись адресов (virtual_alias_maps или header/body_checks) или, по возможности, master.cf и main.cf + plugin_vaderetro.conf, maild_postfix.conf

без конфигов или описания по шагам где-что делается при обработке входящих , сложно что-то конкертное посоветовать

Сообщение было изменено valya krasnobaeva: 05 Декабрь 2012 - 14:44

[valya krasnoglazova]

конечно, без сопливых скользко, но на всякий случай:

Dr.Web MailD может работать с сервером Postfix так же и в режиме
before-queue (но этот режим не рекомендуется использовать при больших
нагрузках на систему)

так что может стоит через content_filter подключить его, к тому же проверка контента drwebd с т.з. скорости обработки довольно дорогая операция

Сообщение было изменено valya krasnobaeva: 05 Декабрь 2012 - 14:52

[Marsel2013]

Большое спасибо за ответы!

valya krasnobaeva, без проблем, прикрепляю в архиве необходимые конфиги. По способу подключения before_queue и after_queue - изначально использовал after_queue, все работало как часы, но проблема была та же - спам валился в always_bcc. Вероятно, я просто не учел какой-то момент при настройке обоих способов.

Прикрепленные файлы:

•  drweb.zip   11,89К   1 Скачано раз

[valya krasnoglazova]

cпасибо, тогда просьба еще заархивировать весь /usr/local/etc/drweb и либо выложить на ftp (см. адрес в личных сообщ.), либо приаттачить сюда

Сообщение было изменено valya krasnobaeva: 05 Декабрь 2012 - 19:15

[Marsel2013]

Ок, скинул архив с логом и папкой DrWeb в личные сообщения

[valya krasnoglazova]

Добрый день, как уже говорила, т.к. maild работает в качестве gateway перед Postfix, - все, что отправляется на spam@domain.com (копии блокированного vaderetro спама) - уходит в Postfix.

Postfix при доставке всей почты для получателей виртуального домена выполняет преобразования адресов, согласно заданным в main.cf картам (virtual_alias_maps, recipient_bcc_maps, sender_bcc_maps)

отчего и получаем:

Dec 5 00:17:25 freebsd drweb-sender: [0x874a80] sender INFO abslKTujL get msg [from: <DrWEB-MAIL-DAEMON@domain.local>; to:<spam@domain.ru>] from queue for processing...
Dec 5 00:17:25 freebsd postfix/smtpd[29454]: 085E32634C3D: client=localhost[127.0.0.1]
Dec 5 00:17:25 freebsd postfix/cleanup[29456]: 085E32634C3D: message-id=<20121204222051.domain.ru@cleint-host>
Dec 5 00:17:25 freebsd drweb-sender: [0x874a80] sender.smtp INFO abslKTujL Successfully sent; router=inet:[127.0.0.1]:26; from=<DrWEB-MAIL-DAEMON@freebsd.domain.local>; to=<spam@domain.ru>; res=[250 2.0.0 Ok: queued as 085E32634C3D^M]
Dec 5 00:17:25 freebsd postfix/qmgr[1492]: 085E32634C3D: from=<DrWEB-MAIL-DAEMON@freebsd.domain.local>, size=1179, nrcpt=2 (queue active)

-----> преобразование перед доставкой

Dec 5 00:17:25 freebsd postfix/virtual[29457]: 085E32634C3D: to=<backup@domain.ru>, relay=virtual, delay=0.01, delays=0/0/0/0, dsn=2.0.0, status=sent (delivered to maildir)
Dec 5 00:17:25 freebsd postfix/virtual[29457]: 085E32634C3D: to=<spam@domain.ru>, relay=virtual, delay=0.01, delays=0/0/0/0, dsn=2.0.0, status=sent (delivered to maildir)
Dec 5 00:17:25 freebsd postfix/qmgr[1492]: 085E32634C3D: removed

т.е. надо в карте, которая отвечает за редирект всего на адрес бекап-ящика ( recipient_bcc_maps, судя по присланному main.cf, но могу ошибаться ) прописать исключение для адреса спам-ящика, а-ля:

!/^spam@domain\.com/i backup@domain.ru (или переменная, которой в main.cf присвоено значение адреса бекап-ящика)

Сообщение было изменено valya krasnobaeva: 06 Декабрь 2012 - 15:21

[valya krasnoglazova]

пара рекомендаций насчет настроек maild_smtp:

- по возможности раскидайте плагины по очередям Filters/BeforeQueue, Filters/AfterQueue, например

BeforeQueue = # оставляем пустым
AfterQueue = vaderetro, drweb

в конфигах плагинов plugin_headersfilter.conf, plugin_modifier.conf правил не увидела, в отсутствии правил в этих конфигах - сами плагины headersfilter, modifier можно не подключать, полезную работу они без правил не выполняют

наличие всех плагинов одновременно только в BeforeQueue - синхронный режим работы, который не рекомендуется использовать для mail-gateways (не стабилен, были проблемы, см. предыдущие треды на тему MailD на форуме)

в секции [Receiver] для параметра RecipientRestrictions можно добавить первым reject_unknown_domain потом reject_unauth_destination, по дефолту в след. версии данный параметр будет содержать 2 этих значения.

Receiver/ProtectedEmails - тут задаются не диапазоны подсетей, а либо просто список e-mail, для которых разрешаем принимать почту, либо можно сделать lookup в файл, по аналогии с картами Postfix, ProtectedEmails = file://path_to_emails.list, формат файла - стандартно список, по адресу на строке

чтобы Receiver/ProtectedEmails заработал надо указать его в качестве значения для RecipientRestrictions = reject_unknown_rcpts - подробно обо всех этих ограничениях на сессию, см.
/usr/local/drweb/doc/maild/readme_postfix.rus

plugin_vaderetro.conf

Action = reject,"redirect(spam@domain)" --> тут осторожней с reject, у вадеретро редко, но бывают фолсы

[Marsel2013]

Здравствуйте! Большое спасибо за разбор проблемы! Получается, что абсолютно все письма попадают к Postfix, не зависимо от способа связи с DrWeb (after, before, milter) и ограничить попадание спама в ящик always_bcc можно средствами Postfix?

Попробую этот вариант, отпишусь. Пока поштудирую мануалы Postfix на эту тему, потому что, если честно, не задавался раньше вопросом как исключить какой-нибудь ящик из always_bcc.

[valya krasnoglazova]

судя по состоянию приаттаченного etc/drweb/software (так понимаю, инсталлировали из run-пакета, просьба поправить если не так !)

-r-xr--r-- 1 root wheel 38620 Jul 31 14:53 drweb-maild-common.remove
-r-xr--r-- 1 root wheel 12976 Jul 31 14:53 drweb-maild-plugin-drweb.remove
-r-xr--r-- 1 root wheel 12152 Jul 31 14:53 drweb-maild-plugin-headersfilter.remove
-r-xr--r-- 1 root wheel 12980 Jul 31 14:53 drweb-maild-plugin-modifier.remove
-r-xr--r-- 1 root wheel 12883 Jul 31 14:53 drweb-maild-plugin-vaderetro.remove
-r-xr--r-- 1 root wheel 11132 Jul 31 14:53 drweb-maild-smtp-bin.remove
-r-xr--r-- 1 root wheel 10326 Jul 31 14:53 drweb-maild-smtp.remove
-r-xr--r-- 1 root wheel 8331 Jul 31 14:53 drweb-maild-web.remove
-r-xr--r-- 1 root wheel 12189 Jul 31 14:53 drweb-maild.remove

и по конфигурации в присланном maild_smtp.conf - drweb-maild в текущем случае выступает просто как внешний шлюз перед Postfix.

можно интегрировать его в Postfix, установив пакет drweb-maild-postfix, и тогда будем иметь 3 варианта подключения (after, before, milter), но в карту постфикса, где определяем преобразвание для пересылки всего на always_bcc, все равно прийдется добавлять исключение + надо будет смотреть чтобы преобразование адресов выполнялось до фильтрации drweb-maild

[Marsel2013]

Да, все верно, установлен из run-пакета. По рекомендациям настройки - спасибо, учту.

А достаточно ли будет при текущей конфигурации просто добавить исключение для always_bcc? Или тут уже надо экспериментировать

[GrayCat]

и тогда будем иметь 3 варианта подключения (after, before, milter)

а можно данный момент подробнее ?
а то у меня с точки зрения postfix-а drweb подключен как мильтер (main.cf: smtpd_milters = inet:localhost:3001)
а с точки зрения maild - after (maild_postfix.conf: [Filters] BeforeQueueFilters = drweb)
и иначе работать не захотело

[valya krasnoglazova]

У постфикса есть 3 варианта подключения внешних сканирующих фильтров:
1. через протокол milter (самый производительный)

 

2. интерфейс content_filter

(c точки зрения внутренних очередей постфикса - это AfterQueue: всех в очередь --> потом фильтруем внешними фильтрами, типа drweb'а --> потом встроенными типа

header-checks, bosy_checks + address rewriting по картам --> и только потом отдаем все демону постфикса cleanup --> доставка)

 

3. интерфейс smtpd_proxy_filter

(c точки зрения внутренних очередей постфикса - это BeforeQueue: всех фильтруем сначала внешними фильтрами, потом внутренними --> отдаем ответ клиенту --> перезаписываем адреса по необходимости и --> в очередь постфикса на доставку)

Maild интегрируется любым из вышеперечисленных способов, но так как он использует для сканирования несколько плагинов, то тоже приходится формировать уже свои внутренние очереди. Ничего общего с очередями постфикса они не имееют. Но зато порожадают уже maild'шные термины BeforeQueue и AfterQueue ))

В случае интеграции с Postfix любым из 3-х способов лучше ставить все сканирующие плагины maild в BeforeQueue, тут написано почему

http://forum.drweb.com/index.php?showtopic=313050&page=2


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

1. если нужно обеспечить высокую производительность, то стоит подключать сканирующие фильтры через libmilter

- при подключении drweb через libmilter Postfix не производит постановку письма в свою очередь до фильтрации (экономим время, ничего не пишем на диск).
по сути тут происходит передача данных, полученных из SMTP-сессии от smtpd,  ---> к drweb-milter по протоколу milter. А далее drweb-milter отдает конверт и тело на растерзание плагинам в maild.

- главная прелесть в том, что обработка соединений идет асинхронно,   - это главное отличие от варианта подключения внешних фильтров в Postfix посредством smtpd_proxy_filter (вариант BeforeQueue c т.з. манов постфикса) 

 

 

2. content_filter: если говорить упрощенно,  письмо вначале дампится в очередь postfix, потом передается внешнему фильтру, затем обратно возвращается в очередь постфикса incoming, если все хорошо (более подробно в манах Postfix - там вообще много деталей).

 

-главное тут, чтобы в main.cf вначале были перечислены все внешние фильтры, а потом уже встроенные, которые делают перезаписи заголовков, редиректы в служебные ящики, address-rewring и пр., иначе начнется каша

 

-если внешний фильтр задержит письмо (reject), сам фильтр (drweb-maild) может сгенерировать DSN + Postfix согласно настройкам может сгенерировать DSN, т.е. надо будет возиться с настройкми DSN тщательно, чтобы в них не захлебнуться потом.

 

-reject проверенного письма на момент поставновки обратно в очередь внутренними фильтрами содержимого, например могут блокировать фильтры на длину заголовков (плагины drweb добавили свои хидеры и т.п.), т.е. вероятно, потребуется ревизия  правил для внутренних фильтров.

 

3. c т.з. производительности и скорости самый плохой вариант - подключение посредством smtpd_proxy_filter

 

плохо потому, что синхронное взаимодействие:

 

- клиент открывает соединение с smtpd,  smtpd сразу передает письмо внешнему фильтру и начинает ждать ответа от фильтра, при этом соединение с клиентом не закрываем, надо вернуть ответ

- в итоге, чем больше клиентов, тем больше тредов smtpd = > больше тредов фильтра => нагрузка на сервер => кол-во писем в сек. меньше по сравнению с остальными вариантами подключения

- плюс, видимо только в том, что не надо дополнительно возиться с настройками DSN и настройками внутренних фильтров содержимого

 

 

 

мы рекомендуем первые два

Сообщение было изменено valya krasnobaeva: 19 Март 2013 - 15:18