Re: qmail or not qmail?
27 января 2010 г. 23:50 пользователь Alexey Pechnikov
<pechnikov@mobigroup.ru> написал:
>> >> > Единственный серьезный баг в qmail - на превышение 2 Гб хидера - вас
>> >> > ровно так же не затрагивает. Причем есть путь обхода (ограничение
>> >> > ресурсов), причем это уже прописано в дебиановском init-скрипте и для
>> >> > нас с вами представляет не более чем теоретический интерес.
>> >> При этом, эксплуатация бага возможна в случае, если ограничение
>> >> ресурсов поставить больше, чем на 2Гб вообще, а не 2Гб на хидер.
>> > Больше 2Гб на письмо? Оно вам надо?.. Притом в дебиановской сборке, если
>> > уж на то пошло, 4 Гб...
>> Больше 2Гб на _процесс_ открывает дырку.
> По-мелкому, но обманываете - там unsigned int - 4 Гб.
Разница не сильно большая на самом деле. Ну будет открыто не через
год, а через три.
>> А Nxx мегабайт на письмо, да еще не факт, что не одновременно
>> несколько - это хотят пользователи. Пока еще только хотят.
> Попробуйте exim-ом такое письмо обработать, подозреваю, что проблемы
> словите много раньше, чем достигнете 4 Гб размера письма. Что касается
> нескольких, то qmail письма в отдельных процессах обрабатывает, так
> что лимит касается именно одного письма.
Ну через пять. Один фиг - оригинальный кумыл точно дыряв, а за
патченый djb не отвечает.
>> >> Процитируйте. Или не приписывайте лишнего.
>> > Вы же утверждали, что даже ошибки exim нам даны свыше и мы обязаны их
>> > смиренно принимать, не пытаясь заменить exim.
Процитируйте.
>> > А вот 1 ошибка qmail с
>> > переполнением в заголовке вам спать почему-то не дает.
>> Процитируйте, где я вообще говорил про ексим.
> Помню, у вас постфикс. Суть дела от этого не меняется, т.к. исходники
> постфикса, насколько я понимаю, вы тоже не смотрели. Но почему-то
> доверяете, что там нет багов...
Я доверяю команде дебиана в данном случае, ибо то, что есть в дебиане
- меня удовлетворяет как по безопасности, так и по функциональности.
В случае кумыла если с безопасностью пока (до увеличения лимитов) всё
хорошо, то с нужной функциональностью там не очень.
>> Про ошибки - мог не так выразиться, но тем не менее, данная ошибка
>> вполне себе даёт удалённого рута, если правильно помню.
> Не факт, что в других системах нет такой же ошибки. Но qmail очень
> тщательно тестировали и тестируют, в т.ч. благодаря громкому заявлению
> DJB о выплате денег за секьюрити баги.
djb не заплатит денег за патченый кумыл и я его понимаю в этом.
При этом без патчей кумыл неюзабелен.
>> С 0 - не напишу. Не с нуля - не вижу патча, который позволил бы хотя
>> бы проверить по списку RBL
> Для этого патч не нужен. Используйте rblsmtpd.
Его недостаточно.
>> и про попадании не меньше чем в N - либо отопнуть, либо добавить хидер
>> с указанием.
> Насчет "не меньше чем в N" я не в курсе, обычно N==1.
И что вы будете делать, если ночью по местному какой-то из rbl
накроется и будет на всех говорить "это спамер", а утром должно придти
письмо из другого часового пояса? Или уважаемый клиент попал в один из
rbl потому что этот rbl заносит в спамеры целыми сетями?
>> Или патча, который позволит
>> проверить helo/from/to/ip внешними средствами и получить решение о
>> приёме до посылки ответа на DATA.
> Вот что касается патчей (по ссылке выше можете посмотреть и другие ресурсы):
> http://www.ru.qmail.org/docs/lwq/lwq.html#patches
> Например, выбираете пункт "5.12. Отклонение недействительных получателей во
> время SMTP-сессии" в оглавлении, узнаете, что список соответствующих патчей
> доступен здесь: http://netdevice.com/qmail/rcptck/ и также вам предлагается
> ссылка на рекомендуемый патч.
Это нормальное поведение бОльшей части MTA.
>> > Если вы, конечно, не захотите прежде подумать - почему
>> > мантейнер деб-пакета не делает этого.
>> Вероятные причины (судя по неполным аналогам из открытых багов):
>> 1) добавил разрозненные патчи, покрывающие какую-то функциональность и
>> успокоился.
>> 2) не предлагали что-то похожее.
> Ну что с вами сделать, чтобы вы перестали на кофейной гуще гадать :-)
[...]
> Так что причины - в бюрократии, увы.
Чтож... Пусть будет бюрократия. Хотя другие пакеты появляются хотя бы
в non-free.
>> Ой как всё запущено... То есть допустить, что юзер с uid 64010 в
>> системе может уже быть вы не в состоянии?
> Опять вы в чем-то непотребном мантейнера подозреваете :-) Позвольте мне
> все же отослать вас к preinst скрипту, вместо того, чтобы его целиком здесь
> приводить. Есть там такая проверка, не волнуйтесь.
Наличие проверки в данном случае означает всего-лишь невозможность
поставить кумыл при наличии юзера.
--
Stanislav
Reply to: