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

Re: qmail or not qmail?



28 января 2010 г. 18:36 пользователь Alexey Pechnikov
<pechnikov@mobigroup.ru> написал:
>> > Специально для вас разыскал этот диалог между дебиан-девелоперами:
>> >> > No, there are not.
>> >> Yes, there are.
>> >> Next? ;-)

>> Красиво, душевно :-)

> Дискуссия была очень похожа на нашу - одни с успехом используют, другие нет,
> взаимопонимания по непонятным причинам не наблюдается.

В нашей дискуссии как раз понятно. Вы предпочитаете самостоятельно
суперклеем склеивать велосипед из деталей очень разного происхождения,
я - взять работающее решение, соединённое болтами, которые иногда надо
подтягивать (в последний раз требовалось месяца два назад - поставил
дрвеб, ибо у начальника инфобезопасности профессиональная паранойя и
кламаву он недостаточно доверяет, в предпоследний - в сентябре, когда
топам захотелось попосылать файлы в 100Мб).

>> Кто-то говорил, что надо обрабатывать заголовок такого размера?
>> Достаточно, если при попадании такого письма МТА не будет падать или
>> открывать дыру.

> В этом смысле все предпочитают ограничивать размер письма. Собственно,
> поправить-то несложно, просто видимо никому не надо было (хотя можно и патч
> поискать, например, посмотреть в том же netqmail, я в него давно не заглядывал).

Я в это верю. Просто когда на это указали djb и какое нынче число?
Сколько лет прошло?

>> Мне проще сделать белый список откуда принимать обязательно и
>> проверять остальных внешними листами, чем принимать в два раза больше
>> почты только потому, что образовался очередной ботнет, не попавший в
>> мой рбл.

> Поищите, вроде где-то я видел доработанный вариант под это дело. Мне он не
> был интересен, так что ссылку не сохранил. Опять же, это внешняя утилита,
> которая на безопасность qmail не влияет.

Дешевле взять проверенное в N местах решение, чем клеить велосипед.

>> Ссылки я смотрю. Главная засада в приведенных вами патчах - они каждый
>> делает какой-то кусочек проверки. А надо - комплекс. Вторая засада -
>> нет уверенности, что даже если каждый патч безопасен, будет безопасно
>> их сочетание.

> Они к разным утилитам относятся, так что не конфликтуют. Опять же, сборка

Не всегда. Часть того, что мне могло бы потребоваться - патчила smtpd.
Сильно не разбирался, но не факт, что они патчили не один и тот же файл.

> http://dbn.smarden.org/sid/ выделяет и отдельную утилиту для "отбоя", чтобы
> не менять оригинальный код ради нового функционала (и DJB это же советует).

Не возражаю, но тогда не вижу смысла именно в кумыле, если все дырки
прикрываются снаружи.

>> > Так и qmail есть в non-free. Речь идет о замене существующего пакета более
>> > функциональным.
>> И даже сделать пакет netqmail тоже не вышло бы?

> И такой пакет есть, лежит в репозитории Gerrit Pape (если не ошибаюсь, для всех
> релизов дебиана, начиная с potato). В 2007-м году, когда qmail был передан в
> public domain, Gerrit пакеты зааплодил на ftp-master - и вот, ждем...

Подозреваю - из-за отсутствия такой уж большой необходимости в кумыле
именно в дистрибутиве.

>> У меня юзеры из LDAP начинаются с uid 10000. При этом, с uid >64000 -
>> технические юзеры типа бекапилки или нагиоса. Привязку программы к
>> какому-либо uid/gid кроме 0 я бы назвал технической проблемой
>> разработчика.

> Во-первых, см. дебиан полиси, где это отнюдь не запрещается. Во-вторых,
> запускать весь софт от рута - это вы через край хватили.

Э... Запуск и привязка - разные вещи.
Скажем, uid для daemon в дебиане равен 1, а в RH - уже 2. Если
какая-либо софтина посчитает, что для запуска под daemon ей необходимо
и достаточно сменить uid на 1, то её автор просчитался. Здесь -
аналогично.

-- 
Stanislav

Reply to: