При каких условиях заблокируется SMTP при умершем контент-фильтре?

При F=T

каков вопрос, таков ответ...

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

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

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

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

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

используя CommunigatePro

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

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

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

Ага, спасибо. Буду копать) Но если что, всегда буду рад уточнениям)

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

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

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

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

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

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

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

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

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

Хм, тоже интересно, спасибо)) А если один из этих?

smtpInputActivep
smtpInputTotal

smtpInputActivep
smtpInputTotal

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

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