Вышел Sendmail 8.13.1

> А почему ты так сразу испугался? ;) У меня на рабочей станции
> постоянно запущено 200+ процессов...

qmail-ов ? Или, вообще, всех ? Запущенных, или активно работающих ?
Это большая за... тьфу, разница.

> Есть опасения за память, процессор, диск или что-то ещё?

Процессор.

>> Вот спул от хлама почистить предварительно - это да, сложнее...

> Вот я и спрашиваю, какие расценки за единицу почищенного ;)

Тебе почистить надо ? :-)
Или ты предлагаешь, чтобы вся эта фигня в спуле валялась ? Вообще,
она вся запросто вычищается по всяким признакам. Хоть по IP
проштрафившегося.

> Ты действительно считаешь, что очередь обрабатывается только в
> порядке поступления, и пока не разберутся с 50000, ничего больше
> не уйдет?

Я всерьез считаю, что алгоритм обработки очереди можно задавать всякий. И всерьез считаю, что 50000 постоянно лежащих, без надежды на
отправку, сообщений, могут помешать в нормальном темпе обрабатывать
сообщения, попадающие в очередь ввиду каких-то проблем с доставкой с
первого раза. Даже в том случае, если доставка откладывается, они,
все равно, требуют внимания, хотябы, просто прочитать последнее время
обращения к файлам. Или массив в памяти обработать, если он так делает - это не суть важно. Кстати, увеличение по экспоненте - это
тоже не сильно правильно.

> > Есть опасения за память, процессор, диск или что-то ещё?
> Процессор.

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

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

Смотря что считать нормальным. Если вторая попытка будет предпринята не через пять минут, а через семь, ты сильно огорчишься? А через десять? Какое время ты считаешь нормальным, если первая попытка не прошла?

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

С этим никто и не спорит, но у qmail достаточно компактный беклог, а дирхеш здорово выручает со stat(). У тебя ведь нет на почтаре файловой помойки? А если система большая, то и рассыткой занимается(ются) машина(ы) отличная(ые) от MX и POP/IMAP.

> Кстати, увеличение по экспоненте - это тоже не сильно правильно.

На самом деле в qmail квадратичная зависимость, это я сам с экспоненциальной баловался ;) Но Ден оказался прав: "an hour-long delay in a day-old message is worth the same as a ten-minute delay in an hour-old message".

>> Есть опасения за память, процессор, диск или что-то ещё?

> Процессор.

Зря. Для qmail узких мест два: диск и сеть.

> Или ты предлагаешь, чтобы вся эта фигня в спуле валялась ? Вообще, она вся запросто вычищается по всяким признакам. Хоть по IP проштрафившегося.

А тебе ее дальше пытаться доставить уже не надо? Если не надо, то и грохни queue/remote/xxxx ненужного сообщения. По каким хочешь признакам, хоть по желанию мизинца левой ноги.

> Какое время ты считаешь нормальным, если первая попытка не прошла?

Вообще, скажем, час. Но без экспонент. А то так, к концу пятидневного срока, и сутки на интервал набегут... :-)

> А если система большая, то и рассыткой занимается(ются) машина(ы) отличная(ые) от MX и POP/IMAP.

Это все - оттягивание "удовольствия". Просто можно больше мусора успеть свалить и бОльшее количество мусора приведет к нежелательным последствиям (читай - проблемам доставки).

> А тебе ее дальше пытаться доставить уже не надо?

Если это то, что через клиентский Open Relay прошло ? Это не то, что не надо, это просто вредно.

> Если не надо, то и грохни queue/remote/xxxx

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

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

> Вообще, скажем, час. Но без экспонент.

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

Иди продай кому-нибудь решения HVMS на кумыл.

У тебя обязательно поинтересуются: "А что, д-р Бернштейн ваш родсвенник"

ОК, не проблема со ответом. Да, дальний родственник, если принять
библейскую гипотезу о происхождении всех людей от Адама и Евы ;)

Ну, а что дальше-то? К чему был комментарий? Ну, родственник.
Какие выводы, на твой взгляд, сделают потенциальные клиенты и о чём
ещё спросят? Хотя, бред это всё. Не может нормальный клиент знать
Бернштейна.

Дык клиенты == ит-отдел заказчика.

Весь вопрос в сапорте и дальнейше развитии.

Кого представляет д-р Берн.?

Кто будет дальше развивать поддерживать кумыл?

Он один?

> Дык клиенты == ит-отдел заказчика.

Ви это сурьёзно? А то я шуток не люблю...

> Кого представляет д-р Берн.?

Что за снова бред опять? А кого представляет автор суньмыла?
Судя по тому, что он гомик, наверное, сексуальные меньшинства ;)

> Кто будет дальше развивать поддерживать кумыл? Он один?

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

Запарил ты паренек.

Есть Sendmail, Inc. - коммерческая контора, которая продает решения.

Sendmail, Inc. builds the most powerful and secure email systems for large enterprises and service providers who depend on email to run their business.

Фсе тема закрыта.

> Есть Sendmail, Inc. - коммерческая контора, которая продает решения.

Но ведь и коммерческие решения на базе qmail тоже предлагают. И далеко не одна компания.

Я запарил? Ты сам себя паришь бездумными комментариями. У тебя штампованное статусное мышление, без логики, без реального анализа
фактов. С таким же успехом можно слушать какую-нибудь нудную официальную
проправительственную радиостанцию ;)

> Есть Sendmail, Inc. - коммерческая контора, которая продает решения.

Я извиняюсь, а остальные - что, хрен сосут?

Ну-ка глянь хотя бы одним взглядом список:
http://qmail.valueclick.com/top.html#paidsup

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

http://www.google.ru/search?q=%22commercial+support+for+qmail%22

> А вот ещё интересен сам механизм бэкапа.

Это не бэкап

> Я так понимаю, что почтовый сервер приходится останавливать для
> копирования очереди. Я прав?

Вообще-то, нет (если заранее подумать о такой ситуации), но...

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

...и даже если бы надо было останавливать, это тоже была бы не
проблема. С тобой это тоже можно не обсуждать, видимо...

Только один из хинтов: ты бы этой остановки и не заметил, скорее всего, даже если она была бы необходима.

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

/Другой/

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

Чем другая? Чем грузины?

> /Другой/

/Иной/ ;)

> Вообще-то, нет (если заранее подумать о такой ситуации), но...

Отсюда подробнее. Про заранее продумать. Хотелось бы точный ответ:
сервер останавливается для копирования очереди или нет.

> Только один из хинтов: ты бы этой остановки и не заметил

А не в этом дело совсем. Проблема в самом факте остановки, а ещё
точнее - в причине остановки: юзер Вася оставил открытый релей. lol.

У них нет собственных продуктов, они не занимаются разработкой.

> У них нет собственных продуктов, они не занимаются разработкой.

Да, Sendmail, Inc. не занимается разработкой опенсорсного sendmail и поддержкой уже установленного. Ну и что?

>> Вот только проблема была в том, что из сотни пользователей такая бяка была ТОЛЬКО у пользователя marketing

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

> > Вообще-то, нет (если заранее подумать о такой ситуации), но...

> Отсюда подробнее. Про заранее продумать. Хотелось бы точный ответ:
> сервер останавливается для копирования очереди или нет.

Я же сказал: если подумать - нет. "Подумать" - это означает

способ 1:
confFALLBACK_MX FallbackMXhost [undefined] Fallback MX host.
Очевидно, что FallbackMX не должен быть общедоступным - его дело
принять почту от основных эммитеров, которую они не смогли доставить
с первого раза. В результате обсуждаемый спам-спул окажется там. Хоть
обостанавливайся.

способ 2:
не выделять под /var/spool/mqueue отдельную файловую систему.
Файловой системой должен быть /var/spool или /var, ну или mqueue в
нестандартном месте. Прикинь время на отработку скрипта и поведение
работающих с mqueue процессов:
---
mv mqueue mqueuebad
md mqueue
---
При этом стоит помнить, что даже если чудо случится и новый процесс
попытается записать в еще несуществующий mqueue, sendmail не вернет
код подтверждения приема и письмо, нарвавшееся на проблему сохранения
уйдет в следующую попытку.

> А не в этом дело совсем. Проблема в самом факте остановки, а ещё
> точнее - в причине остановки: юзер Вася оставил открытый релей.
> lol.

А что бы сделал ты, если надо было бы остановить этот поток ? Не
забывай, там еще и то, что доставляется могло бы оказаться. Или ты бы
спокойно дождался, пока спам-очередь рассосется, несмотря на то, что
ты этим конкретный вред окружающим причиняешь ?

>> А не в этом дело совсем. Проблема в самом факте остановки, а ещё
>> точнее - в причине остановки: юзер Вася оставил открытый релей.
>> lol.

> А что бы сделал ты, если надо было бы остановить этот поток ? Не
> забывай, там еще и то, что доставляется, могло бы оказаться.

Еще вариант - нахрен запретить абонентам релеем провайдера пользоваться... ;-) Ага ?