Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

hi,

 Fri, Oct 16, 2015 at 20:58:47, eugen wrote about "Re: [freebsd] sendmail + 
roundcube": 

> Зависит от определения стандартной конфигурации.
> С дефолтным конфигом и под атакой - да, есть проблемы,

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

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

Нет.


-netch-

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

 Fri, Oct 16, 2015 at 21:30:33, eugen wrote about "Re: [freebsd] sendmail + 
roundcube": 

> >>> Но реально даже плюсанутые localparts используют только нердомамонты.
> 
> Просто потому что тупо не знают о возможностях MTA, схемах адресации
> и вообще читать документацию немодно.
> 
> Откуда им знать, что в sendmail, для того чтобы, скажем, прикрутить
> IM-рассылку к уведомлениям из JIRA в дополнение к почтовым уведомлениям,
> есть готовая схема адресации вида username+79876543...@domain.org?

"Готовая схема", говорите?

> При которой полное уведомление доставляется по адресу usern...@domain.org,
> а заголовок письма уходит по SMS или через какой-нибудь Instant messaging,
> и что для этого достаточно прописать три строчки в .mc, указав путь к команде
> отправки SMS или IM и шаблон для её аргументов и затем рулить просто записями
> в virtusertable, выбирая, которые домены/субдомены/отдельные ящики 
> обрабатывать
> по такой схеме.

Вы что-то не то курили, коллега.

Во-первых, там в принципе нет никакого автомата типа "полное письмо -
в основной ящик, заголовок - на SMS". Есть форвард, в котором лучшее,
что можно сделать - это сделать отдельный ~/.forward+P2 для адреса
вида user+P2, и передать это в procmail.
Не делается даже укладки этого суффикса в окружение, в отличие,
например, от exim.
То есть "схема" требует полного заката солнца вручную в виде форварда
на свой код.
(Напоминаю, что расщепление адресатов возможно только при алиасе или
форварде. Лукап по virtusertable на это неспособен.)

Во-вторых, в самом интересном варианте - локального форварда - схема
работает относительно недавно, когда в ForwardPath сделали добавку в
виде поиска с +$h. В те времена, когда это было максимально нужно,
этой добавки не было, и надо было руками (.mc, etc.) менять ForwardPath
на вариант с ним.

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

> А ведь всё это документировано в Sendmail Installation and Operation Guide,
> что идёт в дистрибутиве.

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


-netch-

Re: [freebsd] sendmail + roundcube

[Eugene Grosbein]

On 17.10.2015 00:48, Valentin Nechayev wrote:

> Но реально даже плюсанутые localparts используют только нердомамонты.
>>
>> Просто потому что тупо не знают о возможностях MTA, схемах адресации
>> и вообще читать документацию немодно.
>>
>> Откуда им знать, что в sendmail, для того чтобы, скажем, прикрутить
>> IM-рассылку к уведомлениям из JIRA в дополнение к почтовым уведомлениям,
>> есть готовая схема адресации вида username+79876543...@domain.org?
> 
> "Готовая схема", говорите?

Да, весь синтаксический сахар в коде sendmail уже есть, только используй.

>> При которой полное уведомление доставляется по адресу usern...@domain.org,
>> а заголовок письма уходит по SMS или через какой-нибудь Instant messaging,
>> и что для этого достаточно прописать три строчки в .mc, указав путь к команде
>> отправки SMS или IM и шаблон для её аргументов и затем рулить просто записями
>> в virtusertable, выбирая, которые домены/субдомены/отдельные ящики 
>> обрабатывать
>> по такой схеме.
> 
> Вы что-то не то курили, коллега.
> 
> Во-первых, там в принципе нет никакого автомата типа "полное письмо -
> в основной ящик, заголовок - на SMS". Есть форвард, в котором лучшее,
> что можно сделать - это сделать отдельный ~/.forward+P2 для адреса
> вида user+P2, и передать это в procmail.
> Не делается даже укладки этого суффикса в окружение, в отличие,
> например, от exim.
> То есть "схема" требует полного заката солнца вручную в виде форварда
> на свой код.
> (Напоминаю, что расщепление адресатов возможно только при алиасе или
> форварде. Лукап по virtusertable на это неспособен.)

Ничего не понял. У меня всё работает, virtusertable вполне способен
на штуки типа:

++@domain.ru   %1...@domain.ru.sms

В результате чего письмо автомагически попадает на стандартный вход нашему 
скрипту,
которому только и остаётся, что взять из него subject и послать куда надо,
а оригинал в неизменном виде выплюнуть на стандартный вход
команде /usr/sbin/sendmail -oem -i, выкусив plussed из адреса назначения,
для разворачивания адреса дальше по userdb/aliases при необходимости
и дальнейшей доставки. Вполне в духе postfix, разве не так? :-)

Детально описано тут: http://dadv.livejournal.com/175951.html

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

Нормальный документ, написан на нормальном английском.

Re: [freebsd] sendmail + roundcube

[Eugene Grosbein]

On 17.10.2015 00:51, Valentin Nechayev wrote:
> hi,
> 
>  Fri, Oct 16, 2015 at 20:58:47, eugen wrote about "Re: [freebsd] sendmail + 
> roundcube": 
> 
>> Зависит от определения стандартной конфигурации.
>> С дефолтным конфигом и под атакой - да, есть проблемы,
> 
> И в пятый раз повторю, что это не под атакой, а в нормальных условиях,
> но неравномерном потоке.
> Когда лёгкий зашкал за верхнюю границу выдерживаемого приводит к
> сверхлинейному торможению, в то время как любая нормально
> спроектированная система должна иметь линейную или сублинейную
> характеристику затрат ресурсов в зависимости от объёма обрабатываемых
> сущностей.

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

Я именно на Pentium-120 обслуживал нагруженный релей во время оно
и многотысячные очереди разгребать приходилось, да. Они возникали
только при флуде, а пока флуда нет - очередь жила нормальной жизнью
и всё доставлялось во время даже без тонких настроек.

Re: [freebsd] sendmail + roundcube

[Eugene Grosbein]

On 17.10.2015 01:20, Valentin Nechayev wrote:

>>> И в пятый раз повторю, что это не под атакой, а в нормальных условиях,
>>> но неравномерном потоке.
>>> Когда лёгкий зашкал за верхнюю границу выдерживаемого приводит к
>>> сверхлинейному торможению, в то время как любая нормально
>>> спроектированная система должна иметь линейную или сублинейную
>>> характеристику затрат ресурсов в зависимости от объёма обрабатываемых
>>> сущностей.
>>
>> При "легкой" нагрузке проблем нет, проблемы появляются только когда
>> нагрузка существенно превышает уровень, который можно назвать "легким".
> 
> Никакой "лёгкой нагрузки" НЕ СУЩЕСТВУЕТ. Это слова, которые
> использовать НЕЛЬЗЯ.

Можно, надо только четко осознавать, что понимается под этим выражением
(как и в математике МОЖНО говорить "очевидно, что..." - это значит "легко 
доказать").

> На любую "лёгкую нагрузку" найдётся недостаток ресурсов.

Разумеется.

> Система или устойчива, не позволяя себя завести в тупик, или
> неустойчива.

На любую систему найдется недостаток ресурсов, который заведет
её в тупик. Ой, знакомые слова :-)

Re: [freebsd] sendmail + roundcube

[Oleksandr V. Typlyns'kyi]

Yesterday Oct 16, 2015 at 09:13 Valentin Nechayev wrote:

> Ещё хороший альтернативный подход показывает zmailer (кто-то ещё
> помнит такое? Один киевский провайдер применял его лет 15 аж до своего
> поглощения).

  Если это тот провайдер о котором я подумал, то справедливости ради стоит 
  отметить, что zmailer был там для разгребания очередей пересылки.
  А для приёма и фильтрации стояла группа exim, которым от большой очереди 
  не шибко хорошо становиться.
-- 
WNGS-RIPE

Re: [freebsd] sendmail + roundcube

[Slawa Olhovchenkov]

On Fri, Oct 16, 2015 at 09:20:40PM +0300, Valentin Nechayev wrote:

>  Sat, Oct 17, 2015 at 01:05:23, eugen wrote about "Re: [freebsd] sendmail + 
> roundcube": 
> 
> > > И в пятый раз повторю, что это не под атакой, а в нормальных условиях,
> > > но неравномерном потоке.
> > > Когда лёгкий зашкал за верхнюю границу выдерживаемого приводит к
> > > сверхлинейному торможению, в то время как любая нормально
> > > спроектированная система должна иметь линейную или сублинейную
> > > характеристику затрат ресурсов в зависимости от объёма обрабатываемых
> > > сущностей.
> > 
> > При "легкой" нагрузке проблем нет, проблемы появляются только когда
> > нагрузка существенно превышает уровень, который можно назвать "легким".
> 
> Никакой "лёгкой нагрузки" НЕ СУЩЕСТВУЕТ. Это слова, которые
> использовать НЕЛЬЗЯ. На любую "лёгкую нагрузку" найдётся недостаток
> ресурсов.
> Система или устойчива, не позволяя себя завести в тупик, или
> неустойчива. Всё остальное - трёп в пользу бедных.

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

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

 Thu, Oct 15, 2015 at 23:31:21, oleg wrote about "Re: [freebsd] sendmail + 
roundcube": 

> > После освоения и многолетней работы с Exim, возвращаться к sendmail нет
> > никакого желания,   кроме  самых простых случаев. Ибо с Exim все, чуть
> > более, чем простые вещи, делаются намного удобней и гибче, прямо из
> > коробки.
> 
>  Надеюсь Exim из коробки может переписать envelope from на основании значений 
> переменных окружения. Будете хостить веб сервисы для 2+ виртуальных доменов - 
> появится задача.

Пафос я оценил. return_path в транспорте пробовал?

> > Например,
> > мой ответ автору вопроса вернулся в виде отлупа из-за юзания им сервиса
> > senderbase.org и отлупа  почты   по  этому  одному  критерию.  Хотя мой
> > релей по всем нормальным критериям - чистый. Так же само идёт  отлуп при
> > попытке написания на postmaster. Думаю - Вы меня поняли...
> 
>  Рекомендую задуматься о причинах отлупа - там приведена вся необходимая 
> информация для администратора почты. Если эта информация недостаточна для 
> понимания проблемы - причина не в этой информации.
>  И еще -  раз уж Вы решили вынести это вынести на публичное обсуждение без 
> моего согласия - дальнейшая дискуссия на эту тему будет негативно  
> свидетельствовать о Вас.

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


-netch-

Re: [freebsd] sendmail + roundcube

[Eugene Grosbein]

On 16.10.2015 13:13, Valentin Nechayev wrote:
>  Fri, Oct 16, 2015 at 02:35:11, eugen wrote about "Re: [freebsd] sendmail + 
> roundcube": 
> 
 Можно подумать, sendmail негибок в конфигурировании или много жрет :-)
>>> sendmail очень неудобен и сложен в настройке, особенно если требуется 
>>> гибкость, 
>> Неправда. Так может говорить только тот, кто не читал документацию
>> на используемый софт, но с exim или postfix ситуация такая же:
>> неудобно тому, кто доку не читает,
> 
> Евгений, я надеюсь, мой авторитет по sendmail (на основании K+1 года
> его использования в продакшене и десятков патчей на разные темы) ты
> опровергать не будешь?

Почему нет? Отсылка к авторитету - плохой аргумент.

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

> Так вот - я категорически подтверждаю слова
> cirtin@: sendmail неудобен и сложен - по крайней мере для всего, что
> выходит за рамки простой стратегии "накидать опций по ману в
> ${hostname}.mc и вызвать make",

"накидать опций по руководству и вызвать make" полностью покрывает
как задачу из топика, так и абсолютное большинство остальных почтовых задач,
о highload речь не идёт, дешевые VPS не используют под highload.

> По пунктам:
> 
> 1. Основным средством конфигурации является "язык переписывания" на
> основе идей REFAL. Это само по себе не было бы настолько тяжёлой
> проблемой, если бы этот язык не пытались впихнуть вообще всюду,
> включая места, где такое не нужно или неудобно.
> В частности, тот же язык используется после уже давно состоявшейся
> канонизации форм адресов для проверки релеинга. Я понимаю, что авторам
> было лениво вводить ещё сущностей, и они тупо отдали тему на откуп
> сообществу - мол, напишите нам реализацию, а мы её включим.

Даже знать от существовании REFAL или о его названии не требуется
для решения типовых задач вроде топика. Есть .mc и опции в нём,
в крайнем случае - готовые, хотя и не входящие в дистрибутив сторонние
дополнения к конфигам и в исключительных случаях LOCAL_CONFIG
опять же с готовыми строчками из руководства, изучения REFAL не требующие.

> 2. Но даже для работы с адресами этот код, за редкими исключениями,
> не нужен. Да, есть всякие чрезмерно грамматичные адреса RFC822 (луч
> пламенного привета IETF), но практически формата localpart@domain
> хватает для 99.% случаев. На переходники с uucp/etc. можно
> поставить и специальную обработку. При старте Exim, Philip Hazel
> намеренно отрёкся от этого всего, и был прав - "в интернете" такое не
> нужно.
> 
> Ещё хороший альтернативный подход показывает zmailer (кто-то ещё
> помнит такое? Один киевский провайдер применял его лет 15 аж до своего
> поглощения).

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

> 3. Код чудовищно архаичен и не подвергался редизайну верхнего уровня
> и/или рефакторингу как минимум последние 30 лет. Для софта это просто
> безумный срок.
> Кто будет возражать - прошу вначале прочитать и понять логику таких
> замечательных функций, как getrequests(), sendall(), dropenvelope(),
> описать её словами. Продолжить содержимым файла queue.c, разобрать
> тёмные моменты логики.
> При изучении конкурентов не потребуется делать аналогичный выворот
> мозга.

Администратору для решения типовых задач не нужно копаться в исходном коде.
 
> 4. Код в текущем состоянии фатально непригоден для автоматизированного
> тестирования.

Кому из администраторов почтовых систем на VPS требуется автоматизированное
тестирование кода MTA? Или даже шире, кому вообще из администраторов почтовых
систем требуется автоматизированное тестирование кода MTA?
Это задача для совсем другого уровния контор.

> 5. Настройка по умолчанию несопровождаема кроме установки вида
> "получать daily run output в локальный ящик".

Неправда, вполне сопровождаемся и при использовании LMTP.

> Начать с дефолта
> LogLevel=9, который не пишет завершения заданий (и от этого нельзя
> вести анализ доставки по логу).

Тому, кому требуется больше чем stat=Sent, не следует спотыкаться о дефолты.

> Далее, логика управления нагрузкой по
> RefuseLA и QueueLA придумана для каких-то других систем, но не
> современных юниксов (возможно, она для старого SunOS?) В наших
> условиях (в первую очередь FreeBSD) она выливалась в самозаклин под
> большой очередью, когда собственно чтение очереди уже даёт нагрузку
> заметно выше уровня QueueLA. Там, где большие потоки, приходилось
> ставить два демона - принимающий без ограничения по форкам, но с
> QueueLA=1, и разгребающий с QueueLA=дофига, но жёстким ограничением по
> количеству потомков и ненулевым MaxQueueAge - и только в таком виде
> удавалось получить устойчивую конфигурацию. Об этом я писал где только
> можно и жаловался авторам, но ответа не было - в лучшем случае "вы же
> придумали, как это правильно делать, вот и радуйтесь себе в тряпочку".
> 
> Это только малая часть того, что 

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

hi,

 Fri, Oct 16, 2015 at 13:50:34, eugen wrote about "Re: [freebsd] sendmail + 
roundcube": 

> >> Неправда. Так может говорить только тот, кто не читал документацию
> >> на используемый софт, но с exim или postfix ситуация такая же:
> >> неудобно тому, кто доку не читает,
> > 
> > Евгений, я надеюсь, мой авторитет по sendmail (на основании K+1 года
> > его использования в продакшене и десятков патчей на разные темы) ты
> > опровергать не будешь?
> 
> Почему нет? Отсылка к авторитету - плохой аргумент.

Это аргумент к тому, что я и читал документацию (включая то, что в ней
сказано сквозь слова;)), и что на практике набил множество шишек с
ним. И этого достаточно для опровержения твоего "так может говорить
только тот, кто не читал документацию". Я её читал, я использовал его
на практике, и я говорю, что sendmail сложен и неудобен.

> "накидать опций по руководству и вызвать make" полностью покрывает
> как задачу из топика, так и абсолютное большинство остальных почтовых задач,
> о highload речь не идёт, дешевые VPS не используют под highload.

Последний аргумент некорректен как минимум по двум причинам:
1. Мы не знаем уровень нагрузки на реальный хост от соседей. Она на
типичном дешёвом хостинге может быть непредсказуемой и временами очень
высокой.
2. Проявление лавинного эффекта самозаклина очереди зависит не от
нагрузки как таковой, а от её отношения к доступным ресурсам.
VPS может обладать крайне низкими ресурсами, особенно "дешёвый" VPS,
вполне может оказаться, что тарифному плану соответствует что-то
уровня P150 в среднем и P2/300 в относительно свободные часы,
а то и ещё что-то послабее (но этого достаточно, чтобы отображать
страничку типа "я, моя собака и мой прайс", генерируемую модной CMS на
PHP). В этом случае достаточно пары сотен писем, чтобы вызвать такой
заклин; а его самоподдерживаемость лишает простого пользователя, не
знакомого с этими хитростями, возможности решить это собственными
силами без потери данных.
Качественная реализация может быть тормозной, но она не имеет права
быть неуправляемой и допускать лавинные нарастания нагрузки по
внутренним причинам.
 
"Абсолютное большинство остальных почтовых задач" сейчас скорее
решаются методами, которые в принципе не предусматривают собственного
почтового домена и MTA, который его держит.

> Кому из администраторов почтовых систем на VPS требуется автоматизированное
> тестирование кода MTA? Или даже шире, кому вообще из администраторов почтовых
> систем требуется автоматизированное тестирование кода MTA?
> Это задача для совсем другого уровния контор.

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

> Даже знать от существовании REFAL или о его названии не требуется
> для решения типовых задач вроде топика.

С кем ты сейчас разговаривал? Я не говорил, что надо про него знать.
Ты начинаешь избивать воображаемого противника.

> Это всё о highload, который совершенно отдельная тема.

С каких это пор уровень потока в 10K писем в сутки стал highload?
(это примерно то, на чём нам начали проявляться подобные эффекты)


-netch-

Re: [freebsd] sendmail + roundcube

[Eugene Grosbein]

On 16.10.2015 14:11, Valentin Nechayev wrote:

 Неправда. Так может говорить только тот, кто не читал документацию
 на используемый софт, но с exim или postfix ситуация такая же:
 неудобно тому, кто доку не читает,
>>>
>>> Евгений, я надеюсь, мой авторитет по sendmail (на основании K+1 года
>>> его использования в продакшене и десятков патчей на разные темы) ты
>>> опровергать не будешь?
>>
>> Почему нет? Отсылка к авторитету - плохой аргумент.
> 
> Это аргумент к тому, что я и читал документацию (включая то, что в ней
> сказано сквозь слова;)), и что на практике набил множество шишек с
> ним. И этого достаточно для опровержения твоего "так может говорить
> только тот, кто не читал документацию". Я её читал, я использовал его
> на практике, и я говорю, что sendmail сложен и неудобен.

Сложен и неудобен для каких задач? Для большинства задач он не сложен
и не неудобен.

>> "накидать опций по руководству и вызвать make" полностью покрывает
>> как задачу из топика, так и абсолютное большинство остальных почтовых задач,
>> о highload речь не идёт, дешевые VPS не используют под highload.
> 
> Последний аргумент некорректен как минимум по двум причинам:
> 1. Мы не знаем уровень нагрузки на реальный хост от соседей. Она на
> типичном дешёвом хостинге может быть непредсказуемой и временами очень
> высокой.
> 2. Проявление лавинного эффекта самозаклина очереди зависит не от
> нагрузки как таковой, а от её отношения к доступным ресурсам.
> VPS может обладать крайне низкими ресурсами, особенно "дешёвый" VPS,
> вполне может оказаться, что тарифному плану соответствует что-то
> уровня P150 в среднем и P2/300 в относительно свободные часы,
> а то и ещё что-то послабее (но этого достаточно, чтобы отображать
> страничку типа "я, моя собака и мой прайс", генерируемую модной CMS на
> PHP). В этом случае достаточно пары сотен писем, чтобы вызвать такой
> заклин; а его самоподдерживаемость лишает простого пользователя, не
> знакомого с этими хитростями, возможности решить это собственными
> силами без потери данных.
> Качественная реализация может быть тормозной, но она не имеет права
> быть неуправляемой и допускать лавинные нарастания нагрузки по
> внутренним причинам.

Лавинный эффект следствие использования дефолтов, да.
Решается чтением документации и использованием соответствующих
стандартных настроек, код читать не требуется.

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

И это тоже, но мы говорим о тех из них, которым нужен свой домен и MTA.

>> Кому из администраторов почтовых систем на VPS требуется автоматизированное
>> тестирование кода MTA? Или даже шире, кому вообще из администраторов почтовых
>> систем требуется автоматизированное тестирование кода MTA?
>> Это задача для совсем другого уровния контор.
> 
> Ты передёргиваешь подменой тезиса, или просто не пожелав понять, к
> чему я выкладываю эти аргументы, или намеренно выцепив самое
> противоречащее твоему представлению. Это плохой метод дискуссии.
> Я говорю, что совокупность указанных факторов подсказывает, что
> sendmail поддерживается намеренно сложным в использовании, для всех
> уровней участников, и что я считаю, что это явная откровенная политика
> авторов - метод монетизации своей работы.

Я в первый раз молча проигнорировал этот аргумент потому,
что это лишь "оценочное суждение". Мотивы авторов sendmail
несущественны, а по моему суждению, ничего подобного нет.
На самом деле, sendmail использовать очень несложно.

>> Даже знать от существовании REFAL или о его названии не требуется
>> для решения типовых задач вроде топика.
> С кем ты сейчас разговаривал? Я не говорил, что надо про него знать.
> Ты начинаешь избивать воображаемого противника.

Ok, аргументы касательно REFAL вычеркиваем.

>> Это всё о highload, который совершенно отдельная тема.
> 
> С каких это пор уровень потока в 10K писем в сутки стал highload?
> (это примерно то, на чём нам начали проявляться подобные эффекты)

На 10K в сутки указанные эффекты могут проявляться на Pentium-120,
если в конфигурации sendmail даже confHOST_STATUS_DIRECTORY не включена.
А если включена и вообще sendmail работает не с тупыми дефолтами,
а с опциями, настроенными под задачу - на Pentium-120 он справляется, проверено.

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

 Fri, Oct 16, 2015 at 02:35:11, eugen wrote about "Re: [freebsd] sendmail + 
roundcube": 

> >> Можно подумать, sendmail негибок в конфигурировании или много жрет :-)
> > sendmail очень неудобен и сложен в настройке, особенно если требуется 
> > гибкость, 
> Неправда. Так может говорить только тот, кто не читал документацию
> на используемый софт, но с exim или postfix ситуация такая же:
> неудобно тому, кто доку не читает,

Евгений, я надеюсь, мой авторитет по sendmail (на основании K+1 года
его использования в продакшене и десятков патчей на разные темы) ты
опровергать не будешь? Так вот - я категорически подтверждаю слова
cirtin@: sendmail неудобен и сложен - по крайней мере для всего, что
выходит за рамки простой стратегии "накидать опций по ману в
${hostname}.mc и вызвать make", и эта сложность далеко выходит за
пределы того, что определяется "естественными" факторами сложности
тематики. По пунктам:

1. Основным средством конфигурации является "язык переписывания" на
основе идей REFAL. Это само по себе не было бы настолько тяжёлой
проблемой, если бы этот язык не пытались впихнуть вообще всюду,
включая места, где такое не нужно или неудобно.
В частности, тот же язык используется после уже давно состоявшейся
канонизации форм адресов для проверки релеинга. Я понимаю, что авторам
было лениво вводить ещё сущностей, и они тупо отдали тему на откуп
сообществу - мол, напишите нам реализацию, а мы её включим.

2. Но даже для работы с адресами этот код, за редкими исключениями,
не нужен. Да, есть всякие чрезмерно грамматичные адреса RFC822 (луч
пламенного привета IETF), но практически формата localpart@domain
хватает для 99.% случаев. На переходники с uucp/etc. можно
поставить и специальную обработку. При старте Exim, Philip Hazel
намеренно отрёкся от этого всего, и был прав - "в интернете" такое не
нужно.

Ещё хороший альтернативный подход показывает zmailer (кто-то ещё
помнит такое? Один киевский провайдер применял его лет 15 аж до своего
поглощения).

3. Код чудовищно архаичен и не подвергался редизайну верхнего уровня
и/или рефакторингу как минимум последние 30 лет. Для софта это просто
безумный срок.
Кто будет возражать - прошу вначале прочитать и понять логику таких
замечательных функций, как getrequests(), sendall(), dropenvelope(),
описать её словами. Продолжить содержимым файла queue.c, разобрать
тёмные моменты логики.
При изучении конкурентов не потребуется делать аналогичный выворот
мозга.

4. Код в текущем состоянии фатально непригоден для автоматизированного
тестирования. Я понимаю, что многие апологеты и классические авторы
open source, воспитанные в лучшем случае на идеях середины 60-х годов
и, может, немного слышавшие про ценность структурного
программирования, никогда про него не слышали или не понимают
ценности, и что это требует усилий больше, чем "just for fun"; но
почему-то:) у конкурентов это обеспечено лучше.
Присутствующие тесты покрывают только часть вспомогательных библиотек
и то в лучшем случае 1/10 от нужного.
Для сравнения, postfix написан предельно модульно (хоть и некоторые
идеи Венемы требуют бутылки водки для вкуривания в них) и при этом всё
равно в разы легче sendmail. Exim в основе цельно написанный, но он
всё равно проще в подходах.

5. Настройка по умолчанию несопровождаема кроме установки вида
"получать daily run output в локальный ящик". Начать с дефолта
LogLevel=9, который не пишет завершения заданий (и от этого нельзя
вести анализ доставки по логу). Далее, логика управления нагрузкой по
RefuseLA и QueueLA придумана для каких-то других систем, но не
современных юниксов (возможно, она для старого SunOS?) В наших
условиях (в первую очередь FreeBSD) она выливалась в самозаклин под
большой очередью, когда собственно чтение очереди уже даёт нагрузку
заметно выше уровня QueueLA. Там, где большие потоки, приходилось
ставить два демона - принимающий без ограничения по форкам, но с
QueueLA=1, и разгребающий с QueueLA=дофига, но жёстким ограничением по
количеству потомков и ненулевым MaxQueueAge - и только в таком виде
удавалось получить устойчивую конфигурацию. Об этом я писал где только
можно и жаловался авторам, но ответа не было - в лучшем случае "вы же
придумали, как это правильно делать, вот и радуйтесь себе в тряпочку".

Это только малая часть того, что стоит ругать - но не хочу сейчас
тратить много времени.

Причины этого всего мне видятся в следующем факторе: sendmail, по
сути, продукт коммерческий, и был таким изначально, а то, что мы
получаем в доступном виде это урезанная версия "для ширнармасс". Любая
непонятка, с точки зрения авторов, должна вылиться в приход к ним в
гости с пачкой денег на тему "сделайте мне хорошо", и тогда они
вытащат все свои наработки от правильного стартового сетапа до всех
форм секретных патчей типа "100500 параметров статистики в mysql".
В связи с этим вспоминается следующее эссе на тему целевых ниш софта и
зависящих от этого решений по дизайну:

http://web.archive.org/web/20120403172742/http://vydrov.com/index.php/archives/38

Re: [freebsd] sendmail + roundcube

[Eugene Grosbein]

On 16.10.2015 02:46, Alexander Sheiko wrote:

> EG> Можно подумать, sendmail негибок в конфигурировании или много жрет :-)
> EG> Можно подумать, со временем sendmail растерял всю свою функциональность
> EG> и теперь годится только для простых вещей. Ничего подобного.
> 
> Евгений - на нём можно настроить всё, особенно - тому, кто с ним работал 
> давно и 
> много.  Но  - для вещей чуть более сложных, чем простые рассылки, намного 
> удобнее 
> использовать   Exim.  Пишу как человек, долго юзавший sendmail и 
> использовавший 
> множество хаков к нему от Виктора Устугова...

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

Re: [freebsd] sendmail + roundcube

[George L. Yermulnik]

Hello!

On Fri, 16 Oct 2015 at 00:11:03 (+0300), Slawa Olhovchenkov wrote:

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

> msg-id обычно проставляется первым же MTA по дороге.
> если я три раз жамкну кнопку "послать" или что там еще в MUA с одним и
> тем же текстом (ну ок, to/from поменяю, или это MUA сделает с
> запозданим по своим каким-то правилам) -- как это еще называть, если
> не дупликатами?

Лично я называл бы тремя разными письмами. Вероятно, это и вызвало наше
недопонимание друг друга =)

-- 
George L. Yermulnik
[YZ-RIPE]

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

hi,

 Fri, Oct 16, 2015 at 14:34:29, eugen wrote about "Re: [freebsd] sendmail + 
roundcube": 

> > Это аргумент к тому, что я и читал документацию (включая то, что в ней
> > сказано сквозь слова;)), и что на практике набил множество шишек с
> > ним. И этого достаточно для опровержения твоего "так может говорить
> > только тот, кто не читал документацию". Я её читал, я использовал его
> > на практике, и я говорю, что sendmail сложен и неудобен.
> 
> Сложен и неудобен для каких задач? Для большинства задач он не сложен
> и не неудобен.

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

> Лавинный эффект следствие использования дефолтов, да.
> Решается чтением документации и использованием соответствующих
> стандартных настроек, код читать не требуется.

Нет. Решается 1) попаданием в халепу (как правило, неожиданно и
невовремя), 2) гуглением проблемы и 3) исправлением по уже готовым
рецептам от того, кто таки читал сырцы (как я). Просто так, чтобы
читая документацию, найти и осознать проблему, требуется особый крайне
редкий стиль мышления, владельцы которого обычно становятся QA
seniors, а не админами.

> Ok, аргументы касательно REFAL вычеркиваем.

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

> > С каких это пор уровень потока в 10K писем в сутки стал highload?
> > (это примерно то, на чём нам начали проявляться подобные эффекты)
> 
> На 10K в сутки указанные эффекты могут проявляться на Pentium-120,
> если в конфигурации sendmail даже confHOST_STATUS_DIRECTORY не включена.
> А если включена и вообще sendmail работает не с тупыми дефолтами,
> а с опциями, настроенными под задачу - на Pentium-120 он справляется, 
> проверено.

Ну да, после того, как разнести демоны приёма и раздачи из очереди -
он может работать практически независимо от производительности машины
(до тех пор, пока не начинаются эффекты вроде таймаутов TCP коннекта).
Но до этого он способен убить практически любую конфигурацию (ну
ладно, Xeon + дофига RAM + SSD + etc. выживут, скорее всего, в любом
реальном случае, или заткнутся на чём-то другом).

Это как с пресловутым 12309 - автор реформ, которые его изначально
породили, работал на машине с 2GB RAM, когда средняя машина вокруг
имела 16-64MB, и на все жалобы отвечал "It works for me".


-netch-

Re: [freebsd] sendmail + roundcube

[Slawa Olhovchenkov]

On Fri, Oct 16, 2015 at 09:13:14AM +0300, Valentin Nechayev wrote:

>  Fri, Oct 16, 2015 at 02:35:11, eugen wrote about "Re: [freebsd] sendmail + 
> roundcube": 
> 
> > >> Можно подумать, sendmail негибок в конфигурировании или много жрет :-)
> > > sendmail очень неудобен и сложен в настройке, особенно если требуется 
> > > гибкость, 
> > Неправда. Так может говорить только тот, кто не читал документацию
> > на используемый софт, но с exim или postfix ситуация такая же:
> > неудобно тому, кто доку не читает,
> 
> Евгений, я надеюсь, мой авторитет по sendmail (на основании K+1 года
> его использования в продакшене и десятков патчей на разные темы) ты
> опровергать не будешь? Так вот - я категорически подтверждаю слова
> cirtin@: sendmail неудобен и сложен - по крайней мере для всего, что
> выходит за рамки простой стратегии "накидать опций по ману в
> ${hostname}.mc и вызвать make", и эта сложность далеко выходит за
> пределы того, что определяется "естественными" факторами сложности
> тематики. По пунктам:

Раз пошла такая пьянка -- режь последний огурец.
Я как бы тоже sendmail использую года так с 1995 во всеяких сложных
конфигурациях, postfix -- примерно с 2003, ну и еще и exim несколько
меньше. Так что тоже выскажусь.

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

sendmail в vps я не использовал, но на железе уровня 2005 года спамер,
сперший пароль, наплодит 30 тыщ писем в очереди, но проблемой будет не
тормоза системы, а попадание в спамлисты.

да, в sendmail REFAL. но в остальных нет ничего. т.е. можно только
выбрать набор каких-то фиксированых проверок и их порядок. если надо
что-то нестандартное -- патчи сырцы!

сейчас найти рецепты для sendmail кажется несколько сложнее.

postfix/exim в последнее время по фичам несколько подтянулись
(научились наконец DSN без патчей!), но у всех трех с SRS не очень
хорошо.

в плюсы postfix/exim можно записать sender email verify из коробки --
к sendmail нужно через milter крутить.

в минусы же postfix -- логи хуже sendmailовских. ну и вообще, общую
переусложненность postfix:

postfix  48387 51021 51021 510210 I -   0:00.02 pickup -l -t fifo -u
root 51021 1 51021 510210 Ss-   0:18.19 
/usr/local/libexec/postfix/master -w
postfix  51023 51021 51021 510210 I -   0:14.45 qmgr -l -t fifo -u
postfix  51218 51021 51021 510210 S -   0:00.02 smtpd -n smtp -t 
inet -u -o stress=
postfix  51219 51021 51021 510210 S -   0:00.01 anvil -l -t unix -u
postfix  52607 51021 51021 510210 S -   0:00.01 trivial-rewrite -n 
rewrite -t unix -u
postfix  52677 51021 51021 510210 I -   0:00.01 cleanup -z -t unix 
-u
postfix  52680 51021 51021 510210 I -   0:00.01 smtp -t unix -u
postfix  52682 51021 51021 510210 I -   0:00.01 smtp -t unix -u
postfix  52684 51021 51021 510210 I -   0:00.01 pipe -n dovecot -t 
unix flags=DRhu user=mailnull:mailnull argv=/usr/local/libexec/dovecot/deliver 
-d ${recipient}
postfix  52709 51021 51021 510210 S -   0:00.02 smtpd -n smtp -t 
inet -u -o stress=
postfix  52793 51021 51021 510210 I -   0:00.01 smtp -t unix -u
postfix  52795 51021 51021 510210 I -   0:00.01 smtp -t unix -u

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

да, я в курсе, что postfix писался для того что бы управлять рассылками на 
пень-100.
только те, кому такое (смасштабированное) нужно сейчас -- об этом спрашивать не 
будут.

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

в общем, несмотря на то, что весь интернет полон шпаргалками на тему
"postfix+dovecot+mysql+вебморда" -- я его настоятельно не советую.

и да, SQLite не советую тоже, как я понял у него очень плохо с совместным 
доступом.
тут надо выбирать
 - или berkley DB
 - или нормальный SQL
 - или спрашивать про пользователей у IMAP

> 3. Код чудовищно архаичен и не подвергался редизайну верхнего уровня
> и/или рефакторингу как минимум последние 30 лет. Для софта это просто
> безумный срок.
> Кто будет возражать - прошу вначале прочитать и понять логику таких
> замечательных функций, как getrequests(), sendall(), dropenvelope(),
> описать её словами. Продолжить содержимым файла queue.c, разобрать
> тёмные моменты логики.

я разбирался, ничего, 

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

hi,

 Fri, Oct 16, 2015 at 13:13:43, slw wrote about "Re: [freebsd] sendmail + 
roundcube": 

> Раз пошла такая пьянка -- режь последний огурец.
[...]

> да, в sendmail REFAL. но в остальных нет ничего. т.е. можно только
> выбрать набор каких-то фиксированых проверок и их порядок. если надо
> что-то нестандартное -- патчи сырцы!

В postfix фиксированный набор. В exim значительно гибче набор и штатно
говорят "вам недостаточно => perl в зубы и вперёд". Через него
действительно можно сделать что угодно.

Перед уходом из LN я сделал тестовую установку на exim, которая
работала через перловый хук с таблицами, рассчитанными на sendmail.
Скорость установки была ровно такая же до погрешности измерения, как и
у прямой реализации на sendmail, несмотря на то, что выгибание под
формат чужих таблиц привело к куче тяжёлого перлового кода.
Я не успел сделать нормальный переход к более подходящему виду, но
тесты показывали, что было бы 2-3-кратное ускорение при той же
результирующей функциональности. Рядом в ukr.net Шарун строил реальный
хайлоад (раз уж Гросбейн любит это слово;)) на мощности порядка сотен
писем в секунду среднего потока и подскоками до десятков тысяч, там он
глубоко оптимизировал затраты, но мог выгнуться под практически любую
задачу. Так что с "патчи сырцы" я тут никак не соглашусь.

> сейчас найти рецепты для sendmail кажется несколько сложнее.

Неудивительно - чуть менее чем все, кто тогда ещё мог писать на этом
чудо-языке, сказали "дапашливы" и перешли к более интеллектуальным
занятиям;))

Ещё сурово помог спам - когда купить какой-нибудь Ironport таки
дешевле, чем самому держать штат дорогих админов на управлении
фильтрами.

> да, я в курсе, что postfix писался для того что бы управлять рассылками на 
> пень-100.
> только те, кому такое (смасштабированное) нужно сейчас -- об этом спрашивать 
> не будут.

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

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

Это отдельный флейм :)

> > Кто будет возражать - прошу вначале прочитать и понять логику таких
> > замечательных функций, как getrequests(), sendall(), dropenvelope(),
> > описать её словами. Продолжить содержимым файла queue.c, разобрать
> > тёмные моменты логики.
> 
> я разбирался, ничего, жив остался.

Ты такой же мамонт, как и я :) рекомендовать такое широкому кругу я не
могу. Жалко птичек.

> > 5. Настройка по умолчанию несопровождаема кроме установки вида
> > "получать daily run output в локальный ящик". Начать с дефолта
> > LogLevel=9, который не пишет завершения заданий (и от этого нельзя
> > вести анализ доставки по логу).
> 
> Шо?
> 
> Oct 16 13:50:35 inter sm-mta[96000]: t9G9oP4x095819: to=leader-...@yandex.ru, 
> delay=00:00:04, xdelay=00:00:01, mailer=esmtp, pri=203421, 
> relay=mx.yandex.ru. [213.180.204.89], dsn=2.0.0, stat=Sent (Ok: queued on 
> mxfront3j.mail.yandex.net as 1444989035-eeXLwLnCXA-oYK8vqd7)
> 
> лог -- по дефолту.

Я про сообщения вида

Oct 16 13:30:32 segfault sm-mta[53431]: tAGAUVgE053430: done; delay=00:00:01, 
ntries=1

они появляются только с 11-го уровня, хотя для понимания происходящего
они важнее раскрытия алиасов (10-й уровень).

> В общем, моя кочка зрения:
> 
> postfix -- нафиг
> в простых случая и exim и sendmail справятся
> если думать лень и хочется готовых рецептов и менять *точно* ничего никогда 
> не будет (как и усложнять) -- наверное exim проще
> если светит в перспективе усложнение (вообще-то оно почти всегда светит) -- 
> лучше потратить время на sendmail.

Лучше таки exim :) или вообще что-то за пределами этой тройки.

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

По нынешним временам лучше бы lua или elisp привинтили.
Хотя я когда-то perl map к нему строил (патч тривиальный, можно
актуализировать).


-netch-

Re: [freebsd] sendmail + roundcube

[Eugene Grosbein]

On 16.10.2015 17:21, Valentin Nechayev wrote:

>>> Это аргумент к тому, что я и читал документацию (включая то, что в ней
>>> сказано сквозь слова;)), и что на практике набил множество шишек с
>>> ним. И этого достаточно для опровержения твоего "так может говорить
>>> только тот, кто не читал документацию". Я её читал, я использовал его
>>> на практике, и я говорю, что sendmail сложен и неудобен.
>>
>> Сложен и неудобен для каких задач? Для большинства задач он не сложен
>> и не неудобен.
> 
> Для всего, что выходит за пределы того, что вкладывается в стандартные
> конфигурации и опции, и при необходимости хоть какой-то надёжности
> против проблем, что я описал.

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

>> Лавинный эффект следствие использования дефолтов, да.
>> Решается чтением документации и использованием соответствующих
>> стандартных настроек, код читать не требуется.
> 
> Нет. Решается 1) попаданием в халепу (как правило, неожиданно и
> невовремя), 2) гуглением проблемы и 3) исправлением по уже готовым
> рецептам от того, кто таки читал сырцы (как я). Просто так, чтобы
> читая документацию, найти и осознать проблему, требуется особый крайне
> редкий стиль мышления, владельцы которого обычно становятся QA
> seniors, а не админами.

Это с любым софтом так. И слово "нет" тут лишнее, так как руководства
есть и сорцы читать таки не требуется.

Re: [freebsd] sendmail + roundcube

[Slawa Olhovchenkov]

On Fri, Oct 16, 2015 at 01:34:23PM +0300, Valentin Nechayev wrote:

> > да, в sendmail REFAL. но в остальных нет ничего. т.е. можно только
> > выбрать набор каких-то фиксированых проверок и их порядок. если надо
> > что-то нестандартное -- патчи сырцы!
> 
> В postfix фиксированный набор. В exim значительно гибче набор и штатно
> говорят "вам недостаточно => perl в зубы и вперёд". Через него
> действительно можно сделать что угодно.

а) по дефолту он без перла.
б) насколько это хорошо -- не смотрел, ничего говорить не буду

> Перед уходом из LN я сделал тестовую установку на exim, которая
> работала через перловый хук с таблицами, рассчитанными на sendmail.
> Скорость установки была ровно такая же до погрешности измерения, как и
> у прямой реализации на sendmail, несмотря на то, что выгибание под
> формат чужих таблиц привело к куче тяжёлого перлового кода.
> Я не успел сделать нормальный переход к более подходящему виду, но
> тесты показывали, что было бы 2-3-кратное ускорение при той же
> результирующей функциональности. Рядом в ukr.net Шарун строил реальный
> хайлоад (раз уж Гросбейн любит это слово;)) на мощности порядка сотен
> писем в секунду среднего потока и подскоками до десятков тысяч, там он
> глубоко оптимизировал затраты, но мог выгнуться под практически любую
> задачу. Так что с "патчи сырцы" я тут никак не соглашусь.

да-да, именно про сто писем в секунду тут и спросили.
ну а 10/с сейчас все осилят. собственно тормозить SA тут будет, если
он есть, а не почтовик.

> > сейчас найти рецепты для sendmail кажется несколько сложнее.
> 
> Неудивительно - чуть менее чем все, кто тогда ещё мог писать на этом
> чудо-языке, сказали "дапашливы" и перешли к более интеллектуальным
> занятиям;))

нет, просто поисковики стали искать говно, а не то, что просишь.

> Ещё сурово помог спам - когда купить какой-нибудь Ironport таки
> дешевле, чем самому держать штат дорогих админов на управлении
> фильтрами.
> 
> > да, я в курсе, что postfix писался для того что бы управлять рассылками на 
> > пень-100.
> > только те, кому такое (смасштабированное) нужно сейчас -- об этом 
> > спрашивать не будут.
> 
> Ну вот где-то потому у меня сейчас postfix только на раздаче рассылок,
> включая данную :)

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

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

исходно и про это спрашивали.

> > > Кто будет возражать - прошу вначале прочитать и понять логику таких
> > > замечательных функций, как getrequests(), sendall(), dropenvelope(),
> > > описать её словами. Продолжить содержимым файла queue.c, разобрать
> > > тёмные моменты логики.
> > 
> > я разбирался, ничего, жив остался.
> 
> Ты такой же мамонт, как и я :) рекомендовать такое широкому кругу я не
> могу. Жалко птичек.

c 1995 года и не требовалось.
просто документации maildb нихрена не было вот и разбирался.
а, еще для того что бы сделать копирование почты.

> > > 5. Настройка по умолчанию несопровождаема кроме установки вида
> > > "получать daily run output в локальный ящик". Начать с дефолта
> > > LogLevel=9, который не пишет завершения заданий (и от этого нельзя
> > > вести анализ доставки по логу).
> > 
> > Шо?
> > 
> > Oct 16 13:50:35 inter sm-mta[96000]: t9G9oP4x095819: 
> > to=leader-...@yandex.ru, delay=00:00:04, xdelay=00:00:01, mailer=esmtp, 
> > pri=203421, relay=mx.yandex.ru. [213.180.204.89], dsn=2.0.0, stat=Sent (Ok: 
> > queued on mxfront3j.mail.yandex.net as 1444989035-eeXLwLnCXA-oYK8vqd7)
> > 
> > лог -- по дефолту.
> 
> Я про сообщения вида
> 
> Oct 16 13:30:32 segfault sm-mta[53431]: tAGAUVgE053430: done; delay=00:00:01, 
> ntries=1
> 
> они появляются только с 11-го уровня, хотя для понимания происходящего
> они важнее раскрытия алиасов (10-й уровень).

зачем? (не испытывал нужды)

> > В общем, моя кочка зрения:
> > 
> > postfix -- нафиг
> > в простых случая и exim и sendmail справятся
> > если думать лень и хочется готовых рецептов и менять *точно* ничего никогда 
> > не будет (как и усложнять) -- наверное exim проще
> > если светит в перспективе усложнение (вообще-то оно почти всегда светит) -- 
> > лучше потратить время на sendmail.
> 
> Лучше таки exim :) или вообще что-то за пределами этой тройки.

qmail. ога.
я, кстати, еще CGP эксплуатировал -- тоже не подарок.

> > REFAL конечно требует несколько выворачивать мозг, но это, вообще-то 
> > полезно.
> 
> По нынешним временам лучше бы lua или elisp привинтили.
> Хотя я когда-то perl map к нему строил (патч тривиальный, можно
> актуализировать).

по нынешним временам в тренде хаскель.
ну или скала.
а, нода!

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

 Fri, Oct 16, 2015 at 14:53:09, adsh wrote about "Re: [freebsd] sendmail + 
roundcube": 

> Разница есть. Валентин выше аккуратно всё расписал. Но я понимаю, почему
> многие уже из немолодого поколения за sendmail держатся. Для того, чтобы с
> ним разобраться и использовать в сложных конфигурациях в своё время нужно
> было потратить множество сил и времени. И этим людям становится немного
> обидно, что всё это сейчас делается проще и гибче. По человечески это всё
> можно понять.

Где-то так. В тяжёлом случае это превращается в тот самый
"профессионализм" по Выдрову.

> Главное, чтобы продолжая сидеть на sendmail они не делали
> всякого рода детских ошибок в логике работе своих почтовых систем.
> 
> Как раз здесь и уместна цитата:
> 
> > ...Научить настороженно относиться к опыту бывалых людей, потому
> > что жизнь меняется необычайно быстро...
> 
> ...и появляются новые MTA ;-).

Важнее тут не то, что появляются новые MTA - они как раз, пока следуют
той же концепции "мы держим свои домены и общаемся по SMTP", все MTA
друг на друга похожи в основных концепциях. А вот если выйти за это
прокрустово ложе - начинается реальный мир, в котором хаоса больше,
чем порядка, потому что
1) Выдают вместо домена только один ящик - и начинаются
герценовски-тяжёлые раздумья о том, "что делать", когда надо один ящик
распихать на большую организацию - на входе, и отправлять те же daily
run outputs в мир, имея формально один обратный адрес на всё - на
выходе;
2) IMAP как хранилище с шареным доступом задавливает собой концепцию
собственно почты, и появляются те, кто за много лет ни разу не принял
и не отправил ни одного письма, но у них типа "почта";
3) Появляются общалки через новые транспорты типа ICQ и XMPP, и доля
общения через email сокращается с ~90% до жалких единиц процентов;
4) Засилье спама вынуждает всех мигрировать на что-то вроде Google
Apps, потому что иначе с фильтрацией не справляются;
5) Все уходят в социалки, и теперь надо о работе на сервере
предупреждать в ВК, потому что почты уже у сотрудников нет...

для меня лично email как что-то существенное, на работу с чем и на
развитие чего следует тратить собственные душевные силы, кончилось
где-то между этапами 3 и 4.

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

А ведь для 95% линуксово-фрибздишных тазиков вместо sendmail'ов
достаточно было бы комбинации логин+пароль+сервер для условного gmail,
чтобы отправлять кроновые отчёты на него, не заботясь о всяких
FEATURE(masquerade_envelope).


-netch-

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

 Fri, Oct 16, 2015 at 15:29:48, slw wrote about "Re: [freebsd] sendmail + 
roundcube": 

> > А ведь для 95% линуксово-фрибздишных тазиков вместо sendmail'ов
> > достаточно было бы комбинации логин+пароль+сервер для условного gmail,
> > чтобы отправлять кроновые отчёты на него, не заботясь о всяких
> > FEATURE(masquerade_envelope).
> 
> да пихали бы сразу в какое гноилище, кто их эти отчеты вообще читает?
> настроили фильтрацию в папку и никогда не смотрят.

Я читаю. Сюрприз:)
Хотя бы чтобы знать, когда дырявые пакеты апгрейдить.
А ещё там многие проблемы видны до перехода в фаталити.


-netch-

Re: [freebsd] sendmail + roundcube

[Anton Yuzhaninov]

On 10/16/15 13:13, Slawa Olhovchenkov wrote:

ну и вообще, общую
переусложненность postfix:

postfix  48387 51021 51021 510210 I -   0:00.02 pickup -l -t fifo -u
root 51021 1 51021 510210 Ss-   0:18.19 
/usr/local/libexec/postfix/master -w
postfix  51023 51021 51021 510210 I -   0:14.45 qmgr -l -t fifo -u
postfix  51218 51021 51021 510210 S -   0:00.02 smtpd -n smtp -t 
inet -u -o stress=
postfix  51219 51021 51021 510210 S -   0:00.01 anvil -l -t unix -u
postfix  52607 51021 51021 510210 S -   0:00.01 trivial-rewrite -n 
rewrite -t unix -u
postfix  52677 51021 51021 510210 I -   0:00.01 cleanup -z -t unix 
-u
postfix  52680 51021 51021 510210 I -   0:00.01 smtp -t unix -u
postfix  52682 51021 51021 510210 I -   0:00.01 smtp -t unix -u
postfix  52684 51021 51021 510210 I -   0:00.01 pipe -n dovecot -t 
unix flags=DRhu user=mailnull:mailnull argv=/usr/local/libexec/dovecot/deliver 
-d ${recipient}
postfix  52709 51021 51021 510210 S -   0:00.02 smtpd -n smtp -t 
inet -u -o stress=
postfix  52793 51021 51021 510210 I -   0:00.01 smtp -t unix -u
postfix  52795 51021 51021 510210 I -   0:00.01 smtp -t unix -u

куча каких-то демонов, как-то перадающих задание друг другу,


Это не переусложнённость, а модульная архитектура:
http://www.postfix.org/OVERVIEW.html
Разделение на разные процессы повышает надёжность и безопасность (за счёт 
privilege separation).


В Dovecot очень похожий подход:
http://wiki2.dovecot.org/Design/Processes

Если всё то же самое запихать в один процесс, сложность никуда не денется 
(просто будет меньше заметна админу).

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

hi,

 Fri, Oct 16, 2015 at 13:48:23, slw wrote about "Re: [freebsd] sendmail + 
roundcube": 

> > В postfix фиксированный набор. В exim значительно гибче набор и штатно
> > говорят "вам недостаточно => perl в зубы и вперёд". Через него
> > действительно можно сделать что угодно.
> а) по дефолту он без перла.

Только что проверил на портах 2-дневной давности - дефолт таки с
перлом.

> > Ну вот где-то потому у меня сейчас postfix только на раздаче рассылок,
> > включая данную :)
> 
> за настройку которой "фе" высказывалось уже наверное десятком
> участников, но это к постфиксу не относится, как и сама рассылка не
> является аргументом.

Если про reply-to, то я не хочу новый цикл:)
Если про свойства самого majordomo, то они, кажется, мешают только
мне.

> > > > Кто будет возражать - прошу вначале прочитать и понять логику таких
> > > > замечательных функций, как getrequests(), sendall(), dropenvelope(),
> > > > описать её словами. Продолжить содержимым файла queue.c, разобрать
> > > > тёмные моменты логики.
> > > 
> > > я разбирался, ничего, жив остался.
> > 
> > Ты такой же мамонт, как и я :) рекомендовать такое широкому кругу я не
> > могу. Жалко птичек.
> 
> c 1995 года и не требовалось.

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

> > Oct 16 13:30:32 segfault sm-mta[53431]: tAGAUVgE053430: done; 
> > delay=00:00:01, ntries=1
> > 
> > они появляются только с 11-го уровня, хотя для понимания происходящего
> > они важнее раскрытия алиасов (10-й уровень).
> 
> зачем? (не испытывал нужды)

Собственно для логгинга конца обработки письма.

> > 
> > Лучше таки exim :) или вообще что-то за пределами этой тройки.
> 
> qmail. ога.

qmail с человеческим лицом зовётся словом postfix.
Мне из qmail только системы алиасов жалко - аналога не дали.
Но реально даже плюсанутые localparts используют только нердомамонты.

> > По нынешним временам лучше бы lua или elisp привинтили.
> > Хотя я когда-то perl map к нему строил (патч тривиальный, можно
> > актуализировать).
> 
> по нынешним временам в тренде хаскель.
> ну или скала.
> а, нода!

Ну, можно и так. V8 с его тщательно вылизанным JIT местами бьёт даже C.
А недостатки JS на таких мелких кусках кода могут не успеть
проявиться.


-netch-

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

hi,

 Fri, Oct 16, 2015 at 17:53:25, eugen wrote about "Re: [freebsd] sendmail + 
roundcube": 

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

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

> > Нет. Решается 1) попаданием в халепу (как правило, неожиданно и
> > невовремя), 2) гуглением проблемы и 3) исправлением по уже готовым
> > рецептам от того, кто таки читал сырцы (как я). Просто так, чтобы
> > читая документацию, найти и осознать проблему, требуется особый крайне
> > редкий стиль мышления, владельцы которого обычно становятся QA
> > seniors, а не админами.
> 
> Это с любым софтом так.

Софт предназначен для облегчения жизни людей (юзеров и админов).
Когда широко известные грабли десятилетиями не лечатся и даже не
предупреждается о них - это не облегчение, это создание мест для
заработка.
Конечно, дарёному коню (opensource) в зубы смотрят не так пристально,
но при наличии выбора берётся всё-таки конь поздоровее :)

> И слово "нет" тут лишнее, так как руководства
> есть и сорцы читать таки не требуется.

Нет.(tm)
Там нет нужного.


-netch-

Re: [freebsd] sendmail + roundcube

[Slawa Olhovchenkov]

On Fri, Oct 16, 2015 at 03:24:36PM +0300, Valentin Nechayev wrote:

> А ведь для 95% линуксово-фрибздишных тазиков вместо sendmail'ов
> достаточно было бы комбинации логин+пароль+сервер для условного gmail,
> чтобы отправлять кроновые отчёты на него, не заботясь о всяких
> FEATURE(masquerade_envelope).

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

Re: [freebsd] sendmail + roundcube

[Slawa Olhovchenkov]

On Fri, Oct 16, 2015 at 03:37:57PM +0300, Valentin Nechayev wrote:

>  Fri, Oct 16, 2015 at 15:29:48, slw wrote about "Re: [freebsd] sendmail + 
> roundcube": 
> 
> > > А ведь для 95% линуксово-фрибздишных тазиков вместо sendmail'ов
> > > достаточно было бы комбинации логин+пароль+сервер для условного gmail,
> > > чтобы отправлять кроновые отчёты на него, не заботясь о всяких
> > > FEATURE(masquerade_envelope).
> > 
> > да пихали бы сразу в какое гноилище, кто их эти отчеты вообще читает?
> > настроили фильтрацию в папку и никогда не смотрят.
> 
> Я читаю. Сюрприз:)
> Хотя бы чтобы знать, когда дырявые пакеты апгрейдить.
> А ещё там многие проблемы видны до перехода в фаталити.

я бы предпочел что бы за меня их читал скрипт.
потому что смысла тратить свое время на чтение нижеследующего я не вижу:

Disk status:
Filesystem   SizeUsed   Avail Capacity  Mounted on
zroot/ROOT   2.1T855M2.1T 0%/
devfs1.0K1.0K  0B   100%/dev
tmpfs1.8G101M1.7G 6%/tmpfs
zroot2.1T136K2.1T 0%/ZROOT
zroot/tmp2.1T553M2.1T 0%/tmp
zroot/usr2.1T2.5G2.1T 0%/usr
zroot/usr/local  2.4T320G2.1T13%/usr/local
zroot/usr/obj2.1T3.8G2.1T 0%/usr/obj
zroot/usr/ports  2.1T1.1G2.1T 0%/usr/ports
zroot/usr/ports/distfiles2.1T489M2.1T 0%
/usr/ports/distfiles
zroot/usr/ports/packages 2.1T7.0M2.1T 0%
/usr/ports/packages
zroot/usr/src2.1T3.6G2.1T 0%/usr/src
zroot/var2.1T571M2.1T 0%/var
zroot/var/crash  2.1T148K2.1T 0%/var/crash
zroot/var/db 2.1T3.9G2.1T 0%/var/db
zroot/var/db/pkg 2.1T 66M2.1T 0%/var/db/pkg
zroot/var/empty  2.1T144K2.1T 0%/var/empty
zroot/var/log2.1T951M2.1T 0%/var/log
zroot/var/mail   2.1T148K2.1T 0%/var/mail
zroot/var/run2.1T428K2.1T 0%/var/run
zroot/var/tmp2.1T908K2.1T 0%/var/tmp
zroot/www2.1T192K2.1T 0%/www
zroot/www/dev0   2.1T1.4G2.1T 0%/www/dev0
zroot/www/dev1   2.1T1.4G2.1T 0%/www/dev1
zroot/www/dev2   2.1T1.4G2.1T 0%/www/dev2
zroot/www/dev3   2.1T1.4G2.1T 0%/www/dev3
zroot/www/dev4   2.1T1.4G2.1T 0%/www/dev4
zroot/www/komandirovka   2.9T812G2.1T27%
/www/komandirovka
zroot/var/spool  2.1T 17G2.1T 1%/var/spool
zroot/poudriere  2.1T128K2.1T 0%/ZROOT/poudriere
zroot/poudriere/data 2.1T195M2.1T 0%/poudriere/data
zroot/poudriere/jails2.1T128K2.1T 0%
/ZROOT/poudriere/jails
zroot/poudriere/jails/10amd642.1T820M2.1T 0%
/poudriere/jails/10amd64
zroot/poudriere/ports2.1T 96K2.1T 0%
/ZROOT/poudriere/ports
zroot/poudriere/ports/default2.1T1.2G2.1T 0%
/poudriere/ports/default
DB   844G 96K844G 0%/DB
DB/var   844G 96K844G 0%/DB/var
DB/var/db844G 96K844G 0%/DB/var/db
DB/var/db/mysql  899G 55G844G 6%/var/db/mysql
DB/var/db/mysql/MyISAM   844G 96K844G 0%
/var/db/mysql/MyISAM
DB/var/db/mysql/innodb-logs  844G128M844G 0%
/var/db/mysql/innodb-logs

c1426.colo.hc.ru ipfw denied packets:
+++ /tmp/security.Rs1jCTcl  2015-10-15 13:39:47.696736237 +0300
+00200   3067081 183759716 deny tcp from table(101) to me dst-port 80
+65535   7555652 769351039 deny ip from any to any

c1426.colo.hc.ru login failures:
Oct 14 00:05:31 c1426 sshd[33110]: Invalid user admin from 62.210.7.49
Oct 14 00:05:31 c1426 sshd[33110]: input_userauth_request: invalid user admin 
[preauth]
Oct 14 00:05:32 c1426 sshd[33110]: Postponed keyboard-interactive for invalid 
user admin from 62.210.7.49 port 60517 ssh2 [preauth]
Oct 14 00:05:32 c1426 sshd[33110]: error: PAM: authentication error for illegal 
user admin from 62-210-7-49.ggsmarket.net
Oct 14 00:05:32 c1426 sshd[33110]: Failed keyboard-interactive/pam for invalid 
user admin from 62.210.7.49 port 60517 ssh2
Oct 14 01:16:55 c1426 sshd[52685]: reverse mapping checking getaddrinfo for 
62-210-27-92.rev.poneytelecom.eu [62.210.27.92] failed - POSSIBLE BREAK-IN 
ATTEMPT!
Oct 

Re: [freebsd] sendmail + roundcube

[Slawa Olhovchenkov]

On Fri, Oct 16, 2015 at 03:49:28PM +0300, Valentin Nechayev wrote:

>  Fri, Oct 16, 2015 at 15:13:27, slw wrote about "Re: [freebsd] sendmail + 
> roundcube": 
> 
> > > > ...Научить настороженно относиться к опыту бывалых людей, потому
> > > > что жизнь меняется необычайно быстро...
> > > 
> > > ...и появляются новые MTA ;-).
> > 
> > школота, считающая, что она познала дао, недоступное динозаврам -- это
> > прикольно!
> > exim -- это примерно 1998 год
> > postfix -- тоже 1998 год.
> > очень новые, ога.
> 
> sendmail - 1979 (вместе с delivermail)
> zmailer - 1988
> smail - ? (но не раньше 1990)
> qmail - 1995
> 
> да, новые. Заметь, после них массового развития темы MTA уже не было.

ага, по 17 лет каждому.
я не удивлюсь если в рассылке есть подписчики младше возрастом.

> Даже CGP ровесник этих двух с точностью до пятилетки.
> То есть сидеть на первом поколении до сих пор реально.

остался только sendmail и CGP
остальные -- либо неживые либо исходно были ошибками.

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

hi,

 Fri, Oct 16, 2015 at 15:47:46, slw wrote about "Re: [freebsd] sendmail + 
roundcube": 

> > Если про reply-to, то я не хочу новый цикл:)
> 
> только ты за него, остальным он мешает.

Ну я как-то ставил. Или тут, или в uanog, не помню.
Пришлось быстро снять эту спиральку, пошли тонны жалоб типа "я не могу
ответить человеку напрямую". Оказалось, что проблемы от вылетевших в
список всяких ДСП сведений и интимных тайн, которых полны даже
разговоры между участниками технических рассылок - эти проблемы ой как
лупят по людям.
Потому что нажать reply и не посмотреть на то, что получилось в h_To -
это встречается чуть более чем всегда. А виноват, естественно, админ
списка.
Нет уж, пусть лучше ты, Шейко и ещё десяток человек будете ворчать на
дублирование писем, но я буду спокойно спать ночью, не ожидая, что ко
мне придут страшные мстятели :)

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

Я тоже не считаю, но вопрос не в этом, а в том, что выше.

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

У меня давно стоит готовый к применению Mailman.
Проблема в том, что я сдался искать вариант, как без переписки пары
злобных модулей заимпортить в его базу уже существующий архив.
Я-то ему подам на вход что угодно - mailbox, maildir, каждое письмо
отдельным вызовом - пофиг, но там генерация страницы веб-архива
нормально не отделяется.
Это было года 3 назад. С тех пор не пробовал, извините уж.

> > Собственно для логгинга конца обработки письма.
> в отрезанном было же тоже самое, не?

?

> > qmail с человеческим лицом зовётся словом postfix.
> > Мне из qmail только системы алиасов жалко - аналога не дали.
> > Но реально даже плюсанутые localparts используют только нердомамонты.
> qmail вообще неработающее говно -- он по mxам вообще научился ходить?

Ну я бы не на это бил, а на лицензию.
Но если всё равно локально собирать, то он патчился до правильного
состояния.

> > А недостатки JS на таких мелких кусках кода могут не успеть
> > проявиться.
> 
> да ладно, язык-то та еще какашка.
> http://stackoverflow.com/questions/359494/does-it-matter-which-equals-operator-vs-i-use-in-javascript-comparisons

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


-netch-

Re: [freebsd] sendmail + roundcube

[Alexander Sheiko]

В письме от Птн, 16 Окт 2015, 09:52 Eugene Grosbein пишет:

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

Разница есть. Валентин выше аккуратно всё расписал. Но я понимаю, почему
многие уже из немолодого поколения за sendmail держатся. Для того, чтобы с
ним разобраться и использовать в сложных конфигурациях в своё время нужно
было потратить множество сил и времени. И этим людям становится немного
обидно, что всё это сейчас делается проще и гибче. По человечески это всё
можно понять. Главное, чтобы продолжая сидеть на sendmail они не делали
всякого рода детских ошибок в логике работе своих почтовых систем.

Как раз здесь и уместна цитата:

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

...и появляются новые MTA ;-).

-- 
WBR, Alexander Sheiko

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

 Fri, Oct 16, 2015 at 15:13:27, slw wrote about "Re: [freebsd] sendmail + 
roundcube": 

> > > ...Научить настороженно относиться к опыту бывалых людей, потому
> > > что жизнь меняется необычайно быстро...
> > 
> > ...и появляются новые MTA ;-).
> 
> школота, считающая, что она познала дао, недоступное динозаврам -- это
> прикольно!
> exim -- это примерно 1998 год
> postfix -- тоже 1998 год.
> очень новые, ога.

sendmail - 1979 (вместе с delivermail)
zmailer - 1988
smail - ? (но не раньше 1990)
qmail - 1995

да, новые. Заметь, после них массового развития темы MTA уже не было.
Даже CGP ровесник этих двух с точностью до пятилетки.
То есть сидеть на первом поколении до сих пор реально.

> новый -- это dma, но еще недавно у него была целая пачка дестких
> болячек.

Без слушания на порту - не в счёт.


-netch-

Re: [freebsd] sendmail + roundcube

[Slawa Olhovchenkov]

On Fri, Oct 16, 2015 at 02:53:09PM +0300, Alexander Sheiko wrote:

> 
> В письме от Птн, 16 Окт 2015, 09:52 Eugene Grosbein пишет:
> 
> > И в том, и в другом случае достаточно прочесть документацию и следовать
> > ей. Не вижу разницы.
> 
> Разница есть. Валентин выше аккуратно всё расписал. Но я понимаю, почему
> многие уже из немолодого поколения за sendmail держатся. Для того, чтобы с
> ним разобраться и использовать в сложных конфигурациях в своё время нужно
> было потратить множество сил и времени. И этим людям становится немного
> обидно, что всё это сейчас делается проще и гибче. По человечески это всё
> можно понять. Главное, чтобы продолжая сидеть на sendmail они не делали
> всякого рода детских ошибок в логике работе своих почтовых систем.
> 
> Как раз здесь и уместна цитата:
> 
> > ...Научить настороженно относиться к опыту бывалых людей, потому
> > что жизнь меняется необычайно быстро...
> 
> ...и появляются новые MTA ;-).

школота, считающая, что она познала дао, недоступное динозаврам -- это
прикольно!
exim -- это примерно 1998 год
postfix -- тоже 1998 год.
очень новые, ога.

новый -- это dma, но еще недавно у него была целая пачка дестких
болячек.

Re: [freebsd] sendmail + roundcube

[Slawa Olhovchenkov]

On Fri, Oct 16, 2015 at 03:36:42PM +0300, Valentin Nechayev wrote:

> hi,
> 
>  Fri, Oct 16, 2015 at 13:48:23, slw wrote about "Re: [freebsd] sendmail + 
> roundcube": 
> 
> > > В postfix фиксированный набор. В exim значительно гибче набор и штатно
> > > говорят "вам недостаточно => perl в зубы и вперёд". Через него
> > > действительно можно сделать что угодно.
> > а) по дефолту он без перла.
> 
> Только что проверил на портах 2-дневной давности - дефолт таки с
> перлом.

хорошо, посмотрел не туда.

> > > Ну вот где-то потому у меня сейчас postfix только на раздаче рассылок,
> > > включая данную :)
> > 
> > за настройку которой "фе" высказывалось уже наверное десятком
> > участников, но это к постфиксу не относится, как и сама рассылка не
> > является аргументом.
> 
> Если про reply-to, то я не хочу новый цикл:)

только ты за него, остальным он мешает.

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

> Если про свойства самого majordomo, то они, кажется, мешают только
> мне.

не только. архива-то нет, к примеру.
а к mm доступный с веба архив идет бесплатным довеском.

> > > > > Кто будет возражать - прошу вначале прочитать и понять логику таких
> > > > > замечательных функций, как getrequests(), sendall(), dropenvelope(),
> > > > > описать её словами. Продолжить содержимым файла queue.c, разобрать
> > > > > тёмные моменты логики.
> > > > 
> > > > я разбирался, ничего, жив остался.
> > > 
> > > Ты такой же мамонт, как и я :) рекомендовать такое широкому кругу я не
> > > могу. Жалко птичек.
> > 
> > c 1995 года и не требовалось.
> 
> Ну вспомнил. В 95-м патчили в системах всё, что можно, иначе работать
> было нельзя. Но и код всех уровней тогда был проще репы.

ну когда лазал тогда и вспомнил.

> > > Oct 16 13:30:32 segfault sm-mta[53431]: tAGAUVgE053430: done; 
> > > delay=00:00:01, ntries=1
> > > 
> > > они появляются только с 11-го уровня, хотя для понимания происходящего
> > > они важнее раскрытия алиасов (10-й уровень).
> > 
> > зачем? (не испытывал нужды)
> 
> Собственно для логгинга конца обработки письма.

в отрезанном было же тоже самое, не?

> > > 
> > > Лучше таки exim :) или вообще что-то за пределами этой тройки.
> > 
> > qmail. ога.
> 
> qmail с человеческим лицом зовётся словом postfix.
> Мне из qmail только системы алиасов жалко - аналога не дали.
> Но реально даже плюсанутые localparts используют только нердомамонты.

qmail вообще неработающее говно -- он по mxам вообще научился ходить?

> > > По нынешним временам лучше бы lua или elisp привинтили.
> > > Хотя я когда-то perl map к нему строил (патч тривиальный, можно
> > > актуализировать).
> > 
> > по нынешним временам в тренде хаскель.
> > ну или скала.
> > а, нода!
> 
> Ну, можно и так. V8 с его тщательно вылизанным JIT местами бьёт даже
> C.

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

> А недостатки JS на таких мелких кусках кода могут не успеть
> проявиться.

да ладно, язык-то та еще какашка.
http://stackoverflow.com/questions/359494/does-it-matter-which-equals-operator-vs-i-use-in-javascript-comparisons

Re: [freebsd] sendmail + roundcube

[Slawa Olhovchenkov]

On Fri, Oct 16, 2015 at 04:01:23PM +0300, Valentin Nechayev wrote:

> hi,
> 
>  Fri, Oct 16, 2015 at 15:47:46, slw wrote about "Re: [freebsd] sendmail + 
> roundcube": 
> 
> > > Если про reply-to, то я не хочу новый цикл:)
> > 
> > только ты за него, остальным он мешает.
> 
> Ну я как-то ставил. Или тут, или в uanog, не помню.
> Пришлось быстро снять эту спиральку, пошли тонны жалоб типа "я не могу
> ответить человеку напрямую". Оказалось, что проблемы от вылетевших в
> список всяких ДСП сведений и интимных тайн, которых полны даже
> разговоры между участниками технических рассылок - эти проблемы ой как
> лупят по людям.
> Потому что нажать reply и не посмотреть на то, что получилось в h_To -
> это встречается чуть более чем всегда. А виноват, естественно, админ
> списка.
> Нет уж, пусть лучше ты, Шейко и ещё десяток человек будете ворчать на
> дублирование писем, но я буду спокойно спать ночью, не ожидая, что ко
> мне придут страшные мстятели :)

вот-вот, нажал reply и вместо списка улетело в личку.
если такое прилетает мне -- я игнорирую.
потому что "публично я самовыражаюсь, а в личной почте --
консультации, которые должны быть оплачены по прайсу" (с) не помню
кто.

ответ лично -- скопируй адрес и отвечай, что за проблема?

смысл текущая настройка имеет для листов с одновременно выполняющимися
двумя условиями:

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

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

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

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

когда-то ты агрументировал тем, что replay-to неслед менять.

> > > Если про свойства самого majordomo, то они, кажется, мешают только
> > > мне.
> > 
> > не только. архива-то нет, к примеру.
> > а к mm доступный с веба архив идет бесплатным довеском.
> 
> У меня давно стоит готовый к применению Mailman.
> Проблема в том, что я сдался искать вариант, как без переписки пары
> злобных модулей заимпортить в его базу уже существующий архив.
> Я-то ему подам на вход что угодно - mailbox, maildir, каждое письмо
> отдельным вызовом - пофиг, но там генерация страницы веб-архива
> нормально не отделяется.
> Это было года 3 назад. С тех пор не пробовал, извините уж.

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

> > > Собственно для логгинга конца обработки письма.
> > в отрезанном было же тоже самое, не?
> 
> ?

ну вот как мне без архива сослаться-показать? я не храню письма в этот
лист.

Re: [freebsd] sendmail + roundcube

[Oleg V. Nauman]

On Friday 16 October 2015 09:39:59 Valentin Nechayev wrote:
>  Thu, Oct 15, 2015 at 23:31:21, oleg wrote about "Re: [freebsd] sendmail + 
roundcube":
> > > После освоения и многолетней работы с Exim, возвращаться к sendmail нет
> > > никакого желания,   кроме  самых простых случаев. Ибо с Exim все, чуть
> > > более, чем простые вещи, делаются намного удобней и гибче, прямо из
> > > коробки.
> >  
> >  Надеюсь Exim из коробки может переписать envelope from на основании
> >  значений> 
> > переменных окружения. Будете хостить веб сервисы для 2+ виртуальных
> > доменов - появится задача.
> 
> Пафос я оценил. return_path в транспорте пробовал?

 Да, была реализация с return_path и внешней подпоркой.

Re: [freebsd] sendmail + roundcube

[Alexander Sheiko]

В письме от Птн, 16 Окт 2015, 15:13 Slawa Olhovchenkov пишет:

> школота, считающая, что она познала дао, недоступное динозаврам -- это
> прикольно!

Молодой человек - если Вы имеете в виду меня, то мне почти 45, а с
sendmail  я имею историю отношений где-то с 97 года.

В рунете Exim получил распространение значительно позднее и перешёл я на
него где-то во второй половине 2000-х.

Прикольно, да :).

-- 
WBR, Alexander Sheiko

Re: [freebsd] sendmail + roundcube

[Alexander Sheiko]

В письме от Птн, 16 Окт 2015, 16:25 Slawa Olhovchenkov пишет:

> школота -- это не всегда возраст.

Хамство при общении с людьми вообще не связано с возрастом.

-- 
WBR, Alexander Sheiko

Re: [freebsd] sendmail + roundcube

[Eugene Grosbein]

On 16.10.2015 19:29, Valentin Nechayev wrote:
> hi,
> 
>  Fri, Oct 16, 2015 at 17:53:25, eugen wrote about "Re: [freebsd] sendmail + 
> roundcube": 
> 
>> Не вижу противоречия. В стандартные конфигурации и опции sendmail
>> вкладывается огромное количество разных задач и для них он не сложен
>> и не неудобен. А для специфических задач и sendmail, и postfix, и exim
>> надо настраивать.
> 
> Противоречие именно в том, что просто быть листовым релеем для 1-2
> собственных доменов это совершенно стандартная и тривиальная задача,
> но в стандартной конфигурации sendmail её не выполняет.

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

Re: [freebsd] sendmail + roundcube

[Sergey V. Dyatko]

On Fri, 16 Oct 2015 15:50:39 +0300
Slawa Olhovchenkov  wrote: 

> On Fri, Oct 16, 2015 at 03:37:57PM +0300, Valentin Nechayev wrote:
> 
> >  Fri, Oct 16, 2015 at 15:29:48, slw wrote about "Re: [freebsd] sendmail +
> > roundcube": 
> > 
> > > > А ведь для 95% линуксово-фрибздишных тазиков вместо sendmail'ов
> > > > достаточно было бы комбинации логин+пароль+сервер для условного gmail,
> > > > чтобы отправлять кроновые отчёты на него, не заботясь о всяких
> > > > FEATURE(masquerade_envelope).
> > > 
> > > да пихали бы сразу в какое гноилище, кто их эти отчеты вообще читает?
> > > настроили фильтрацию в папку и никогда не смотрят.
> > 
> > Я читаю. Сюрприз:)
> > Хотя бы чтобы знать, когда дырявые пакеты апгрейдить.
> > А ещё там многие проблемы видны до перехода в фаталити.
> 
> я бы предпочел что бы за меня их читал скрипт.
> потому что смысла тратить свое время на чтение нижеследующего я не вижу:
> 
> Disk status:
[skipped]

можно переместиться сразу на конец данного письма и прочесть нужное. mutt, я
уверен, умеет такое.


--
wbr, tiger

Re: [freebsd] sendmail + roundcube

[Slawa Olhovchenkov]

On Fri, Oct 16, 2015 at 04:21:18PM +0300, Alexander Sheiko wrote:

> 
> В письме от Птн, 16 Окт 2015, 15:13 Slawa Olhovchenkov пишет:
> 
> > школота, считающая, что она познала дао, недоступное динозаврам -- это
> > прикольно!
> 
> Молодой человек - если Вы имеете в виду меня, то мне почти 45, а с
> sendmail  я имею историю отношений где-то с 97 года.

школота -- это не всегда возраст.

> В рунете Exim получил распространение значительно позднее и перешёл я на
> него где-то во второй половине 2000-х.
> 
> Прикольно, да :).

срачи exim/postfix/sendmail/qmail начались еще в прошлом тысячелетии и
я их помню.

вот только не помню, когда там exim научился DSN?

Re: [freebsd] sendmail + roundcube

[Slawa Olhovchenkov]

On Fri, Oct 16, 2015 at 04:31:47PM +0300, Alexander Sheiko wrote:

> 
> В письме от Птн, 16 Окт 2015, 16:25 Slawa Olhovchenkov пишет:
> 
> > школота -- это не всегда возраст.
> 
> Хамство при общении с людьми вообще не связано с возрастом.

ага

Re: [freebsd] sendmail + roundcube

[Eugene Grosbein]

On 16.10.2015 21:44, Sergey V. Dyatko wrote:

> Это, конечно, круто, но пример с jira не удачен чуть более чем полностью.
> Севшая батарейка телефона при минимуме полезной инфы в смс в случае 
> более-менее
> активной jira.

Конкретно с jira пример сугубо из практики. В SMS информация такого типа:

Вам задача из раздела Работы системного администратора No SYSADMIN-5959:
Проверить работу сканера штрих-кодов в маг93.
http://192.168.1.50:8092/browse/SYSADMIN-5959

А с чего бы батарейке сесть?

Re: [freebsd] sendmail + roundcube

[Eugene Grosbein]

On 16.10.2015 21:44, Sergey V. Dyatko wrote:

> Это, конечно, круто, но пример с jira не удачен чуть более чем полностью.
> Севшая батарейка телефона при минимуме полезной инфы в смс в случае 
> более-менее
> активной jira.

Конкретно с jira пример сугубо из практики. В SMS информация такого типа:

Вам задача из раздела Работы системного администратора No SYSADMIN-5959:
Проверить работу сканера штрих-кодов в маг93.
http://192.168.1.50:8092/browse/SYSADMIN-5959

А с чего бы батарейке сесть?

Re: [freebsd] sendmail + roundcube

[Sergey V. Dyatko]

On Fri, 16 Oct 2015 22:14:33 +0700
Eugene Grosbein  wrote: 

> On 16.10.2015 21:44, Sergey V. Dyatko wrote:
> 
> > Это, конечно, круто, но пример с jira не удачен чуть более чем полностью.
> > Севшая батарейка телефона при минимуме полезной инфы в смс в случае
> > более-менее активной jira.
> 
> Конкретно с jira пример сугубо из практики. В SMS информация такого типа:
> 
> Вам задача из раздела Работы системного администратора No SYSADMIN-5959:
> Проверить работу сканера штрих-кодов в маг93.
> http://192.168.1.50:8092/browse/SYSADMIN-5959
> 
> А с чего бы батарейке сесть?
> 
> 
как часто тебе jira вообще что-либо пишет? мне по 50+ писем в день, и это при
том, что сейчас на нее дико подзабили и "таски" обычно скайпом "заводят".

 p.s. ты специально свой тандерберд
настроить нормально не можешь или тебе нравится по несколько одинаковых писем
слать в рассылку (внимательным товарищам: я видел и тогда, что там from
разный, как минимум)?


--
wbr, tiger

Re: [freebsd] sendmail + roundcube

[Eugene Grosbein]

On 16.10.2015 22:18, Sergey V. Dyatko wrote:

> как часто тебе jira вообще что-либо пишет? мне по 50+ писем в день, и это при
> том, что сейчас на нее дико подзабили и "таски" обычно скайпом "заводят".

Мне она вообще не пишет, мопед не мой, я его только налаживал.

>  p.s. ты специально свой тандерберд
> настроить нормально не можешь или тебе нравится по несколько одинаковых писем
> слать в рассылку (внимательным товарищам: я видел и тогда, что там from
> разный, как минимум)?

Это у меня руки кривые просто, ещё раз прошу прощения.

Re: [freebsd] sendmail + roundcube

[Sergey V. Dyatko]

On Fri, 16 Oct 2015 21:30:33 +0700
Eugene Grosbein  wrote: 

> On 16.10.2015 20:01, Valentin Nechayev wrote:
> 
> >>> Но реально даже плюсанутые localparts используют только нердомамонты.
> 
> Просто потому что тупо не знают о возможностях MTA, схемах адресации
> и вообще читать документацию немодно.
> 
> Откуда им знать, что в sendmail, для того чтобы, скажем, прикрутить
> IM-рассылку к уведомлениям из JIRA в дополнение к почтовым уведомлениям,
> есть готовая схема адресации вида username+79876543...@domain.org?
> 
> При которой полное уведомление доставляется по адресу usern...@domain.org,
> а заголовок письма уходит по SMS или через какой-нибудь Instant messaging,
> и что для этого достаточно прописать три строчки в .mc, указав путь к команде
> отправки SMS или IM и шаблон для её аргументов и затем рулить просто записями
> в virtusertable, выбирая, которые домены/субдомены/отдельные ящики
> обрабатывать по такой схеме.
> 
> А ведь всё это документировано в Sendmail Installation and Operation Guide,
> что идёт в дистрибутиве.
> 

Это, конечно, круто, но пример с jira не удачен чуть более чем полностью.
Севшая батарейка телефона при минимуме полезной инфы в смс в случае более-менее
активной jira.
Единственный полезный вар-т использования этой фичи который я смог придумать -
сообщения от мониторинга, но почему-то лично я вполне обхожусь +1 письмом
на номер@оператор-email2.sms, тест ровно тот же что и в почте.


--
wbr, tiger

Re: [freebsd] sendmail + roundcube

[Eugene Grosbein]

On 16.10.2015 18:53, Alexander Sheiko wrote:
> 
> В письме от Птн, 16 Окт 2015, 09:52 Eugene Grosbein пишет:
> 
>> И в том, и в другом случае достаточно прочесть документацию и следовать
>> ей. Не вижу разницы.
> 
> Разница есть. Валентин выше аккуратно всё расписал. Но я понимаю, почему
> многие уже из немолодого поколения за sendmail держатся. Для того, чтобы с
> ним разобраться и использовать в сложных конфигурациях в своё время нужно
> было потратить множество сил и времени.

Как и с любым другим MTA.

> И этим людям становится немного
> обидно, что всё это сейчас делается проще и гибче.

Причем тут "обидно"? Я слова не сказал против альтернатив, пользуйтесь,
ради бога. Я говорю о том, что большинство задач в альтернативах
решаются не гибче и не проще, чем в sendmail и везде нужно матчасть изучать.

Re: [freebsd] sendmail + roundcube

[Eugene Grosbein]

On 16.10.2015 20:01, Valentin Nechayev wrote:

>>> Но реально даже плюсанутые localparts используют только нердомамонты.

Просто потому что тупо не знают о возможностях MTA, схемах адресации
и вообще читать документацию немодно.

Откуда им знать, что в sendmail, для того чтобы, скажем, прикрутить
IM-рассылку к уведомлениям из JIRA в дополнение к почтовым уведомлениям,
есть готовая схема адресации вида username+79876543...@domain.org?

При которой полное уведомление доставляется по адресу usern...@domain.org,
а заголовок письма уходит по SMS или через какой-нибудь Instant messaging,
и что для этого достаточно прописать три строчки в .mc, указав путь к команде
отправки SMS или IM и шаблон для её аргументов и затем рулить просто записями
в virtusertable, выбирая, которые домены/субдомены/отдельные ящики обрабатывать
по такой схеме.

А ведь всё это документировано в Sendmail Installation and Operation Guide,
что идёт в дистрибутиве.

Re: [freebsd] sendmail + roundcube

[Oleksandr V. Typlyns'kyi]

Yesterday Oct 16, 2015 at 13:13 Slawa Olhovchenkov wrote:

> да, в sendmail REFAL. но в остальных нет ничего. т.е. можно только
> выбрать набор каких-то фиксированых проверок и их порядок. если надо
> что-то нестандартное -- патчи сырцы!

> postfix/exim в последнее время по фичам несколько подтянулись
> (научились наконец DSN без патчей!), но у всех трех с SRS не очень
> хорошо.
> 
> в плюсы postfix/exim можно записать sender email verify из коробки --
> к sendmail нужно через milter крутить.

 Но сам milter - это хороший механизм.
 Когда он появился в postfix, то качественно улучшил ситуацию в работе с 
 антивирусами и прочими внешними фильтрами.

> в минусы же postfix -- логи хуже sendmailовских. ну и вообще, общую
> переусложненность postfix:
> 
> postfix  48387 51021 51021 510210 I -   0:00.02 pickup -l -t fifo 
> -u
> root 51021 1 51021 510210 Ss-   0:18.19 
> /usr/local/libexec/postfix/master -w
> postfix  51023 51021 51021 510210 I -   0:14.45 qmgr -l -t fifo -u
> postfix  51218 51021 51021 510210 S -   0:00.02 smtpd -n smtp -t 
> inet -u -o stress=
> postfix  51219 51021 51021 510210 S -   0:00.01 anvil -l -t unix 
> -u
> postfix  52607 51021 51021 510210 S -   0:00.01 trivial-rewrite 
> -n rewrite -t unix -u
> postfix  52677 51021 51021 510210 I -   0:00.01 cleanup -z -t 
> unix -u
> postfix  52680 51021 51021 510210 I -   0:00.01 smtp -t unix -u
> postfix  52682 51021 51021 510210 I -   0:00.01 smtp -t unix -u
> postfix  52684 51021 51021 510210 I -   0:00.01 pipe -n dovecot 
> -t unix flags=DRhu user=mailnull:mailnull 
> argv=/usr/local/libexec/dovecot/deliver -d ${recipient}
> postfix  52709 51021 51021 510210 S -   0:00.02 smtpd -n smtp -t 
> inet -u -o stress=
> postfix  52793 51021 51021 510210 I -   0:00.01 smtp -t unix -u
> postfix  52795 51021 51021 510210 I -   0:00.01 smtp -t unix -u
> 
> куча каких-то демонов, как-то перадающих задание друг другу,
> сквозной queue-id заводится достаточно поздно и если отлуп происходит до
> его заведения (из-за rDNS у отправителя или еще по каким подобным причинам)
> то при большом потоке почты искать причину можно до морковкиного заговения.
> 
> да, я в курсе, что postfix писался для того что бы управлять рассылками на 
> пень-100.
> только те, кому такое (смасштабированное) нужно сейчас -- об этом спрашивать 
> не будут.

  Это из коробки то разделение, без которого sendmail от большой очереди 
нехорошо :)
  И это "как-то перадающих задание" позволяет относительно просто делать 
  самый изощренный роутинг, когда следующие в цепочке могут быть запущены 
  с разными параметрами.

-- 
WNGS-RIPE

Re: [freebsd] sendmail + roundcube

[Valentin Nechayev]

 Sat, Oct 17, 2015 at 01:05:23, eugen wrote about "Re: [freebsd] sendmail + 
roundcube": 

> > И в пятый раз повторю, что это не под атакой, а в нормальных условиях,
> > но неравномерном потоке.
> > Когда лёгкий зашкал за верхнюю границу выдерживаемого приводит к
> > сверхлинейному торможению, в то время как любая нормально
> > спроектированная система должна иметь линейную или сублинейную
> > характеристику затрат ресурсов в зависимости от объёма обрабатываемых
> > сущностей.
> 
> При "легкой" нагрузке проблем нет, проблемы появляются только когда
> нагрузка существенно превышает уровень, который можно назвать "легким".

Никакой "лёгкой нагрузки" НЕ СУЩЕСТВУЕТ. Это слова, которые
использовать НЕЛЬЗЯ. На любую "лёгкую нагрузку" найдётся недостаток
ресурсов.
Система или устойчива, не позволяя себя завести в тупик, или
неустойчива. Всё остальное - трёп в пользу бедных.

> Я именно на Pentium-120 обслуживал нагруженный релей во время оно
> и многотысячные очереди разгребать приходилось, да. Они возникали
> только при флуде, а пока флуда нет - очередь жила нормальной жизнью
> и всё доставлялось во время даже без тонких настроек.

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


-netch-