Вышел sendmail 8.13.6: устранена серьезная уязвимость

> Никаких проблем, крое, конечно, времени.

А время у вас, конечно же, бесплатно? Тогда возвращайтесь в свою
песочницу, нам говорить не о чем ;)

Разве это возможно в принципе ? ;-) Если серьёзно 1- сначала на тестовой машине потом на сервер. А если всё же - собирал sendmail достаточно раз что бы сказать, что сборка проходит без проблем.

> Разве это возможно в принципе ? ;-)

Легко. Глянь чэндждлог на slackware-current. Буквально вчера ошибка в
сборке X.org.

> Если серьёзно 1- сначала на тестовой машине потом на сервер.

Дык, уважаемый... Это уже явно не одна секунда, как было тут заявлено ;)
А помножьте на сотню удаленных серваков? Вполне интересные цифры
получаются. Очень это дорогое удовольствие получается - содержать
sendmail в качестве MTA.

Что за тяжелый бред с обновлениями?

Новые администраторы не умеют делать yum -y update sendmail или apt-get update && apt-get upgrade?

Хоть на тысяче серверов это делается автоматически и занимает по времени от секунд до минут в зависимости от скорости канала.

> Мне еще хотябы один обслуживаемый домен нужен, его я тоже угадывать не хочу.

следующим вопросом, я так понимаю, будут рутовые пароли к этому серваку? :)

> > Никаких проблем, крое, конечно, времени.

> А время у вас, конечно же, бесплатно? Тогда возвращайтесь в свою
> песочницу, нам говорить не о чем ;)

Говорить, действительно, не о чем. :-) лучше я один раз потрачу его на апдейт в нное количество времени, чем буду переделывать отлаженну и хорошо, а главное, предсказуемо работающую систему на какую-то хрень. Пробовали уже. Сколько раз пробовали, столько раз на шлимыло и откатывались. Надоело. Я уже давно не готов после выхода каждой новой версии какого-либо другого MTA делать попытки уйти на него, хорош. Думаю, следующий этап будет smX, в тот же момент еще посмотрю на Exim.

>Дык, уважаемый... Это уже явно не одна секунда, как было тут заявлено ;) 1 сек - время на РЕстарт. До и после sendmail работает.

>А помножьте на сотню удаленных серваков? Вполне интересные цифры получаются.

Если эта 100 удаленных серваков на разных ОС/версиях ОС, тогда при обновлени/добавлении/изменении софигурации/функициональности (последнее для фенов qmail) любого ПО вопрос непростой.

Однко при правильном подходе к делу - учет, унификация версий,параметров сборки/конфигов/версий ПО всё не так уж и страшно..

> > А что мешает остановить ?

> Вах. И это говорит админ? Или программер, а админ по совместительству?

Это говорит человек, который представляет, о чем говорит. В отличие от. service sendmail restart - это ничто по сравнению с reload на какой-нибудь семитысячной кошке. :-)

> во-во, нука назови его. Не online.de часом ?

Кстати, похоже, они-таки избавились от qmail. Или, всё-таки, "объяснили" ему, что такое вменяемость...

> Доменное имя по IP никогда не учили находить?

реверс - это еще не обслуживаемый почтовый домен:

mail from:<>
250 ok
rcpt to:<postmaster@stoneport.math.uic.edu>
553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)
rcpt to:<postmaster@math.uic.edu>
553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)

Админ, блин. :-)

> Что за тяжелый бред с обновлениями?

> Новые администраторы не умеют делать yum -y update sendmail или apt-get update && apt-get upgrade?

> Хоть на тысяче серверов это делается автоматически и занимает по времени от секунд до минут в зависимости от скорости канала.

У провайдеров и больших компаний есть специально разработанные процедуры установки патчей и апгрейдов. Для этого они делают специальный стенд, на котором выполняют апгрейд, потом направляют на этот стенд поток почты ( это не 1 - 2 письма, а гигабайты ) и проверяют живучесть системы. Только после этого пишется подробный план апгрейда основной системы, оповещаются пользователи о возможных проблемах и выполняется непосредственно апгрейд. На это уходит от недели до месяца. Если не следовать такой процедуре и в момент апгрейда случится хоть малейший сбой, то в службу тех поддержки придет несколько миллионов жалоб от клиентов и она просто "утонет". Поэтому большой конторе выгоднее поставить "лишний" сервер с надежной системой, которую не нужно обновлять каждый месяц, чем жить как на пороховой бочке. По-этому и используют debian или Solaris (а в последнее время еще и RHES) в качестве серверов, apache в качестве web и qmail для приема почты.

> реверс - это еще не обслуживаемый почтовый домен:
> mail from:<>

А зачем первые две строчки с ответом 220 обрезал? Там MTA как раз сам
светит свое доменное имя. Будь добр его использовать, догадливый ты наш ;)

>Дык, уважаемый... Это уже явно не одна секунда, как было тут заявлено ;) 
>А помножьте на сотню удаленных серваков? Вполне интересные цифры 
>получаются. Очень это дорогое удовольствие получается - содержать 
>sendmail в качестве MTA.

Чепуха.
Если у вас работает ровно один сервер, и на него принимается по 5000 писем в секунду,
то, конечно, простой в течение пяти минут - это фатально.

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

>> mail from:<>

> А зачем первые две строчки с ответом 220 обрезал? Там MTA как раз сам
> светит свое доменное имя. Будь добр его использовать, догадливый ты
> наш ;)

Там MTA может светить всё, что его душе угодно. Хоть член. Хочешь сказать, что a.mx.cr.yp.to - это домен ? :-)

> и потому раскидать пусть даже на 100 машин обновленный пакет - вовсе не проблема.

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

> используется несколько почтовых серверов,

Тут этого, похоже, не понимают. И не понимают, что когда огранизован лоад балансинг, отключение одного сервера практически незаметно.

>У провайдеров и больших компаний есть специально разработанные процедуры установки патчей и апгрейдов. Для этого они делают специальный стенд, на котором выполняют апгрейд, потом направляют на этот стенд поток почты ( это не 1 - 2 письма, а гигабайты ) и проверяют живучесть системы. Только после этого пишется подробный план апгрейда основной системы, оповещаются пользователи о возможных проблемах и выполняется непосредственно апгрейд. На это уходит от недели до месяца. Если не следовать такой процедуре и в момент апгрейда случится хоть малейший сбой, то в службу тех поддержки придет несколько миллионов жалоб от клиентов и она просто "утонет". Поэтому большой конторе выгоднее поставить "лишний" сервер с надежной системой, которую не нужно обновлять каждый месяц, чем жить как на пороховой бочке. По-этому и используют debian или Solaris (а в последнее время еще и RHES) в качестве серверов, apache в качестве web и qmail для приема почты.

Чего-чего? Т.е. вы хотите сказать, что если выключить почтовый сервер, скажем, на час (!) (и пусть существует всего одна mx запись для обслуживаемых доменов), то вся почта пропадет? Очевидно, что вы совсем не в курсе как работают системы по протоколу smtp.

>Bogerm * (*) (23.03.2006 14:01:53)

> Там MTA может светить всё, что его душе угодно. Хоть член. Хочешь сказать, что a.mx.cr.yp.to - это домен ? :-)

Хочу сказать, что это доменное имя машины, на которой живет MTA, и
которое легко проверяется простым запросом к DNS. А искомы домен -
cr.yp.to. Только идиот мог не догадаться. Это дом, где живет qmail ;)

> если выключить почтовый сервер, скажем, на час (!) (и пусть существует всего одна mx запись для обслуживаемых доменов), то вся почта пропадет?

Чо дурачка-то строить? Почта может и не пропадет, а вот телефон
провайдера раскалится до бела.

>Время, сестра, назови время! С учетом всех телодвижений! Потом назови стоимость его единицы, потом помножь на 100 и результат кинь в студию.

От 10 минут до часа на все про все, в зависимости от того, как настроена система автообновлений.

То есть, сначала сборка всего этого на тестовой машине, тестирование на стабильность работы и __после__ этого - от 10 минут до часа рабочего времени. И то - только для того, чтобы не рестартовать сервис на всех машинах одновременно, а ждать окончания уже установленных почтовых сессий.

P.S. Если у Вас в парке сто однотипный машин-почтовых серверов, и Вы обновляете ПО на них руками, есть повод задуматься о Вашей пофпригодности.

> Чего-чего? Т.е. вы хотите сказать, что если выключить почтовый сервер, скажем, на час (!) (и пусть существует всего одна mx запись для обслуживаемых доменов), то вся почта пропадет? Очевидно, что вы совсем не в курсе как работают системы по протоколу smtp.

Если мой провайдер выключит мне почту на час в то время когда я жду важного письма, то он пойдет лесом. Если это сделает админ в большой конторе ( более 10 тыс. пользователей ), то он будет уволен. Рассказывать байки про MX рекорды и теорию рутинга он будет дома своей бабушке.

> От 10 минут до часа на все про все, в зависимости от того, как настроена система автообновлений.

Ну, то есть 100 часов на 100 машин по максимуму? Ну что же... ерунда
совсем, пустяк. Множим на 100 баксов... всего в 10 штук обошлось вам
такое обновление. Ничего, терпимо. Бывает хуже ;)

> P.S. Если у Вас в парке сто однотипный машин-почтовых серверов, и Вы обновляете ПО на них руками

Опа, а что если среди них есть linux'ы, sunOS, openBSD и freeBSD всех
мастей и оттенков? Я уже конечно задумался о моей профпригодности, но...

>Если мой провайдер выключит мне почту на час в то время когда я жду важного письма, то он пойдет лесом. Если это сделает админ в большой конторе ( более 10 тыс. пользователей ), то он будет уволен. Рассказывать байки про MX рекорды и теорию рутинга он будет дома своей бабушке

Откройте для себя, что такое load balancing. Уверяю, у __нормального__ провайдера Вы даже не заметите, что вместо одной машины стала работать другая.

Никакой вменяемый сисадмин не остановит сразу __все__ машины, обслуживающие MX. И потому даже без балансировки нагрузки почта все равно будет доставлена. С использованием балансировки даже IP адрес останется прежним.

А вот если в конторе 10000 пользователей и у нее ровно один почтовый сервер..... лол, короче.

> Хочу сказать, что это доменное имя машины, на которой живет MTA, и
> которое легко проверяется простым запросом к DNS.

Говорю же - не хочу гадать.

> А искомы домен - cr.yp.to.

Ok.

> Только идиот мог не догадаться. Это дом, где живет qmail ;)

да-да-да. :-)

mail from:<>
250 ok
rcpt to:<jsajasbvja@cr.yp.to>
250 ok
data
354 go ahead
test
.
250 ok 1143112860 qp 63140

Ну вот, что и следовало ожидать. Принято сообщение на взятый с потолка E-Mail. Это означает, что данный домен можно легко использовать спамеру для генерации фиктивных обратных E-Mail.

1. Спам легко пройдёт проверку на smtp callback.
2. на cr.yp.to посыпется вагон отлупов и создаст нехилый трафик.

>Ну, то есть 100 часов на 100 машин по максимуму? Ну что же... ерунда совсем, пустяк. Множим на 100 баксов... всего в 10 штук обошлось вам такое обновление. Ничего, терпимо. Бывает хуже ;)

Научитесь ЧИТАТЬ. НА ВСЕ ПРО ВСЕ.

>Опа, а что если среди них есть linux'ы, sunOS, openBSD и freeBSD всех мастей и оттенков? Я уже конечно задумался о моей профпригодности, но...

Я тоже задумался о Вашей профпригодности. Использование зоопарка операционных систем и бахвальство этим характерно как раз для не совсем профессиональных администраторов.

> Если мой провайдер выключит мне почту на час в то время когда я жду важного письма,

Если ты ждёшь доставки на столько важного письма E-Mail-ом, тебе следует подумать о выходе на пенсию. Блин, как достали дебилы, пытающиеся строить критичный ко времени бизнес на основе сети Интернет. Товой провайдер - это всего лишь один и кучи, тех, кто может быть отвественным за задержки.

> Пожалуйста, не подумайте, что sendmail - это устаревшая программа с проблемами безопасности.

Подумаешь - устаревшая... Сколько лет пингу или тару? ;-)

> 1. Спам легко пройдёт проверку на smtp callback.

1) Назовём rfc, которое запрещает это делать
2) Назовём rfc, которое разрешает делать обратное

>2. на cr.yp.to посыпется вагон отлупов и создаст нехилый трафик.

Назовем rfc, которое говорило бы о том, что это неправильно ;)

> 1. Спам легко пройдёт проверку на smtp callback. > 2. на cr.yp.to посыпется вагон отлупов и создаст нехилый трафик.

Не пойдет если домен настроен нормальным админом, а не адептом sendmail. Письмо от <> распознается как письмо от MAILER-DAEMON, на которое ответ не генерится.

> Использование зоопарка операционных систем и бахвальство этим характерно как раз для не совсем профессиональных администраторов.

Увы, не от админа этот факт зависит. Странно, что вы это не знаете.
И о горе! Таким админам c зоопарком по-преднему платят хорошие деньги ;)

"Дебилы" достали админов? ЛОЛ! А когда было по-другому? Дебилы тебе денег платят - не хочешь - иди улицы подметать, а sendmail дома поставишь...

> >2. на cr.yp.to посыпется вагон отлупов и создаст нехилый трафик.
>Назовем rfc, которое говорило бы о том, что это неправильно ;)

Поправлюсь - как тут правильно заметили, на '<>' как в первом примере,
отлупа не будет. А вообще, политика отлупов - сугубо внутреннее дело
фирмы, и настраивается теоретически как угодно. Я могу давать отлупы
не глядя всей Азии - kr,jp,cn и т.п. Однако нужно всегда помнить, что
qmail из коробки не нарушает никаких rfc, а если и нарушает, то по
причине их неоднозначности или противоречивости. Админ на месте может
сделать все, что ему угодно. Этого не запретишь.

>Увы, не от админа этот факт зависит. Странно, что вы это не знаете. И о горе! Таким админам c зоопарком по-преднему платят хорошие деньги ;)

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

Если это не так, то явно что-то не то с головой начальника технического отдела.

А то, что на этой сотне машин запущено по почтовому серверу - это, простите, даже не смешно.

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

> > 1. Спам легко пройдёт проверку на smtp callback. > 2. на cr.yp.to посыпется вагон отлупов и создаст нехилый трафик.

> Не пойдет если домен настроен нормальным админом, а не адептом
> sendmail. Письмо от <> распознается как письмо от MAILER-DAEMON, на
> которое ответ не генерится.

Ты тормоз, да ? Ключевой момент не mail from:<>, а rcpt to:<аинея@домен>. Нахрена он принимает почту для _своего_ _несуществующего_ пользователя ? А все потому, что, из коробки, он не может при приёме базу локальных пользователей проверить. Это - основная болезнь почтовиков с Qmail и Postfix.

> >2. на cr.yp.to посыпется вагон отлупов и создаст нехилый трафик.

> Назовем rfc, которое говорило бы о том, что это неправильно ;)

Ну и сиди со своим qmail, заваленным тоннами спама. Можешь с администрацией online.de пообщаться на тему, что они там с qmail сделали. :-)

>"Дебилы" достали админов? ЛОЛ! А когда было по-другому? Дебилы тебе денег платят - не хочешь - иди улицы подметать, а sendmail дома поставишь...

От ответа уклонились... Так что, действительно администраторам конечного smtp сервера приходится увольняться, или их телефон раскаляется до бела от гневных клиентов, когда один из промежуточных релеев/провайдеров остановился?

>Bogerm * (*) (23.03.2006 14:34:36)

> Если ты ждёшь доставки на столько важного письма E-Mail-ом, тебе следует подумать о выходе на пенсию. Блин, как достали дебилы, пытающиеся строить критичный ко времени бизнес на основе сети Интернет. Товой провайдер - это всего лишь один и кучи, тех, кто может быть отвественным за задержки.

Специально для дебилов небольшой экскурс в историю. Internet произошел из системы DARPANET, разработанной военными для надежной доставки информации. В ее структуру заложены все возможности построения систем, критичных к надежности и скорости доставки. Отвественные провайдеры и админы способны построить бесперебойные сервисы. На западе провайдеры гарантируют 99% online в год, а в противном случае полный возврат денег. Нормальных админов учат строить bullet-proof системы и они используют в своей работе пакеты, заслужившие хорошую репутацию. Дебилов ничему не учат и они используют пакеты, которые они умеют устанавливать ( например sendmail ). Извините за резкий тон, но сами напросились.

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

Ой-ой, какие мы молодые и строгие ;) Может назовешь эти две основные ОС? ;)
А если речь не идёт не о провайдерах? А если эти вообще конторы разные?
Если они просто клиенты у обслуживающей их фирмы? Ничего, что так много вопросов? ;)

> Ну и сиди со своим qmail, заваленным тоннами спама.

Дык, эта... нет у меня тонн спама. Нет даже маленькой тележки со спамом...
Можно я умру от стыда за то, что не вписался в твою стройную теорию про
неудачников qmail-админов? ;)

> От ответа уклонились... Так что, действительно администраторам конечного smtp сервера приходится увольняться, или их телефон раскаляется до бела от гневных клиентов, когда один из промежуточных релеев/провайдеров остановился?

Похоже вы сами не представляете как работает почта. Откройте заголовки нескольких писем и посмотрите через сколько релеев они проходит. 90% писем проходят очень просую цепочку: client compuer -> ISP smtpd -> isp-relay -> recipient's isp relay -> recipient's isp mail storage -> recipient's computer.

В большинстве случаев ответсвенными являются 2 провайдера. Если у одного из них периодически возникают проблемы, то его пользователи перебираются к другому.

>Ой-ой, какие мы молодые и строгие ;) Может назовешь эти две основные ОС? ;) 

Пожалуйста:
Solaris + Windows (один из ОПСОС России, увы не имею права сказать какой именно)

Linux + DOS (сеть универмагов)

FreeBSD + Linux для VDS (компания Мастерхост)


>А если речь не идёт не о провайдерах?

Тогда причем тут сто машин с sendmail?

>А если эти вообще конторы разные? 

Вы работаете в ста конторах одновременно?

>Если они просто клиенты у обслуживающей их фирмы? Ничего, что так много вопросов? ;)

Хорошо-хорошо. Расскажите общественности, что изменится, если надо 
будет обновить.... скажем очередную дырявую версию clamav для столь 
любимого Вами qmail?

Ваши действия?

Забавно, обслуживающая фирма может диктовать, какой почтовый сервер 
использовать, а какую оперционную стстему - нет. Забавно это, право же :))

> На западе провайдеры гарантируют 99% online в год, а в противном случае полный возврат денег.

Это чушь.

1. Никто не дасть гарантию за соседа, отвечать можно только за свой собственный участок сети.

2. У меня есть регулярная информация из первых рук на тему, как "там" (если конкретно, в обном из городов США) обеспечивается "99% online в год", по крайней мере, у одного отдельно взятого оператора. :-)

> Извините за резкий тон, но сами напросились.

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

А что касается экскурса, это я в курсе, но есть одно но: см п 1. Тогда эта сеть рассчитывалась на _одного_ владельца со всеми вытекающими. И очень хорошо получилось, кстати, раз при текущем положении вещей, создает впечатление надёжности.

>Если ты ждёшь доставки на столько важного письма E-Mail-ом, тебе следует подумать о выходе на пенсию. Блин, как достали дебилы, пытающиеся строить критичный ко времени бизнес на основе сети Интернет. Товой провайдер - это всего лишь один и кучи, тех, кто может быть отвественным за задержки.

Предлагаешь пользоваться голубиной почтой?

Не знаю кого там достали дебилы, а у нас большая часть доков и договоренностей идет через e-mail. И все работает.

> Не знаю кого там достали дебилы, а у нас большая часть доков и
> договоренностей идет через e-mail. И все работает.

А тебя пугает задержка в один час ? :-)

>> От ответа уклонились... Так что, действительно администраторам конечного smtp сервера приходится увольняться, или их телефон раскаляется до бела от гневных клиентов, когда один из промежуточных релеев/провайдеров остановился?

>Похоже вы сами не представляете как работает почта. Откройте заголовки нескольких писем и посмотрите через сколько релеев они проходит. 90% писем проходят очень просую цепочку: client compuer -> ISP smtpd -> isp-relay -> recipient's isp relay -> recipient's isp mail storage -> recipient's computer.

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

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

Идем далее, отключение канала связи одного из провайдеров в цепочке тоже приводит у увольнению почтового администратора? Ах, да, резервные каналы, переключение на которые у одного из промежуточных провайдеров может уйти от секунд до часов...

И ваши 99% в год - это ориентировочно 88 часов в год, вполне достаточно для обновления sendmail раз в два года.

>Bogerm * (*) (23.03.2006 14:56:18)

> Хорошо-хорошо. Расскажите общественности, что изменится, если надо
будет обновить.... скажем очередную дырявую версию clamav для столь
любимого Вами qmail?

Я бы сказал, если бы знал о версии clamav _для_ qmail ;) Это что-то
новое для меня. Звучит так же, как "версия bash для qmail".

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

А что тут забавного??? Поделитесь смыслом забавности? ОС часто может
быть привязана к железу, начнем с этого хотя бы... Да, настройщик роялей
может сменить струны, но вот сам рояль - вряд ли, да и зачем?

> В большинстве случаев ответсвенными являются 2 провайдера. Если у
> одного из них периодически возникают проблемы

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

И вот тут-то и выясняется, то, что между двумя MTA сообщения передаются как бы напрямую, является только видимостью. И никакие резервные каналы тут не спасают, пока руками не пнёшь.

>Я бы сказал, если бы знал о версии clamav _для_ qmail ;) Это что-то новое для меня. Звучит так же, как "версия bash для qmail".

Понятно. С Вами нало разговаривать как с идиотом - только очень простыми предложениями. В более сложных Вы путаетесь и теряете суть.

Итак, повторяю вопрос:

У Вас сто машин с зоопарком систем. На машинах установлен qmail. К qmail прикручен clamav. Выясняется, что в сlamav находится очередная дырка. Ваши действия?

>А что тут забавного??? Поделитесь смыслом забавности?

Забавно тем, что жЫзненно.

>ОС часто может быть привязана к железу, начнем с этого хотя бы...

Приведите примеры таких (хотя бы одной) контор, администрирующих порядка сотни клиентов, у которых есть не только зоопарк ситем, но и зоопарк архитектур и у которых на каждом сервере живет по MX.