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

>Да, он тоже с Cyrus-IMAP хорошо интегрируется. :-) По крайней мере,
>судя по описанию.

Угу.

cyrus_delivery:
driver = lmtp
current_directory = /var/spool/imap
command = "/usr/lib/cyrus-imapd/deliver -l"
batch_max = 20
user = cyrus


и всё. Я ж грю - красивый :)

дырявый? а аргументировать?

> и всё.

Несовсем. Еще http://anfi.homeunix.net/exim/rtvcyrus.html

Кстате, о быстроте qmail:

Postfix из коробки порвал qmail из коробки же. На одной и той же машине, используются как простейшие эмиттеры, прогоняют через себя 15-20Гб/300k почты в день.

//Loseki

4Az * (*) (24.03.2006 11:53:45):
Кстати, интересно - а список пользователей из цируса он сам высасывает? Или на всех пользователей 220, а затем баунсы рассылать о несуществующих адресах?

//Loseki

> Или на всех пользователей 220, а затем баунсы рассылать о
> несуществующих адресах?

Если бы так, я бы не согласился с тем, что Exim хорош. ;-)
Но Az про это не дописал.

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

http://www.securitylab.ru/vulnerability/204979.php

Как в свое время говорил (если мне память ни с кем не изменяет) уважаемый БоБуК, по коду Exim можно лекции читать "Как нужно программировать конечные автоматы".
Да вот недавняя есть уязвимость, но она не в exim'е, а в патче, к-м к нему прикручивается спамотсосин. Это - дырявость? Нюню.

Насчет пользователей - этов exim'е как напишешь в конфиге - так и будет. Скажешь не проверять реципиента - не будет проверять. Скажешь смотреть системных юзверей - будет смотреть системных. Скажешь ходить за юзверями в мускул или постгри - будет туда ходить. Хошь просто в файлики пихай список юзверей, хошь - по виртуальным доменам рассовывай.
В общем, на мой взгляд по гибкости exim ни в чем не уступает sendmail. (ой, ща придут монстры и начнут камнями кидаться).

Циррозу отдаётся письмо через сокет, он его пытается доставить, видит, что юзверь не существует - и даёт ошибку. Список пользователей видит только Cyrus.

> Это не "модульность" и не "unix-way", а идотизм. Делать pipe + fork + exec на каждое письмо - это тоже самое, что использовать cgi для web.

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

> Вот именно: __на_каждую_сессию__. Вместо того, чтобы общаться по единожды созданному persistent connection.

Докажи, что твое решение правильно, а в qmail неправильное. Не на
пальцах и без эмоций и слюней.

> Вот еще считать.

Лучше бы твой мозг выдал команду "Вот еще стучать по клаве и засорять
форум". Было бы логично. Искать мы не хотим, считать не хотим.
При этом лозунги толкаем.

> Вот персонал online.de понял

Что понял персонал online.de? Где можно прочитать про их озарение?

> Насчет безопасности - нашел 1 годовалую дырочку.

Это мало? Это приговор ;)

> Да вот недавняя есть уязвимость, но она не в exim'е, а в патче, к-м к нему прикручивается спамотсосин. Это - дырявость?

А какая вонь стоит, когда заходит речь о патчах qmail! Хотя в них
таких дыр не находят.

>Что понял персонал online.de? Где можно прочитать про их озарение?

Выше по треду если почитать, то вполне можно догадаться. При наличии мозгов :)

Насчет считать - опять жеж выше по треду вон, человек посчитал - 102.4 миллиона комбинаций на перебор 5символьных мыл. У быстрого сендмейла :)при миллионе в час получается 102.5 часа. А в обычной, нормально настроенной системе, в которой перед режектом пауза хотя бы секунд 5, получается что? 102.4 * 5 сек = примерно 16 лет. Такие расчеты тебя устраивают? 6 символьные перебрать - умножай еще на 40 :)

>Это мало? Это приговор ;)
Хех. Тогда надо приговорить все. Кроме qmail :)))))

>Циррозу отдаётся письмо через сокет..

А он его пхать начинает прямо на этапе сессии (с трудом себе представляю) или после data или после quit? Т.е. 550 No such user мы словим на этапе сессии или баунсом, сгенерённым exim'ом?

//Loseki

на этапе сессии.

> > Вот персонал online.de понял

> Что понял персонал online.de? Где можно прочитать про их озарение?

Ну проверь, как они _теперь_ обрабатывают почту для отсутствующих пользователей. Рассказать необходимый набор команд ?

> на этапе сессии.

На самом деле нет. В момент передачи сообщения Цирусу письмо уже принято. Но и Sendmail, и Exim могут спросить, доступен ли пользователь такой-то, сразу после rcpt to:, получить ответ на тему наличия или оверквоты и вернуть соответствующую ошибку, если необходимо. Кстати, в тарболе sendmail присутствуют два перловых скрипта, которые показывают принцип использования данного механизма.

вопрос был о том, будет ли 550 во время смтп-сессии или exim примет письмо и начнет боунсами кидаться. Ответ был - на этапе сессии будет режект (по крайней мере, так в конфиге по умолчанию, хотя это можно и отключить/переделать/etc)

> вопрос был о том, будет ли 550 во время смтп-сессии или exim примет письмо и начнет боунсами кидаться.

А, да, это вот этот ответ

> Циррозу отдаётся письмо через сокет, он его пытается доставить, видит, что юзверь не существует - и даёт ошибку.

несовсем точный.

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

> Так ведь "sendmail может обрабатывать МИЛЛИОНЫ писем в ЧАС"!!! ;)

Это не поможет.

> Вот и считай: 26 букв, 10 цифр, плюс парочка знаков -- считаем алфавит в 40 символов. Значит, до шестисимвольных адресов мы доберемся через 102.4 миллиона попыток (то есть будем иметь список _всех_ валидных пятисимвольников). Если еще учесть недопустимые комбинации, да добавить перебор по словарю...

Я же воде разборчиво написал "имена пользователей _больше_ пяти букв". Одних только шестисимвольных слов получится 40^6 == 4096000000. Использовать словарь для поиска никто не будет, а вот для отправки спама это возможно. Только от отправки спама по словарю поведение qmail тоже не спасёт. А вот трафик возрастёт значительно.

address_cyrus:
  debug_print = "T: address_cyrus for $local_part@$domain"
  driver = lmtp
  socket = /var/run/cyrus/socket/lmtp
  delivery_date_add
  envelope_to_add
  return_path_add
  group = mail
  transport_filter = /usr/bin/tr -d \\000

> Выше по треду если почитать, то вполне можно догадаться. При наличии мозгов :)

Вот ещё догадываться ;) А словеса в треде авторитету не имеют.

> Насчет считать - опять жеж выше по треду вон, человек посчитал - 102.4 миллиона комбинаций на перебор 5символьных мыл

А если чуть эвристику применить? Адреса типа fghfjhg@domain.com
используют практически исключительно сами спаммеры. У остальных в 99%
случаев они представляют что-то осмысленное. Берем справочник имен
и фамилий для конкретной страны. Строим правила транскрипции и
возможные комбинации сцепки имени с фамилией. Что-то мне подсказывает,
что за 2 часа можно поиметь 99% ящиков в системе вне зависимости от
количества символов в них ;) А ви что думаете по этому поводу, господа
с мозгами?

> > > Если имена пользователей больше пяти букв, найти их перебором не реально.
>> Так ведь "sendmail может обрабатывать МИЛЛИОНЫ писем в ЧАС"!!! ;)
>Это не поможет.

Секундочку... миллион ПИСЕМ в час. А сколько отлупов? Явно ведь больше!
Как минимум раз в пять больше отлупов должен смочь обработать, если
про миллион писем не соврали ;)

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

Вот ещё проверять.

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

> Вот ещё проверять.

Ну, тогда можешь пойти в... пень с идеями сферического программиста в вакууме. :-)

> > Вот ещё проверять.
>Ну, тогда можешь пойти в... пень с идеями сферического программиста в вакууме. :-)

Дык после тебя только. Ты ж тоже на любую ссылку отзываешься "Вот ещё" ;)

> Секундочку... миллион ПИСЕМ в час. А сколько отлупов? Явно ведь больше! > Как минимум раз в пять больше отлупов должен смочь обработать, если про миллион писем не соврали ;)

confBAD_RCPT_THROTTLE - If set and the specified number of recipients in a single SMTP transaction have been rejected, sleep for one second after each subsequent RCPT command in that transaction.

> А если чуть эвристику применить? Адреса типа fghfjhg@domain.com используют практически исключительно сами спаммеры. У остальных в 99% случаев они представляют что-то осмысленное. Берем справочник имен и фамилий для конкретной страны. Строим правила транскрипции и возможные комбинации сцепки имени с фамилией. Что-то мне подсказывает, что за 2 часа можно поиметь 99% ящиков в системе вне зависимости от количества символов в них ;) А ви что думаете по этому поводу, господа с мозгами?

Ну, берём твой словарь и просто по нему рассылаем спам. Спамерский эффект тот-же самый. В чём же выгода? Одни убытки, например на трафике.

А что за проблема у vpopmail с квотами?

> Ты ж тоже на любую ссылку отзываешься "Вот ещё" ;)

Не на любую. Только на ту, которая не имеет смысла ввиду наличия уже готового эффекта. Как то надцать раз упомянотое изменение принципа работы online.de. Да и просто исходя из семилетнего опыта разборок с потоками почты.

Мда.... читать мудрствования анонимусов весело. До колик.

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

То есть, для Вас неочевидно, что приложение, которое на каждое письмо делает pipe + fork + exec работает медленнее приложения, которое передает данные по persistent connection?

>Докажи, что твое решение правильно, а в qmail неправильное. Не на пальцах и без эмоций и слюней.

В qmail оно не неправильное. Да, можно делать exec + pipe. Более того, куча утилит Unix именно так и работает, например, ls -la | wc -l.

Но для высоконагруженного сервера постоянно запускать программу очень и очень дорого по ресурсам, а самое гравное - долго. Более того, если запускаемое приложение должно подключаться с СУБД, или, например, загружать какой-либо большой файл даннах, оно будет делать это КАЖДЫЙ РАЗ, вместо того, чтобы сделать все подобные действия единожды, только при запуске.

> Ну, берём твой словарь и просто по нему рассылаем спам. Спамерский эффект тот-же самый. В чём же выгода? Одни убытки, например на трафике.

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

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

Ты считаешь, что спаммер за свои деньги спам рассылает ?! Ну-ну... Да ему плевать с высокой колокольни на актуальность базы в большинстве случаев.

>А если чуть эвристику применить? Адреса типа fghfjhg@domain.com используют практически исключительно сами спаммеры. У остальных в 99% случаев они представляют что-то осмысленное. Берем справочник имен и фамилий для конкретной страны.

Во-первых, уже тебе сказали про то, что спаммеры тоже могур рассылать со словарём.

Во-вторых, с чего ты взял, что большинство ящиков в имени имеют что-то с точки зрения компьютера осмысленное? ИМХО, не меньше половины всех ящиков как раз имеют с точки зрения словарей совершенно бессмысленные имена.

> То есть, для Вас неочевидно, что приложение, которое на каждое письмо
делает pipe + fork + exec работает медленнее приложения, которое
передает данные по persistent connection?

Нет, абсолютно не _очевидно_. Я соглашусь с этим в рамках чистой теории,
но не в контексте сравнения реальных софтин qmail/sendmail! Очень
по-разному можно запрограммировать одно и тоже. Между авторами qmail
и sendmail огромнейшая пропасть в разнице их квалификации. Автор qmail
на полную катушку использовал все бесспорные плюсы форкающейся модели,
и при этом сумел удержать на достойном уровне производительность.

Чтобы быть ещё более убедительным, я могу привести пример вебсервера,
который форкается на каждый запрос и при этом умудряется порвать апаче
по производительности. Это fnord. Думать нужно и практику иметь, а
не повторять заплесневелые догмы.

> Более того, если запускаемое приложение должно подключаться с СУБД,
или, например, загружать какой-либо большой файл даннах, оно будет
делать это КАЖДЫЙ РАЗ

Ещё одна догма и ещё одна глупость. Смотрим tinydns, открывающий базу
на диске (!) на каждый запрос, и bind, который все записи держит в
памяти. tinydns рвёт bind на любом размере базы вплоть до нескольких
гигабайт! Программировать нужно уметь, а не сопли жевать.

> Между авторами qmail и sendmail огромнейшая пропасть в разнице их квалификации.

Да, согласен. Один из них всего лишь хороший программист с гипертрофированным самомнением.

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

Не верю (с). Статистику в студию. Любой нормальный человек предпочтёт
осмысленное имя ящика. Любая массовая почтовая система по-умолчанию
предложит вам создать ящик в стиле имя_фамилия.

> лишь хороший программист с гипертрофированным самомнением.

Хрен с ним с самомнением! Извините за мой французский ;) Я его (djb)
вообще терпеть не могу как человека. Пообщался в форумах достаточно...
Однако софт он пишет не просто правильный, а почти идеальный. В мире
найдётся от силы 3-4 человека, которые отдалённо могут приблизиться
к нему по качеству написания софта. Это бог от программирования.
Хотите вы этого или нет.

>Нет, абсолютно не _очевидно_. Я соглашусь с этим в рамках чистой теории, но не в контексте сравнения реальных софтин qmail/sendmail! Очень по-разному можно запрограммировать одно и тоже.

Судя по всему, г-н анонимус не тестировал ни qmail ни postfix ни sendmail. Блаженны веруюшие.

>Между авторами qmail и sendmail огромнейшая пропасть в разнице их квалификации.

Это заметно.

>Автор qmail на полную катушку использовал все бесспорные плюсы форкающейся модели,

Автор давно забил на qmail. Вот когда qmail писался, при тех нагрузках, он вполне отвечал требованиям. А сейчас, когда надо не только рассылать почту, но и фильтровать ее от вирусов и спама, и самое главное - делать это __быстро__, увы qmail не подходит. Потому, что вся эта "модульность" хороша тогда, когда надо только один раз форкнуться и отдать данные процессу, а когда на каждое письмо надо сделать fork три раза последовательно (спаморезка + антивирус + доставщик) это никуда уже не годится.

Хотите сравнить smtp-серверы - сравните их с подключенным спам-фильтром, антивирусом и с авторизацией из базы. И я сомневаюсь, что в этом случае qmail будет так хорошо, как кричат об этом его апологеты.

>Чтобы быть ещё более убедительным, я могу привести пример вебсервера, который форкается на каждый запрос и при этом умудряется порвать апаче по производительности. Это fnord. Думать нужно и практику иметь, а не повторять заплесневелые догмы.

Порвать Apache - это, простите несерьезное сравнение.

Сравните-ка лучше fnord с nginx / 0w-httpd.

А на fnord я посмотрел. Строго говоря, не на что там смотреть -- этот сервер попросту ничего не умеет.

>Ещё одна догма и ещё одна глупость. Смотрим tinydns, открывающий базу на диске (!) на каждый запрос, и bind, который все записи держит в памяти. tinydns рвёт bind на любом размере базы вплоть до нескольких гигабайт! Программировать нужно уметь, а не сопли жевать.

Пожалуйста не надо сравнивать ПО с разным функционалом. Потому как тогда mysql порвет oracle по скорости и занимаемой памяти.

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

кстати уважаемые а почему вы цирус все используете?он мне как то не понравился я на курьере остановился.Может зря?:)

ИМХО postfix --- среднее между qmail и sendmail...
как раз та золотая середина %)

rtc (*) (23.03.2006 12:38:48)

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


Реальный пример в студию.

хотя что от тебя ждать, только пиздеть и умеешь.

> Судя по всему, г-н анонимус не тестировал ни qmail ни postfix ни sendmail. Блаженны веруюшие.

Аналогично отвечу и я.

> Автор давно забил на qmail. Вот когда qmail писался, при тех нагрузках, он вполне отвечал требованиям.

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

> Потому, что вся эта "модульность" хороша тогда, когда надо только один раз форкнуться и отдать данные процессу

Есть такая хорошая американская поговорка: Profile, don't speculate.
Я даю живые примеры в подтверждение своих слов, вы - только пустые
словеса.

> Порвать Apache - это, простите несерьезное сравнение.

Это почему же? Апаче по качеству кода даже лучше sendmail.
Я сравниваю preforked model (которая якобы быстрее должна быть) с
чисто форкающейся моделью (форк на каждый запрос). Что не нравится?

> А на fnord я посмотрел. Строго говоря, не на что там смотреть -- этот сервер попросту ничего не умеет.

А что он должен уметь? Тестируется количество запросов в секунду.
Сравниваются модели, а не фичи.

> Пожалуйста не надо сравнивать ПО с разным функционалом.

Хватит 3.14еть уже! Программы одного назначения и функционала.

> Реальный пример в студию.

Уже спрашивали его про пример. Давно не отвечает. Нету примеров
видимо... Когда споришь про qmail, его нужно либо знать профессионально,
либо вообще молчать скромно в уголке...

> В мире найдётся от силы 3-4 человека, которые отдалённо могут
> приблизиться к нему по качеству написания софта. Это бог от
> программирования. Хотите вы этого или нет.

Он может быть кем угодно от программирования. Но когда он пишет некий софт, который должен работать, как я уже сказал, не в вакууме, в рассчёте на своё мировоззрение, ни для чего, кроме как для обучения программированию по своему коду, этот софт не годится. Ну или надо много дописывать. Если ты программист по совместительству, то ты допишешь. Может быть, даже правильно. Может, даже, кому-то это тоже подойдёт...

> > Реальный пример в студию.

> Уже спрашивали его про пример.

Я немного про другое пример привёл. Первый же попавшийся qmail-сервер повёл себя так, как я и думал. А мне тут начали доказывать, что это не бага, а фича. baka-kun, правда, заметил, что это руки администратора, скорее, а не проблема собственно qmail, но я вот, почему-то, это вижу практически повсеместно у серверов с qmail.

> кстати уважаемые а почему вы цирус все используете?он мне как то не понравился я на курьере остановился.Может зря?:)

Хороший вопрос... Наверное, зависит от задач и перспектив роста.

Ключевые моменты на мой взгляд:

1. Cyrus использует индексированный maildir. Плюс - быстрее, минус - писать туда должен только он.

2. Cyrus умеет отдавать информацию о ящике. Плюс - MTA не должен знать вообще ничего о пользователях. Есть минус - он не отдаёт оставшуюся квоту, то есть, последнее сообщение может превысить эту квоту на любой объём (но следует помнить, что, как правило, у MTA задаётся предельный размер сообщения, так что размер не бесконечен).

3. Поддержка RFC3028 от авторов RFC.

4. У Cyrus есть такая штука - Murder. Для крупной системы может потребоваться.

5. Shared folders, хотя это у Курьера тоже уже есть кажется.

>Чушь. Как раз в то время, когда он писался был очень большой соблазн сделать один жирный демон "три в одном" и получить лучшую производительность, так как железки тогда были в 10 раз слабее.

Значит, автор не забил на qmail? Класс! И какая дата последнего изменеия qmail аффтором?

>Есть такая хорошая американская поговорка: Profile, don't speculate. >Я даю живые примеры в подтверждение своих слов, вы - только пустые словеса.

Вы даете не примеры, а фикцию. Повторяю, ВЫ СРАВНИВАЕТЕ ПРОДУКТЫ РАЗНОЙ ФУНКЦИОНАЛЬНОСТИ. Давайте сравним MySQL и Oracle и будем кричать, что Оракл - аЦтой, ведь по памяти и скорости его рвет MySQL, игнорируя при этом тот факт, что реализованных возможностей в MySQL - даже не 5% от Oracle.

> Порвать Apache - это, простите несерьезное сравнение.

>Я сравниваю preforked model (которая якобы быстрее должна быть) с чисто форкающейся моделью (форк на каждый запрос). Что не нравится?

То, что у Apache и fnord РАЗНАЯ ФУНКЦИОНАЛЬНОСТЬ. Перед тем, как отдать клиенту данные, Apache и fnord делают РАЗНОЕ количество действий, не связанных с сетевым (accept/read/write) и IPC (fork) взаимодействием, андестенд?

>А что он должен уметь? Тестируется количество запросов в секунду.

>Сравниваются модели, а не фичи.

Еще раз и для медленно: НЕЛЬЗЯ СРАВНИВАТЬ ПО РАЗНОЙ функциональности. Если бы fnord умел все тоже самое, что и Apache, сравнение было бы допустимым. Кроме реализованных моделей fork и prefork Apache и fnord отличаются по функциональности.

>Хватит 3.14еть уже! Программы одного назначения и функционала.

Хорошо, если Apache и fnord - программы одинакового функционала, покажите мне документацию по API fnord для загружаемых модулей а-ля Apache. Также хотелось бы увидеть поддержку Action и SetHandler в fnord. Еще юы не мешало увидеть внятное описание аналога для mod_rewrite, mod_include и реализации fastcgi.

> Перед тем, как отдать клиенту данные, Apache и fnord делают РАЗНОЕ количество действий, не связанных с сетевым (accept/read/write) и IPC (fork) взаимодействием, андестенд?

На примере с раздачей статики список РАЗНЫХ действий в студию.

> Хорошо, если Apache и fnord - программы одинакового функционала, покажите мне документацию

Перечитываем ещё раз свой пост и мой ответ. Он был дан на заявление о
разной функциональности tinydns и bind. Я сказал, что эти программы
имеют одно и то же назначение и один и тот же функционал.

> Первый же попавшийся qmail-сервер повёл себя так, как я и думал.

Думать можно что угодно, а qmail ведёт себя так, как прописано в rfc.
Что в этом сложного для понимания?