Oops, sendmail did it again! :)
Victor Forsyuk
Привіт!
Ну шо, сендмилівці, знов одягання латок на швидкість? ;-)))
http://www.sendmail.org/8.12.9.html
p.s. А може того - go postfix, go exim? ;-)
Vladimir Litovka
Victor Forsyuk wrote:
> p.s. А може того - go postfix, go exim? ;-)
та давно уже пора :-)
--
:r !ripewhois DOKA-RIPE
-------------------------------------------------------------------------
Never try to teach a pig to sing. It wastes your time and annoys the pig.
-- Lazarus Long, "Time Enough for Love"
Egor Egorov
>> p.s. А може того - go postfix, go exim? ;-)
> та давно уже пора :-)
А вот интересно - хоть когда-нибудь поток дыр в sendmail прекратится?..
--
Egor Egorov
Ensita.NET, web development company
Visit: http://www.ensita.net/
Private newsletter: http://lenta.fine.kiev.ua/
Alexey Golovatenko
Forewer!!!
( :-)>
Victor Forsyuk <spam_naf...@tormoz.net> пишет в
сообщении:b68qpk$num$1...@whale.gu.net...
>
> Прив╕т!
>
> Ну шо, сендмил╕вц╕, знов одягання латок на швидк╕сть? ;-)))
Vladimir Litovka
и остался. Почему-то в Exim за все время его существования не было ни
одного remote root exploit и вообще я не припоминаю там сколь-нибудь
существенных граблей. Наверное вопрос во внутреннем дизайне?
Egor Egorov wrote:
> Vladimir Litovka <do...@kiev.sovam.com> wrote:
>
>
>>>p.s. А може того - go postfix, go exim? ;-)
>>
>> та давно уже пора :-)
>
>
> А вот интересно - хоть когда-нибудь поток дыр в sendmail прекратится?..
>
--
Victor Forsyuk
VL> Victor Forsyuk wrote:
>> p.s. А може того - go postfix, go exim? ;-)
VL> та давно уже пора :-)
От я і провокую ;-)
Alexey Golovatenko
Vladimir Litovka <do...@kiev.sovam.com> пишет в
сообщении:b68tc2$1f74$1...@news.kiev.sovam.com...
> IMHO никогда. Изначально дырявый софт, каким был несколько лет назад,
таким
> и остался. Почему-то в Exim за все время его существования не было ни
> одного remote root exploi
Опосля вроде чисто
Юрий_К
> p.s. А може того - go postfix, go exim? ;-)
да, думаю после исправления сендмайла за постфиксы и экзимы возьмутся...
>
Pavel
Сегодня же снесу это гавно :) и поставлю postfix, давно я в его сторону
смотрел.
"Victor Forsyuk" <spam_naf...@tormoz.net> wrote in message
news:b68qpk$num$1...@whale.gu.net...
Egor Egorov
> Все, достало.
> Сегодня же снесу это гавно :) и поставлю postfix, давно я в его сторону
> смотрел.
Я тоже. Несколько лет к этому шел, но таки прийдется перети с sendmail на что-то
другое. :-+
Кто расскажет в двух словах про exim и postfix?
Vladimir Litovka
Egor Egorov wrote:
> Кто расскажет в двух словах про exim и postfix?
оно работает :-)
Alexey Golovatenko
Egor Egorov <eg...@fine.kiev.ua> пишет в
сообщении:b69elo$ka3$1...@hyppo.gu.net...
> Pavel <pav...@uni.de> wrote:
>
> > Все, достало.
> > Сегодня же снесу это гавно :) и поставлю postfix, давно я в его сторону
> > смотрел.
>
> Я тоже. Несколько лет к этому шел, но таки прийдется перети с sendmail на
что-то
> другое. :-+
>
> Кто расскажет в двух словах про exim и postfix?
Установка в течении 5-10 минут
Конфигурится через встроенные конфиги кот требуют правки.
Фильтры, поддержка рбл, разные ручные фильтры, переадресации вплоть до
скрипту (одно время у меня работал форвард на смс через скриптик (дерибан
на куски, нормальная транслитерация итд - правда скриптец снесся после
закрытия на прием от моего айпишника)
Вообщем одни плюсы.
Ставь последний не бету и забудь про него на пару лет Ж-)
Basil Vizgin
>
> Pavel <pav...@uni.de> wrote:
>
> > Все, достало.
> > Сегодня же снесу это гавно :) и поставлю postfix, давно я в его сторону
> > смотрел.
>
> Я тоже. Несколько лет к этому шел, но таки прийдется перети с sendmail на что-то
> другое. :-+
>
> Кто расскажет в двух словах про exim и postfix?
По 20$ за слово?:)
Michael Shigorin
> да, думаю после исправления сендмайла за постфиксы и экзимы возьмутся...
--
---- WBR, Michael Shigorin <mi...@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/
Michael Shigorin
Igor Karpov
Egor Egorov <eg...@fine.kiev.ua> wrote:
> Pavel <pav...@uni.de> wrote:
>
>> Все, достало.
>> Сегодня же снесу это гавно :) и поставлю postfix, давно я в его сторону
>> смотрел.
>
> Я тоже. Несколько лет к этому шел, но таки прийдется перети с sendmail на что-то
> другое. :-+
>
> Кто расскажет в двух словах про exim и postfix?
Раз уж зашла об этом речь - здесь живёт русскоязычный список рассылки по
Exim:
http://karpov.com.ua/mailman/listinfo/
На днях был зарегистрирован exim.org.ua, через какое-то время список
будет перенесён туда. Если у кого-то есть желание и возможность создать
и поддерживать сайт по Exim, пишите. Не думаю, что есть смысл
поддерживать зеркало www.exim.org, лучше уж наполнять сайт переводными
документами, примерами и т.д. и т.п.
Regards,
--
Objectivity is in the eye of the beholder.
Alexander Trotsai
MS>Юрий_К <ad...@web-standart.net> wrote:
MS>> да, думаю после исправления сендмайла за постфиксы и экзимы возьмутся...
MS>За что??
чтоб не раслаблялись
если ты проснулся и у тебя ничего не болит - значит ты умер
:)
--
Best regard, Aleksander Trotsai aka MAGE-RIPE aka MAGE-UANIC
My PGP key at ftp://blackhole.adamant.ua/pgp/trotsai.key[.asc]
Ушел в себя и заблудился...
Alex V. Belinsky
> Pavel <pav...@uni.de> wrote:
>
>
>>Все, достало.
>>Сегодня же снесу это гавно :) и поставлю postfix, давно я в его сторону
>>смотрел.
>
>
> Я тоже. Несколько лет к этому шел, но таки прийдется перети с sendmail на что-то
> другое. :-+
>
> Кто расскажет в двух словах про exim и postfix?
>
читается как детская книжка. exim - для эстетов :)
--
FOZZ-RIPE
http://uafug.org.ua/
_K
> :)
>
Vladimi...@ukr.net
>> если ты проснулся и у тебя ничего не болит - значит ты умер
>> :)
>>
Видел как у нас прикручен drweb ?
Никаких нотифаев, ничего. На этапе SMTP сессии отбивает.
После точки в DATA говорит:
550 Message rejected: virus found.
--
VVS56-RIPE
Egor Egorov
> Кто расскажет в двух словах про exim и postfix?
Всем спасибо кто откликнулся:)
Victor Forsyuk
>> IMHO никогда. Изначально дырявый софт, каким был несколько лет назад, таким
>> и остался. Почему-то в Exim за все время его существования не было ни
>> одного remote root exploi
Версии 3.6 не было. Ты имел в виду 3.36?
Так это был не remote root, а local priviledge escalation, причем
воспользоваться могли только те, кто был внесен в admin group (то
есть и так уже не левые люди, а администраторы сервиса). Хотя
таковое уточнение, конечно, не оправдывает ;)
AG> Опосля вроде чисто
За всю историю (с '96-го?) я припоминаю только одну плюху, которая
могла быть ремотно использована при условии специфической конфигурации
exim'а.
Victor Forsyuk
>> Ну шо, сендмилівці, знов одягання латок на швидкість? ;-)))
А, ню-ню.
>> p.s. А може того - go postfix, go exim? ;-)
ЮК> а вот есть в экзиме либ-милтер такой-же?
http://www.exim.org
http://www.exim.org/exim-html-4.10/doc/html/spec.html
ЮК> да, думаю после исправления сендмайла за постфиксы и экзимы возьмутся...
"Всё равно его не брошу, потому что он хороший"? :-)))
Victor Forsyuk
>> если ты проснулся и у тебя ничего не болит - значит ты умер
>> :)
>>
В пузі (exiscan + what you want). Читайте доки - вони rulez! :)
Victor Forsyuk
VL> Egor Egorov wrote:
>> Кто расскажет в двух словах про exim и postfix?
VL> оно работает :-)
И таки уложился в 2 слова! :-)
Victor Forsyuk
MS> sudo apt-get install postfix-smtpd, пока Витя exim не собрал :)
А, у Егорова ALT? Тогда почему еще не postfix, который там default MTA?
exim у меня собран и уже более-менее причёсан - с нормальной разумности
дефолтным конфигом и т.п. Я просто с выкладыванием в Sisyphus не тороплюсь,
хочу ещё немного вкусностей добавить - примеров, комментариев (делаю
на русском и украинском откомментированный конфиг и украинский exim.8).
Valentin Nechayev
>>> Egor Egorov wrote:
>>> p.s. А може того - go postfix, go exim? ;-)
>> та давно уже пора :-)
EE> А вот интересно - хоть когда-нибудь поток дыр в sendmail прекратится?..
Есть такое слово - рефакторинг. Ты его знаешь.
Так вот - если в софт напихано функциональности в сто раз больше, чем было
изначально, причём рефакторинг не делался - то вся эта функциональность
приткнута кривоскрученной проволокой и держится на соплях.
Вот и весь тебе sendmail изнутри. Когда деструктор и конструктор письма -
одна и та же функция, причём генерация отлупов выполняется в деструкторе...
-netch-
Victor Forsyuk
>>
>> Кто расскажет в двух словах про exim и postfix?
>>
AVB> читается как детская книжка. exim - для эстетов :)
Никоим образом не хочу плохо отзываться о postfix'е - репутация у него
хорошая, автор уважаемый, работу он делает справно. И конфиг, таки да,
человеческий, с сендмыловским ни в какое сравнение...
Но имею IMHO, что у постфикса есть только один плюс в сравнении с exim -
он привычнее тем, кто переходит с сендмыла. Exim же построен и конфигурится
совершенно в другом стиле (и я бы сказал - "прозрачнее").
Я бы сказал, что мой окончательный выбор определило чтение FILTER_README
постфикса. Это слишком неэлегантно...
Valentin Nechayev
>>> Victor Forsyuk wrote:
AVB>> Ставь postfix. Разобраться проще. Конфиг по сравнению с сендмыловым
AVB>> читается как детская книжка. exim - для эстетов :)
VF> Никоим образом не хочу плохо отзываться о postfix'е - репутация у него
VF> хорошая, автор уважаемый, работу он делает справно. И конфиг, таки да,
VF> человеческий, с сендмыловским ни в какое сравнение...
VF> Но имею IMHO, что у постфикса есть только один плюс в сравнении с exim -
VF> он привычнее тем, кто переходит с сендмыла. Exim же построен и конфигурится
VF> совершенно в другом стиле (и я бы сказал - "прозрачнее").
У postfix есть один большой жирный плюс - параллельная раздача. В результате
это идеальное средство для эмиттера списка рассылки или провайдерского
smtp, когда задача - максимально быстро отдать и сдыхаться от нагрузки.
Раздача uanog'а, например, сократилась с ~40 минут до менее минуты на
подавляющее большинство адресов, при переходе на него.
И вообще, его построение заточено под этакий себе core router - минимум
навороченной обработки, максимум на лёгкость и скорость обработки.
Да, при этом добавляется функциональность на иные виды применений, но она
у него выглядит как-то сбоку припёка...
VF> Я бы сказал, что мой окончательный выбор определило чтение FILTER_README
VF> постфикса. Это слишком неэлегантно...
-netch-
Vladimi...@ukr.net
VF>> он привычнее тем, кто переходит с сендмыла. Exim же построен и конфигурится
VF>> совершенно в другом стиле (и я бы сказал - "прозрачнее").
VN> У postfix есть один большой жирный плюс - параллельная раздача. В результате
VN> это идеальное средство для эмиттера списка рассылки или провайдерского
VN> smtp, когда задача - максимально быстро отдать и сдыхаться от нагрузки.
Что значит параллельная раздача ?
--
VVS56-RIPE
Valentin Nechayev
>>> Vladimi...@Ukr.Net wrote:
VN>> У postfix есть один большой жирный плюс - параллельная раздача. В результате
VN>> это идеальное средство для эмиттера списка рассылки или провайдерского
VN>> smtp, когда задача - максимально быстро отдать и сдыхаться от нагрузки.
> Что значит параллельная раздача ?
Это когда одно и то же письмо доставляется одновременно на несколько серверов
назначения. Сколько стволов дадут, в столько и пойдёт ;)
-netch-
Andrey Blochintsev
В zmailer-е это тоже есть. Только он уже давно не развивается...
Michael Shigorin
> хочу ещё немного вкусностей добавить - примеров, комментариев (делаю
> на русском и украинском откомментированный конфиг и украинский exim.8).
Vladimi...@ukr.net
>> Что значит параллельная раздача ?
VN> назначения. Сколько стволов дадут, в столько и пойдёт ;)
А что с ним происходит, когда очередь скапливается ну просто
агромная, история умалчивает :(
В лучшем случае (очередь до 10к писем), нет проблем доставки,
postfix действительно бегает шустро. Но как только появляются
проблемы и в очереди накапливается огромное количество почты,
начинаются весьма серьезные тормоза и приходится говорить, что
количество smtp клиентов в количестве 600 штук многовато, снизим
до 200, а там и до 120. В итоге получается ситуация, когда
queue runner забирает под себя все отдающие ресурсы и если что-то
понадобилось прокинуть "дальше" и сейчас (случай провайдерского релея),
то обломайтис, нельзя: все заняты.
Именно из-за этой грабли я и забыл про постфикс на своем эмиттере.
Может из-за того, что нет у меня специфики frebsd-fug, а есть
обычный релей. BTW: на весьма слабом аппарате (даж стыдно говорить)
проблемная очередь всегда в районе 1200-2500 писем и LA~=0.5, что не
вызывает никаких затыков во время queue run для других доставщиков.
Нагрузка подскакивает до 1-1.5 во время пробегания по очереди.
PS: postfix простоял на mail-out.ukr.net кажется неделю, потом
был заменен из-за огромного LA на exim, после чего ситуация
стабилизировалась и вышла на автопилотный режим. Машина доставляет
в сутки в районе 120k писем.
--
VVS56-RIPE
George Pavlenko
news:2003040115...@segfault.kiev.ua...
Не совсем понял - зачем _одно_ письмо доставлять
на несколько серверов?
(Я надеюсь, речь не шла об альтернативных MX одного
и того же домена - чтобы на всякий случай распихать
письмо на них всех ;-)
Наверное, речь шла о том, что выходной спул разгребается
несколькими потоками параллельно: первый поток берет
первое письмо и пытается его отправить, второй поток -
второе и т.д. Кстати, эта фича есть и в ESMS. И те цифры
нагрузок, которые здесь (в K-писем) приводили товарищи
с ukr.net вполне у меня на Фортунате под ESMS соизмеримы.
Никаких заторов, и гниленький CPU нагружается ниже 1%...
(Это я конечно, никого не агитирую, просто обмениваюсь
опытом и информирую - вдруг кому интересно.)
Victor Forsyuk
>> Это когда одно и то же письмо доставляется одновременно на несколько серверов
>> назначения. Сколько стволов дадут, в столько и пойдёт ;)
GP> Не совсем понял - зачем _одно_ письмо доставлять
GP> на несколько серверов?
Затем, что у одного письма может быть несколько (и даже очень
много) получателей, обслуживаемых разными серверами.
GP> (Это я конечно, никого не агитирую, просто обмениваюсь
GP> опытом и информирую - вдруг кому интересно.)
Интересно чисто теоретически - не ставить же Windows только ради
того, чтобы попробовать Ваше ПО.
Andrey Anastassiev
>
> Не совсем понял - зачем _одно_ письмо доставлять
> на несколько серверов?
> (Я надеюсь, речь не шла об альтернативных MX одного
> и того же домена - чтобы на всякий случай распихать
> письмо на них всех ;-)
>
> Наверное, речь шла о том, что выходной спул разгребается
> несколькими потоками параллельно: первый поток берет
> первое письмо и пытается его отправить, второй поток -
> второе и т.д. Кстати, эта фича есть и в ESMS. И те цифры
Скорее имелось ввиду, одни потоки принимают письма и складывают их в
очередь, другие потоки маршрутизируют почту (это мне, это снова мне, это
нафиг, это туда, это сюда) и третьи потоки рассылают почту по серверам
или раскладывают по ящикам. При этом все это работает на разных компах
:) Ы? esms так умеет?
> нагрузок, которые здесь (в K-писем) приводили товарищи
> с ukr.net вполне у меня на Фортунате под ESMS соизмеримы.
> Никаких заторов, и гниленький CPU нагружается ниже 1%...
> (Это я конечно, никого не агитирую, просто обмениваюсь
> опытом и информирую - вдруг кому интересно.)
3 тыс писем за пару минут успеет обработать? Или пару часиков подождать
прийдется? И не просто в очередь воткнуть, а сразу пытаться отправить
адресатам. Учитывая что n% коннектов будет висеть на таймаутах, m%
процентов сразу вернется и k% будет с ошибками в адресе.
Кстати, все про exim, postfix и никто qmail не вспомнил :) а почему?
Valentin Nechayev
>>> Andrey Anastassiev wrote:
AA> >Не совсем понял - зачем _одно_ письмо доставлять
AA> >на несколько серверов?
AA> >(Я надеюсь, речь не шла об альтернативных MX одного
AA> >и того же домена - чтобы на всякий случай распихать
AA> >письмо на них всех ;-)
AA> >
AA> >Наверное, речь шла о том, что выходной спул разгребается
AA> >несколькими потоками параллельно: первый поток берет
AA> >первое письмо и пытается его отправить, второй поток -
AA> >второе и т.д. Кстати, эта фича есть и в ESMS. И те цифры
AA>
AA> Скорее имелось ввиду, одни потоки принимают письма и складывают их в
AA> очередь, другие потоки маршрутизируют почту (это мне, это снова мне, это
AA> нафиг, это туда, это сюда) и третьи потоки рассылают почту по серверам
AA> или раскладывают по ящикам. При этом все это работает на разных компах
AA> :) Ы? esms так умеет?
Тоже неправильно. Нет, речь про параллельную _раздачу_ _одного_ письма.
На одной машине (про много - разговор отдельный).
Когда получателей много, а сумма времён доставки на них чудовищна (бывают
и много суток), параллельная раздача сокращает время доставки на большинство
получателей до нескольких минут или даже секунд, оставляя мариноваться
только долготянущиеся доставки.
AA> Кстати, все про exim, postfix и никто qmail не вспомнил :) а почему?
Опять двадцать пять... кривая лицензия, невозможность развития иначе
как по соизволению DJB, хреновые логи (фиг проследишь к какому из N+1
доставляемых сейчас писем относится то или иное ругательство) и прочая
и прочая и прочая. И самый главный его козырь - железобетонная секурность -
давно покрыт postfix'ом, который даёт такую же защиту при значительно
большей и более удобной функциональности.
Мне одной фичи не хватает, что есть в qmail - *параметризованные*
тегированные форварды. Это когда письмо, например, на vasya-get-zuka
при наличии форварда ~vasya/.qmail-get- (не помню какой там суффикс)
вызывает программу в этом форварде и параметр `zuka' передаёт в переменной
окружения. Если кто из местных exim'оводов расскажет как это сделать на
exim - у меня будет где воткнуть exim...
-netch-
Authentic Vendor
news:b6cgtb$r9u$1...@whale.gu.net...
> George Pavlenko <em...@teleport.kiev.ua> wrote:
> >> Это когда одно и то же письмо доставляется одновременно на несколько
серверов
> >> назначения. Сколько стволов дадут, в столько и пойдёт ;)
>
> GP> Не совсем понял - зачем _одно_ письмо доставлять
> GP> на несколько серверов?
>
> Затем, что у одного письма может быть несколько (и даже очень
> много) получателей, обслуживаемых разными серверами.
Я понимал под письмом послание в адрес одного получателя.
(Так сказать математическая трактовка: сложная задача разбивается
на ряд поздадач. Понимаете?)
>
> GP> (Это я конечно, никого не агитирую, просто обмениваюсь
> GP> опытом и информирую - вдруг кому интересно.)
>
> Интересно чисто теоретически - не ставить же Windows только ради
> того, чтобы попробовать Ваше ПО.
Упаси боже! Речь, повторяю, шла только об "информации".
(Так сказать, из параллельного мира ;-)
Valentin Nechayev
>>> Что значит параллельная раздача ?
VN>> Это когда одно и то же письмо доставляется одновременно на несколько серверов
VN>> назначения. Сколько стволов дадут, в столько и пойдёт ;)
> А что с ним происходит, когда очередь скапливается ну просто
> агромная, история умалчивает :(
> В лучшем случае (очередь до 10к писем), нет проблем доставки,
> postfix действительно бегает шустро. Но как только появляются
> проблемы и в очереди накапливается огромное количество почты,
> начинаются весьма серьезные тормоза и приходится говорить, что
> количество smtp клиентов в количестве 600 штук многовато, снизим
> до 200, а там и до 120. В итоге получается ситуация, когда
> queue runner забирает под себя все отдающие ресурсы и если что-то
> понадобилось прокинуть "дальше" и сейчас (случай провайдерского релея),
> то обломайтис, нельзя: все заняты.
Ну, я с похожим сталкивался. Решено было тривиально - ставится fallback_relay
и всё, что не ушло за один цикл перебора MX'ов, отправляется на fallback.
В случае LN на fallback'е просто sendmail (ну, настроенный и запущенный
так, чтобы тянуть тяжёлую нагрузку из долгоиграющих писем).
А на самом деле при большом количестве smtp плющило систему: когда
вспухало письмо с большим количеством получателей, или просто [n]qmgr решал,
чтоо пора поднять всё deferred, он форкал дохрена smtp сразу, VM
говорила "ой" и аварийно скидывала всех в своп. Соответственно
LA прыгала до количества работающих процессов. То есть они оттуда оперативно
выползали, и кроме вспухания LA и всеобщей задумчивости на пару секунд -
проблем не было, но дежурные ругались;)
Против этого лечение - ограничить темп порождения новых процессов - я оформил
идею, но реализовать и посмотреть, насколько лечит, у меня руки не дошли,
решили ограничить smtp процессы количеством в два раза больше среднего
за бизнес-время.
> Именно из-за этой грабли я и забыл про постфикс на своем эмиттере.
Зря. Простой fallback уже лечит 90-95% этой проблемы.
> Может из-за того, что нет у меня специфики frebsd-fug, а есть
> обычный релей.
fug - ты про местную рассылку? - там не так много получателей.
На smtp.lucky.net спокойно вываливали и по две тысячи получателей.
Работало - типа вечером выбрасываем, а к утру оно расползётся.
Ну так оно стало расползаться не к утру, а за 3 секунды по Киеву, и максимум
за минуту - по Украине, на все живые сервера, а потом уже задумчиво
мариновало остальных.
> BTW: на весьма слабом аппарате (даж стыдно говорить)
> проблемная очередь всегда в районе 1200-2500 писем и LA~=0.5, что не
> вызывает никаких затыков во время queue run для других доставщиков.
> Нагрузка подскакивает до 1-1.5 во время пробегания по очереди.
> PS: postfix простоял на mail-out.ukr.net кажется неделю, потом
> был заменен из-за огромного LA на exim, после чего ситуация
> стабилизировалась и вышла на автопилотный режим. Машина доставляет
> в сутки в районе 120k писем.
Попробуй перед exim'ом воткнуть postfix с fallback_relay. Может, у тебя
какая-то существенная специфика, но IMO должно стоять ровно.
-netch-
Authentic Vendor
news:8e3pl-...@seawind.kiev.ua...
> Скорее имелось ввиду, одни потоки принимают письма и складывают их в
> очередь, другие потоки маршрутизируют почту (это мне, это снова мне, это
> нафиг, это туда, это сюда) и третьи потоки рассылают почту по серверам
> или раскладывают по ящикам.
Естественно. А как же иначе? ;-)
> При этом все это работает на разных компах
> :) Ы? esms так умеет?
На "разных компах"? Не знаю...
Одна копия ESMS работает на одном компе.
Но все это делает ;-)
> > нагрузок, которые здесь (в K-писем) приводили товарищи
> > с ukr.net вполне у меня на Фортунате под ESMS соизмеримы.
> > Никаких заторов, и гниленький CPU нагружается ниже 1%...
> > (Это я конечно, никого не агитирую, просто обмениваюсь
> > опытом и информирую - вдруг кому интересно.)
>
> 3 тыс писем за пару минут успеет обработать? Или пару часиков подождать
> прийдется? И не просто в очередь воткнуть, а сразу пытаться отправить
> адресатам. Учитывая что n% коннектов будет висеть на таймаутах, m%
> процентов сразу вернется и k% будет с ошибками в адресе.
Нет проблем. Ошибки (в адресах) у всех бывают.
У ESMS с этим проблем пока не наблюдалось: все
обрабатывается корректно. (И не только в укрнете,
кстати ;-)
Authentic Vendor
> AA> Скорее имелось ввиду, одни потоки принимают письма и складывают их в
> AA> очередь, другие потоки маршрутизируют почту (это мне, это снова мне,
это
> AA> нафиг, это туда, это сюда) и третьи потоки рассылают почту по серверам
> AA> или раскладывают по ящикам. При этом все это работает на разных компах
> AA> :) Ы? esms так умеет?
>
> Тоже неправильно. Нет, речь про параллельную _раздачу_ _одного_ письма.
> На одной машине (про много - разговор отдельный).
> Когда получателей много, а сумма времён доставки на них чудовищна (бывают
> и много суток), параллельная раздача сокращает время доставки на
большинство
> получателей до нескольких минут или даже секунд, оставляя мариноваться
> только долготянущиеся доставки.
В этой ситуации, как я уже писал в ответ г-ну Форсюку,
ESMS предпочитает рассматривать такую ситуацию как
сумму писем. Письмо в направлении N адресатов просто
разбивается на N писем, которые впоследствии отправляются
M потоками "на общем основании".
> Мне одной фичи не хватает, что есть в qmail - *параметризованные*
> тегированные форварды. Это когда письмо, например, на vasya-get-zuka
Кстати (опять же, прошу не рассматривать как агитацию), в ESMS
вопрос с форвардингом проработан, IMHO, неплохо...
Andrey Blochintsev
> >>> Что значит параллельная раздача ?
> VN>> Это когда одно и то же письмо доставляется одновременно на несколько серверов
> VN>> назначения. Сколько стволов дадут, в столько и пойдёт ;)
> > А что с ним происходит, когда очередь скапливается ну просто
> > агромная, история умалчивает :(
> > В лучшем случае (очередь до 10к писем), нет проблем доставки,
> > postfix действительно бегает шустро. Но как только появляются
> > проблемы и в очереди накапливается огромное количество почты,
> > начинаются весьма серьезные тормоза и приходится говорить, что
> > количество smtp клиентов в количестве 600 штук многовато, снизим
> > до 200, а там и до 120. В итоге получается ситуация, когда
> > queue runner забирает под себя все отдающие ресурсы и если что-то
> > понадобилось прокинуть "дальше" и сейчас (случай провайдерского релея),
> > то обломайтис, нельзя: все заняты.
>
> Ну, я с похожим сталкивался. Решено было тривиально - ставится fallback_relay
> и всё, что не ушло за один цикл перебора MX'ов, отправляется на fallback.
> В случае LN на fallback'е просто sendmail (ну, настроенный и запущенный
Ага, то есть postfix на "раздачу" справляется хуже sendmail-а...
Впрочем, скорей всего вопрос в умении и желании их готовить ;)
> так, чтобы тянуть тяжёлую нагрузку из долгоиграющих писем).
> А на самом деле при большом количестве smtp плющило систему: когда
> вспухало письмо с большим количеством получателей, или просто [n]qmgr решал,
> чтоо пора поднять всё deferred, он форкал дохрена smtp сразу, VM
> говорила "ой" и аварийно скидывала всех в своп. Соответственно
> LA прыгала до количества работающих процессов. То есть они оттуда оперативно
> выползали, и кроме вспухания LA и всеобщей задумчивости на пару секунд -
> проблем не было, но дежурные ругались;)
Хмм неужели zmailer "на раздачу" еще в лидерах...?
у него scheduler fork-ает "smtp-ы" (точней транспорты) по
потребностям, причем транспорт выполняет доставку не
единичного письма (точней одному адресату, так как доставка
даже одного письма разным адресатам идет независимо/параллельно),
а кормится от scheduler-а командами "доставляй это, доставляй то...";
если scheduler решает, что транспорт долго сидит без дела, может
и скомандовать завершиться. Есть ограничения как на общее число
транспортов, так и по "направлениям".
Только увы оно старое, и по современным меркам подходит только
"на раздачу".
> Против этого лечение - ограничить темп порождения новых процессов - я оформил
> идею, но реализовать и посмотреть, насколько лечит, у меня руки не дошли,
> решили ограничить smtp процессы количеством в два раза больше среднего
> за бизнес-время.
>
> > Именно из-за этой грабли я и забыл про постфикс на своем эмиттере.
>
> Зря. Простой fallback уже лечит 90-95% этой проблемы.
Ну дык этот fallback тоже нужен...
> > Может из-за того, что нет у меня специфики frebsd-fug, а есть
> > обычный релей.
>
> fug - ты про местную рассылку? - там не так много получателей.
> На smtp.lucky.net спокойно вываливали и по две тысячи получателей.
> Работало - типа вечером выбрасываем, а к утру оно расползётся.
> Ну так оно стало расползаться не к утру, а за 3 секунды по Киеву, и максимум
> за минуту - по Украине, на все живые сервера, а потом уже задумчиво
> мариновало остальных.
>
> > BTW: на весьма слабом аппарате (даж стыдно говорить)
> > проблемная очередь всегда в районе 1200-2500 писем и LA~=0.5, что не
> > вызывает никаких затыков во время queue run для других доставщиков.
> > Нагрузка подскакивает до 1-1.5 во время пробегания по очереди.
> > PS: postfix простоял на mail-out.ukr.net кажется неделю, потом
> > был заменен из-за огромного LA на exim, после чего ситуация
> > стабилизировалась и вышла на автопилотный режим. Машина доставляет
> > в сутки в районе 120k писем.
120k - это писем или "адресатов"?
_K
> Это когда одно и то же письмо доставляется одновременно на несколько серверов
> назначения. Сколько стволов дадут, в столько и пойдёт ;)
vladimi...@ukr.net
VN> Попробуй перед exim'ом воткнуть postfix с fallback_relay. Может, у тебя
VN> какая-то существенная специфика, но IMO должно стоять ровно.
Моя специфика 1,3 получателя на письмо. Никаких рассылок
через туда не проходит. Хотя попробую, если появится затык.
--
VVS56-RIPE
Andrey Anastassiev
> "Andrey Anastassiev" <sea...@ukrpost.net.localdomain> wrote in message
> news:8e3pl-...@seawind.kiev.ua...
>
>
>>Скорее имелось ввиду, одни потоки принимают письма и складывают их в
>>очередь, другие потоки маршрутизируют почту (это мне, это снова мне, это
>>нафиг, это туда, это сюда) и третьи потоки рассылают почту по серверам
>>или раскладывают по ящикам.
>
>
> Естественно. А как же иначе? ;-)
Имелось ввиду что одна программа только принимает почту, вторая
маршрутизирует, третья только отправляет (именно так работает qmail). А
не одна и та же программа и принимает и занимается маршрутизацией с
отправкой.
Еще раз уточню...
>>3 тыс писем за пару минут успеет обработать? Или пару часиков подождать
>>прийдется? И не просто в очередь воткнуть, а сразу пытаться отправить
>>адресатам. Учитывая что n% коннектов будет висеть на таймаутах, m%
>>процентов сразу вернется и k% будет с ошибками в адресе.
>
>
> Нет проблем. Ошибки (в адресах) у всех бывают.
> У ESMS с этим проблем пока не наблюдалось: все
> обрабатывается корректно. (И не только в укрнете,
> кстати ;-)
За сколько будет обработано порядка 3000 транзитных писем? С учетом
таймаутов, недостижимых серверов и просто тормознутых соединений (типа,
время соединения около 30-60 сек).
Alexandr Kovalenko
>> если ты проснулся и у тебя ничего не болит - значит ты умер
>> :)
>>
Есть ли жизнь в оффлайне?...
--
Alexandr Kovalenko
WNet ISP
Serge Pekarsky
>>
>> Нет проблем. Ошибки (в адресах) у всех бывают.
>> У ESMS с этим проблем пока не наблюдалось: все
>> обрабатывается корректно. (И не только в укрнете,
>> кстати ;-)
>
> За сколько будет обработано порядка 3000 транзитных писем? С учетом
> таймаутов, недостижимых серверов и просто тормознутых соединений (типа,
> время соединения около 30-60 сек).
>
обсудить тут же с местными гуру.
а то Вендоры только зазнаваться мастера. (съедет/не съедет?)
--
Serge Pekarsky
SP4-UANIC
Oleh Hrynchuk
Вас тут носом пхали в РФЦ вже десь з рік...
Правда без особливого толку... :(
"Authentic Vendor" <auth...@vendor.kiev.ua> сообщил/сообщила в новостях
следующее: news:b6cn93$a2a$1...@news.lucky.net...
Alex V. Belinsky
>>>>Victor Forsyuk wrote:
>
>
> AVB>> Ставь postfix. Разобраться проще. Конфиг по сравнению с сендмыловым
> AVB>> читается как детская книжка. exim - для эстетов :)
> VF> Никоим образом не хочу плохо отзываться о postfix'е - репутация у него
> VF> хорошая, автор уважаемый, работу он делает справно. И конфиг, таки да,
> VF> человеческий, с сендмыловским ни в какое сравнение...
> VF> Но имею IMHO, что у постфикса есть только один плюс в сравнении с exim -
> VF> он привычнее тем, кто переходит с сендмыла. Exim же построен и конфигурится
> VF> совершенно в другом стиле (и я бы сказал - "прозрачнее").
>
> У postfix есть один большой жирный плюс - параллельная раздача. В результате
> это идеальное средство для эмиттера списка рассылки или провайдерского
> smtp, когда задача - максимально быстро отдать и сдыхаться от нагрузки.
всё-таки остался сендмыл - уж очень лениво и напряжно на работающем
мыльнике перенаточку делать.
> Раздача uanog'а, например, сократилась с ~40 минут до менее минуты на
> подавляющее большинство адресов, при переходе на него.
> И вообще, его построение заточено под этакий себе core router - минимум
> навороченной обработки, максимум на лёгкость и скорость обработки.
> Да, при этом добавляется функциональность на иные виды применений, но она
> у него выглядит как-то сбоку припёка...
>
М-да, выстрел какого-нить списка рассылки на пару-десять тысяч
рисипиентов выглядит впечатляюще - разлетается в считанные минуты.
> VF> Я бы сказал, что мой окончательный выбор определило чтение FILTER_README
> VF> постфикса. Это слишком неэлегантно...
>
>
> -netch-
--
FOZZ-RIPE
http://uafug.org.ua/
Michael Shigorin
> Впрочем, скорей всего вопрос в умении и желании их готовить ;)
резолвинг на тот бэкрезолвинг, что выдается для LL?
Michael Shigorin
> Имелось ввиду что одна программа только принимает почту, вторая
> маршрутизирует, третья только отправляет (именно так работает qmail).
привилегиями.
Vladimi...@ukr.net
>> Имелось ввиду что одна программа только принимает почту, вторая
>> маршрутизирует, третья только отправляет (именно так работает qmail).
MS> привилегиями.
Да в сад эти привилегии, когда более-менее нужные фичи нельзя
прикрутить.
--
VVS56-RIPE
Valentin Nechayev
>> Тоже неправильно. Нет, речь про параллельную _раздачу_ _одного_ письма.
>> На одной машине (про много - разговор отдельный).
>> Когда получателей много, а сумма времён доставки на них чудовищна (бывают
>> и много суток), параллельная раздача сокращает время доставки на
>> большинство
>> получателей до нескольких минут или даже секунд, оставляя мариноваться
>> только долготянущиеся доставки.
AV> В этой ситуации, как я уже писал в ответ г-ну Форсюку,
AV> ESMS предпочитает рассматривать такую ситуацию как
AV> сумму писем. Письмо в направлении N адресатов просто
AV> разбивается на N писем, которые впоследствии отправляются
AV> M потоками "на общем основании".
Плавали, знаем. Sendmail 8.12 так делает. К сожалению, это половинчатое
решение. Один тяжелый получатель задерживает всех легких после него.
-netch-
Lucky Vendor
> AV> В этой ситуации, как я уже писал в ответ г-ну Форсюку,
> AV> ESMS предпочитает рассматривать такую ситуацию как
> AV> сумму писем. Письмо в направлении N адресатов просто
> AV> разбивается на N писем, которые впоследствии отправляются
> AV> M потоками "на общем основании".
>
> Плавали, знаем. Sendmail 8.12 так делает. К сожалению, это половинчатое
> решение. Один тяжелый получатель задерживает всех легких после него.
Я вас не понимаю. В чем состоит "половинчатость"?
Возможно, я просто не до конца ясно выразился?
Попробую еще раз. Имеем N писем: первое в адрес X1
получателей, второе - в адрес X2 получателей,..., N-е -
в адрес XN получателей. В итоге нужно обработать
X1+X2+...+XN независимых задач. Это поручается M
потокам. На мой взгляд, время выполнения этой задачи
не зависит от того, в каком порядке это будет делаться.
(Во всяком случае, _наперед_ сделать об этом какие-либо
предположения IMHO невозможно.) ESMS сразу разбивает
все это на одноадресные письма и отправляет их всех по
очереди M потоками. (Разбивка выполняется одним демоном,
отправка - другим.)
Lucky Vendor
> >>Скорее имелось ввиду, одни потоки принимают письма и складывают их в
> >>очередь, другие потоки маршрутизируют почту (это мне, это снова мне, это
> >>нафиг, это туда, это сюда) и третьи потоки рассылают почту по серверам
> >>или раскладывают по ящикам.
> >
> >
> > Естественно. А как же иначе? ;-)
>
> Имелось ввиду что одна программа только принимает почту, вторая
> маршрутизирует, третья только отправляет (именно так работает qmail). А
> не одна и та же программа и принимает и занимается маршрутизацией с
> отправкой.
В ESMS каждая задача решается отдельным демоном.
(Все они, впрочем, работают в рамках одного процесса.
Однако, какое это имеет значение?)
>
> Еще раз уточню...
>
> >>3 тыс писем за пару минут успеет обработать? Или пару часиков подождать
> >>прийдется? И не просто в очередь воткнуть, а сразу пытаться отправить
> >>адресатам. Учитывая что n% коннектов будет висеть на таймаутах, m%
> >>процентов сразу вернется и k% будет с ошибками в адресе.
> >
> >
> > Нет проблем. Ошибки (в адресах) у всех бывают.
> > У ESMS с этим проблем пока не наблюдалось: все
> > обрабатывается корректно. (И не только в укрнете,
> > кстати ;-)
>
> За сколько будет обработано порядка 3000 транзитных писем? С учетом
> таймаутов, недостижимых серверов и просто тормознутых соединений (типа,
> время соединения около 30-60 сек).
Все зависит от:
1) Количества рабочих потоков отправки (задается
админом в конфиге)
2) Ширины канала
3) Процента "гнилых" писем (неверный адрес,
лежит принимающий SMTP и т.д.)
Michael Shigorin
PS: по части "эмиттеров": а опенрелеи -- это схемы с открытым анодом,
которые могут некисло перегреть катоды своего и последующих каскадов и
даже выжечь питание предыдущих...
Michael Shigorin
> В ESMS каждая задача решается отдельным демоном.
> (Все они, впрочем, работают в рамках одного процесса.
> Однако, какое это имеет значение?)
Valentin Nechayev
>>> Andrey Blochintsev wrote:
>> Ну, я с похожим сталкивался. Решено было тривиально - ставится fallback_relay
>> и всё, что не ушло за один цикл перебора MX'ов, отправляется на fallback.
>> В случае LN на fallback'е просто sendmail (ну, настроенный и запущенный
AB> Ага, то есть postfix на "раздачу" справляется хуже sendmail-а...
AB> Впрочем, скорей всего вопрос в умении и желании их готовить ;)
ну, it depends. Я игрался только с nqmgr (потому что qmgr, когда я его
копал, работал, мягко говоря, странно). Может, qmgr с этим сейчас справляется
лучше.
>> так, чтобы тянуть тяжёлую нагрузку из долгоиграющих писем).
>> А на самом деле при большом количестве smtp плющило систему: когда
>> вспухало письмо с большим количеством получателей, или просто [n]qmgr решал,
>> чтоо пора поднять всё deferred, он форкал дохрена smtp сразу, VM
>> говорила "ой" и аварийно скидывала всех в своп. Соответственно
>> LA прыгала до количества работающих процессов. То есть они оттуда оперативно
>> выползали, и кроме вспухания LA и всеобщей задумчивости на пару секунд -
>> проблем не было, но дежурные ругались;)
AB> Хмм неужели zmailer "на раздачу" еще в лидерах...?
AB> у него scheduler fork-ает "smtp-ы" (точней транспорты) по
AB> потребностям, причем транспорт выполняет доставку не
AB> единичного письма (точней одному адресату, так как доставка
AB> даже одного письма разным адресатам идет независимо/параллельно),
AB> а кормится от scheduler-а командами "доставляй это, доставляй то...";
AB> если scheduler решает, что транспорт долго сидит без дела, может
AB> и скомандовать завершиться. Есть ограничения как на общее число
AB> транспортов, так и по "направлениям".
AB> Только увы оно старое, и по современным меркам подходит только
AB> "на раздачу".
Судя по твоему описанию - да, он работает лучше. То есть форкать транспорты
оно форкает по потребности, и завершает если не нужен. А вот команды
транспортам отправляются, кажется, без учета текущих соединений. Хотя здесь
я мог вполне соврать - этот уровень копал очень мало.
>> Зря. Простой fallback уже лечит 90-95% этой проблемы.
AB> Ну дык этот fallback тоже нужен...
А он и так нужен. Грубо говоря, нагрузка первой попытки доставки и нагрузка
долго не доставляемых писем - очень разные по характеру, и когда у меня
появилась возможность все вторые вынести на отдельный тазик (даже не очередь
и не демон, а тазик) - это было сделано.
> >> стабилизировалась и вышла на автопилотный режим. Машина доставляет
> >> в сутки в районе 120k писем.
AB> 120k - это писем или "адресатов"?
Судя по сообщению про 1.3 адресата на письмо в среднем - это без разницы.
-netch-
Valentin Nechayev
>>> vladimi...@ukr.net wrote:
VN>> Попробуй перед exim'ом воткнуть postfix с fallback_relay. Может, у тебя
VN>> какая-то существенная специфика, но IMO должно стоять ровно.
> Моя специфика 1,3 получателя на письмо. Никаких рассылок
> через туда не проходит. Хотя попробую, если появится затык.
Ну тогда: если получателей больше, например, 20, и через этот сервер еще
не проходило, и DSN не запрошено (postfix не умеет DSN) - отдать на postfix.
На exim'овом языке это должно делаться достаточно просто.
-netch-
_K
подозрительно - может он и работает так-же?
Lucky Vendor
news:sfsql-...@inmetex.com.ua...
> Lucky Vendor <ven...@ln.ua> wrote:
> > В ESMS каждая задача решается отдельным демоном.
> > (Все они, впрочем, работают в рамках одного процесса.
> > Однако, какое это имеет значение?)
>
> Wow.
Wow здесь совершенно ни при чем: он исполняет
в NT 16-битные модули, в то время как ESxx являются
32-битными задачами, и, таким образом, ни в какой
трансляции не нуждаются (напомню, что в NT все
сводится в конечном счете к Win32 API - "родной"
архитектуре этой ОС).
Vladimi...@ukr.net
K> а что www.exim.org - это сайт экзима?
K> подозрительно - может он и работает так-же?
а что там не так ? :-)
--
VVS56-RIPE
Vladimi...@ukr.net
VN>>> Попробуй перед exim'ом воткнуть postfix с fallback_relay. Может, у тебя
VN>>> какая-то существенная специфика, но IMO должно стоять ровно.
>> Моя специфика 1,3 получателя на письмо. Никаких рассылок
>> через туда не проходит. Хотя попробую, если появится затык.
VN> Ну тогда: если получателей больше, например, 20, и через этот сервер еще
VN> не проходило, и DSN не запрошено (postfix не умеет DSN) - отдать на postfix.
VN> На exim'овом языке это должно делаться достаточно просто.
http://dun.ukr.net/exim/spec_13.html#IX921
remote_max_parallel
Type: integer
Default: 2
This option controls parallel delivery of one message to a number of remote hosts. If the value is less than 2, parallel delivery is disabled, and Exim does all the remote
deliveries for a message one by one. Otherwise, if a single message has to be delivered to more than one remote host, or if several copies have to be sent to the same remote host, up to remote_max_parallel deliveries are done simultaneously. If more than remote_max_parallel deliveries are required, the maximum number of processes are started, and as each one finishes, another is begun. The order of starting processes is the same as if sequential delivery were being done, and can be controlled by the remote_sort_domains option. If parallel delivery takes place while running with debugging turned on, the debugging output from each delivery process is tagged with its process id.
This option controls only the maximum number of parallel deliveries for one message in one Exim delivery process. Because Exim has no central queue manager, there is no way of controlling the total number of simultaneous deliveries if the configuration allows a delivery attempt as soon as a message is received. If you want to control the total number of deliveries on the system, you need to set the queue_only option. This ensures that all incoming messages are added to the queue without starting a delivery process. Then set up an Exim daemon to start queue runner processes at appropriate intervals (probably fairly often, for example, every minute), and limit the total number of queue runners by setting the queue_run_max parameter. Because each queue runner delivers only one message at a time, the maximum number of deliveries that can then take place at once is queue_run_max multiplied by remote_max_parallel.
(Тут мы можем контролировать не количеством, а через LA, см. deliver_queue_load_max)
If it is purely remote deliveries you want to control, use queue_smtp instead of queue_only. This has the added benefit of doing the SMTP routing before queuing, so that several messages for the same host will eventually get delivered down the same connection.
--
VVS56-RIPE
Victor Forsyuk
VF>> Никоим образом не хочу плохо отзываться о postfix'е - репутация у него
VF>> хорошая, автор уважаемый, работу он делает справно. И конфиг, таки да,
VF>> человеческий, с сендмыловским ни в какое сравнение...
VF>> Но имею IMHO, что у постфикса есть только один плюс в сравнении с exim -
VF>> он привычнее тем, кто переходит с сендмыла. Exim же построен и конфигурится
VF>> совершенно в другом стиле (и я бы сказал - "прозрачнее").
VN> У postfix есть один большой жирный плюс - параллельная раздача. В результате
У exim тоже это есть.
VN> это идеальное средство для эмиттера списка рассылки или провайдерского
VN> smtp, когда задача - максимально быстро отдать и сдыхаться от нагрузки.
У провайдера есть и другие задачи. ;-)
Valentin Nechayev
>>> Victor Forsyuk wrote:
VF>>> Но имею IMHO, что у постфикса есть только один плюс в сравнении с exim -
VF>>> он привычнее тем, кто переходит с сендмыла. Exim же построен и конфигурится
VF>>> совершенно в другом стиле (и я бы сказал - "прозрачнее").
VN>> У postfix есть один большой жирный плюс - параллельная раздача. В результате
VF> У exim тоже это есть.
Мне уже доложили;) Когда я последний раз его смотрел - наверно, не было.
Но у exim'а она не синхронизирована между параллельно работающими доставками,
это IMO не слишком хорошо (я этих чудес с неуправляемыми доставками уже
у sendmail'а насмотрелся). Ограничение через LA - это не ограничение,
а издевательство. Было бы что-то типа hoststat'а, но с >1 доставкой на
целевой сервер - было бы нормальное решение.
(Postfix страдает дуркой с другой стороны - у него ограничение параллельных
доставок по почтовому домену назначения, но не по серверу получателя.
В результате он способен открыть одновременно по одному соединению на письмо
на fallback relay, давая такой себе DoS для того. Exim, судя по описанию,
способен на аналогичные шутки.)
VN>> это идеальное средство для эмиттера списка рассылки или провайдерского
VN>> smtp, когда задача - максимально быстро отдать и сдыхаться от нагрузки.
VF> У провайдера есть и другие задачи. ;-)
Ну так я на другие и не предлагаю.
-netch-
Sergiy Zhuk
On Tue, 01 Apr 2003, Valentin Nechayev writes:
> У postfix есть один большой жирный плюс - параллельная раздача. В результате
Это есть, но нет механизма приоритетов на очереди.
Скажем, sendmail-у можно рассказать, что очередь на внутренние машины нужно
разгребать каждые N секунд вне зависимости от предыдущего статуса хоста.
Еще ему можно объяснить, что для aol.com нужно использовать другие time outs
на сессии и кешировать соединение, а для других это не нужно и т.д.
> И вообще, его построение заточено под этакий себе core router - минимум
> навороченной обработки, максимум на лёгкость и скорость обработки.
еще мне понравилась реализация и конфигурация TLS, хоть она и не родная...
--
rgds,
serge
Valentin Nechayev
>>> Sergiy Zhuk wrote:
>> У postfix есть один большой жирный плюс - параллельная раздача. В результате
SZ> Это есть, но нет механизма приоритетов на очереди.
Потому что очередь одна.
SZ> Скажем, sendmail-у можно рассказать, что очередь на внутренние машины нужно
SZ> разгребать каждые N секунд вне зависимости от предыдущего статуса хоста.
Ась? Это где? Прочитал описание определения queuegroup, нигде такого
не нашёл.
SZ> Еще ему можно объяснить, что для aol.com нужно использовать другие time outs
SZ> на сессии и кешировать соединение, а для других это не нужно и т.д.
Расскажи как. То ли я сегодня полный тормоз, то ли это фича только
вашего сендмыла, а в стандартном такого нет.
>> И вообще, его построение заточено под этакий себе core router - минимум
>> навороченной обработки, максимум на лёгкость и скорость обработки.
SZ> еще мне понравилась реализация и конфигурация TLS, хоть она и не родная...
-netch-
Andrey Blochintsev
>
> SZ> Скажем, sendmail-у можно рассказать, что очередь на внутренние машины нужно
> SZ> разгребать каждые N секунд вне зависимости от предыдущего статуса хоста.
>
> Ась? Это где? Прочитал описание определения queuegroup, нигде такого
> не нашёл.
Кто, про что, я про zmailer ;)
*/*
# when the scheduler gets to the end of the retry sequence,
# it starts over at some random point in the middle. The
# numbers are factors of the scheduling interval.
retries="1 1 2 3 5 8 13 21 34"
smtp/*{my.local.domain,my.other.domain}
# when the scheduler gets to the end of the retry sequence,
# it starts over at some random point in the middle. The
# numbers are factors of the scheduling interval.
retries="1 1 1"
Покрутив еще и maxchannel/maxring/MaxTHR, добиваемся того, что на my.local.domain
почта ходит независимо от занятости transport-ов для остального.
>
> SZ> Еще ему можно объяснить, что для aol.com нужно использовать другие time outs
> SZ> на сессии и кешировать соединение, а для других это не нужно и т.д.
>
> Расскажи как. То ли я сегодня полный тормоз, то ли это фича только
> вашего сендмыла, а в стандартном такого нет.
Ну как минимум, можно описать другой mailer, который "тоже smtp",
но с другими параметрами + mailertable.
Sergiy Zhuk
On Thu, 03 Apr 2003, Valentin Nechayev writes:
> SZ> Скажем, sendmail-у можно рассказать, что очередь на внутренние машины нужно
> SZ> разгребать каждые N секунд вне зависимости от предыдущего статуса хоста.
>
> Ась? Это где? Прочитал описание определения queuegroup, нигде такого
> не нашёл.
>
> SZ> Еще ему можно объяснить, что для aol.com нужно использовать другие time outs
> SZ> на сессии и кешировать соединение, а для других это не нужно и т.д.
>
> Расскажи как. То ли я сегодня полный тормоз, то ли это фича только
> вашего сендмыла, а в стандартном такого нет.
ну вот, например, так (кусок скрипта, запускающего сендмыл):
$SM -bd
# daemons running the queue
$SM -q31s -OMinQueueAge=5d -OMaxDaemonChildren=20 \
-OPidFile=$PIDFILE.1
$SM -q47s -OMaxDaemonChildren=32 \
-OPidFile=$PIDFILE.2
$SM -q59s -OMaxDaemonChildren=32 \
-OPidFile=$PIDFILE.3
$SM -q10m -qRyahoo.com -OMaxDaemonChildren=8 \
-OForkEachJob=0 -OHostStatusDirectory="" -OMinQueueAge=0 \
-OPidFile=$PIDFILE.5
$SM -q30m -qRaol.com -OMaxDaemonChildren=8 \
-OForkEachJob=0 -OHostStatusDirectory="" \
-OPidFile=$PIDFILE.6
$SM -q30m -qRhotmail.com -OMaxDaemonChildren=8 \
-OForkEachJob=0 -OHostStatusDirectory="" \
-OPidFile=$PIDFILE.7
$SM -q30m -qRwebtv.com -OMaxDaemonChildren=8 \
-OForkEachJob=0 -OHostStatusDirectory="" \
-OPidFile=$PIDFILE.8
При этом делаешь multiple queues:
define(`QUEUE_DIR', `/var/spool/mqueue/q*')dnl
и сами каталоги:
mkdir -p /var/spool/mqueue/q{0,1,2,3}/{q,x,d}f
В сумме это очень сильно помогает.
Для incoming relays немного другие настройки.
--
rgds,
serge
Valentin Nechayev
>>> Sergiy Zhuk wrote:
> SZ>> Еще ему можно объяснить, что для aol.com нужно использовать другие time outs
> SZ>> на сессии и кешировать соединение, а для других это не нужно и т.д.
SZ> $SM -q10m -qRyahoo.com -OMaxDaemonChildren=8 \
SZ> -OForkEachJob=0 -OHostStatusDirectory="" -OMinQueueAge=0 \
SZ> -OPidFile=$PIDFILE.5
Таки торможу. Сам так делал когда надо было. Но это же не конфигом...
-netch-
Sergiy Zhuk
On Fri, 04 Apr 2003, Valentin Nechayev writes:
> SZ> -OPidFile=$PIDFILE.5
>
> Таки торможу. Сам так делал когда надо было. Но это же не конфигом...
Непринципиально.
А вот на postfix такое не исполнишь, да и ручками очередь не разгребешь.
Короче, на incoming еще туда-сюда, а на outgoing только если туча мыла на
*много разных* доменов.
Зоопарк, однако - это плохо, хотя местами неизбежно...
--
rgds,
serge
Yaroslav Halchinsky
> Непринципиально.
> А вот на postfix такое не исполнишь, да и ручками очередь не разгребешь.
> Короче, на incoming еще туда-сюда, а на outgoing только если туча мыла на
> *много разных* доменов.
> Зоопарк, однако - это плохо, хотя местами неизбежно...
В postfix можно почту на разные destinations доставлять разными транспортами,
которые суть smtp, запущенные с разными ключиками.
--
Regards,
Yaroslav Halchinsky
Sergiy Zhuk
On Mon, 07 Apr 2003, Yaroslav Halchinsky writes:
> В postfix можно почту на разные destinations доставлять разными транспортами,
> которые суть smtp, запущенные с разными ключиками.
Похоже, не совсем то, т.е. это только часть задачи.
Еще важно, как часто проверять очередь в зависимости от destination.
Есть какой-то flush, который типа аналог sendmail -qR, но он на него мало
похож.
--
rgds,
serge
Victor Forsyuk
VN> Мне одной фичи не хватает, что есть в qmail - *параметризованные*
VN> тегированные форварды. Это когда письмо, например, на vasya-get-zuka
VN> при наличии форварда ~vasya/.qmail-get- (не помню какой там суффикс)
VN> вызывает программу в этом форварде и параметр `zuka' передаёт в переменной
VN> окружения. Если кто из местных exim'оводов расскажет как это сделать на
VN> exim - у меня будет где воткнуть exim...
Вопрос - тебе хочется сделать drop-in replacement? Т.е., научить exim
обрабатывать существующие .qmail-фафа-ляля файлы? Или годится просто
в любом виде реализация тегированных форвардов с параметрами?
Если первое - надо малость почесать репу. Задача, явно, реализуемая,
хотя, наверняка, конфигурация не будет отличаться читабельностью ;)
Если второе, то это что-то в таком стиле:
В секции routers:
userforward:
driver = redirect
check_local_user
file = $home/.forward
allow_filter
no_verify
no_expn
local_part_suffix = "-*"
local_part_suffix_optional
check_ancestor
Сам файл .forward должен быть exim'овским фильтром, то есть, начинаться
со строки
# Exim filter
и содержать логику, позволяющую передавать суффикс в шелловский враппер,
который и установит его в переменную окружения (если именно в этом
задача):
if $local_part_suffix is "-foo"
then
save $home/Mail/foo-folder
else
pipe "/path/to/pipe/shell-wrapper $local_part_suffix"
endif
Victor Forsyuk
>> VF> Но имею IMHO, что у постфикса есть только один плюс в сравнении с exim -
>> VF> он привычнее тем, кто переходит с сендмыла. Exim же построен и конфигурится
>> VF> совершенно в другом стиле (и я бы сказал - "прозрачнее").
>>
>> У postfix есть один большой жирный плюс - параллельная раздача. В результате
>> это идеальное средство для эмиттера списка рассылки или провайдерского
>> smtp, когда задача - максимально быстро отдать и сдыхаться от нагрузки.
AVB> Именно так и пользуем - в качестве outgoing SMTP emitter. На приём еще
AVB> всё-таки остался сендмыл - уж очень лениво и напряжно на работающем
AVB> мыльнике перенаточку делать.
Разве что лениво ;-). Я глобаловские почтовики перевёл, никаких граблей,
всё переключилось тихо и незаметно. Зато теперь система управляется легко
и естественно, без ударов кувалдой по sendmail.cf и подозрений в
нетрадиционности Эрика Оллмена.
AVB> М-да, выстрел какого-нить списка рассылки на пару-десять тысяч
AVB> рисипиентов выглядит впечатляюще - разлетается в считанные минуты.
Так и в exim это не проблема. А вот когда тебе захочется настроить
фильтрацию спама или вирусов... "почувствуйте разницу" (c) рекалама
Victor Forsyuk
VN>>> У postfix есть один большой жирный плюс - параллельная раздача. В результате
VF>> У exim тоже это есть.
VN> Мне уже доложили;)
Я уже прочитал;)
VN> Когда я последний раз его смотрел - наверно, не было.
Странно, если верить табличке опций, то remote_max_parallel существовала
с самого начала (впрочем, проверять лениво).
VN> Но у exim'а она не синхронизирована между параллельно работающими доставками,
VN> это IMO не слишком хорошо (я этих чудес с неуправляемыми доставками уже
Да, есть такое. Автор явно исповедует принцип KISS :)
VN> у sendmail'а насмотрелся). Ограничение через LA - это не ограничение,
VN> а издевательство. Было бы что-то типа hoststat'а, но с >1 доставкой на
VN> целевой сервер - было бы нормальное решение.
Насколько я понял автора, он считает "более дешевым нормальным решением"
прогон рассылки через очередь (queue_smtp*) с частым запуском разбора
очереди (типа раз в минуту). Минус - некоторая (допустим, минутная)
задержка, плюс - queue-runner уже имеет информацию о роутинге и может
вдувать кучу писем через одно SMTP-соединение.
VN> (Postfix страдает дуркой с другой стороны - у него ограничение параллельных
VN> доставок по почтовому домену назначения, но не по серверу получателя.
VN> В результате он способен открыть одновременно по одному соединению на письмо
VN> на fallback relay, давая такой себе DoS для того. Exim, судя по описанию,
VN> способен на аналогичные шутки.)
Хмм... насколькя я понял, нет.
Alex V. Belinsky
> Alex V. Belinsky <fo...@kw.ua.no.spam> wrote:
>
> >
> AVB> Именно так и пользуем - в качестве outgoing SMTP emitter. На приём еще
> AVB> всё-таки остался сендмыл - уж очень лениво и напряжно на работающем
> AVB> мыльнике перенаточку делать.
>
> Разве что лениво ;-). Я глобаловские почтовики перевёл, никаких граблей,
> всё переключилось тихо и незаметно. Зато теперь система управляется легко
> и естественно, без ударов кувалдой по sendmail.cf и подозрений в
> нетрадиционности Эрика Оллмена.
>
reject'ами по unresolved. Не заметил? ;)
> AVB> М-да, выстрел какого-нить списка рассылки на пару-десять тысяч
> AVB> рисипиентов выглядит впечатляюще - разлетается в считанные минуты.
>
> Так и в exim это не проблема. А вот когда тебе захочется настроить
> фильтрацию спама или вирусов... "почувствуйте разницу" (c) рекалама
>
Настроено, Витя, всё уже настроено. Никаких проблем с прикручиванием
ДрВеба и прочих content-filters. Стесин не даст соврать. :)
И я ж не спорю на тему exim vs. postfix.
--
FOZZ-RIPE
http://uafug.org.ua/