Вышел Sendmail 8.13.1

> Сендмыл послать 1 млн. писем в час

может и больше

по данным из книжки "Sendmail performance tuning" SS5 с камнем MicroSPARC II 85MHz, 32M RAM, Solaris 2.6 посылает 242 сообщения в секунду без какой-то особой настройки sendmail.cf на sendmail 8.12.2.

242*60*60*24 = 20 908 800

двадцать миллионов сообщений на SS5 - это неплохо. покажите мне это на qmail, который форкается на каждый чих.

> Вот от сюда подробней. С номерами RFC и конкретными претензиями к реализации SMTP.

да пожалуйста. отсутствие правильной обработки MX, привязка номеров inode к файлам в очереди и асинхронная ее запись устроят? любой из этих проблем достаточно, что бы терять почту.

Как это... да он не соблюдает RFC 2822... Не правильно он с заголовками письма работает, DJb сделал это вроде как нарочно, так как при этом режется на 99% спам, но сам факт неприятен, иногда теряется нужная почта, например сообщения от разных роботов.

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

Неправильная обработка MX это когда он только первую MX-запись видит? На это давно есть патч. И даже если это не то что я назвал - на это тоже есть патч. И на то что вы сейчас подумали - тоже есть патч. Да, qmail без патчей это все равно что первая брачная ночь без невесты ((ц) каффказская пленнитса), это минус написания программ профессором а не реальным девелопером, но qmail + патчи это сила и наше усе. По поводу привяки номеров к inode я не понял, это тоже что ли в RFC описано? Спрашивали-то про muck up RFC standarts!

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

По-моему, уже проще что-то свое написать. Или забыть, как про страшный сон и потратить силы с пользой. Там, в начале, был вариант,
куда силы с пользой потратить можно. ;-)

> На сендмыле уже версий пять как релей закрыт по дефолту

Это смотря что версиями считать. Если 8, то это все та же v.8. Если
9,10,11,12,13, то да, версий пять (только, кажется, в 8.9 этого не
было уже). А у если начать каждый релиз учитывать, то уже и со счета
сбиться можно, сколько их с тех пор прошло. :-)

> По-моему, уже проще что-то свое написать. Или забыть, как про страшный сон и потратить силы с пользой. Там, в начале, был вариант, куда силы с пользой потратить можно. ;-)

нееет, уж проще таки патч ;) благо ковыряться в сорсах кумыла - одно удовольствие, срауз видно, профессор писал. как, вы ни разу не писали патчи для qmail? ;-)

> И на то что вы сейчас подумали - тоже есть патч

извините, мне делом надо заниматься, а не патчи собирать. я верю, что можно найти сотню патчей, которые будут делать массу всякой ерунды, но в таком случае qmail - не _продукт_ а _поделка_.

> это минус написания программ профессором а не реальным девелопером

пускай профессура занимается computer science а программисты пишут софт. каждому свое. а то у нас уже кухарки управляли государством.

> По поводу привяки номеров к inode я не понял, это тоже что ли в RFC описано? Спрашивали-то про muck up RFC standarts!

это нарушает RFC вот в каком смысле. по RFC серевер, принявший ответственность за доставку сообщения, обязан его доставить. при привязке файла очереди к inode, в случае проблем с файловой системой, например, или перезагрузки и переноса fs на другой узел, даже в случае тривиального бэкапа или копирования файлов в другой каталог (для распаралеливания очереди), файлы перестанут обрабатываться qmail. Т.о. сообщения, за доставку которых qmail должен отвечать, не будут доставлены. И это by design. Это нарушает RFC.

> RFC серевер, принявший ответственность за доставку сообщения, обязан его доставить.

Даже если окажется в эпицентре ядерного взрыва? Про бэкап очереди qmail
есть faq: http://cr.yp.to/qmail/faq/reliability.html
Вполне разумное объяснение неразумности резервного копирования очереди.
И в конце такой однозначный вывод:

You may encounter people who dispute one or more of the above
statements. Those people don't know what they're talking about.

Это про тебя ;)

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

Уважаемый не знаком с такой вещью как ports? Я один раз прописываю в /etc/make.conf if для qmail (WITH_BLABLA_PATCH=yes) и затем ставлю все на раз make install clean'ом. Ок, у вас не bsd а что-то там еще, если это "что-то там еще" - не _поделка_, то оно должно иметь соответствующий способ дистрибуции пакета qmail со всеми патчами. Так что можете смело заниматься делом. Итак, этот аргумент отпал. Чем еще смертельны патчи? Я не спорю что это _хуже_ чем native support но правда в том, что с этим _можно_жить_без_проблем_и_дополнительных_телодвижений_.

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

винчестер дает дуба во время обработки сообщения и получатель его (сообщение) не получает. все MTA в равной степени нарушают RFC. ситуация настолько же реальная, насколько все описанные вами. вообще, не знаю, насколько это реально плохо, т.к. нормальная система сама перегрузиться просто так не должна, как не должна и иметь "проблем с файловой системой". не буду говорить что проблема надумана, но ни у кого пока ее не встречал. если бы она была ТАК КРИТИЧНА то... верно, был бы патч! :-))

> Я не спорю что это _хуже_ чем native support но правда в том, что с
> этим _можно_жить_без_проблем_и_дополнительных_телодвижений_.

Некоторые и в подворотне живут... Удивительно... :-)
Зачем ?!

> винчестер дает дуба во время обработки сообщения и получатель его
> (сообщение) не получает. все MTA в равной степени нарушают RFC

Можно придумать не одну ситуацию, когда требуется перенести очередь.
И нафига этот головняк c inode (кстати, я про него первый раз
услышал, прикольно) ? Зачем усложнять ?

> т.к. нормальная система сама перегрузиться просто так не должна,

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

Нда...

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

> Можно придумать не одну ситуацию, когда требуется перенести очередь.

Придумать можно всё, что угодно! Только вот вопрос: А зачем... придумывать? ;)

> Некоторые и в подворотне живут... Удивительно... :-)

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

> Можно придумать не одну ситуацию, когда требуется перенести очередь.
И нафига этот головняк c inode (кстати, я про него первый раз
услышал, прикольно) ? Зачем усложнять ?

вот ниипу, зачем, но оно работает, я о нем не сейчас услышал, но сейчас вспомнил впервые за долгое время, хотя кумыло дигаю и рассылки читаю - ну не сталкивается народ с ТАКОЙ проблемой потери почты. теоретически это может и баг (хотя вот, djb спорит), но практически такое маловероятно.

>Но должна быть на это рассчитана.

мне что, попробовать ребутнуть сервак в пиковые моменты, накропав скриптик который спамит почтой, и попробовать, не потеряется ли она? :-)) ок, утром на плейграунде попробую, мне не в лом :)

> qmail - это такой Microsoft среди юниксовых MTA.

Ещё не слышал более глупого сравнения... Если б микрософтовский софт
хотя бы отдалённо работал так же стабильно, и был написан хоть примерно
с таким же качеством, юникс бы уже вымер как класс! Уж меня точно никто
бы не заставил возиться с линуксом или фрибзд, если бы у микрософт был
софт такого же класса как qmail. Но увы, чудес не бывает ;)

> отсутствие правильной обработки MX

Это ты о чем? Если один MX не отвечает, то qmail _будет_ пробовать другие. Вот если MX ответит 5хх, то да, сразу баунс, что вполне логично. Но почта не потеряется. Хотя, действительно, существует патч для борьбы с админами, рисующими в dns левые MXы.

> привязка номеров inode к файлам в очереди и асинхронная ее запись устроят?

Это проблема qmail, что _после_ его создания умные писатели libc и разных fs сделали запись метаданных асинхронной? Да, есть патч, который делает sync() сразу после close(), но перед ответом 250. Но кто вам виноват, что дефолтное поведение open() изменилось?

> это нарушает RFC вот в каком смысле. по RFC серевер, принявший ответственность за доставку сообщения, обязан его доставить. при привязке файла очереди к inode, в случае проблем с файловой системой, например,

Какого рода проблемы с fs сменят inode? Может это такие проблемы, из-за которых файлы вообще теряются? И как с этим может бороться _любой_ софт?

> или перезагрузки и переноса fs на другой узел,

Это `cp -R /whereis/qmail/queue /new/qmail/queue` ? Так сам себе злобный буратин. Утилит для корректной переноски очереди больше одной, да и своя за 10 минут на коленке пишется, если приспичит. А если готовую fs переносить, как там inode-ы перепутаются, от тряски винта в кармане?

> даже в случае тривиального бэкапа

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

> или копирования файлов в другой каталог (для распаралеливания очереди)

В qmail это решается другими способами. Надежными. Да и до уровня где-то 200 одновременных доставщиков и/или 100-200Мб почты в час точно ничего распараллеливать не надо на самом простом железе. Проверено электроникой.

PS. Я понимаю, это у тебя это от "незнания врага", но все же...

> Можно придумать не одну ситуацию, когда требуется перенести очередь.

Придумать можно и штаны через голову надевать... Но даже ЭТО с qmail удобней. Как я сказал выше, скрипт пишется за 10 минут, не считая нескольких готовых.

Но о ситуации, где _требуется_, я бы послушал...

> И нафига этот головняк c inode (кстати, я про него первый раз услышал, прикольно) ? Зачем усложнять ?

Наоборот, упрощать. inode -- это номер сообщения, который заведомо уникален. Плюс сама техника помещения сообщения в очередь и дальнейшей работы с ним гарантирует надежность доставки (если надежна fs).

> Как это... да он не соблюдает RFC 2822...

Ты пальцем, пальцем ткни. Если про Received:, то они полностью соответствуют 2822, если про то, что qmail не исправляет за MUA Date:, From:, Message-Id:, равно как и одиночный <CR> или <LF> на <CR><LF>, то не барское это дело -- в тело письма лезть.

> Не правильно он с заголовками письма работает

Он их не трогает, только свои Received: вставляет.

> иногда теряется нужная почта, например сообщения от разных роботов.

Покажи эту почту, и что с ней делает qmail. Может ты считаешь, что он должен делать это: http://cr.yp.to/proto/ofmip.html ? Дак я уже сказал -- не барское это дело.

Я так понял здесь собрались одни спецы по sendmail.  ;)
Не могу одну фичу прикрутить.
У меня в sendmail прикручен SMTP AUTH, естественно всем кто прошел авторизацию разрешен релей, в логах типа authid=vasiliy.
Мне необходимо управлять пользователями которые прошли авторизацию,
и часть из них просто не выходила  из домена (корпоративная почта).
Возможно дополнительно прикрутить еще и access map на проверку ??
К примеру возможно ли так:
authid=vasiliy    RELAY
authid=petrov     OK

> Даже если окажется в эпицентре ядерного взрыва?

нет. но если мне придется переместить очередь, это не должно привести к ее потере.

> You may encounter people who dispute one or more of the above statements. Those people don't know what they're talking about.

Берштайн известен тем, что его мнение - единственно верно. ;) Если ему (и тебе) не приходилось распараллеливать очереди, то я тут не причем.

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

> винчестер дает дуба во время обработки сообщения и получатель его (сообщение) не получает. все MTA в равной степени нарушают RFC.

только sendmail fsync() делает, а qmail на это плевал. в результате, если sendmail говорит 250, то сообщение уже сохранено, а в qmail оно еще может в кеше жить сколько угодно. а в случае с softupdates, дело будет совсем плохо.

наверное, есть патч. но я ужне писал, что сбор коллекции патчей - явно не аргумент в пользу qmail

>Вот я постфикс поставил и стоит он себе непатченный четвертый год. А >сендмыл - перделка, все вермя патчить надо. 
Если бы я был твоим начальником, то тебя бы уволил, а постфикс оставил )))

>Вот я постфикс поставил и стоит он себе непатченный четвертый год. А >сендмыл - перделка, все вермя патчить надо. Если бы я был твоим начальником, то тебя бы уволил, а постфикс оставил )))

а вот если бы я был вашим начальником, то я бы вас обоих разогнал, постфикса бы затёр и поставил сендмыла. а потом трахался с ним бы целыми днями разбирая птичек и закорючек в его cf конфиге :)))

Я тоже себе постфикс ставил, так он начал все письма пользователя "marketing" перенаправлять rootу. Нигде не было ни файла .forward ни aliasa, даже в исходниках ничего не было, но почта вместо marketing идет на root. Т.к. почты было много, а времени мало, снес postfix и вернулся на sendmail. Так и не знаю, в чем причина (под sendmail все работает).

> Вот если MX ответит 5хх, то да, сразу баунс, что вполне логично.

Кстати, это не логично. Это - единственно верно. Так что это точно не минус...

> Хотя, действительно, существует патч для борьбы с админами,
> рисующими в dns левые MXы.

А вот это - лишняя работа.

> Но кто вам виноват, что дефолтное поведение open() изменилось?

А то поведение было документированным ? Или это просто из кода следовало ?

> Это `cp -R /whereis/qmail/queue /new/qmail/queue` ? Так сам себе
> злобный буратин. Утилит для корректной переноски очереди больше
> одной

Вот и речь о чем. cp всегда под рукой.

> Я так понял здесь собрались одни спецы по sendmail. ;)

Спецы по SM тут что-то не замечены... :-) Может, скрываются хорошо...
Учитывая, что параметр authid, кажется, доступен в виде макроса ${auth_author}, то можно описать проверку через access.db. Но я не слон, чтобы такие вещи сходу на коленке писать - я уже писал, что, по большей части, через прототип конфига конфигурю.

SM ? А шо цэ таке ?

> Я тоже себе постфикс ставил, так он начал все письма пользователя "marketing" перенаправлять rootу. Нигде не было ни файла .forward ни aliasa, даже в исходниках ничего не было, но почта вместо marketing идет на root. Т.к. почты было много, а времени мало, снес postfix и вернулся на sendmail. Так и не знаю, в чем причина (под sendmail все работает).

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

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

Это точно. Вот только проблема была в том, что из сотни пользователей такая бяка была ТОЛЬКО у пользователя marketing. Ко всем остальным юзерам почта ходила без проблем (я же не сразу ставил новый MTA на боевую машину, сначала поиграл на тестовой).

> но если мне придется переместить очередь, это не должно привести к ее потере.

Здесь почти в каждом слове проблемы с логикой. Разбираем:

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

"мне" - это человеку, а речь шла об RFC применительно к smtp-серверам ;)
Всё еще не понятно? Ну, любое дело можно довести до полной крайности.
Например, физически привести письмо адресату на дискетке, и при этом
гордо заявлять о том, что ваш почтовик не нарушил ни единого пункта RFC ;))

Ну и вся фраза целиком напоминает какой-то дурдом:
"если мне придется переместить очередь, это не должно привести к ее
потере". Сравните: "если мне придется кантовать коробку с хрустальным
сервизом, это не должно привести к его потере".

> Берштайн известен тем, что его мнение - единственно верно. ;)

А никто не смог доказать обратное ;) И потом, я тоже не верю в
возможность существования множества различных и, при этом, верных мнений. Такого не бывает!

> двадцать миллионов сообщений на SS5 - это неплохо. покажите мне это на qmail, который форкается на каждый чих.

Ай, какие слабенькие познания предмета. Ну, вот зачем ты сказал про
форк? Можешь хотя бы примерно сказать, сколько _тысяч_ форков в секунду
может сделать любая qmail-* программа на современном железе?
Если можешь, то к чему это упоминание про "Solaris 2.6 посылает
242 сообщения в секунду"? ;)

> Ай, какие слабенькие познания предмета. Ну, вот зачем ты сказал про форк? Можешь хотя бы примерно сказать, сколько _тысяч_ форков в секунду может сделать любая qmail-* программа на современном железе? Если можешь, то к чему это упоминание про "Solaris 2.6 посылает 242 сообщения в секунду"? ;)

во, сразу видно, пришел человек со знанием дела ! дай жару этим бездарям, а то они за вчера и сегодня такой ерунды тут намолотили :)

>> но если мне придется переместить очередь, это не должно привести
>> к ее потере.

>Здесь почти в каждом слове проблемы с логикой. Разбираем:

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

Проваливается куча спама c какой-нибудь выделенки (ну, опенрелей учудили и смартрелей на провайдера). Вся эта куча, причем, идет на неотвечающие MX. То есть на попытку доставить нет 5xx. В спуле за ночь оказывается тысяч под 50 недоставленных сообщений. Твои действия ?

А при чем тут форки и современное железо?

High Volume Mail Solution - от Sendmail существует в природе и

действительно пропускает миллионы писем в час.

Ну конечно это очень серьезная система и стоит денег.

Под кумыл систем такого маштаба в природе нет.

>В спуле за ночь оказывается тысяч под 50 недоставленных сообщений. Твои действия ?

Если я провайдер, то отключаю релей для данной выделенки и шлю
оповещение клиенту. Очередь саморассасывается за время, указанное в
control/queuelifetime. И что, какая проблема? Мне очень интересно, что
делают в таких случаях господа, использующие sendmail. Неужели ручками
что-то делают с очередью? И что, так каждый раз при любой вирусной
эпидемии и из-за каждого нового открытого релея? Потрясающе!

> Под кумыл систем такого маштаба в природе нет.

На что ты готов поспорить? Ты проводил специальные изыскания по данной
теме и сделал такой вывод? Или ты сначала сделал вывод с той целью,
чтобы потом кто-то поискал за тебя и ткнул тебя носом в готовые
данные? Ну, давай, признавайся! А пока первый тычок носом:
http://www.shupp.org/maps/ispcluster.html

>> В спуле за ночь оказывается тысяч под 50 недоставленных сообщений.
>> Твои действия ?

> Если я провайдер, то отключаю релей для данной выделенки и шлю
> оповещение клиенту.

Это само собой, но уже поздно, спул забит.

> Очередь саморассасывается за время, указанное в
> control/queuelifetime.

Да ну ?! :-) В сколько ниток очередь обрабатывается ? Почитай RFC на тему таймаутов и прикинь, за сколько один обработчик пройдет по всей очереди. Затем подели на количество параллельных обработчиков. Затем прикинь время. Или ты просто 50000 qmail-ов сразу запускаешь и оно у
тебя в раз улетает ? :-)

Вообще, мне нравится это "саморассасывается за указанное время" :-)

> Мне очень интересно, что делают в таких случаях господа,
> использующие sendmail.

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

А че спорить то?

Ну для мелкого isp может и пойдет.

Просто посмотри какие компании в списке Fortune 10.

7 из них используют решения от Sendmail, понятно что не голый МТА

> Это само собой, но уже поздно, спул забит.

Нет, если уж до конца разбираться, то забитый спул - это вовсе не
"само собой"! Мудрый провайдер использует так называемый "tarpitting" -
технику приёма для предотврацения именно таких случаев.
http://www.palomine.net/qmail/tarpit.html

> Да ну ?! :-) В сколько ниток очередь обрабатывается ?

Нету ниток в qmail'e ;) Есть процессы. Количество отдновременных
qmail-send процессов для удалённой доставки контроллируется параметром
control/concurrencyremote. В непатченном qmail - максимально 120,
в патченном (big-concurrency.patch) это количество ограничено только
здравым смыслом. Для крупного ISP имеет смысл 500 и более одновременных
отправок.

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

Чудеса. Сколько платят за такой труд?

> Ну для мелкого isp может и пойдет.

Что такое "мелкий ISP" и из чего сделано столь глубокомысленное
заключение? Интересен ход мысли ;) Если я угадал правильно, то
этот ход примерно таков:

его_использует_компания_из_списка_Fortune_10 ? подходит для большого ISP : а нет, так для маленького

Мудро ;)

> 7 из них используют решения от Sendmail, понятно что не голый МТА

Во-первых, не понятно. Давай не подразумевать того, что не написано.
Во-вторых, у богатых свои привычки. Многие из них и веб-серверы на IIS
держат. И что, будем перенимать передовой опыт? ;)

Они не просто богатые, а к тому же очень большие, и задачи по обработке
почты сложнее, чем у ISP.

А я утверждаю, что их почтовые задачи много проще. Разубеди меня ;)

И ещё не забудь описать замеченные тобой преимущества "High Volume Mail
Solution от Sendmail" по сравнению с решением на базе qmail (линк я
давал). Хотя бы чисто конструктивные. Не надо зря воздух сотрясать.
Только факты, плиз.

Я конечно могу сравнить, но только за деньги.

А так мне не охота парится для твоего развития :)

В таком случае имеет смысл попариться для СВОЕГО развития ;)

>> Да ну ?! :-) В сколько ниток очередь обрабатывается ?

>Нету ниток в qmail'e ;) Есть процессы. Количество отдновременных

Сути не меняет. :-)

> Для крупного ISP имеет смысл 500 и более одновременных
> отправок.

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

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

>Чудеса. Сколько платят за такой труд?

Кому ? Железки - они на халяву работают... Или это про набор команды mv и запуск отдельного обработчика(ов). Так это и скрипт сделать может... Вот спул от хлама почистить предварительно - это да, сложнее... Это же надо целых строчки четыре символов по 40 написать. Да потом еще ждать немеряно... ;-)

> То есть, 500 процессов одновременно занимаются обслуживанием спула ?

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

> А на текущую обработку что-то остается ?

Я, честное слово, не понял сути поднимаемой проблемы. Что должно
остаться? Есть опасения за память, процессор, диск или что-то ещё?

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

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

> Я конечно могу сравнить, но только за деньги.

Sun-ch, спасиб, конечно, но фирма в ваших услугах (увы!) не нуждается ;-(
За деньги ты скажешь ровно то же самое: sendmail круче, ибо его используют 7 из 10 самых богатых компаний. на большее твой
аналитический ум не способен. И я очень сильно подозреваю, что ты
реально совсем не знаком с архитектурой рекламируемого тобой решения.

> То есть, 500 процессов одновременно занимаются обслуживанием спула ? А на текущую обработку что-то остается ? На то, что вот прямо сейчас юзеры шлют ? :-)

Ты действительно считаешь, что очередь обрабатывается только в порядке поступления, и пока не разберутся с 50000, ничего больше не уйдет? Но это не так. Как только освободиться первый qmail-remote, то новому отдадут свеженькое письмо. Если еще учесть, что задержка между повторными доставками увеличивается по экспоненте, и если произошла ошибка, то сообщение будет отложено еще на час... Короче, беклог в 50000 не в состоянии сильно замедлить отправку почты кумейлом.