LINUX.ORG.RU

Ответ на: комментарий от AS

Да, прошу прощения. Попробую иначе. В настройках почтового сервера мы настраиваем максимальное кол-во входящих подключений с одного, а также со всех IP адресов. При превышении установленного порога, в следствии большого числа принимаемых сервером подключений, мы получаем ошибку примерно такого вида:
SMTP too many (50) streams open //где 50 - установленный лимит на подключения.
Как следствие, если происходит попытка превышения установленного порога (50 в данном примере), то плагин контент-фильтра блокирует дополнительные подключения.

Но что, если этот плагин зависнет? Просто перестанет работать? Т.е. по идее, установленное ограничение должно исчезнуть и на сервер может хлынуть поток различных подключений. Такое может произойти, например, от DDoS-атаки. Так вот. Что необходимо сделать, чтобы в случае выхода из строя плагина, SMTP-сессии прекратили открываться вообще? Чтобы произошла автоматическая блокировка.

Понятно, что можно настроить системный файерволл на ограничение максимального числа входящий сессий на внешнем интерфейсе. И вообще то говоря, так надо делать, но как можно справится с этой задачей средствами почтового сервера? В идеале, как с этим справиться, используя CommunigatePro, но если не на нём, то хотя бы просто в теории. А я уже попытаюсь экстраполировать.

Заранее спасибо.

zerropull ()
Ответ на: комментарий от AS

Или можно еще немного иначе задать данный вопрос:
«При каких условиях умерший плагин блокирует входящие SMTP сессии». О каком плагине речь, я объяснил в большом посте.

zerropull ()
Ответ на: комментарий от zerropull

используя CommunigatePro

Это вот самое главное. Ответ F=T верен для исходного вопроса, без последующего уточнения, но для Sendmail и фильтра, подключенного через milter. С учётом уточнения, для Sendmail, ещё настройка лимитов у самого MTA

то хотя бы просто в теории.

В теории, за лимитом количества сессий должен следить MTA, а не плагины. Мне кажется, CGP это должен уметь.

AS ★★★★★ ()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

Требуется уточнение. MTA должен умень это изначально или это должно как либо настраиваться? Если второй вариант, то я буду искать, но если это должно происходить автоматически, то как работает механизм? Не обязательно все подробно объяснять. Но хотя бы подскажите, как эту инфу найти.

zerropull ()
Ответ на: комментарий от zerropull

Но если что, всегда буду рад уточнениям)

CGP я и не видел никогда, только слышал. :-)

Но хотя бы подскажите, как эту инфу найти.

В Гугле искать что-то вроде: «CommunigatePro connections limit». Можно «rate limit» заодно.

AS ★★★★★ ()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

Понятно)) Вот в разделе Триггеры я нашел такую опцию: smtpInputReverseFailed Это может быть она? Выглядит так:
Элемент: smtpInputReverseFailed
Обработчик: Warning (тут выбор - Warning или ничего)
Граница: выбирается число. Я так понимаю, что число ошибок до срабатывания триггера.
За: Временной промежуток в секундах.

Пишу всё это потому, что даже примерно не представляю, как надо имитировать данную ситуацию, чтобы проверить догадку.

zerropull ()
Ответ на: комментарий от zerropull

я нашел такую опцию: smtpInputReverseFailed Это может быть она?

Однозначно нет, но штука хорошая. Можно, видимо, блокировать отправителя при большом количестве ошибок (попыток доставки на левые локальные E-Mail, к примеру).

AS ★★★★★ ()
Ответ на: комментарий от zerropull

smtpInputActivep
smtpInputTotal

У меня даже CGP нет. Проверь. Сделай меньше нормы и посмотри, упрётся, или нет.

По поводу smtpInputReverseFailed. Что-то я ночью «Reverse» пропустил. В общем, читай внимательно, к чему оно относится. «Reverse» намекает на PTR, но такого рода триггер для PTR странен.

AS ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.