В принципе можно, поскольку это на уровне правил.
А она у вас вообще включена? Что-то я в стандартной конфигурации вообще не вижу подключение плагина tcp_list.
MaxConnectionFromIP без подключения плагина и редактирования правил вообще не обрабатывается. Никак. Есть общее ограничение, задаваемое через MaxConnections.
mixsv пишет: Я так понимаю, что после включения плагина, в OnConnect.rules.txt в начало надо прописать что-то вроде PeerIP:Mask= 10.0.0.128:255.255.255.128 | \EOF
Тогда не будет выполнена строка SMTP. Не вызовет ли это колизий?
Тогда подключения из этой подсети не будут обрабатываться вообще.
pig пишет: MaxConnectionFromIP без подключения плагина и редактирования правил вообще не обрабатывается. Никак. Есть общее ограничение, задаваемое через MaxConnections.
Странно. А мне показалось, что обрабатывается. Я поясню.
Мой сервер работает как транзитный для отправки писем наружу для одной сторонней организации. Все письма приходят как бы с одного адреса. Они частенько осуществляет рассылку 22-35 писем.
Когда стояло значение по умолчанию MaxConnectionFromIP=20, 21-ое письмо в рассылки отвергалось. После установки параметра MaxConnectionFromIP=30 такие рассылки стали проходить нормально и только при превышении 30 отвергались.
То, что вы говорите, — это не MaxConnectionsFromIP, а, скорее всего, MaxMsgsNumber, ограничение количества писем на одно подключение. Там формула отказа 452 Too many mails per session. Есть ещё MaxRcptNumber, ограничение числа адресатов на письмо. Естественно, оба можно отключить или ослабить в зависимости с том числе и от IP.
Использование:
в начале OnConnect.rules.txt — проверка, типа:
NCONN 10 > | CloseConnection \EOF
или типа: PeerIP:Mask= 10.0.0.128:255.255.255.128 | NCONN 10 > | CloseConnection \EOF
Также допускается проверка и при любых других событиях,
например, после авторизации.
И чтобы исключить определенный адрес правило должно выглядеть как-то так
Давайте не будем гадать. Покажите лог команд и ответов — там увидим, по какому параметру отказ идёт и что надо крутить.
Дело в том, что MaxConnections явно никому отказа не даёт — просто приём соединения задерживается, пока кто-нибудь не отключится. Это ваш случай? Я понял, что нет — установилось подключение, пошли письма, потом после энного письма отказ и выключение. Или я неправильно понимаю?
P.S. Подключение tcp_list с его возможностями, ограничение на MaxConnections не снимает. Просто позволяет ставить дополнительные ограничения.
Это одна из рассылок. Как видите 10054 — это принудительный разрыв соединения. Я думал, что это связано с MaxConnectionsFromIP, но уменьшив это число до 10 и сделав тестовую рассылку, я убедился, что этот параметр не причем.
И конечно, я понимаю, что TCP_List не оказывается влияние на MaxConnections, мой вопрос по строке правила для TCP_List связан с интересом с подготовкой к работе сервера MX-ом и возможностью использования параметра MaxConnectionsFromIP для предотвращения массовых рассылок из инета.
И еще. Обратите внимание, в логе сформировано письмо на postmaster@localhost. Откуда оно берется — непонятно. Но т.к. такого адреса нет отправителю поступает письмо с 550 ответом об отсутствии такого адреса. Это вводит в заблуждение. Но, что это такое и как бороться — не знаю.
Лучше бы не это смотреть, а командный лог — DATA\log\smtp\200704log.txt
Но криминала тут не вижу. 10054 — это когда соединение рвёт "та сторона". Или они сами отвалились, или файрвол забодал. Eserv тут ни при чём. Про postmaster@localhost надо спрашивать отправителя user3222@kru.minfin39.ru на IP-адресе 192.168.20.4 — он отправлял. Возможно, отвечал кому-то.
В командном логе нет ничего странно. Там нет даже информации о postmaster@localhost.
Ну с этим ладно, понаблюдаю еще, посмотрю, там видно будет. Криманала действительно нет, письма то доходят исправно.
Что скажите по правилу выше? Я правильно его изобразил.
Только я бы воткнул его в OnThreadConnect, куда-нибудь в начало, перед или сразу после обработки SMTP[Active], и сделал примерно такого вида:
PeerIP:Mask= 10.0.0.128:255.255.255.255 0= [IF]
NCONN SMTP[MaxConnectionsFromIP] >NUM > [IF]
" 451 Sorry, too many connections from your IP [{CLIENT}]. Please try again later.{CRLF}" SMTP_FPUTS StopProtocol \EOF
[THEN]
[THEN]
[IF] — [THEN] просто потому, что строки длинные и заворачиваются.
А она у вас вообще включена? Что-то я в стандартной конфигурации вообще не вижу подключение плагина tcp_list.
Плагин TCP_List в CommonPlagins присутствует, но где он включается и для чего предназначен я не знаю.
Раз параметр MaxConnectionsFromIP обрабатывается и без плагина, то значит где-то это зашито. В OnConnect.rules.txt всего одна строка — SMTP.
Я так понимаю, что после включения плагина, в OnConnect.rules.txt в начало надо прописать что-то вроде
PeerIP:Mask= 10.0.0.128:255.255.255.128 | \EOF
Тогда не будет выполнена строка SMTP. Не вызовет ли это колизий?
Тогда подключения из этой подсети не будут обрабатываться вообще.
Странно. А мне показалось, что обрабатывается. Я поясню.
Мой сервер работает как транзитный для отправки писем наружу для одной сторонней организации. Все письма приходят как бы с одного адреса. Они частенько осуществляет рассылку 22-35 писем.
Когда стояло значение по умолчанию MaxConnectionFromIP=20, 21-ое письмо в рассылки отвергалось. После установки параметра MaxConnectionFromIP=30 такие рассылки стали проходить нормально и только при превышении 30 отвергались.
А MaxConnections достаточно большое.
Но раз вы говорите, что не обрабатывается, надо еще раз понаблюдать.
Тогда вопрос по использованию TCP_List.
Там в плагине есть пример использования:
Использование:
в начале OnConnect.rules.txt — проверка, типа:
NCONN 10 > | CloseConnection \EOF
или типа:
PeerIP:Mask= 10.0.0.128:255.255.255.128 | NCONN 10 > | CloseConnection \EOF
Также допускается проверка и при любых других событиях,
например, после авторизации.
И чтобы исключить определенный адрес правило должно выглядеть как-то так
PeerIP:Mask= 10.0.0.128:255.255.255.255 0= | NCONN SMTP[MaxConnectionsFromIP] > | CloseConnection \EOF
Дело в том, что MaxConnections явно никому отказа не даёт — просто приём соединения задерживается, пока кто-нибудь не отключится. Это ваш случай? Я понял, что нет — установилось подключение, пошли письма, потом после энного письма отказ и выключение. Или я неправильно понимаю?
P.S. Подключение tcp_list с его возможностями, ограничение на MaxConnections не снимает. Просто позволяет ставить дополнительные ограничения.
2007-03-28 17:20:59;user3222@kru.minfin39.ru;r35020@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:20:59;user3222@kru.minfin39.ru;r35017@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:20:59;user3222@kru.minfin39.ru;r35018@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:20:59;user3222@kru.minfin39.ru;r35022@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:21:01;user3222@kru.minfin39.ru;r35010@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:20:59;user3222@kru.minfin39.ru;r35019@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:21:00;user3222@kru.minfin39.ru;r35016@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:20:59;user3222@kru.minfin39.ru;r35021@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:21:00;user3222@kru.minfin39.ru;r35015@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:21:02;user3222@kru.minfin39.ru;r35004@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:21:00;user3222@kru.minfin39.ru;r35014@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:21:02;user3222@kru.minfin39.ru;r35005@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:21:01;user3222@kru.minfin39.ru;r35007@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:21:02;user3222@kru.minfin39.ru;r35006@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:21:01;user3222@kru.minfin39.ru;r35012@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:21:01;user3222@kru.minfin39.ru;r35011@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:21:01;user3222@kru.minfin39.ru;r35009@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:21:04;user3222@kru.minfin39.ru;r35003@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:21:05;user3222@kru.minfin39.ru;r35002@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:21:05;user3222@kru.minfin39.ru;r35001@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:21:02;user3222@kru.minfin39.ru;postmaster@localhost;0;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;550
2007-03-28 17:21:14;postmaster@kru.minfin39.ru;user3222@kru.minfin39.ru;88967;<34397968c402ab$9edca520$0208a8c0@LOCALHOST>;127.0.0.1;0
2007-03-28 17:21:01;user3222@kru.minfin39.ru;r35013@rayons.ru;67200;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;10054
2007-03-28 17:21:01;user3222@kru.minfin39.ru;r35008@rayons.ru;54400;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;10054
2007-03-28 17:21:22;user3222@kru.minfin39.ru;r35008@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
2007-03-28 17:22:14;user3222@kru.minfin39.ru;r35013@rayons.ru;87928;<000b01c77144$4df95850$3564a8c0@finans.local>;192.168.20.4;0
Это одна из рассылок. Как видите 10054 — это принудительный разрыв соединения. Я думал, что это связано с MaxConnectionsFromIP, но уменьшив это число до 10 и сделав тестовую рассылку, я убедился, что этот параметр не причем.
И конечно, я понимаю, что TCP_List не оказывается влияние на MaxConnections, мой вопрос по строке правила для TCP_List связан с интересом с подготовкой к работе сервера MX-ом и возможностью использования параметра MaxConnectionsFromIP для предотвращения массовых рассылок из инета.
И еще. Обратите внимание, в логе сформировано письмо на postmaster@localhost. Откуда оно берется — непонятно. Но т.к. такого адреса нет отправителю поступает письмо с 550 ответом об отсутствии такого адреса. Это вводит в заблуждение. Но, что это такое и как бороться — не знаю.
Но криминала тут не вижу. 10054 — это когда соединение рвёт "та сторона". Или они сами отвалились, или файрвол забодал. Eserv тут ни при чём. Про postmaster@localhost надо спрашивать отправителя user3222@kru.minfin39.ru на IP-адресе 192.168.20.4 — он отправлял. Возможно, отвечал кому-то.
Ну с этим ладно, понаблюдаю еще, посмотрю, там видно будет. Криманала действительно нет, письма то доходят исправно.
Что скажите по правилу выше? Я правильно его изобразил.
Только я бы воткнул его в OnThreadConnect, куда-нибудь в начало, перед или сразу после обработки SMTP[Active], и сделал примерно такого вида:
[IF] — [THEN] просто потому, что строки длинные и заворачиваются.
Большое спасибо за помощь и внимание.
Еще раз спасибо.