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

Re: qmail or not qmail?



28 января 2010 г. 13:46 пользователь Alexey Pechnikov
<pechnikov@mobigroup.ru> написал:

> Специально для вас разыскал этот диалог между дебиан-девелоперами:
[...]
>> > > Yes, there are.
>> >
>> > No, there are not.
>>
>> Yes, there are.
>>
>> Next? ;-)

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

>> >> Больше 2Гб на _процесс_ открывает дырку.
>> > По-мелкому, но обманываете - там unsigned int - 4 Гб.
>> Разница не сильно большая на самом деле. Ну будет открыто не через
>> год, а через три.

> Схоластикой занимаетесь, по сути. Поскольку обработать заголовок большего
> размера нельзя, т.к. предел это для беззнакового целого. А использование
> long long нарушит переносимость. Так что полагаю, что эта же проблема есть
> во всех портабельных MTA. Раз уж вы до сих пор не сподобились посмотреть,
> почему этот "баг" не закрыт, опять приходится здесь объяснять.

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

>> Ну через пять. Один фиг - оригинальный кумыл точно дыряв, а за
>> патченый djb не отвечает.

> Хм, есть рассылка, где можете получить поддержку, есть дебиан-мантейнеры,
> с кем можно проконсультироваться и так далее. На необитаемый остров вовсе не
> похоже.

Угу... Похоже на деревню...

> Что касается именно использования множества патчей - тут я вас вполне
> понимаю. Именно потому, собственно, я сам и выбрал qmail, чтобы можно было
> нужную функциональность добавлять внешними утилитами. Ваш любимый
> отбой несуществующих адресатов может быть организован аналогично rblsmtpd,
> и если мне оно понадобится, то я воспользуюсь именно вспомогательной утилитой,
> вместо ковыряния исходников. Но возгласы вида "там есть патчи, усе пропало!",
> мне отнюдь не кажутся осмысленными, т.к. лишь чтук пять патчей закрывают
> дыры, а остальные это просто расширение функциональности, например, поддержка
> ldap (в дебиановском qmail ее как патч впихнули, хотя можно найти сборку именно
> qmail-ldap).

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

>> >> и про попадании не меньше чем в N - либо отопнуть, либо добавить хидер
>> >> с указанием.
>> > Насчет "не меньше чем в N" я не в курсе, обычно N==1.
>> И что вы будете делать, если ночью по местному какой-то из rbl
>> накроется и будет на всех говорить "это спамер", а утром должно придти
>> письмо из другого часового пояса? Или уважаемый клиент попал в один из
>> rbl потому что этот rbl заносит в спамеры целыми сетями?

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

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

>> >> Или патча, который позволит
>> >> проверить helo/from/to/ip внешними средствами и получить решение о
>> >> приёме до посылки ответа на DATA.
>> > Например, выбираете пункт "5.12. Отклонение недействительных получателей во
>> > время SMTP-сессии" в оглавлении, узнаете, что список соответствующих патчей
>> > доступен здесь: http://netdevice.com/qmail/rcptck/ и также вам предлагается
>> > ссылка на рекомендуемый патч.
>> Это нормальное поведение бОльшей части MTA.

> Вы просили _патч_, я вам на него дважды ссылку дал. Что ж вы теперь-то от него
> отмежеваться решили? Впрочем, выше я и альтернативный вариант привел, коль
> вы ссылки не смотрите...

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

>> > Так что причины - в бюрократии, увы.

>> Чтож... Пусть будет бюрократия. Хотя другие пакеты появляются хотя бы
>> в non-free.

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

И даже сделать пакет netqmail тоже не вышло бы?

>> >> Ой как всё запущено... То есть допустить, что юзер с uid 64010 в
>> >> системе может уже быть вы не в состоянии?
>> > Опять вы в чем-то непотребном мантейнера подозреваете :-) Позвольте мне
>> > все же отослать вас к preinst скрипту, вместо того, чтобы его целиком здесь
>> > приводить. Есть там такая проверка, не волнуйтесь.
>> Наличие проверки в данном случае означает всего-лишь невозможность
>> поставить кумыл при наличии юзера.

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

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

-- 
Stanislav

Reply to: