27 января 2010 г. 23:50 пользователь Alexey Pechnikov <pechni...@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