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 года
> его использования в продакшене и десятков патчей на разные темы) ты
> опровергать не будешь?
Почему нет? Отсылка к авторитету - плохой аргумент.
<quote>Научить не кланяться авторитетам, а исследовать их и сравнивать их
поучения
с жизнью. Научить настороженно относиться к опыту бывалых людей, потому что
жизнь меняется необычайно быстро.</quote>
> Так вот - я категорически подтверждаю слова
> cirtin@: sendmail неудобен и сложен - по крайней мере для всего, что
> выходит за рамки простой стратегии "накидать опций по ману в
> ${hostname}.mc и вызвать make",
"накидать опций по руководству и вызвать make" полностью покрывает
как задачу из топика, так и абсолютное большинство остальных почтовых задач,
о highload речь не идёт, дешевые VPS не используют под highload.
> По пунктам:
>
> 1. Основным средством конфигурации является "язык переписывания" на
> основе идей REFAL. Это само по себе не было бы настолько тяжёлой
> проблемой, если бы этот язык не пытались впихнуть вообще всюду,
> включая места, где такое не нужно или неудобно.
> В частности, тот же язык используется после уже давно состоявшейся
> канонизации форм адресов для проверки релеинга. Я понимаю, что авторам
> было лениво вводить ещё сущностей, и они тупо отдали тему на откуп
> сообществу - мол, напишите нам реализацию, а мы её включим.
Даже знать от существовании REFAL или о его названии не требуется
для решения типовых задач вроде топика. Есть .mc и опции в нём,
в крайнем случае - готовые, хотя и не входящие в дистрибутив сторонние
дополнения к конфигам и в исключительных случаях LOCAL_CONFIG
опять же с готовыми строчками из руководства, изучения REFAL не требующие.
> 2. Но даже для работы с адресами этот код, за редкими исключениями,
> не нужен. Да, есть всякие чрезмерно грамматичные адреса RFC822 (луч
> пламенного привета IETF), но практически формата localpart@domain
> хватает для 99.9999% случаев. На переходники с 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 - и только в таком виде
> удавалось получить устойчивую конфигурацию. Об этом я писал где только
> можно и жаловался авторам, но ответа не было - в лучшем случае "вы же
> придумали, как это правильно делать, вот и радуйтесь себе в тряпочку".
>
> Это только малая часть того, что стоит ругать - но не хочу сейчас
> тратить много времени.
Это всё о highload, который совершенно отдельная тема.
