Re: qmail or not qmail?
Alexey Pechnikov -> debian-russian@lists.debian.org @ Sat, 30 Jan 2010 00:53:01 +0300:
>> Слушай, а давай ты не будешь рассуждать о вкусе устриц, которых ты
>> не ел? А то если начать нашей корпоративной почтовке рассказывать,
>> что ради доставки почты по UUCP и проверки ее на спам и вирусы
>> пришлось лезть в самое нутро, она тебя так обсмеет, что тебе это
>> DDoS'ом покажется, и никакой qmail не спасет...
AP> Как поставить отдельные обработчики для локально и удаленно
AP> доставляемой почты? Как назначить разные обработчики для почты,
AP> пересылаемый на разные хосты? И так далее. А тупая обработка _всей_
AP> принятой почты одинаково - даром не нужна.
Что значит "как"? Для локально и удаленно доставляемой они там уже
разные. Прямо в поставке. Для некоторых хостов я почту отправляю по
UUCP. Делается это через transport_maps.
Или тебе какую обработку? Если ты говоришь о локально vs. удаленно
_доставляемой_, то там остается уже только отправлялка.
>> А что до "движок монолитный" - так с таким аргументом, как твой, у нас у
>> всей системы движок монолитный - /lib/libc*... busybox-static только
>> отдельно...
AP> У вас?.. Может быть. А qmail собран с diet libc ;-)
Ну, значит, у твоего qmail отдельный монолитный движок.
AP> И притом, запуская qmail-smtpd, я могу быть уверен, что код для
AP> работы с pop или imap в принципе не задействован, так что мне не
AP> требуется о нем думать (не нужны мне эти довески). А в postfix все
AP> перемешано, и уязвимость в общей либе может "выстрелить" в любой
AP> момент.
А в postfix кода pop или imap нет вообще. Поэтому я не "могу быть
уверен", а просто уверен, что он не задействуется. А уязвимость в
dietlibc и в твой qmail может выстрелить в любой момент.
AP> В qmail я полностью контролирую выполняемый код
Что, лично аппрувишь каждую процессорную инструкцию?
AP> и это большое преимущество, в то же время в любой момент, если
AP> вдруг мне понадобится pop или imap доступ сделать (хотя зачем?), я
AP> могу тут же запустить нужный обработчик (через tcpserver). Могу
AP> через stunnel соединяться, или ssl-enabled tcpserver
AP> запустить... все идеально настраиваемо. В то время как в постфикс
AP> засунута поддержка ssl через фиг знает что,
Ты не поверишь - через абсолютно тот же самый libssl, что stunnel. И
запустить postfix через stunnel - тоже никаких проблем. А вот как ты
будешь через stunnel передавать в qmail авторизацию по клиентскому
сертификату так, чтоб qmail это понял - это я б посмотрел...
И как ты будешь с stunnel или tcpserver реализовывать STARTTLS на 25
порту - это я б тоже посмотрел...
--
The last good thing written in C was Franz Schubert's Symphony number 9.
-- Erwin Dieterich
Reply to: