ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Почтовый прокси



Anton Yuzhaninov wrote:
1. сократить число тех коннекций которые доходят до MTA
Наличие фронтенда перед exim, postfix, и т. д. позволит: Точно
позволит? Тут, по-моему, pf полезней будет.

Для входящих mx - pf не может сказать клиенту ошибку 550 с текстом и
URL, и если на заблокированном IP вдруг окажется честный отправитель,
он не будет знать почему его почта не принимается и что ему нужно
сделать, чтобы она стала приниматься.
Издревле принято в таких случаях писать письмо постмастеру :-)

Если без шуток, действительно, как обычно, 10% средств хватает для решения 90% задачи. Для того, чтобы послать лесом глупых спамеров, немного надо. А с умными уже нехай МТА (backend) борется со всей изощрённостью. Только надо оному МТА оставить возможность сделать отлуп на любой стадии SMTP сессии, а не только после DATA. И позаботиться о том, чтобы это был фронтенд для МТА, а не фронтенд для постфикса.

Для клиентского smtp pf совсем но подходит - тут принципе нет таких IP
которые нужно блокировать. На одном IP если это NAT может сидеть как N
машин с вирусами, так и честные пользователи. Вируса либо отваливаются
по таймауту ничего не сказав, либо пытаются говорить MAIL FROM не
сказав предварительно AUTH. pf тут не поможет отфильтровать тех
кто говорит auth, от тех кто не говорит этого.
Почему же? Немножко подходит :-) synproxy, rdr round-robin, шейпер вполне могут некоторые полезные задачи решить.

Но я не спорю, обработка соединений там, где обязательно SMTP AUTH - самая подходящая задача для фронтенда. Единственное, что при этом требуется - проверить имя/пароль. Больше ничего проверять не надо.

P.S. В любой ипостаси фронтенд должен показать МТА всю SMTP сессию. IMHO это непреложное условие.



 




Copyright © Lexa Software, 1996-2009.